Datum:
Hy ich habe leider Probleme mit dem schreiben auf meinem Display von Pollin (HLM8070 mit M50530) Pins sind: Pin 01 Ground Pin 02 5V Pin 03 dimmer Pin 04 OC1 Pin 05 RW Pin 06 EX Pin 07 DB0 Pin 14 DB7 Pin 15 OC2 Die Helligkeit kann ich regeln aber ich kann nichts schreiben!! kann mir jemand nen Beispiel Programm in C geben?
Datum:
kann mir jemand den Ablauf erklären? 1. also ich muss wahrscheinlich erst das Display initialisieren (wie?))? 2. kann ich einfach Daten senden wie bei RS232? also lege die 8Bit an DB0-DB7 und das Display übernimmt es dann oder wie? hab das Toturial durchgeschaut aber da steht nix zum Ablauf...
Datum:
kann mir jemand das Datenblatt erklären? auf Seite 4 wenn mir jemand das Datenblatt erklären könnte!!! könnte ich den Code übernehmen.... HELP!! R/W ==? RS ==? E ==?
Datum:
Hi Jörn, auf den ersten Blick hätte ich gesagt, dass in dem Ding ein Standard (Hitachi-HD44780 kompatibel) Controller verbaut ist. Ich hatte eben nur einen flüchtigen Blick auf das Datenblatt geworfen und es sind zumindest ein paar Sachen anders als beim Hitachi: Das Pinning ist ähnlich (D0-7 oder D4-7 im 4-Bit Mode, E, R/W) aber er hat neben RS (I/O C1) noch einen zweiten I/O-Control Eingang I/O C2 außerdem hat er wesentlich mehr Ram. Man müßte sich jetzt mal intensiv durch das Datenblatt wühlen und nachsehen, ob und wie er sich vom Hitachi unterscheidet (Adressierung, Befehle etc.). Dann kann man sehen, ob man die Standard Hitachi Routinen verwenden kann; die Hardware-Beschaltung dürfte fast identisch sein. Pinbelegung für Art.Nr. 120387 LCD-Pin Funktion Standard Hitachi 1 GND GND 2 VDD +5V VDD +5V 3 Kontrast Kontrast 4 I/OC1 RS 5 R/W R/W 6 ex E 7 DB0 DB0 8 DB1 DB1 9 DB2 DB2 10 DB3 DB3 11 DB4 DB4 12 DB5 DB5 13 DB6 DB6 14 DB7 DB7 15 I/OC2
Datum:
Ich habe gerade noch hier was gefunden: http://ssl.bulix.org/projects/lcd4linux/wiki/M50530 "These displays are made by different manufactures, and come in various sizes. The main difference between the M50530 and the HD44780 is that the M50530 can control much larger displays (mine has 8 rows and 24 columns). " Der Unterschied zum Hitachi scheint wohl wirklich die unterstützte Display-Größe zu sein (der Hitachi kann nur 80 Zeichen und bei größeren Displays werden einfach mehrere Controller verbaut). Daher wage ich mal die Prognose, dass Du die normalen Hitachi-Routinen mehr oder weniger übernehmen kannst.
Datum:
Angehängte Dateien:hallo! ich habe ein beispielprogramm in assembler für das pollin-lcd am atmega8 geschrieben. es funktioniert, ob das programm aber "sauber" geschrieben ist, kann ich nicht beurteilen. vielleicht kann es jemand brauchen... mfg michael
Datum:
Hallo, eine Beschreibung über den Anschluss des Displays an einem Mega8 gibt es hier: http://www.happy-micro.de/index.php?option=com_con... Gruß, Ralf
Datum:
Also mein Display zeigt mit Michaels Programm was an, allerdings nicht das, was es soll! kann das am Takt liegen?
Datum:
Angehängte Dateien:Mensch, das hatte ich doch mal geschrieben und dann nachher nicht mehr genutzt. Ich habe die Quellen mal angehangen. Ich habe den im 4 Bit Modus betrieben und mit einem Logik Analyzer nach Datenblatt programmiert und lief super.
Datum:
Hallo, Ich habe heute den Code von Thomas K. ausprobiert. Ich habe alles so angehängt, wie in M50530.h beschrieben. Trotzdem zeigt das Display nur eine Reihe schwarzer Balken an. Kann mir jemand sagen, an was das liegen könnte und mir helfen, dieses Display zum Laufen zu bringen? Das wäre wirklich nett. Sorry übrigens, dass ich den Thread wieder ausgrabe...
Datum:
Hast du die Ports auch so entsprechend genutzt und wenn nicht, hast du die Definitionen im Header angepasst? Stimmt deine eingestellte Taktfrequenz in deinem Projekt mit der tatsächlichen Taktung auf dem Board überein? Sind die Fuses dahingehend auch ordentlich gesetzt? Erstmal die Vermutung: falsch angeschlossen oder Timings stimmen nicht (delays zu kurz/lang)
Datum:
Danke erstmal für die schnelle Antwort. Nachdem ich es jetzt einige Male überprüft habe wage ich zu behaupten, dass es richtig angeschlossen ist. Mit dem Takt bin ich mir nicht sicher, im Makefile steht
F_OSC = 1000000 |
und das Fusebit steht auf
100001: Int. RC Osc. 1MHz [...] |
Bisher habe ich immer mit Bascom gearbeitet und da funktionierts so mit
$crystal = 1000000 |
Woher weiß ich, wie lange die Delays sein müssen?
Datum:
Hmm, ok. Ich hatte bisher immer mit AVR Studio gearbeitet und da wäre der Takt in den Projektoptionen einzutragen. Dieser Takt definiert dann das Symbol F_CPU und nicht F_OSC. Aber egal, da WinAVR meckert (die delay unit), wenn F_CPU undefiniert ist. Hast du vllt. irgendwelche Warnungen oder Hinweise beim Compilieren des Codes?
Datum:
F_CPU ist nirgends definiert (zumindest hab ichs nirgends gefunden) und ich bekomme auch keine Warnungen. Ich habe jetzt aber wie bei http://www.mikrocontroller.net/articles/AVR-GCC-Tu... ein
#ifndef F_CPU #define F_CPU 1000000 #endif |
eingefügt. Es passiert aber das selbe wie davor...
Datum:
Gut dann setze ich mich nochmal hin und bau eine Schaltung auf und teste es mit deiner Konfiguration (Int OSC bei 1 MHz, Quellen aus diesem Thread). Ich melde mich dann nochmal mit den Ergebnissen. Kontrastregler hast du schon verstellt?
Datum:
Ja, der Kontrastregler funktioniert, es gibt helle und dunkle Klötze ;) Danke für die Mühe, ich hoffe es läuft bei mir auch mal irgendwann...
So, ich habe nun mir einen ATMega32 und das ganze durchgespielt: es lief nicht. Dann den Logic Analyzer geholt und damit getestet - sah alles gut aus, aber es lief nicht. Dann die Timings und die Signale nochmal mit dem Datenblatt verglichen und es fiel auf, dass die Daten falsch waren zur Initialisierung. Also nochmal alle Signale überprüft und die Datenleitungen verhielten sich komisch. Im Endeffekt habe ich viel Zeit verbracht um festzustellen, dass der ATMega 32 ein JTAG Interface hat und dieses liegt auf Port D. Also deaktiviert und alles lief. Ich habe nun die ganzen Timings (die waren zuvor sehr großzügig) nochmals gut gestrafft bzw. entfernt. Somit ist nun das Display auch recht schnell anzusprechen (auch mit internem 1 MHz Takt). Im Anhang die bis auf die Timings unveränderte Originalquellen in einem AVR Studio Projekt. Ziel ATmega 32 mit internem 1 MHz Oszillator. Das Timing Bild ist mit im Archiv enthalten. Von daher nun die Frage: Welcher Controller? JTAG ist auf einem der genutzten Ports und eingeschaltet?
Datum:
Controller ist ein Atmega16, JTAG war aber schon aus. Mit dem neuen Code funktionierts aber scheinbar. Zumindest komm ich bis zum cls(). Juhuu. Allerdings bekomm ich es nicht hin, was vernünftiges hinzuschreiben, kannst du mir ein Beispiel machen, das irgendwas hinschreibt? C kann ich nämlich nicht wirklich gut und deshalb bin ich mir nicht sicher, ob ich das mit den Strings richtig gemacht hab.
Datum:
Siehe Anhang. Da ist ein komplettes Projekt drin mit Ausgabe eines
Textes ("TEST"). Genau diese Ausgabe ist auch in dem LA Diagramm zu
sehen.
In wie fern kommst du zu "cls()"? Diese Funktion löscht den Bildschirm
und setzt den Cursor auf die linke obere Ecke. Da dies aber der
Standardzustand ist nach LCDInit(); solltest du keinen Unterschied
feststellen. Was bedeutet in so fern bei dir "komm ich bis zum cls()"??
Datum:
Ich hab ein cls() nach dem LCDInit() gemacht, wusste nicht dass das unnötig ist. So hat es aus meiner Sicht funktioniert bis zum cls(), da danach das Display leer war. Wenn ich jetzt etwas ausgeben will wird auch etwas ausgegeben. Allerdings nicht das, was es soll, sondern irgendwelche chinesischen Zeichen (zumindest sehen sie so aus). Woher kann das kommen?
Datum:
Zeig doch mal deinen Code den du bisher hast. Und teile mal den Controller mit den du nutzt - und ob du die Belegung wie im Header gemacht hast oder andere Ports/Leitungen nutzt (z.B. alles an Port C, o.ä.).
Datum:
Die Belegung ist wie im Header mit einem Atmega16. Der Code ist m50530.c, ergänzt mit
int main(void) { _delay_ms(1000); LCDInit(); LCDSend( 0, LCD_CMD_SETDISPLAYMODE | dmDisplayOn | dmCursorOn | dmCursorBlink); LCDWrite("TEST"); return 0; } |
Also eigentlich deine Testfunktion, ich hab nur noch ein Delay davorgemacht, damit ich es besser überprüfen kann. Soweit funktioniert es auch. Erst ist das Display leer, dann (nach 1 Sekunde) kommen diese komischen Zeichen.
Datum:
Ok, nur nochmal zur Sicherheit: JTAG Enable Fuse ist deaktiviert worden? Und du nutzt das 4x20 Zeichen Display von Pollin (HLM8070)? Oder hast du eine andere Konfiguration, also mehr oder weniger Zeilen oder Spalten?
Datum:
Ja, JTAG ist deaktiviert, habs mal testweise angeschaltet, dann zeigts gar nichts an, mit abgeschaltet immer noch die chinesischen Zeichen. Mein Display ist das hier: http://www.pollin.de/shop/dt/MjE2OTc4OTk-/Baueleme..., heißt schonmal gleich. Aber 4x20 Zeichen? Meins hat 4x16, wie bei Pollin angegeben.
Datum:
4x16 ist richtig. Wir haben das gleiche Display wobei es bei dir tut, bei mir nicht. Ok, grundlegend scheint das Init hin zu hauen, somit sollten die ganzen Steuer- und Datenleitungen hinhauen. Mein Display zeigt bei dem Testprogramm "TEST" an, bei deinem chinesische Zeichen. Falls vllt. doch ein paar Datenleitungen Probleme machen, mach mal bitte ein Foto von den chinesischen Zeichen. Ansonsten, falls die Timings zu knapp sein sollten, der originale Beitrag von mir hat langsamere Timings. Schonmal wieder damit probiert? Was hängt noch an dem Controller dran bzw. ist er auf einem Board? Welches Board? Was ist sonst noch angeschlossen?
Datum:
Er ist auf nem Steckbrett mit dem Display, sonst ist nichts dran. Ich probier jetzt nochmal das alte...
Datum:
Dann bin ich wirklich ratlos. Ich habe es mit Quarz, ohne Quarz (interner OSC), mit Oszillator, etc ausprobiert und es klappt alles. Einzig JTAG beim Port D und Aktualisierung der Taktfrequenz in den Quellen waren Stolpersteine. Ich hatte auch alles auf einem Steckbrett, nur das LCD dran. Der Controller aber war direkt auf dem STK500 was auch das Display mit versorgte. Ansonsten schonmal nach der Initialisierung den Kontrastregler bewegt? Beim Schreiben des Originalcodes war ich auch dem verweifeln Nahe, da ich den Kontrast immer so eingestellt hatte, dass es uninitialisiert die 1 1/2 Balken zeigte und nach der Initialisierung war nix zu sehen. Bis ich irgendwann mal den Kontrast nachregulierte und alles war auf dem Display zu sehen und funktionierte... Ansonsten bin ich echt ratlos. Wie gesagt, ein Foto von den komischen Zeichen wäre nochmal nett. Ansonsten wenn das auch wirklich 4 Stück sind (wie auch der ausgegebene Text lang ist), dann würde ich aus lauter Not schon fast einen defekten Character Generator oder CG RAM vermuten, aber eigentlich ist dies eher unwahrscheinlich.
Ja, es sind 4 Zeichen, das würde schon passen... Ich probier einfach noch ein bisschen rum, vllt klappts ja doch noch, ansonsten werd ich nächstes mal ein Standarddisplay kaufen und das einfach mit Bascom verwenden. Trotzdem danke, ich melde mich, wenns geklappt hat.
Datum:
Wenn ich das richtig sehe, dann sind die beiden letzten Zeichen gleich? Wenn dem so ist, dann überprüfe deine Leitung D5 vom Display, also PC1. Dieser ist entweder nicht richtig verbunden oder mit einer anderen Leitung zusammen geschlossen. Bitte überprüfe dies - vllt. eine Lötbrücke am Display vom Kabel anlöten? Pieps das mal bitte durch.
Datum:
Tatsächlich waren die Pins 14 und 15 am Display zusammengelötet. Jetzt macht es aber grade gar nichts mehr, vllt ist beim rumprobieren was kaputtgegangen. Ich werd morgen nochmal probieren, obs doch noch will.
Datum:
Na endlich. Ich dachte schon ich werd noch ganz blöde im Hirn. Nun dann hoffe ich morgen mal auf einen problemlosen Ablauf.
Datum:
Und wie sieht es nun aus? Eine gewischt bekommen an der negativen Kontrastspannung? Oder LCD weggeworfen?
Datum:
Wies aussieht ist beim Auseinanderlöten von den Pins was kaputt gegangen, auf jeden Fall zeigts nichts mehr an, weder was richtiges noch chinesische Zeichen :( Mal schauen wie meine LCD-Karriere jetzt weitergeht ;). Vielleicht probier ichs nochmal mit dem Display, vielleicht kauf ich aber auch eins, das mit Bascom kann, dann wirds einfacher...
Datum:
Schade, gerade für den Preis von nichtmal 3 Euro bei Pollin ist das Display gar nicht mal so schlecht. Und bisher ist mir auch noch keins gestorben, alle verrichten ihren Dienst. Nur beim reinen auseinander löten sollte das Display im Normalfall auch nicht zerstört werden. Aber nun gut, ich hoffe das nächste Display klappt besser.
Datum:
Angehängte Dateien:Hi, irgendwie bekomme ich das Display mit den 2. Quellen und dem Testprogramm an meinem ATMega 16 nicht zum laufen. Habe die Ports entsprechend angepasst, die Steuerleitungen liegen auf PA2..PA5, die Datenleitungen auf PD0..4. Auf RW und Ex kann ich die beschriebenen Bitmuster sehen, aber auf den Datenleitungen kommt irgendwie immer nur auf DB5 ein Signal. Habe die Ausgabe "TEST" auch einfach mal in eine Schleife gepackt um besser messen zu können (analoges Oszi) aber da tut sich rein gar nichts. Arbeite mit AVR Studio, die F_CPU habe ich gesetzt, der JTAG sollte dekativiert sein.... Die Ausgabe ist einfach eine Zeile schwarze Kästchen, und dann 1 Ziele halbe schwarze Kästchen? Ein Testprogramm dass durch PortA einfach ein Schieberegister durchlaufen lässt, tut auf dem IC einwandfrei. Wenn ich versuche auf anderen Datenbits noch debug signale auszugeben, geht dass irgendwie gar nicht (z.B. PB0 toggeln). Anbei mal meine Dateien... Bin für jeden Tipp dankbar. //
Datum:
Sorry, mit "JTAG sollte dekativiert sein" meinte ich, dass ich das JTAGEN Fuse ausprobiert habe (beide Zustände gefused) sich aber nichts getan hat. Auch als ich die Data Leitungen auf PORTD gelegt habe, kamen keine sinnvollen Data Signale aus dem ATMEGA. Habe mein Testprogramm (einfaches durchschieben von Bits= auf alle Ports ausgeweitet, und hat auf ALLEN funktoniert. CU //hufnala
Datum:
So, nun nochmal: Du hast die Datenleitungen auf DB0..DB4 angeschlossen? Das sind 5 Datenleitungen und keine 4. Danach schreibst du das die Datenleitungen alle nichts machen, ausser DB5 - und was liegt denn an der Leitung nun an? Hast du beachtet die Datenleitungen wirklich an Port 0..3 anzuschliessen? Wie kommst du dann auf die anderen beiden Leitungen? Wenn du andere Datenleitungen nutzt, dann musst du die Ausmaskierung abändern und die Bits noch entsprechend schieben. Passt auch die F_CPU Definition zu der wirklichen Taktfrequenz deines ATMegas? Wenn du 8 MHz angibst und er nur bei 1 MHz int. Osc. läuft, dann klappt keine einzige delay Funktion.
Datum:
Hi Thomas, hoffentlich habe ich mehr Probleme mit dem Tippen als mit dem Löten ;-), inzwischen habe ich das Display schon wieder abgelötet... Die Steuerleitungen waren auf PA2..PA5. Die Datenleitungen waren auf PD0..PD3, es waren die Datenleitungen des Panels DB 4..7 (Pins 11..14) gem. Pinning oben aus dem Thread. (lt. "// data port, LCD signals DB4-DB7 have to be connected to P0-P3" aus der m50530.h). Die Define Angaben in der 50530.h wurden entsprechend angepasst:
// data port, LCD signals DB4-DB7 have to be connected to P0-P3 #define LCDDATAPORT PORTD #define LCDDATADIR DDRD #define LCDDATAPIN PIND // control port, LCD signals RW, EX, I/OC1, I/OC2 #define LCDCTRLPORT PORTA #define LCDCTRLDIR DDRA //#define LCDCTRLPIN PIND #define LCDPIN_RW PA2 #define LCDPIN_IOC1 PA4 #define LCDPIN_IOC2 PA5 #define LCDPIN_EX PA3 |
Auf "RW" und "EX" konnte ich zyklisch ein Signal messen, dass dem im Logikanalyzer entspricht. Auf DB5 konnte ich zyklisch ein Signal mit dem Oszi messen, dass anscheinend dem 0x02 Signal bei ca. -350µs aus dem Plot entspricht. Dieses Signal kommt zyklisch, leider konnte ich mit meinem Oszi die Zykluszeit nicht feststellen, da die Wiederholdauer verglichen zu den Peaks extrem ungünstig war. Ich denke ich habe auch inzwischen die Ursache gefunden, aber keine Abstellmaßnahme: Die delay.h/delay.c scheint bei mir einen zyklischen RESET auszulösen. Keine Ahnung warum. Ich habe ein Programm, mit dem ich einfach eine "1" auf allen Ausgängen durchschiebe, dass hat mal mit der delay.h funktioniert. Die Aufrufe von _delay_ms in der main Schleife VOR dem zyklischen ausführen [while(1)... ] scheinen IMMER einen RESET des µC zu verursachen. Der ATMega16 lief die ganze Zeit mit Werkseinstellungen, geändert wurde ztw. das JTAG Fuse und die Oszillatoreinstellung von 1Mhz auf 8Mhz (und zurück) bei Anpassung des F_CPU und der Einstellung im Projekt. Den Watchdog etc. habe ich nicht bewusst initialisiert (Werkseinstellung?). Software ist AVRStudio 4.17 Build 666 Der µC läuft jetzt mit anderer SW sauber (Soft-PWM), allerdings habe ich da anfangs genau das gleiche Phänomen festgestellt, aus irgendeinem Grund geht der IC in RESET wenn ich einen _delay_ms(xxxx) (xxxx=konstante, keine Variable) in der main aufrufe oder in einer von main aufgerufenen init-funktion. Mit dem toggeln eines Ausgangs in der Main beim startup habe ich es letzlich gefunden und so lange auskommentiert bis der _delay_ms als Ursache gefunden war. Frage zur Delay Funktion: Kann ein falscher F_CPU (nicht passend zur gefusten Frequenz) ein solches Verhalten auslösen (Absturz/RESET)? Ich hatte bisher beim stöbern nur gefunden dass die Zeiten (natürlich!) nicht passen... Danke für die Unterstützung. //hufnala
Datum:
Ich würde bei sowas vllt. nochmal den WDT ausschliessen wollen. Also zum einen mal die Fuses nachschauen ob der WDT nicht vielleicht enabled ist und zum anderen auch mal den Reset Grund aus dessen Register auslesen. Dann kommt man der Ursache auch schonmal näher (vielleicht doch ein Brown-Out?). Ansonsten kenn ich keine Resets aufgrund von Delays. Ich werde mich zumindest am WE nochmal hinsetzen und versuchen das ganze nachzustellen. Also HLM8070 Display an einem ATMega 16 mit interner Clock von 1 bzw. 8 MHz und mit geteilten Ports (Signalleitungen/Datenleitungen). Ich werde mich dann auch mal näher mit deiner Anpassung beschäftigen. Ich gebe dann hier Rückmeldung.
Datum:
Hi Thomas, alles klar, auch wenn ich bisher noch kein WDT Fuse gefunden habe sondern nur ein Register gehe ich da hinterher. Das mit dem RESET Register schaue ich mir auch an. Vorgehensweise : ISR auf'n RESET und dann den RESET wert auf RS232 raus oder als BIN Wert auf'm Port (z.B. mit einer Case Anweisung?)? JTAG Interface habe ich leider keines. Brown Out schaue ich auch nochmal, aber das Netzteil bringt 3A, ist eingestellt auf 1/2 A Strombegrenzung und da war ich bisher weit weg. Davor sitzt noch ein (sauber entstörter) 7805. Aber für sowas habe ich ja das 20 Jahre alte Oszi :-) Ciao Lars
Datum:
Hallo Lars, Du kannst den Reset Grund aus dem MCUSR Register lesen. Dies muss vor der Initialisierung geschehen und wenn du es in eine Variable schreibst, muss diese von der Initialisierung ausgenommen werden. Ein Beispielcode dafür findet man in der WinAVR Hilfe die bei WinAVR mit beiliegt: http://www.nongnu.org/avr-libc/user-manual/group__... Dort kannst du das MCUSR mit auslesen und dann später im Programm z.B. per UART ausgeben. Die Erklärung was nun anhand des Wertes den Reset ausgelöst hat, findet man in den Manuals zur MCU bei Atmel. Das wäre mal recht interessant zu erfahren, weil dann hat man schonmal einen guten Tipp in welche Richtung man suchen muss. Grüße, Thomas
Datum:
Angehängte Dateien:Hi Thomas, also dass mit dem RESET bin ich los, habe mal den Watchdog abgeschaltet, und bin alle Frequenzen nochmal durchgegangen. Das mit dem MCUSR habe ich anders gemacht, vermtl. funktioniert es deshalb nicht, habe einfach das Register in den Port kopiert. Weiterhin habe ich jetzt hier die Leitungen zum Display nochmal verlötet, da war zwar alles ok, aber mit immer an und ablöten war mir zu blöd, jetzt geht's über'n Breadboard, und alles auf PORTA. Generell bin ich soweit dass mein Programm läuft, aber das Display zeigt wie gehabt nur 1,5 Reihen schwarze Blöcke. Im Anhang mal meine SW. ziemlich viel auskommentiert. Jetzt messe ich gerade alles nochmal durch. Habe auf alle Fälle deutlich mehr signale als gestern, warum auch immer. Habe den Code mal drangehängt, vielleicht fällt Dir ja was auf, die LED an PD5 wird schön brav alle 2ms umgeschaltet, d.h. dass timing sollte generell passen... //CU Lars
Datum:
Edit: Habe die _delay_ms langsam von 500 auf 2ms verringert bis ich mit dem Oszi schön messen kann, am Ergebnis auf dem display hat das nichts geändert.... //Lars
Datum:
Update: Ich hab's. Es läuft. So ein blöder Fehler, vermutet habe ich es gestern ja schon fast, aber dann hat mich das mit dem RESET durch den Wind gebracht. Wenn ich mein Netzteil einschalte, ist der Spannungsanstieg anscheinend zu langsam für das Display. Habe jetzt einfach mal den Stecker gezogen und dann wieder neu gesteckt, jetzt tut's manchmal dass was es soll! Dass wollte ich gestern mit dem Delay am Anfang erschlagen und das Display erst nach 500ms initialisieren... Vielen Dank einstweilen, ich muss mal sehen dass ich das jetzt SW technisch hinbekomme! Schönes Wochende Gruß Lars
Datum:
Hallo Lars, Na sehr schön, das freut mich für dich. Und ich habe mir eine weitere Aufgabe am WE erspart. Aber Hauptsache das ganze läuft nun. Ich werde mir aber trotzdem nochmal auf die ToDo Liste setzen, dass man die Datensignale und Steuersignale auf unterschiedliche Ports legen kann. Grüße, Thomas
Datum:
Hi Thomas, vielleicht doch noch eine kleine Hilfestellung: Der Code
_delay_ms(1000); //StartDelay LCD?
LCDInit(); //LED initialisieren
LCDSend( 0, LCD_CMD_SETDISPLAYMODE | dmDisplayOn | dmCursorOn | dmCursorBlink);
//LCDWrite("TEST");
_delay_ms(200);
while (1)
{
PORTD ^= (1<<PD5);
LCDSetCursorPos(1,1);
_delay_ms(5);
LCDWrite("TEST");
_delay_ms(1000);
}
return(0);
}
|
macht nicht ganz dass was ich will, nämlich an Zeile1 Spalte1 immer "TEST" ausgeben ;-). Statt dessen kommt je nachdem wie ich mit den delays spiele (beim Init usw.) eine unterschiedliche Ausgabe. Bei kurzen Delays sinds TST oder TES, bei den jetzigen Delays sehe ich "T" "S" "T" immer an 1,1, wobei der Buchstabe nicht nach 1000ms immer durchwechselt. Muss ich da noch irgendwelche Delays einhalten, oder irgendwas anders konfigurieren? Das Display hat 4*16 Zeichen. Gruß Lars
Datum:
Hallo Lars, ich vermute du nutzt auch das HLM8070 von Pollin und an diesem habe ich den Treiber entwickelt und getestet. Die Ausgaben funktionierten bei mir einwandfrei ohne irgendwelche Delays dazwischen. Ich müsste es bei mir auch nochmal ausprobieren. Grundlegend würde ich hier aber mal wieder auf eine anders lautende F_CPU Definition in den Projektoptionen tippen. Also eine andere Frequenz definiert als auf welcher der Controller im Endeffekt läuft. Grüße, Thomas
Datum:
ja, ist dass von Pollin, Best Nr. LCD-Modul HLM8070 hm, und wie kriege ich dass am sicheresten raus? Die fuses stehen auf 0100 für CKSEL3..0 und die F_CPU auf
#define F_CPU = 8000000UL; |
Die Frquency im AVR Studio steht ebenfalls auf 8000000 und der Optimierungsgrad ist auf -Os und mit
while (1)
{
PORTD ^= (1<<PD5);
LCDSetCursorPos(1,1);
LCDWrite("TEST");
_delay_ms(10);
}
|
habe ich das gleiche und meine LED blinkt mit 10ms ON/OFF Time am PD5? Der WritePGM ist auch nicht besser ;-( Naja, da suche ich morgen weiter... Schönen Abend noch, und Danke nochmals Gruß Lars P.S. bist Du über ICQ, Skype oder so zu erreichen? Dann mülle ich hier nicht mehr länger das Forum voll...
Datum:
Hi Ich versuche auch schon seit Monaten obiged LCD zum laufen zu bekommen. Ich mag es an einen Arduino Duemilanove betreiben. Also ATmega168, das sollte ja nicht so schwierig sein den Treiber anzupassen aba ich bekomme es nicht gebacken! http://arduino.cc/en/Main/ArduinoBoardDuemilanove Mit Arduino hat keiner Erfahrung???
Datum:
Hufnala hatte es im Endeffekt hinbekommen, soweit ich weiss. <ironie>Und was dein Problem ist, Rolf, ist eine Frage für die Glaskugel, schon allein bei den wenigen Informationen die du einem hier zum Fraß vorwirfst. Eine Pinbelegung ist überbewertet, Taktfrequenzen, Fuses und andere Belegungen braucht eh kein Mensch. Mit diesem Input sagt meine Glaskugel: da muss wohl ein Fehler vorliegen...</ironie>
Datum:
test_LCD.pde Testdatei für Arduino IDE:
#include <m50530.h>
void setup()
{
// wait for power up
delay(5000);
LCDInit();
LCDSend( 0, LCD_CMD_SETDISPLAYMODE | dmDisplayOn | dmCursorOn | dmCursorBlink);
LCDWrite("TEST");
}
void loop()
{
}
|
In der m50530.h wurden nur die Ports angepasst (auf Port D):
// data port, LCD signals DB4-DB7 have to be connected to P0-P3 #define LCDDATAPORT PORTD #define LCDDATADIR DDRD #define LCDDATAPIN PIND // control port, LCD signals RW, EX, I/OC1, I/OC2 #define LCDCTRLPORT PORTD #define LCDCTRLDIR DDRD //#define LCDCTRLPIN PIND #define LCDPIN_RW 7 //alt PD13 #define LCDPIN_IOC1 6 #define LCDPIN_IOC2 4 #define LCDPIN_EX 5 |
Die Arduino IDE gibt Fehlermeldungen: undefined reference to `LCDInit()' undefined reference to `LCDSend(unsigned char, unsigned char)' undefined reference to `LCDWrite(char const*)' das ganze ist in irgendeiner Temp-Datei. Die Headerdatei (m50530.h) ist ja eingebunden... also warum bekomme ich den Fehler? Zur Info: Vorher habe ich eine anderen Treiber modifiziert (aus einem anderen Forum Link finde ich nicht mehr). Dieser lief Fehlerfrei, aber das LCD hat nichts angezeigt (nur die 1,5 Balken) -> Kontrtast geht... Nachdem ich so nicht weiter gekommen bin wollte ich nun diesen hier ausprobieren... LCD ist so angeschlossen (4 Bit Mode): LCD-Pin Funktion 1 GND -> Masse 2 VDD +5V -> +5V (Rot) 3 Kontrast -> auf Poti-Mittenlanschluss 4 I/OC1 -> I/O Pin 5 R/W -> auf Masse, da nur schreiben 6 ex -> execute Signal (2x/Zyclus verwenden da 4-bit) 7 DB0 -> nicht verwenden 8 DB1 -> nicht verwenden 9 DB2 -> nicht verwenden 10 DB3 -> nicht verwenden 11 DB4 -> Datenbus 1 12 DB5 -> Datenbus 2 13 DB6 -> Datenbus 3 14 DB7 -> Datenbus 4 15 I/OC2 -> I/O Pin Ach es ist auch ein Atmega328
Datum:
Rolf W. schrieb: > Die Arduino IDE gibt Fehlermeldungen: > undefined reference to `LCDInit()' > undefined reference to `LCDSend(unsigned char, unsigned char)' > undefined reference to `LCDWrite(char const*)' Bedeutet von dem Treiber ist nichts enthalten. Durch den Header kennt er die Funktionen aber deren Implementierung kennt er nicht. Diese ist in der .c Datei und die hast du anscheinend nicht eingebunden. Somit wird von dem Treiber nichts genutzt. > das ganze ist in irgendeiner Temp-Datei. Die Headerdatei (m50530.h) ist > ja eingebunden... also warum bekomme ich den Fehler? Weil die .c Datei nicht eingebunden wurde. > Zur Info: > Vorher habe ich eine anderen Treiber modifiziert (aus einem anderen > Forum Link finde ich nicht mehr). Dieser lief Fehlerfrei, aber das LCD > hat nichts angezeigt (nur die 1,5 Balken) -> Kontrtast geht... Nachdem > ich so nicht weiter gekommen bin wollte ich nun diesen hier > ausprobieren... Was heisst für dich denn "funktionieren"? Wenn du die 1,5 Balken siehst, dann ist das Display nicht initialisiert. D.h. es der alte Treiber funktionierte somit genauso wenig. > LCD ist so angeschlossen (4 Bit Mode): > LCD-Pin Funktion > 5 R/W -> auf Masse, da nur schreiben Warum gibst du dann oben PD7 an, wenn das R/W Signal auf Masse liegt? Was für einen Sinn soll das haben? Und mein Treiber liest btw. das BUSY Flag von dem Display, somit ist nix von wegen nur schreiben. Wenn du das so machen willst, dann nutze den vorherigen Treiber, der ja schon funktionierte. Grüße, Muetze1
Datum:
OK mit einem: #include <m50530.c> in der test_LCD.pde geht es ohne Fehlermeldungen (das compilieren). Jetzt bin ich mit dem neuen Treiber genau soweit wie mit dem alten, ich kann es auf den Controller spielen, das LCD zeigt aba nix an.
Datum:
Hallo Rolf! Was ist mit dem R/W Signal? Auf Masse? Auf PD7? Was ist mit dem USB Teil bzw. dem USART auf dem Atmel? PD0 und PD1 sind TxD und RxD - ist diese initialisiert? Ändern sich die Pins von PORTD beim ausführen bzw nach dem Reset? Grüße, Muetze1
Datum:
R/W ist am Display direkt auf Masse gelötet um das Kabel zu sparen. Kann man doch so machen? In der Software wollte ich es einfach auf einen unbelegten Pin legen. Kann ich die PORTD Zustände mit einem Multimeter messen? Ich versuche gerade die DB4-7 an andere Anschlüsse zu legen. Muss noch raus finden wie ich die in der Software einstelle....
Datum:
Rolf W. schrieb: > R/W ist am Display direkt auf Masse gelötet um das Kabel zu sparen. Kann > man doch so machen? In der Software wollte ich es einfach auf einen > unbelegten Pin legen. Bitte die Antworten auch lesen sonst brauchen wir hier nicht weiter zu machen.
Datum:
Sorry Thomas K., habe das aus dem vorherigen Beitrag nicht richtig verstanden mit dem RW. Ich habe jetzt eine RW Leitung gelegt. Ich habe 3 verschiedene Arten zu LCD anschließen getestet (Port B, C, D) -> geht nicht. Ich denke das Problem liegt in der Arduino IDE, ich bin mir nicht mal sicher wie ich die Pins in der .c-Datei nennen muss. In dem zugehörigen Forum bekomme ich Null Hilfe. Arduino soll einfacher sein weil es viele Sachen von "alleine" macht, ich spiele mittlerweile mit dem Gedanken mir ein normalen uC zuzulegen und die Arduino-Scheiße weg hauen...
Datum:
Hallo Rolf, Hmm, ok, also wenn es auch mit dem angeschlossenen RW nicht funktioniert, wird es problematisch mit den Fehlerquellen. Ich kenne die Arduino Dinger nicht und kann somit auch nichts zu deren IDE oder Hardware sagen. Sind denn nach einem Reset Aktivitäten an den Pins sichtbar? Also mal ein LED an einen Pin des Ports angeschlossen und nach dem Reset geschaut ob sie aufleuchtet (Widerstand nicht vergessen, und nur eine LED für den gesamten Port pro Versuch)? Sie sollten zumindest mal kurz rumflackern. Dies sollte sich auf allen Pins des Portes nachvollziehen lassen. Grüße, Muetze1
Datum:
bin noch dran.... ich hab das Arduino Forum durchsucht wie ich die DB ect schreiben kann (viele Stunden), jetzt versuche ich mehr Systematisch vor zu gehen und ein test-Projekt zu machen wo ich Ports testen kann.
Datum:
Bin "etwas" weiter gekommen: Habe raus gefunden dass ich die PBx -> PINBx ändern kann, dann kann ich es mit Ardoini IDE kompilieren und drauf schieben, es tut sich bloß immer noch nix (LCD: 1,5 Zeilen mit Balken)
Datum:
Danke an Thomas K. für die Hilfsbereitschaft! Ich gebe auf, da es bei Pollin ein 27x4 LCD mit Standard HD44780 Controller für 5€ gibt. Dafür gibt es bei Arduino Treiber die ich bloß anpassen muss. Schade um die raus geschmissene Zeit, aber 5€ für ein noch größeres Display mit Standard Treibern ist unschlagbar.
Datum:
Angehängte Dateien:Hallo, ich hatte bis gestern auch Probleme mit dem Display und dem C-Code von muetze1. Das Display wollte einfach nicht. Ich steuere es auch im 4-Bit-Modus an und nutze einen Atmega8 als µC. Im unitialisierten Zustand zeigt das Display ja diese 1½ schwarzen Balken an. Interessant war bei mir aber, dass es nach dem Aufruf von LCDInit() nur noch ein schwarzer Balken war. Ich habe dann herausgefunden, dass dies dann passiert, wenn die ersten 4 Bits übertragen wurden, aber die nächsten dann irgendwie verloren gingen. Also habe ich mir mal den ASM-Code von Michael zu Gemüte geführt. Er steuert das Display zwar im 8-Bit-Modus an, aber interessant waren für mich die Delays und das Überprüfen des busy-Flags. Michael überprüft das busy-Flag nämlich gar nicht, sondern durchläuft stattdessen 255 eine Schleife mit einem NOP. Das hab ich direkt mal ausprobiert und meinen Code dementsprechend angepasst. Ich ignoriere das busy-Flag also und warte stattdessen ein paar NOPs lang. Und dann hat es direkt funktioniert. Die nächsten 4 Bit wurden angenommen und das Display war initialisiert. Von da an klappte alles. Ich habe an dem Code von muetze1 aber noch ein paar Änderungen durchgeführt. Es ist nämlich jetzt möglich die vier Daten-Bits auf verschiedene Ports und Bits zu legen. Die Control-Bits sind aber weiterhin auf einen festlegbaren Port begrenzt, aber die Bits für EX, R/W, I/OC1 und I/OC2 kann man auf diesem Port frei wählen. Im Anhang also der C-Code, der bei mir unter Ubuntu 10.04 mit eclipse und avrdude ohne Probleme kompiliert. Mein Atmega8 ist auf 1 MHz getaktet. Sollte also jemand einen µC nutzen, der eine höhere Frequenz hat, müssen womöglich an ein paar Stellen noch ein paar mehr NOPs eingefügt werden. Der Code ist außerdem noch etwas mehr kommentiert als vorher, sollte also leicht verständlich sein. Viel Spaß damit und falls jemand Sonderwünsche hat, so soll er sie stellen.
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten