mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Erfahrungen im Einsatz von eDIP240


Autor: Juergen Harms (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Juergen Harms (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S Das Löschen aller definierten Touchbereiche innerhalb von x1y1-x2y2 
meinte ich

Autor: Juergen Harms (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: C. D. (schnack)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.