Hi Experten, ich habe heute den halben Feiertag damit verbracht, dass ich ein Mini-Projekt umgesetzt habe. Ich habe auf einem Steckboard einen HD44780 dran. Funktioniert. Über einen Atmega 32 steuer ich den an. Das Experiment war: Ich nehme einen Text, den zerteile ich in die beiden Zeilen dieses Displays. Gefunden habe ich einen Bibeltext, Auszug: "Gen 1:8 Und Gott nannte die Feste Himmel. Da ward aus Abend und Morgen der andere Tag." Nun habe ich den Atmega seriell über Python angesteuert, sprich, ich habe den Text zerlegt auf 1. Zeile: "Gen 1:8", 2. Zeile: "Und Gott"... (16 Zeichen erstmal) Der Weg dahin war kantig, es funktioniert soweit, aber: 1) Ist es korrekt, das es laut Datenblatt verschiedene Zeichensatz-ROMs gibt, aber man nicht umschalten kann, also: Ich habe keine deutschen Umlaute 2) Der ober Brainer war, das ich versucht habe, über ASCII über 128 (ich hatte mir da zwei ausgesucht, 193 und 194), Kommandos zu setzen, sprich: Display löschen und Cursor auf Zeile 1, Cursor auf Zeile 2. Ging nicht! Ich hatte es binär versucht, zB 1100010. Ging nicht! Beim Debugging bin ich echt sauer geworden, habe dann stattdessen einfach "$" und "#" genommen, und dann ging es... das empfinde ich als extrem unlogisch, oder sehe ich was falsch? 3) Die Geschwindigkeit. Ich habe vorhin die Baud-Rate auf 19200 erhöht. Ich kann dem Display zuschauen, wie es die Buchstaben aufbaut. Die erscheinen ganz lasch von links, das dauert pro Zyklus locker eine oder eine halbe Sekunde. Kennt ihr sowas? Merci für Komentare, Jens
Hi >1) Ist es korrekt, das es laut Datenblatt verschiedene Zeichensatz-ROMs >gibt, aber man nicht umschalten kann, Ja. >also: Ich habe keine deutschen Umlaute Beim allg. üblichen Zeichensatz gibt es die deutschen Umlaute. Allerdings haben die dort einen anderen Code als beim PC. >2) Der ober Brainer war, das ich versucht habe, über ASCII über 128 (ich >... >oder sehe ich was falsch? Verstehe nicht was du da gemacht hast. >3) Die Geschwindigkeit. Ich habe vorhin die Baud-Rate auf 19200 erhöht. >Ich kann dem Display zuschauen, wie es die Buchstaben aufbaut. Die >erscheinen ganz lasch von links, das dauert pro Zyklus locker eine oder >eine halbe Sekunde. Kennt ihr sowas? Nur bei schlechter Software. MfG Spess
Hi Spess, >>also: Ich habe keine deutschen Umlaute > > Beim allg. üblichen Zeichensatz gibt es die deutschen Umlaute. > Allerdings haben die dort einen anderen Code als beim PC. Verstehe ich nicht. Im Rom A00 sehe ich zb kein "Ä". Nur Japan über 128. >>2) Der ober Brainer war, das ich versucht habe, über ASCII über 128 (ich >... >>oder sehe ich was falsch? > > Verstehe nicht was du da gemacht hast. Naja, japanische Zeichen kommen in der Bibel nicht vor. Also, siehe Python-Code, ich hatte z.B. ser.write(0b11000010) #reset auf position oben mit clear versucht. Keine Chance. Im C-Code, siehe Anhang, dann zum Beispiel, logischerweise: SR(USART_RXC_vect){ value = UDR; //read UART register into value if (value == '#') { // hier nun versagte value = 0b11000010 lcd_setcursor( 0, 1 ); lcd_clear(); zeilennummer = 1; return; } if (value == '$') { //if (0) { lcd_setcursor( 0, 2 ); zeilennummer = 2; //return; } if (zeilennummer == 1) { if (value != '#') { lcd_data(value); } } if (zeilennummer == 2) { if (value != '$') { lcd_data(value); } } } Kleiner Kommentar: Natürlich sind die beiden if unten schöner schreibbar etc. und so, aber darauf kommt es nicht an. Besonders krass fand ich, dass das Modul ser einen Unterschied zwischen "$" und '$' macht, zur Warnung! "$" ging NICHT durch als solches! Oder habe ich da Python falsch verstanden? Für mich ist das dasselbe. >>3) Die Geschwindigkeit. Ich habe vorhin die Baud-Rate auf 19200 erhöht. >>Ich kann dem Display zuschauen, wie es die Buchstaben aufbaut. Die >>erscheinen ganz lasch von links, das dauert pro Zyklus locker eine oder >>eine halbe Sekunde. Kennt ihr sowas? > > Nur bei schlechter Software. Mag sein, ich sehe aber keinen Fehler. C-Code ist angehangen. Danke für Probelesen! LG Jens
. Die >>erscheinen ganz lasch von links, das dauert pro Zyklus locker eine oder >>eine halbe Sekunde. Kennt ihr sowas? > Spess, präziser, ich meine den Aufbau des Displays, natürlich nicht pro Buchstabe.
J. W. schrieb: > ich meine den Aufbau des Displays, natürlich nicht pro > Buchstabe. Ist trotzdem wahnsinnig langsam. Um ein 2x20 komplett zu füllen, sind genau 42 HD44780-Kommandos nötig, die allesamt maximal 47µs dauern. D.h.: bei optimaler Programmierung ist das komplette Display spätestens nach knapp 2ms mit einem neuen Inhalt befüllt. Der Engpaß ist also eher die serielle Übertragung, denn um 40 Zeichen mit 8N1 bei 115.2kbps zu übertragen, braucht's rund 3.5ms. Ergo: Jedes Programm, was wesentlich länger als 3.5ms benötigt, um 40 Zeichen per RS232 zu empfangen und auf zwei Displayzeilen zu verteilen, ist nur eins: unterirdisch schlecht. Voraussetzung ist natürlich, daß der Takt hoch genug ist, um den Durchsatz zu bewältigen.
J. W. schrieb: > Verstehe ich nicht. Im Rom A00 sehe ich zb kein "Ä". Nur Japan über 128. Das ist korrekt. Um auf einem A00 ROM deutsche Umlaute (oder andere beliebige Zeichen) zu bekommen, musst du die frei definierbaren benutzen (char 0x00 bis 0x07). Nur der ROM A02 besitzt fertige Umlaute für Europa. Ab Seite 17 des Hitachi Datenblattes sind die Tabellen. Bei ROMs mit der Bxx Kennung kann alles drin sein - das sind kundenspezifische ROMs.
J. W. schrieb: > . Die >>>erscheinen ganz lasch von links, das dauert pro Zyklus locker eine oder >>>eine halbe Sekunde. Kennt ihr sowas? >> > Spess, präziser, ich meine den Aufbau des Displays, natürlich nicht pro > Buchstabe. Ich brauch mit nur dein Python Programm ansehen um zu sehen, warum das alles grotten-langsam ist. Zähl halt mal deine ganzen sleep da drinnen zusammen, wieviel Zeit du da drinnen verbrutzelst.
Karl Heinz Buchegger schrieb: > J. W. schrieb: >> . Die >>>>erscheinen ganz lasch von links, das dauert pro Zyklus locker eine oder >>>>eine halbe Sekunde. Kennt ihr sowas? >>> >> Spess, präziser, ich meine den Aufbau des Displays, natürlich nicht pro >> Buchstabe. > > > Ich brauch mit nur dein Python Programm ansehen um zu sehen, warum das > alles grotten-langsam ist. Zähl halt mal deine ganzen sleep da drinnen > zusammen, wieviel Zeit du da drinnen verbrutzelst. Ach so? Dir ist schon bewusst, das ein # ein Kommentarzeichen ist? Der Aufbau des Displays dauert lange, also der Zeile oben und unten, eine Verzögerung bei einer neuen Zeile hat damit nur wirklich nichts zu tun. LG, Jens
> > Ergo: Jedes Programm, was wesentlich länger als 3.5ms benötigt, um 40 > Zeichen per RS232 zu empfangen und auf zwei Displayzeilen zu verteilen, > ist nur eins: unterirdisch schlecht. > > Voraussetzung ist natürlich, daß der Takt hoch genug ist, um den > Durchsatz zu bewältigen. Da bin ich doch neugierig, was an dem Python-Skript so schlecht ist? Ich arbeite mit 19200 Baud, das sollte ja wohl reichen? Dazu habe ich einen Baud-Quarz mit 7,3... MHz, das sollte es ja wohl kaum sein. Der Code ist absolut trivial und sollte es wohl kaum sein, es sei denn, Du kannst mir darin einen Fehler zeigen!? LG, Jens
J. W. schrieb: > Da bin ich doch neugierig, was an dem Python-Skript so schlecht ist? Ich > arbeite mit 19200 Baud, das sollte ja wohl reichen? Dazu habe ich einen > Baud-Quarz mit 7,3... MHz, das sollte es ja wohl kaum sein. > Der Code ist absolut trivial und sollte es wohl kaum sein, es sei denn, > Du kannst mir darin einen Fehler zeigen!? Nein, natürlich liegt es nicht an Deiner Software. Es ist völlig normal, dass das Display so langsam beschrieben wird. Es kann ja kaum sein, dass es bei anderen schneller läuft. Gruß Jobst
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.