Bedienpanel mit 20x4 und Softkeys

[dg1vs]

Hallo,

ich habe mich beim DDS Funktionsgenerator immer etwas geärgert, dass man mit dem kleinen Display immer „ewig“ scrollen muss. Deshalb habe ich vor einiger Zeit mal einen Versuch gestartet, ein größeres „PM8“ zu entwerfen. Außerdem dient es als Display für „meine“ Version des UNI-C (siehe http://thoralt.ehecht.com/phpbb/viewtopic.php?f=9&t=385), da ich unbedingt einen AT90CAN128 als µC haben möchte, da ich CAN bei einem universellen Controllerboard für sehr sinnvoll halte. Anbei ein Bild des aktuellen Standes.



Ich habe beim Einarbeiten in die Layout-Software und Leiterplattenherstellung einiges Lehrgeld gezahlt, kann Euch aber nun meinen Entwurf vorstellen (siehe Anhang). Für Anregungen etc. bin ich Euch dankbar (den Mikromatch Stecker http://thoralt.ehecht.com/phpbb/viewtop ... 0&start=15 [die aktuell letzten 2 Beiträge] kommt auf die nächste Version). Hier ein Bild der LP.



Als Display habe ich die EA DIP204-4 (http://www.lcd-module.de/pdf/doma/dip204-4.pdf) benutzt. Die Software habe ich angepasst, aber sicher was vergessen. Wenn ich einen cvs-Zugang bekomme, baue ich es auch in die Quellen ein, aber zunächst nur für den DDS. Das define

Code: Alles auswählen

//#define DISPLAY208
// oder
#define DISPLAY420

für den Display-Typ sollte man später auch einer zentralen Stelle halten.

Und nun kommt mein „Angstgegener“ . Da ich vor über 15 Jahren beschlossen das Thema MMI konsequent zu meiden, stehe ich vor dem Problem, was packt man nun in die 80 Zeichen.... Die unterste Zeile sollte die Icons für Hoch/Runter (Rechts/Links außen) und die Bedeutungen der zwei „neuen“ Softkeys enthalten. Vielleicht ist es auch sinnvoll die Bedeutung von allen 4 Tastern zu ändern. Hier wäre ich auf Eure Ideen angewiesen. Meine Bitte: wenn jemand Ideen zur Gestaltung hat, mir bitte mitteilen.

Grüße Karsten

PS: Ich habe noch eine max. zwei Leiterplatten übrig, die weisen aber 3 kleiner Designfehler auf, die man aber einfach korrigieren kann. Einfach kurze Mail bei Bedarf.

[dg1vs]

Habe den Code vergessen.

Karsten

[psclab38]

Hi Karsten

ich habe mich beim DDS Funktionsgenerator immer etwas geärgert, dass man mit dem kleinen Display immer „ewig“ scrollen muss. Deshalb habe ich vor einiger Zeit mal einen Versuch gestartet, ein größeres „PM8“ zu entwerfen.

Das Scrollen war für mich eigentlich nie so das große Problem, die etwas eingeschränkte Übersichtlichkeit schon eher. Meistens war das Display mit 8 Zeichen einfach nur zu kurz. Andererseits wollte ich keine Einschubslots im Gehäuse mit breiten Frontplatten versperren.

Und nun kommt mein „Angstgegener“ . Da ich vor über 15 Jahren beschlossen das Thema MMI konsequent zu meiden, stehe ich vor dem Problem, was packt man nun in die 80 Zeichen.... Die unterste Zeile sollte die Icons für Hoch/Runter (Rechts/Links außen) und die Bedeutungen der zwei „neuen“ Softkeys enthalten. Vielleicht ist es auch sinnvoll die Bedeutung von allen 4 Tastern zu ändern. Hier wäre ich auf Eure Ideen angewiesen. Meine Bitte: wenn jemand Ideen zur Gestaltung hat, mir bitte mitteilen.

Ich hab' jetzt eine Weile überlegen müssen, was ich Dir antworten soll. Einerseits bist Du ja schon mit der Hardware recht weit, aber ich muß zugeben, daß ich bei dem bereits geleisteten Aufwand schon eine grundsätzliche Idee zur MMI-Gestaltung auch der oberen drei Zeilen erwartet hätte. Manchmal muß man seinen Angstgegner einfach angreifen, um weiterzukommen...

Frag' Dich einfach, was willst Du sehen, und was willst Du mit nur wenigen Handgriffen einstellen können.

Vorschlag: Zunächst fast alles beim Alten lassen und in den beiden mittleren Zeilen die derzeitigen Menüausgaben einblenden, ggf. erweitert. Und in die Titelzeile Statusinformationen, wie Frequenz und Amplitude. Als Softkeys könnte ich mir den Schnellzugriff auf eben diese beiden Funktionen vorstellen. Das zumindest als erster Schritt um zu sehen, wie gut sich das MMI so macht.

Die Software habe ich angepasst, aber sicher was vergessen.

Zeigt es denn schon das "Standardmenü" an? Was den Code angeht, die Menüführung ist im C-Code ja recht gut getrennt vom Rest. Abhängig vom endgültigen MMI könnte man quasi eine eigene Datei für Deine Variante aufmachen.

Grüße
Paul

[dg1vs]

Hi Paul,

Das Scrollen war für mich eigentlich nie so das große Problem, die etwas eingeschränkte Übersichtlichkeit schon eher. Meistens war das Display mit 8 Zeichen einfach nur zu kurz. Andererseits wollte ich keine Einschubslots im Gehäuse mit breiten Frontplatten versperren.

Die EA DIP204-4 sind meiner Meinung nach ein guter Kompromiss.

Ich hab' jetzt eine Weile überlegen müssen, was ich Dir antworten soll. Einerseits bist Du ja schon mit der Hardware recht weit, aber ich muß zugeben, daß ich bei dem bereits geleisteten Aufwand schon eine grundsätzliche Idee zur MMI-Gestaltung auch der oberen drei Zeilen erwartet hätte. Manchmal muß man seinen Angstgegner einfach angreifen, um weiterzukommen...

Das hätte glatt von mir kommen können . Letztlich ist die Hardware ja der erste Angriff.... Was mir wirklich fehlt, so blöd wie es klingt, ist eine Art gedankliches Modell, um MMI-Sachen zu erstellen.

Zeigt es denn schon das "Standardmenü" an? Was den Code angeht, die Menüführung ist im C-Code ja recht gut getrennt vom Rest. Abhängig vom endgültigen MMI könnte man quasi eine eigene Datei für Deine Variante aufmachen.

Ja das "Standardmenü" funktioniert. Einfach lcd.h und lcd.c ersetzen und 80% des Displays sind ungenutzt . So war auch mein Plan. Eine panel204.* Variante erstellen und im Makefile (oder Avr-Studio) die passende Variante auswählen/einstellen. Maximal kommen irgendwo noch ein paar #define rein und fertig. Der Code ist m.M. nach sehr gut strukturiert. Ich habe für meinen UNI-C Prototypen auch auf der DDS-Software aufgesetzt und war sehr angenehm überrascht. Einzig die Nameskonventionen mußte ich aufgrund meiner beruflichen Prägung ändern, was mit eclipse aber völlig easy ist.

Ich werde mal ein Blatt Papier nehmen und ein paar MMI-Skizzen erstellen. Erst das Design, dann der Code.

Grüße Karsten

[dg1vs]

Hallo,

ich bin beim Anpassen des Codes gestern Abend auf folgendes Problem gestoßen und nicht sicher, ob es ein Verständnisproblem von mir ist.

Im Panel.c gibt es ab ca. Zeile 776 folgenden Codeabschnitt

Code: Alles auswählen

if(g_ucMenuItemChanged)
{
	SetActivityTimer(75);
	g_ucMenuItemChanged = 0;

	// force output parameter name to LCD
	ATOMIC_RW(xg_uScrollTimer, 0xFFFF);
	g_ucScrollOffset = 0;

	// set new acceleration values
	SetEncoderAcceleration(pgm_read_word(&g_currentMenuItem->iEI1),
			pgm_read_word(&g_currentMenuItem->iEI2),
			pgm_read_word(&g_currentMenuItem->iEI3),
			pgm_read_word(&g_currentMenuItem->iEI4));

	// also update parameter display
	if(null!=UpdateDisplayFunction)
		UpdateDisplayFunction(1,
				(void*)pgm_read_word(&g_currentMenuItem->pParam));

	// if there's no EncoderFunction, display triangle to indicate if there
	// is a submenu or output a blank line if not
	else
	{
		if(null!=(void*)pgm_read_word(&g_currentMenuItem->pSubmenu))
			LCDOverwrite_P(7, 1, 1, PSTR("\x05"));
		else
			LCDClearLine(1);
	}
}

Ich habe es aber nicht geschaftt in folgende Zeile reinzulaufen (mit Debugger)

Code: Alles auswählen

LCDClearLine(1);

Hat jemand eine Idee und kann mir Bitte einen Tip geben wo mein Denkfehler liegt.

Grüße und Danke

Karsten

[psclab38]

Hi Karsten,

Ich habe es aber nicht geschaftt in folgende Zeile reinzulaufen (mit Debugger)

Code: Alles auswählen

LCDClearLine(1);

Welchen Debugger verwendest Du? Den JTAGICEmk2? Im AVR Studio kann man nicht an jeder Anweisung einen Brechpunkt setzen, wenn der compilierte Code zu gut optimiert ist.

Eigentlich muß der Code ja funktionieren,

Code: Alles auswählen

	{
		if(null!=(void*)pgm_read_word(&g_currentMenuItem->pSubmenu))
			LCDOverwrite_P(7, 1, 1, PSTR("\x05"));
		else
			LCDClearLine(1);
	}

denn das Dreieck in Sonderzeichen 0x05 erscheint brav in Abhängigkeit davon, ob ein Untermenü vorhanden ist oder nicht. Inwiefern die mit "LCDClearLine(1);" gelöschte Zeile nicht gleich wieder mit Inhalten überschrieben wird, hab ich mir jetzt nicht direkt angeschaut. Mein Debugger ist im Moment abgeklemmt.

Grüße
Paul

[dg1vs]

Hi Karsten,
Welchen Debugger verwendest Du? Den JTAGICEmk2? Im AVR Studio kann man nicht an jeder Anweisung einen Brechpunkt setzen, wenn der compilierte Code zu gut
optimiert ist.

Ja den AT JTAG ICE2, ich kann versuchen, die Optimierung runterzudrehen.

Eigentlich muß der Code ja funktionieren,

Code: Alles auswählen

	{
		if(null!=(void*)pgm_read_word(&g_currentMenuItem->pSubmenu))
			LCDOverwrite_P(7, 1, 1, PSTR("\x05"));
		else
			LCDClearLine(1);
	}

denn das Dreieck in Sonderzeichen 0x05 erscheint brav in Abhängigkeit davon, ob ein Untermenü vorhanden ist oder nicht. Inwiefern die mit "LCDClearLine(1);" gelöschte Zeile nicht gleich wieder mit Inhalten überschrieben wird, hab ich mir jetzt nicht direkt angeschaut. Mein Debugger ist im Moment abgeklemmt.

Ja das Dreick erscheint, dass passt, aber das Löschen nicht. Das ist auf dem 2x8 Display auch kein Problem, weil es dann sofort mit anderen Sachen überschrieben wird.

Ich werde heute Abend mit den den Optimierungen spielen (solange mich Frau und Kinder lassen ). Vielleicht habe ich auch was übersehen.

Grüße

Karsten

[dg1vs]

Ich werde heute Abend mit den den Optimierungen spielen (solange mich Frau und Kinder lassen ). Vielleicht habe ich auch was übersehen.

Naja das Spielen hat etwas länger gedauert. Ich habe alle möglichen und unmöglichen Compileroptimierungsoptionen ausprobiert, aber ich laufe nicht in die Zeile:

Code: Alles auswählen

LCDClearLine(1);

.

Die Wirkung auf dem 082 ist ok, weil es dann sofort mit anderen Sachen überschrieben wird. Auf dem großen Display jedoch nicht. Ich bin leider noch nicht ganz hinter das Wunschverhalten gestiegen

Grüße

Karsten

[psclab38]

Naja das Spielen hat etwas länger gedauert. Ich habe alle möglichen und unmöglichen Compileroptimierungsoptionen ausprobiert, aber ich laufe nicht in die Zeile:

Hi Karsten,

ich hab's mir grade nochmal angeschaut. Die Lösung ist eigentlich ganz einfach und Du hast sie oben in dem Codefragment auch mitgeliefert :
Die Schlüsselstelle ist die Abfrage vorher, ob das jeweilige Menü denn eine "UpdateDisplayFunction" hat:

Code: Alles auswählen

      if(null!=UpdateDisplayFunction)
            UpdateDisplayFunction(1,
                    (void*)pgm_read_word(&g_currentMenuItem->pParam));

        // if there's no EncoderFunction, display triangle to indicate if there
        // is a submenu or output a blank line if not
        else
        {
            if(null!=(void*)pgm_read_word(&g_currentMenuItem->pSubmenu))
                LCDOverwrite_P(7, 1, 1, PSTR("\x05"));
            [b]else[/b]
                LCDClearLine(1);
        }

Da das normalerweise zutrifft, und der "else" Zweig bei Menüpunkten mit "UpdateDisplayFunction" gar nicht angesprungen wird, kommt man auch gar nicht an die fragliche Stelle. Der Code "LCDClearLine(1);" würde nur angesprungen wenn sowohl "UpdateDisplayFunction" als auch pSubmenu Null wären. Das ist aber derzeit wohl nirgendwo konfiguriert, auch in der DIV-C nicht. Ist wohl mehr so der Vollständigkeit halber da.

Ob man da was drehen müßte, damit es auch mit Deinem großen Display funktioniert, hab ich jetzt nicht untersucht.

Grüße
Paul

[dg1vs]

Hallo *,

anbei mal der Start-Screen des Panels.


Der "Rest" ist auf dem Stand des kleinen Display, zusätzlich gibt es eine Statusleiste, die die aktuelle Signalform, Sweep an/aus und Burst an/aus darstellen. Eine Taste habe ich mit dem Rücksetzen auf Defaultwerte belegt. Geht so ganz schnell . Aktuell will ich demnächst das TRMS-Modul aufbauen, dann gibt es noch eine Version. Ein paar Ideen hab ich noch, obwohl MMI-Design nie meine Leidenschaft werden wird.

Beim Lesen der TODO ist mir noch aufgefallen, dass PWM, AM und FM geplant gewesen war/ist. Wie ist da der Stand?

Grüße Karsten

PS: Dank an Paul für die Motivation mit dem "Angstgegner"

[psclab38]

anbei mal der Start-Screen des Panels.

Sieht doch schon sehr schön aus!

Der "Rest" ist auf dem Stand des kleinen Display, zusätzlich gibt es eine Statusleiste, die die aktuelle Signalform, Sweep an/aus und Burst an/aus darstellen. Eine Taste habe ich mit dem Rücksetzen auf Defaultwerte belegt. Geht so ganz schnell .

Hast Du da auch noch ein Bildchen davon? So wie Du es beschreibst, wäre das ein guter Kompromiss zwischen Aufwand und besserer Darstellung!

Beim Lesen der TODO ist mir noch aufgefallen, dass PWM, AM und FM geplant gewesen war/ist. Wie ist da der Stand?

AM und FM können wir knicken, denke ich. PWM hat Thoralt mal angefangen und versprochen, es auch fertig zu machen. @Thoralt: was fehlt da eigentlich noch?

PS: Dank an Paul für die Motivation mit dem "Angstgegner"

Gerne! Man muß es nur versuchen. Der schwierigste Teil ist es, den inneren Schweinehund zu überlisten.

[thoralt]

[...] PWM hat Thoralt mal angefangen und versprochen, es auch fertig zu machen. @Thoralt: was fehlt da eigentlich noch?

Ich habe befürchtet, dass die Frage kommt Naja, Haus, Job und kleines Baby lassen derzeit keinen Raum für Basteleien. Im Winter wird das besser, und Herbst hat ja bereits angefangen...

Also, was fehlt zum PWM:

• Eingabe der PWM-Frequenz und des PWM-Verhältnisses
• Umrechnung der Frequenz in Vorteiler/Teiler des Timers im AVR, hier immer Auswahl des optimalen Vorteilers beachten, damit die Auflösung der PWM möglichst groß bleibt
• Zurückrechnen in tatsächliche Frequenz (Rundung wegen der ganzzahligen Teilerverhältnisse im Timer), Anzeige der tatsächlichen Frequenz; Alternative: Einrasten der Frequenzeingabe auf "krummen" Werten, wie sie durch die Timer-Teilung entstehen
• Anlöten des kleinen Drahtes vom Timerausgang an die Verstärkerstufe, damit die ganze Zauberei auch hinten rauskommt

Die Sache mit der vernünftigen Auswahl der Eingabemethode (Frequenz<->Timerwerte) ist das größte Teilproblem. Ich habe das nach wie vor auf dem Schirm, und ehrlich, bisher sind keine privaten Basteleien dazwischengekommen *g*

Wenn aber einer von Euch zu ungeduldig ist, kann er sich gern drum kümmern, wobei ich jederzeit für Fragen zur Verfügung stehe.

Viele Grüße
Thoralt

[dg1vs]

Hast Du da auch noch ein Bildchen davon? So wie Du es beschreibst, wäre das ein guter Kompromiss zwischen Aufwand und besserer Darstellung!

Ich mache bei Gelegenheit noch 1-2 Bilder (muss aber erst Stativ aufbauen)

Karsten

[dg1vs]

Hallo,

ich habe mein Änderungen sortiert und versucht alles mit

Code: Alles auswählen

#ifdef COMPILE_WITH_DISPLAY204
#else
#endif

Schaltern zu versehen. Ist zwar ein mächtiges #define-Monster geworden. Scheint aber gut zu funktionieren. Die Darstellung ist nicht exakt die, die ich möchte (und schon umgesetzt hatte),
aber so beschränken sich die Änderungen zunächst auf kleine Dinge. Bei einem kleinen Display funktioniert alles wie bekannt.

Ich würde gerne die Sachen einchecken, den Zugang hat mir Hartmut eingerichtet. Auch würde ich mich "besser" fühlen, wenn jemand die Änderungen reviewen würde, bevor ich sie einchecke. Im Anhang also alle geänderten File zum SF-Stand


Anmerkungen die mir aufgefallen sind
----------------------------------------
Mir ist aufgefallen, dass bei folgendem Code das Enter keine Bedeutung hat (jedenfalls habe ich mit den originalen Quellen keine Effekt am Gerät bemerkt)

Code: Alles auswählen

switch(Params.ucSweepSlope)
{
	case SWEEP_UP:
		LCDOverwrite_P(2, DISPLAY_LINE_1, 6, PSTR("Up   \x05"));
		break;
	case SWEEP_DOWN:
		LCDOverwrite_P(2, DISPLAY_LINE_1, 6, PSTR("Down \x05"));
		break;
	case SWEEP_UPDOWN:
		LCDOverwrite_P(0, DISPLAY_LINE_1, 8, PSTR("Up+Down\x05"));
		break;
}

Habe ich da was übersehen oder nicht verstanden?

Für das kleine Display könnte man m.M. noch Platz sparen, wenn man in cursor nur die 2 verwendeten Symbole einträgt.

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.

Grüße Karsten

[psclab38]

Hi Karsten,

Ist zwar ein mächtiges #define-Monster geworden. Scheint aber gut zu funktionieren.

Naja, ganz so schlimm ist es nicht geworden; es hält sich wirklich in Grenzen.

Die Darstellung ist nicht exakt die, die ich möchte (und schon umgesetzt hatte), aber so beschränken sich die Änderungen zunächst auf kleine Dinge.

Aber es interessiert mich dann schon noch, wie es "aussieht"... Die besten Ideen für Verbesserungen kommen meistens bei der Betrachtung der ersten Versuche.

Bei einem kleinen Display funktioniert alles wie bekannt.

Ich hab's mal mit Deinen Files compiliert und geladen. Sieht ok aus auf meinem kleinen Display.

Ich würde gerne die Sachen einchecken, den Zugang hat mir Hartmut eingerichtet. Auch würde ich mich "besser" fühlen, wenn jemand die Änderungen reviewen würde, bevor ich sie einchecke. Im Anhang also alle geänderten File zum SF-Stand.

Ich hab's mir mal kurz durchgesehen und mir gefällt's. Nur kleine Anmerkung: Du hast fast überall in LCDwrite und LCDOverwrite die Zeilennummer durch eine #define-Konstante ersetzt, was als Nebeneffekt der Lesbarkeit gut tut. Das könnte man in Deinem NEUEN Code (ganz unten panel.c) auch noch machen, dann isses konsistent. Vielleicht braucht's noch ein paar mehr #defines, aber durch die durch die neue Variante eingeführte Komplexität könnte damit vielleicht etwas kompensiert werden.

Der resultierende Code ist gut 30 Byte länger, das ist wohl der Funktion Panel_PrintEnter geschuldet.

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.

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. Das einzige, was mir so einfällt ist, die ganze Zeile oder vielleicht auch nur die Strings im printf mit

Code: Alles auswählen

#ifdef COMPILE_WITH_DISPLAY204
#else
#endif

einzuschließen. Das spart die extra-Funktion, aber die Lesbarkeit ist auch suboptimal.

Das führt auch schon zu:

Code: Alles auswählen

switch(Params.ucSweepSlope)
{
	case SWEEP_UP:
		LCDOverwrite_P(2, DISPLAY_LINE_1, 6, PSTR("Up   \x05"));
		break;
	case SWEEP_DOWN:
		LCDOverwrite_P(2, DISPLAY_LINE_1, 6, PSTR("Down \x05"));
		break;
	case SWEEP_UPDOWN:
		LCDOverwrite_P(0, DISPLAY_LINE_1, 8, PSTR("Up+Down\x05"));
		break;
}

Das ist bestimmt noch ein Überbleibsel aus vergangenen Tagen, als das Sweep-Menü mehrere Evolutionsstufen durchlief. Das "Enter" kann da weg.

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.

Grüße
Paul