Hallo Kollegen, ich habe jetzt angefangen mein LCD-Kode so zu ändern dass ich 5pins von PORTB verwende und 2 Pins von PORTD. Vorher war alles auf PORTB gelegt (siehe lcd_m50530.h,c) Allerdings funktioniert jetzt mein Kode nicht mehr seit ich es geänder habe. Habe sehr viel ausprobiert und gesucht. Leider vergebens... Vielleeicht könnt Ihr mir mit eurem guten C-Kenntnissen auf die richtige Spur brinnen. grüße Khan
Danke dir! Dein Kode wollte ich so wieso einbauen, aber vorher wollte ich es mal auf primitive Art und weise lösen... Wenn ich dein Kode jetzt kodiere und es geht wieder schief wird es für mich noch schwieriger... grüße Khan
Hallo, also ich habe den v. Peter Dannegger Kode mal reingehackt. Aber immer noch nicht weiter gekommen ;-( Könnt Ihr mir bitte sagen ob die Zeilen 140 bis 144 so ok ist? grüße Khan
Was ich an vielen LCD-Codemonstern nicht verstehe ist, daß da bis zu 6 verschiedene Baustellen aufgemacht werden müssen: Es werden extra Routinen für low und high Nibble benutzt. Es werden extra Routinen für Daten, Kommando benutzt. Es werden extra Routinen für Initialisierung benutzt. Es wird unbedingt versucht, von der Initsequenz im Datenblatt abzuweichen. Bei mir gibt es dagegen nur eine einzige Nibble-Routine, die dann alle anderen Routinen aufrufen. Man muß also nur die eine Nibbleausgabe richtig machen, dann funktioniert auch der ganze Rest. Also ich kann meine kleine Routine in Deinem Codemonster nirgends wiederfinden. Wenn etwas nicht geht, dann schreibt man keinen riesen Code. Laß erstmal alle unnötigen Funktionen weg und gib einfach nur in einer Zeile "Hallo Welt" aus. Laß vor allem den Busy-Test raus. Insbesondere beim Init darf der ja garnicht gemacht werden! Das LCD ist auch mit Delays schnell genug. Im Gegenteil, man muß sogar noch zusätzlich Delays machen, damit der Mensch Zeit hat, es überhaupt abzulesen. Der Busytest hat daher nur den merkbaren Effekt, daß ein zusätzlicher IO-Pin belegt wird und auch deutlich mehr Code. Wenn Du mal nen Link zum Datenblatt postest, könnte ich da mal reingucken. Peter P.S.: Ich habe noch kein Text-LCD gehabt, das mit diesem Treiber nicht läuft. Nur bei den EA-DOG muß man noch extra Befehle für Kontrast und Booster senden, steht aber alles im Datenblatt.
Du hast ja volkommen recht!! Ich wollte nur den schon funktionierenden Kode um die Pinflexibilität erweitern. Danach den Kode optimieren... Aber wie du siehst ist es total in die Hose gegangen... grüße Khan
Sorry vorhin habe ich dir die falschen Kodefiles geschickt. dies sind die richtigen
> Ich wollte nur den schon funktionierenden Kode um die > Pinflexibilität erweitern. > Danach den Kode optimieren... > > Aber wie du siehst ist es total in die Hose gegangen... Zurück zu Start, gehe nicht über Los. Zurück zum funktionierenden Code, sicherstellen das er auch immer noch funktioniert und die Änderungen noch einmal machen. Aber diesmal in kleineren Schritten ändern und jede einzelne Änderung für sich alleine ausprobieren und testen.
Khan schrieb:
> Sorry vorhin habe ich dir die falschen Kodefiles geschickt.
Hatte ich schon erwähnt, daß ich Codemonster mit 1000 Baustellen nicht
mag?
Mach Dir eine Nibble-Ausgabe-Funktion und nur diese darf die 4
Datenleitungen und das Enable anfassen.
Für alle anderen Funktionen sind diese 5 Signale streng verboten, sie
dürfen nur die Nibblefunktion aufrufen.
Ich sehe auch keinen Grund, Delays selber zu basteln, wenn der Compiler
Dir bessere Funktionen zur Verfügung stellt.
Der Code wird dadurch nur unleserlicher, da keiner weiß, was Du mit
"short" meinst.
_delay_us( 1 ); versteht dagegen jeder sofort.
Der Chip ist etwas anders als der HD44780, aber nicht viel. Man muß nur
fürs Kursor setzen ne zusätzliche Steuerleitung benutzen. Die Änderungen
sind also minimal.
Ich würde auch die Initialisierung mit dem 2-maligen Setzen in den
8Bit-Modus übernehmen, damit wird der Code sicherer.
Peter
Hallo, also ich habe den Fehlerort lokalisiert. Allerdings weis ich nicht genau warum, deswegen bitte ich nochmal um eure Hilfe. Die Routine void LCD_waitReady(void) ist schuld daran. Die Routine funktioniert bis Zeile 157 kann aber nicht in if (flags & 6) { // bits 1 oder 2 gesetzt, also entweder sind wie im 8bit-mode oder wir haben gerade den zweiten Teil im 4bit-mode gelesen break; } hinein springen -> endlosschleife.. d.h. dass ich //flags = LCD_PIN; // zeile 147 flags = PINB & ( 1 << PB0 ); flags |= PINB & ( 1 << PB1 ); flags |= PINB & ( 1 << PB2 ); flags |= PINB & ( 1 << PB3 ); falsch programmiert habe.... könnt Ihr mir bitte hierfür nochmal helfen... Dafür bin ich echt dankbar.. Grüße Khan
Khan schrieb: > d.h. dass ich > //flags = LCD_PIN; // zeile 147 > > flags = PINB & ( 1 << PB0 ); > flags |= PINB & ( 1 << PB1 ); > flags |= PINB & ( 1 << PB2 ); > flags |= PINB & ( 1 << PB3 ); > falsch programmiert habe.... > > könnt Ihr mir bitte hierfür nochmal helfen... Die Technik ist grundsätzlich (fast) in Ordnung. Was war denn die ursprüngliche Belegung von LCD_PIN Welches Bit am LCD_PIN bedeutete was?
Khan schrieb: > flags = PINB & ( 1 << PB0 ); > flags |= PINB & ( 1 << PB1 ); > flags |= PINB & ( 1 << PB2 ); > flags |= PINB & ( 1 << PB3 ); Das ist kein pinvariabler Code, nur unnütze Schreibarbeit. Ist identisch zu:
1 | flags = PINB & 0x0F; |
Universell muß man es so machen, daß die Bitposition egal ist:
1 | flags = 0; |
2 | if( LCD_D4_PIN ) flags |= 1<<0; |
3 | if( LCD_D5_PIN ) flags |= 1<<1; |
4 | if( LCD_D6_PIN ) flags |= 1<<2; |
5 | if( LCD_D7_PIN ) flags |= 1<<3; |
Peter
@ Karl heinz Buchegger LCD_PIN ist als PINB definiert. @Peter Dannegger hast du den high Nibble absichtlich angegeben? Denn in der if abfrage unter dem Code wird ja nach if (flags & 6) gefragt, also die ersten 3 bits... grüße Khan
Ich nenne die IOs immer nach ihrer Funktion. Und im 4-Bit Mode muß man am LCD D7..4 verwenden. Ich habe nur das Codefragment umgeschrieben auf Pinunabhängigkeit. Ob es funktioniert, weiß ich nicht, da ich den Busy-Test nicht verwende. Er bringt ja keinerlei Vorteile. Peter
Hallo Peter, wiese bringt das Busy-test keine Vorteile? Grüße Khan
Khan schrieb:
> wiese bringt das Busy-test keine Vorteile?
Weil der Mensch mit Ablesen viel langsamer ist, als das LCD mit festen
Delays.
Und daher ist es egal, ob das LCD nun 1% oder 0,99% der CPU-Zeit
verbraucht.
Wenn man einen Mehraufwand treibt, sollte es sich auch lohnen. Ansonsten
ist es rausgeschmissene Programmierzeit und Codeverbrauch.
Im AVRFreaks hat kürzlich jemand LCD-Code mit 1ms Enablepuls
veröffentlicht.
Er hat also garnicht gemerkt, daß der Code mindestens 50-mal langsamer
ist, als nötig.
Peter
Hmm, interessant! Da das wass du sagst logisch klingt werde ich diesen Teil raus schmeissen. Wenn ich mal fertig bin mit dem Projekt werde ich es hier veröffentlichen. Leider habe ich sehr wenig Zeit um dieses Hobby so richtig ins Reine zu bringen. Aber irgendwann ist es soweit;-) Dank dir für alles.. Grüße Khan
Bitte 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.