Moin! In einem im Tutorial zur Ansteuerung eines Displays angegebenen Quellcode finden sich folgende Zeilen: //////////////////////////////////////////////////////////////////////// //////// // Pinbelegung für das LCD, an verwendete Pins anpassen // Alle LCD Pins müssen an einem Port angeschlossen sein und die 4 // Datenleitungen müssen auf aufeinanderfolgenden Pins liegen // LCD DB4-DB7 <--> PORTD Bit PD0-PD3 #define LCD_PORT PORTD #define LCD_DDR DDRD #define LCD_DB PD0 // LCD RS <--> PORTD Bit PD4 (RS: 0=Data, 1=Command) #define LCD_RS PD4 // LCD EN <--> PORTD Bit PD5 (EN: 1-Impuls für Daten) #define LCD_EN PD5 //////////////////////////////////////////////////////////////////////// ///// Tatsächlich sieht meine Pinbelegung so aus: RS = D2 E = D3 D4-D7 = D4-D7 Wie schreibe ich (gemäß Weisung des Tutorial) den Code um?
Stephan R. schrieb: > Tatsächlich sieht meine Pinbelegung so aus: > > RS = D2 > E = D3 > D4-D7 = D4-D7 > > Wie schreibe ich (gemäß Weisung des Tutorial) den Code um? Den Code schreibst du gar nicht um, aber die #define :-) Deine Datenbits fangen bei DB4 an
1 | #define LCD_DB PD4
|
2 | #define LCD_RS PD2
|
3 | #define LCD_E PD3
|
// LCD RS <--> PORTD Bit PD2 (RS: 0=Data, 1=Command) #define LCD_RS PD2 // LCD EN <--> PORTD Bit PD3 (EN: 1-Impuls für Daten) #define LCD_EN PD3 Dafür sindja die #define Einstellungen. Somit kann man C-Code auch einfach portieren. sieht auf einem anderen Controller vielleicht so aus: #define LCD_RS GPIO.PORTXY.PIN99 Damit wird LCD_RS erstzt, mit was auch immer.
Nun habe ich die #defines entsprechend meinem avr-board angepasst und das Tutorial-Programm gebrannt. Dennoch schwarzer Balken. Das kann doch gar nicht sein!!
Stephan R. schrieb: > Nun habe ich die #defines entsprechend meinem avr-board angepasst und > das Tutorial-Programm gebrannt. Dennoch schwarzer Balken. > Das kann doch gar nicht sein!! Doch das kann sein. Das Forum ist voll mit immer gleichen Fragen, so wie deine. Das Thema "LCD funktioniert nicht" taucht jeden Tag mindestens 2 mal auf. Welches LCD hast du genau? Vielleicht ist es ja gar kein Kompatibles! Welcher Controller ist da drauf? Stimmt die Taktfrequenz, die du im Programm angegeben hast? Hast du die Verkabelung kontrolliert? Ja? 3 mal?
Der schwarze Balken kann schon sein, es gibt noch weitere Ursachen: Kontrastspannung richtig eingestellt? -> Datenblatt LCD-Kontroller, Display Ist der im Display verwendete Kontroller auch der im Tutorial verwendete? "fast 100% kompatibel" heißt auch nur "fast" -> Init-Routinen des Displays prüfen. Wartezeiten prüfen, ggf. auch Busy-Signal verwenden.
Es handelt sich um das myavr-Standard-Ansteck-LCD des myavr- Boards: http://shop.myavr.de/Add-Ons%20und%20Module/myAVR%20LCD%20Add-On.htm?sp=article.sp.php&artID=15 Daher halte ich Kompatiblitäts- und Verkabelungsprobleme für wenig wahrscheinlich. Und da ich den fast unveränderten Code aus dem Tutorial nehme, sollt dieser doch auch stimmen :( Die Frequenz ist auch korrekt eingestellt, wobei ich mich frage, wozu das so wichtig ist. Einzige Annahme: die Frequenz bestimmt die Pausenzeiten, die angeblich so wichtig für das Display sind...?
Stephan R. schrieb: > Es handelt sich um das myavr-Standard-Ansteck-LCD des myavr- Boards: > > http://shop.myavr.de/Add-Ons%20und%20Module/myAVR%20LCD%20Add-On.htm?sp=article.sp.php&artID=15 > Gibts da kein Demoprogramm dazu? (Kenn das MyAvr System nur dem Namen nach und weiß nicht wie da der Lieferumfang ist) > Daher halte ich Kompatiblitäts- und Verkabelungsprobleme für wenig > wahrscheinlich. Kardinalfehler #1 bei der Fehlersuche: Nimm nichts als gegeben an. > Und da ich den fast unveränderten Code aus dem Tutorial nehme, sollt > dieser doch auch stimmen :( Nö. > Die Frequenz ist auch korrekt eingestellt, wobei ich mich frage, wozu > das so wichtig ist. Einzige Annahme: die Frequenz bestimmt die > Pausenzeiten, die angeblich so wichtig für das Display sind...? Ganz genau das ist der Grund. Hast du die Taktfrequenz kontrolliert? Oder nimmst du nur an, dass du sie im Programm so angegeben hast, wie sie wirklich ist.
Stephan R. schrieb: > Daher halte ich Kompatiblitäts- und Verkabelungsprobleme für wenig > > wahrscheinlich. Anders gesagt: mit Bascom programmiert lief die Kiste schon mal. Es gibt ein Demo-file, das liegt allerdings nur als Hex-file vor. Wie oder von wo aus kann das brennen?
Stephan R. schrieb: > Stephan R. schrieb: >> Daher halte ich Kompatiblitäts- und Verkabelungsprobleme für wenig >> >> wahrscheinlich. > > Anders gesagt: mit Bascom programmiert lief die Kiste schon mal. Na das ist ja schon mal was. D.h. dann tatsächlich, dass du nicht soweit daneben sein kannst. Irgendeine Kleinigkeit. (Was heißt: schon mal? Vor 1 Tag, vor 1 Woche, 1 Monat? Sicher, dass du die Verkabelung in der Zwischenzeit nicht geändert hast?) > Es gibt ein Demo-file, das liegt allerdings nur als Hex-file vor. Wie > oder von wo aus kann das brennen? Wie brennst du denn sonst? Kannst du dort kein HEX-File auswählen?
Meine Heizung ist im Sommer auf Sommermodus. Da brennt nix. Meinen Mikrocontroller jedenfalls flashe ich mit WinAVR-Programm Taste.
Stephan R. schrieb: > Meine Heizung ist im Sommer auf Sommermodus. Da brennt nix. > > Meinen Mikrocontroller jedenfalls flashe ich mit WinAVR-Programm Taste. Aha. Dann hol dir doch das MyAVR-Brennprogramm vom Hersteller (wozu bietet er es denn zum Download an). Damit kann man dann auch HEX-Files direkt flashen. Im übrigen: Wenn wir mal davon ausgehen, dass deine Hardware immer noch korrekt funktioniert: Programm zeigen.
Klingt im Jahr 2010 ungewöhnlich, aber ich bekomme mein Programm weder AUS dem Programmierlaptop ins Internet noch Internet IN selbigen. Ich werds heut abend von daheim aus machen. Danke erstmal!
ICH FASS ES NICHT! Problem gelöst: eine defekt Lötstelle auf dem made-in-germany- Originalboard! Das grenzt an Sabotage!!
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.