Ich habe mich in den letzten Wochen intensiv mit dem Programmieren einer Anwendung beschaeftigt, die ein eDIP-240 (http://www.lcd-module.de/deu/pdf/grafik/edip240-7.pdf) Display zur Steuerung mit Menus, Listen und Schaltflaechen einsetzt. Ich habe dabei eine Reihe von Beobachtungen gemacht, die ich gerne allgemein zugaenglich machen moechte. Der wichtigste Schluss ist, dass das eDIP fuer so eine Aufgabe hervorragend geeignet ist. Es hat aber ein paar Kinderkrankheiten und Dokumentationsschwaechen, ich hoffe dass diese Bemerkungen helfen, damit besser umzugehen. 1. Protokollwahl, Systemintegration Ich habe mich fuer SPI (Alternativen sind I2C und seriell) entschieden - bei weitem am einfachsten zu handhaben bei einer engen Kopplung des eDIP an den uController (AT90Can128, 62.5 kHz - bedingt durch Teilfaktor von 16 MHz Quarz). Geschwindigkeit ist ueberhaupt kein Problem - der Flaschenhals ist das eDIP und seine Faehigkeit Befehle abzuarbeiten, nicht die Geschwindigkeit mit der man es mit Befehlen bombardiert - siehe auch weiter unten. Mein SPI ist Interrupt getrieben (ich muss mit Interrupts arbeiten, um in Echtzeit auf ankommende CAN Pakete reagieren zu koennen). Zur Einfachheit ist Pin20 (Input-ready) gepollt (ich habe alle 10 msec Systemtakt Interrupts bei deren Bearbeitung ich auch auf Vorliegen von Daten vom eDIP schaue). 2. Grundlegende Probleme in der Implementierung des eDIP - Das eDIP braucht 5 usec Zeit bis es nach dem Empfang des BCC das Ack-Byte generiert und auf das SPI Interface gelegt hat. Man darf daher nicht nach dem Senden des BCC sofort einen weiteren SPI Zyklus zum Empfang des Ack anhaengen - wenn man das tut, bekommt man statt des ACK das Echo des letzten vorher gesendeten Bytes: man muss mindestens 5 usec warten. Und - wichtig - das Ack muss von Anfang an behandelt werden (nicht, wie ich das zuerst wollte, erst beim Bereinigen der fertigen Anwendung im nachhinein anbringen), mit ACK - NAK wehrt sich (theoretisch - siehe weiter unten) das eDIP wenn es beim Verdauen von Befehlen nicht nachkommt, das heisst die Behandlung von ACK - NAK wichtig. - Dieser ACK - NAK Mechanismus funktioniert nur bedingt, ich habe den Eindruck dass in der eDIP Prozedur zum Abarbeiten des Inputspeichers ein kleiner Wurm ist: es kommt oefters vor, dass das eDIP anstelle ein NAK zu senden seinen Input einfach wegwirft, man sieht ihn dann in der Terminalebene. Es gibt ein zweites kleineres Problem: laut Beschreibung erwartet das eDIP dass man nach Empfang eines NAK das gerade verworfene Paket ein zweites Mal sendet. Wenn man das tut, stellt man fest, dass das eDIP manchmal trotz Senden des NAK ein im Paket enthaltenen Befehl korrekt abgearbeitet hat, und der neugesandte Befehl somit das gleich noch ein zweites Mal macht. Meine Gewaltloesung zum Umgehen dieses Problems ist einfach: Vermeiden dass das eDIP zu schnell mit Befehlen gefuettert wird und damit Erreichen dass man ueberhaupt nicht in die Situation kommt, dass dieser Fehler auftritt. Dazu muss man Wartezeiten zwischen den Befehlen vorsehen. 3. Wartezeiten Wie oben gesagt, das eDIP arbeitet fuer mich nur richtig, wenn die Befehle im Mittel nur so schnell ankommen wie das eDIP im Mittel mit dem Verarbeiten nachkommt. Auch wenn der NAK Mechanismus richtig funktioniert, ist man besser daran vorzubeugen: in meiner Erfahrung braucht das eDIP nach einem NAK viel Zeit um wieder auf die Fuesse zu fallen, es ist effizienter vorbeugend zu warten - ich habe das aber nicht durch Messen belegt. Was eindeutig belegt ist: wenn einmal ein NAK gekommen ist, besser pauschal 150 msec warten als das eDIP mit neuen Versuchen in kuerzeren Abstaenden zu belasten. Leider gibt es ueberhaupt keine Dokumentation ueber die Zeit, die das eDIP zum Verarbeiten spezifischer Befehle braucht - Messen ist auch schwer, weil der Eingangspuffer des eDIP eine ausgleichende und mittelnde Rolle spielt. Letztenendes bin ich mit Trial and Error am besten zurechtgekommen. Am meisten Zeit brauchen Loesch- und Menu Befehle - Wartezeiten von ca 100 msec koennen noetig sein. Auch die Ausgabe von laengeren Textketten braucht Zeit, nach einem laengeren Text warte ich 20 - 30 msec. Das heisst, man muss verhaeltnismaessig muehsam Befehl fuer Befehl mit der Wartezeit heruntergehen bis das eDIP mit dem Wegwerfen anfaengt, und dann wieder ein wenig Sicherheit dazugeben (und darauf achten, dass die Pufferung natuerlich auch vorhergehende Befehle mitspielen laesst) - ein wenig Dokumentation des Herstellers wuerde hier vieles leichter und sicher machen. 4. Echtzeitprobleme Ich habe 2 Echtzeitquellen, die das Senden von Befehlen an das eDIP ausloesen (Empfang von Daten ueber CAN - der AT90CAN128 haengt an einem Bus - und Touchpad Ergeignisse. Ein Verriegeln der Ausgabebefehle an den eDIP allein reicht nicht, ich habe auch die Wartezeiten nach den Befehlen in den Verriegelungsmechanismus mit einbeziehen muessen - sonst kommt es gelegentlich erst recht zum Ueberfluten des eDIP mit Befehlen. 5. Anwendungsprogrammierung Meine Anwendung redet mit dem eDIP ueber zwei Prozeduren: EdipPutCommand ( <data>, <length>, <memory-type>, <wartezeit> ) ; <data> = die Befehlskette (ram oder program-memory) <length> = Laenge der Befehlskette - muss leider explizit angegeben werden - die Kette kann 0-Zeichen enthalten, und C kennt leider die pascal-artigen Ketten mit vorangestelltem Laengenbyte nicht <memory-type> = Information ob die Kette in ram liegt oder im Program DatenSpeicher - eine Besonderheit der Programmierung auf AVR und aehnlichen Maschinen <wartezeit> = Wartezeit (Millisekunden) die automatisch nach Uebertragung des Beefehls eingehalten wird, und zwar mit Aufrechterhalten des "Busy" Status der Software Schnittstelle zum eDIP. EdipReadData ( <puffer> ) ; <puffer> = Speicher in dem die rufende Prozedur die vom eDIP gelesenen Daten findet - synchronisiert mit dem Pin 20. Dies ist praktisch etwas heikel, es kommt leicht zur Situation, wo logisch nicht nachvollziehbar noch Daten im eDIP liegen, obwohl man theoretisch alles gelesen hat, und Pin 20 aktiv bleibt. Trotz grosser Sorgfalt kommt das - sehr gelegentlich - vor, ich werde wohl zur Sicherheit dies mit einem Timeout Mechanismus ueberwachen und noetigenfalls heilen. 6. Praktische Erfahrungen Ich bin nicht sehr gluecklich mit den Fonts - sie sind zum Teil haesslich (z.B. franzoesiche Zeichen mit Akzenten in einigen Fonts). Auch die Kodierung ist wenig befriedigend - sie entspricht nicht der Defaultkodierung auf meiner Unixplatform (UTF-8) und ich muss Sonderzeichen hexadezimal einfuegen. Es fehlt in den vorhandenen Kontrollbefehlen eine gute Implementierung fuer automatische Touchtastenwiederholung (noetig wenn man numerische Werte eingeben will mit langsam und schnell Hinauf- und Hinunterlaufen). Tastenrepetition ist zwar im Prinzip moeglich durch die Aufeinanderfolge von ESC-A-A-\0 und ESC-A-A-\1, ist aber sehr heikel auf das Einhalten von Wartezeiten und fuehrt leicht zu ein wenig "Stottern" - eine entsprechende Funktion im Befehlssatz des eDIP waere eine echte Bereicherung. Diese Bemerkungen sollen weniger eine Aufzaehlung von Schwierigkeiten, als Hinweise sein, wie man sie umgehen kann. Das darf nicht negativ ueberbewertet werden: letztenendes ist das eDIP etwas grossartiges, und man kann es nur mit viel Nachdruck weiterempfehlen (und hoffen, dass der Hersteller bald einmal eine ueberarbeitete Version der Firmware herausgibt und seine Dokumentation ein wenig ergaenzt).
Fonts kannst Du Dir leicht selbst bauen, die mitgelieferten sind nur ein Vorschlag. Und dann kannst Du auch jede beliebige Codierung verwenden (ANSI, CP437, was auch immer).
Fonts: klar, und das ist ja eigentlich auch ein Nebengeleise, die Bemerkung haette ich mir wohl sparen koennen - die wichtige Aussage ist ueber das Protokoll. Trotzdem: wer schon einmal mit Fonts gespielt hat weiss, wie zeitaufwaendig es ist, etwas zu machen was Hand und Fuss hat. Und eigentlich finde ich schon, dass auch Vorschlaege gut sein koennten; wenn jeder neue Nutzer anfangen muss ungefaehr die gleichen Verbesserungen an den Fonts fuer sich neu zu erarbeiten ist das keine sehr ideale Loesung.
Hallo Juergen, Respekt und vielen Dank für diesen umfangreichen Bericht. Habe auch so ein eDIP inkl. Touchtastenabfrage im Betrieb, allerdings nur über eine drahtlose RS232 Verbindung (ohne Pin 20 Abfragemöglichkeit). Das war (schon einige Zeit her) nicht einfach zu programmieren und viele meiner damaligen Probleme erscheinen mit Deiner Doku nun in neuem Licht. Die unberechenbaren Reaktionszeiten sind in der Tat ein Problem und es waren einige Klimmzüge nötig dieses Display voll unter Kontrolle zu behalten, denn zuweilen kam und kommt einfach kein ACK. Diese Reaktionszeiten sollte man mittels Timer im Auge behalten und ggf. die beabsichtigte Lese/Schreib Operation automatisch neu instruieren. Mit den Fonts bin ich eigentlich zufrieden, zumal sich einzelne Zeichen leicht ändern lassen. Die grobpixlige Darstellung lässt sowieso wenig kreativen Spielraum. Interessant wären da mal mehr und farbige Pixel- mal sehen was das neue eDIPTFT so bringt. In der Firmware vermisse ich auch eine Funktion, nämlich das partielle Löschen der Pixel eines beliebigen Bereichs von x1y1-x2y2. Egon
P.S Das Löschen aller definierten Touchbereiche innerhalb von x1y1-x2y2 meinte ich
Ich habe wieder einmal den alten Fehler gemacht und vor dem Schreiben nicht genug gelesen - als ich die Font Bemerkung sah habe ich nachgeschaut und festgestellt, dass die --fexec-charset=<charset> Option des GCC Kompilers mir erlauben sollte den Kompiler die Arbeit machen zu lassen - nur habe ich beim schnellen Suchen keinen der Standard Kodes gefunden, welcher der im eDIP verwendetet Kodierung entspricht. Hat da jemand eine Ahnung? Immerhin, damit steht es dafuer sich Muehe zu geben und eine portable Loesung zu machen - waere vielleicht eine Idee das Forum - oder ist da die Code-Sammlung richtig ? - zu verwenden um Ergebnisse auszutauschen (meine Panels muessen franzoesisch sprechen, und da stellt sich sowohl das Problem der Kodierung als auch der Darstellung der Sonderbuchstaben). Das Grundproblem ist ja, dass ich meine Zeit verwenden moechte um moeglichst schnell eine ordentlich laufende (erste) Anwendung zu haben, und nicht um moeglich viel Spass beim Trixen mit dem eDIP zu haben. Ja, und hier ist noch ein Problem fuer das ich noch keine Loesung habe: ich schone meinen Bildschirm indem ich nach ein paar Minuten die Beleuchung ausschalte. Zum wieder Einschalten sollte man den Bildschirm einfach beruehren - und hier liegt das Problem, denn definiert sind da ja nur die Touchbereiche, und die findet man "im Dunkeln" nicht unbedingt. Ich habe versucht, den Bereich ausserhalb definierter Flaechen als "freien Tastbereich" zu definieren. Geht nicht, wenn man das als letzten Bereich definiert, geht ein wenig, wenn der freie Bereich als erstes definiert wird. Aber hier stecke ich: die Beruehrung im freien Bereich wird zwar korrekt gemeldet, aber nach dem Lesen geht nichts mehr - wahrscheinlich ein Fehler in meinem Kode, aber nicht offensichtlich (und einstweilen habe ich wichtigeres fertig zu machen).
Hi, wie gut ist denn die Touch-Funktionalität der Module? Kann man mit dem Wurstfinger drauf gehen oder ist ein Stift erforderlich/sinnvoll? Ich muß noch anmerken, daß ich solchen Modulen liebäugele, aber exakt 0 Erfahrung damit habe und mich frage, wie man mit Verschmutzungen umgeht oder wie empfindlich die Teile sind. Grüße schnack
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.