c't-Lab

psclab38 hat geschrieben:Bevor Du eincheckst, synchronisiere Dich bitte mit Thoralt, den haben wir ja auch erst wieder aktiviert und wir sollten seinen Kreativitätschub positiv unterstützen . Das TODO muß dann halt auch noch irgendwie verarztet werden.

dg1vs hat geschrieben:Eine Sache habe ich noch offen, Macros für "Char" in sprintf oder ähnlichen Funktionen. Hat jemand einen guten Link zu dem Thema. Es geht um die "Sonderzeichen" die sich in Abhängigkeit vom benutzten Display unterscheiden. Und da sind wir auch bei den 2 Symbolen, wo eine Macroersetzung extrem hilfreich wäre. Auf die Schnelle ist mir nichts eingefallen.

#define SONDERZEICHEN "\x05"
//#define SONDERZEICHEN "\x06"
//#define SONDERZEICHEN "\x07"
LCDOverwrite_P(... PSTR("Text" SONDERZEICHEN "Text");

psclab38 hat geschrieben:Hi Karsten,

dg1vs hat geschrieben:Eine Sache habe ich noch offen, Macros für "Char" in sprintf oder ähnlichen Funktionen. Hat jemand einen guten Link zu dem Thema. Es geht um die "Sonderzeichen" die sich in Abhängigkeit vom benutzten Display unterscheiden. Und da sind wir auch bei den 2 Symbolen, wo eine Macroersetzung extrem hilfreich wäre. Auf die Schnelle ist mir nichts eingefallen.

Diese Frage ist mir beim Review auch gekommen. Schade, daß man im String die #define-Konstanten nicht direkt einsetzen kann, zumindest wäre mir diese Möglichkeit noch nicht untergekommen.

psclab38 hat geschrieben: Ich überleg mal grad so: Du hast ja die RAM-Zeichen des Displays für Deine Zwecke umdefiniert, aber eines (das erste) ist ja komplett leer. Und ein Leerzeichen gibt's aber schon im ROM des Displays; könnte man da nicht noch an die entsprechende Stelle bei 0x05 den Pfeil reinquetschen... und es wäre für beide Optionen zumindest hier gleich. Is' nur so eine Idee. Eine elegante Lösung für alle Optionen ist aber wohl nicht drin.

thoralt hat geschrieben:Hallo Leute,

psclab38 hat geschrieben:Bevor Du eincheckst, synchronisiere Dich bitte mit Thoralt, den haben wir ja auch erst wieder aktiviert und wir sollten seinen Kreativitätschub positiv unterstützen . Das TODO muß dann halt auch noch irgendwie verarztet werden.

Nun, ich habe derzeit kleine Änderungen in dds.h, dds-hw.h, main.c, timer.c sowie timer.h. Diese werden hoffentlich automatisch vom CVS gemerged. Größere Änderungen fanden bisher in dds-hw.c, panel.c und panel.h statt. Ich habe kein Problem damit, wenn Karsten erstmal eincheckt. Ich mache ein Backup von meinen Quellen und dann mal ein Update, mal sehen, was passiert. Die paar Kontrollen auf Konflikte an den für mich wichtigen Stellen habe ich dann schnell gemacht. Also, nur zu!

dg1vs hat geschrieben:Eine Sache habe ich noch offen, Macros für "Char" in sprintf oder ähnlichen Funktionen. Hat jemand einen guten Link zu dem Thema. Es geht um die "Sonderzeichen" die sich in Abhängigkeit vom benutzten Display unterscheiden. Und da sind wir auch bei den 2 Symbolen, wo eine Macroersetzung extrem hilfreich wäre. Auf die Schnelle ist mir nichts eingefallen.

Ich weiß nicht, ob ich das Problem richtig verstanden habe, aber wie wäre es mit einem Konstrukt wie folgendem:

Code: Alles auswählen

#define SONDERZEICHEN "\x05"
//#define SONDERZEICHEN "\x06"
//#define SONDERZEICHEN "\x07"
LCDOverwrite_P(... PSTR("Text" SONDERZEICHEN "Text");

Da kann man dann SONDERZEICHEN auf den passenden Wert definieren und das wird dann im String weiter unten mit eingebaut.

Viele Grüße
Thoralt

dg1vs hat geschrieben:ich habe die Sachen in CVS eingecheckt. Diese Woche komme ich eh zu nichts mehr. Ich habe meine TODO's in der Liste fixiert und werde mich am nächsten Wochenende wieder intensiv dem Thema widmen.

psclab38 hat geschrieben: PS: ich hatte mir angewöhnt, das Changelog.txt bei Uploads zu pflegen; da behält man die Übersicht.

dg1vs hat geschrieben: Eigentlich müßte man die Sammlung an Änderungen taggen/labeln und das neue Label beschreiben. Dazu kenne ich mich mit CVS nicht mehr wirklich gut aus, ...

dg1vs hat geschrieben: Ich versuche ja "Enter" und "Back" mit getrennten Symbolen anzuzeigen. Dazu muss an den passenden Stellen ein Aufruf erfolgen. OK, das ist "fast" einfach.
Schwierig ist es in der aktuellen Umsetzung zu unterscheiden, ob es "Enter" oder "Back" ist, da nur auf
if(null!=(void*)pgm_read_word(&g_currentMenuItem->pSubmenu))
geprüft wird. Und da habe ich dann gepfuscht.... und es irgendwie probiert. Deswegen die Unterschiede zwischen Wunsch und CVS-Stand.

psclab38 hat geschrieben:

dg1vs hat geschrieben: Ich versuche ja "Enter" und "Back" mit getrennten Symbolen anzuzeigen. Dazu muss an den passenden Stellen ein Aufruf erfolgen. OK, das ist "fast" einfach.
Schwierig ist es in der aktuellen Umsetzung zu unterscheiden, ob es "Enter" oder "Back" ist, da nur auf
if(null!=(void*)pgm_read_word(&g_currentMenuItem->pSubmenu))
geprüft wird. Und da habe ich dann gepfuscht.... und es irgendwie probiert. Deswegen die Unterschiede zwischen Wunsch und CVS-Stand.

Nur so 'ne Idee: die Menüebene mitzählen, in einer static-Variable. Wenn wir uns auch weiterhin auf eine Untermenüebene beschränken, dann wäre es einfach: wenn (Untermenü && Enter) dann Back. Wenn (Hauptmenü && Enter) dann Untermenü.

psclab38 hat geschrieben: Übrigens noch so als Hinweis: es schließen sich Burst- und Sweepmodus gegenseitig aus. Ich glaube mich zu erinnern, daß der Sweep den Burstmodus implizit abschaltet; ich hab das aber jetzt nicht kontrolliert.

#define PANEL_STR_SWEEP_UP 			"Up"
#define PANEL_STR_SWEEP_DOWN 			"Down"
#define PANEL_STR_SWEEP_UPDOWN 		"Up+Down"

#define PANEL_MENU_STR_FREQUENCY		"Frequency"

menu_entry_t PROGMEM MenuFrequency = {
		.cName = PANEL_MENU_STR_FREQUENCY,
		.pEncoderFunction = FrequencyEncoderFunction,
		.pEnterFunction = FrequencyEnterFunction,
		.pUpdateDisplayFunction = FrequencyUpdateDisplayFunction,
		.pSubmenu = null,
		.pPrevious = (void*)&MenuSettings,
		.pNext = (void*)&MenuLevel,
		.iEI1 = 250, .iEI2 = 50, .iEI3 = 10, .iEI4 = 1,
		.pParam = &(Params.dFrequency), .ucIdentifier = MENU_FREQUENCY};

void SweepSlopeUpdateDisplayFunction(uint8_t ucForceUpdate,
		void *pParam __attribute__((unused)))
{
	if((LastParams.ucSweepSlope!=Params.ucSweepSlope)||ucForceUpdate)
	{
		// display new setting
		switch(Params.ucSweepSlope)
		{
			case SWEEP_UP:
				LCDOverwrite_P((SPALTEN_MAX + 1 - sizeof(PANEL_STR_SWEEP_UP)), DISPLAY_LINE_1, (sizeof(PANEL_STR_SWEEP_UP)-1), PSTR(PANEL_STR_SWEEP_UP));
				break;
			case SWEEP_DOWN:
				LCDOverwrite_P((SPALTEN_MAX + 1 - sizeof(PANEL_STR_SWEEP_DOWN)), DISPLAY_LINE_1, (sizeof(PANEL_STR_SWEEP_DOWN)-1), PSTR(PANEL_STR_SWEEP_DOWN));
				break;
			case SWEEP_UPDOWN:
				LCDOverwrite_P((SPALTEN_MAX + 1 - sizeof(PANEL_STR_SWEEP_UPDOWN)), DISPLAY_LINE_1, (sizeof(PANEL_STR_SWEEP_UPDOWN)-1), PSTR(PANEL_STR_SWEEP_UPDOWN));
				break;
		}
	}
}

dg1vs hat geschrieben:

psclab38 hat geschrieben: Übrigens noch so als Hinweis: es schließen sich Burst- und Sweepmodus gegenseitig aus. Ich glaube mich zu erinnern, daß der Sweep den Burstmodus implizit abschaltet; ich hab das aber jetzt nicht kontrolliert.

Ich habe den Code jetzt nicht kontrolliert, aber ich kann gleichzeitig Burst- und Sweepmodus anschalten.

dg1vs hat geschrieben:Jetzt noch ne Idee:
Was haltet Ihr von folgendem Vorgehen:
...

Code: Alles auswählen

void SweepSlopeUpdateDisplayFunction(uint8_t ucForceUpdate,
		void *pParam __attribute__((unused)))
{
	if((LastParams.ucSweepSlope!=Params.ucSweepSlope)||ucForceUpdate)
	{
		// display new setting
		switch(Params.ucSweepSlope)
		{
			case SWEEP_UP:
				LCDOverwrite_P((SPALTEN_MAX + 1 - sizeof(PANEL_STR_SWEEP_UP)), DISPLAY_LINE_1, (sizeof(PANEL_STR_SWEEP_UP)-1), PSTR(PANEL_STR_SWEEP_UP));
				break;
			case SWEEP_DOWN:
				LCDOverwrite_P((SPALTEN_MAX + 1 - sizeof(PANEL_STR_SWEEP_DOWN)), DISPLAY_LINE_1, (sizeof(PANEL_STR_SWEEP_DOWN)-1), PSTR(PANEL_STR_SWEEP_DOWN));
				break;
			case SWEEP_UPDOWN:
				LCDOverwrite_P((SPALTEN_MAX + 1 - sizeof(PANEL_STR_SWEEP_UPDOWN)), DISPLAY_LINE_1, (sizeof(PANEL_STR_SWEEP_UPDOWN)-1), PSTR(PANEL_STR_SWEEP_UPDOWN));
				break;
		}
	}
}

Auch wenn es jetzt erstmal chaotischer aussieht, ich bekomme aber so die redundante Nutzung der Längeninformation weg. Letztlich wird 3 mal die Information über den String benutzt, 2 x mal die Länge und einmal der String. Damit es schön wird, müßte man dass Ganze noch in ein Gesamtmakro packen. Nachteil: einmal + einmal -.

dg1vs hat geschrieben: Aktuell versuche ich noch den Code etwas bezüglich Speicher zu optimieren. Mit PWM und großen Display liege ich auf dem ATMEGA32 bei:
Program: 32066 bytes (97.9% Full). Compiler ist der WinAVR-20100110.

dg1vs hat geschrieben:Was noch auf der Agenda liegt, ist die Verriegelung von Burst/Sweep/PWM. Ist diese schon angedacht, oder habe ich bei der Darstellung nen Fehler gemacht? Ich habe es noch nicht geschafft da reinzuschauen.

dg1vs hat geschrieben:Aktuell versuche ich noch den Code etwas bezüglich Speicher zu optimieren.

avr-gcc -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=16000000UL -I /usr/local/AVRMacPack/include -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wextra -Werror -Wstrict-prototypes -Wa,-adhlns=uart.lst  -std=gnu99 -fno-inline-small-functions -fno-split-wide-types -fno-tree-scev-cprop -ffreestanding -ffunction-sections -fdata-sections -mcall-prologues --combine -fwhole-program -Wl,--relax,--gc-sections,-Map=dds.map,--cref,-u,vfprintf -MD -MP parser.c timer.c dds-hw.c dds-parser.c encoder.c i2c.c i2creg.c lcd.c panel.c main.c uart.c --output dds.elf -lprintf_flt -lm

thoralt hat geschrieben: Der Trick ist hier, dass alles in einem Durchgang und als eigenständiges Programm (-fwhole-program) übersetzt wird. Das spart bei mir gegenüber der herkömmlichen Art mit Makefile nochmal 400 Bytes.