Erfahrungen im Einsatz von eDIP240

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).