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?
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...
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 ==?
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 DB3DB3
11 DB4 DB4
12 DB5 DB5
13 DB6 DB6
14 DB7 DB7
15 I/OC2
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.
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
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.
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...
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)
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
1
F_OSC = 1000000
und das Fusebit steht auf
1
100001: Int. RC Osc. 1MHz [...]
Bisher habe ich immer mit Bascom gearbeitet und da funktionierts so mit
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?
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?
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?
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.
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()"??
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?
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.ä.).
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.
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?
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?
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.
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.
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.
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...
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.
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.
//
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
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.
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:
1
// data port, LCD signals DB4-DB7 have to be connected to P0-P3
2
#define LCDDATAPORT PORTD
3
#define LCDDATADIR DDRD
4
#define LCDDATAPIN PIND
5
6
// control port, LCD signals RW, EX, I/OC1, I/OC2
7
#define LCDCTRLPORT PORTA
8
#define LCDCTRLDIR DDRA
9
//#define LCDCTRLPIN PIND
10
#define LCDPIN_RW PA2
11
#define LCDPIN_IOC1 PA4
12
#define LCDPIN_IOC2 PA5
13
#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
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.
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
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__avr__watchdog.html
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
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
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
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
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
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
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
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
1
#define F_CPU = 8000000UL;
Die Frquency im AVR Studio steht ebenfalls auf 8000000 und der
Optimierungsgrad ist auf -Os
und mit
1
while (1)
2
{
3
PORTD ^= (1<<PD5);
4
LCDSetCursorPos(1,1);
5
LCDWrite("TEST");
6
_delay_ms(10);
7
}
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...
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???
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>
In der m50530.h wurden nur die Ports angepasst (auf Port D):
1
// data port, LCD signals DB4-DB7 have to be connected to P0-P3
2
#define LCDDATAPORT PORTD
3
#define LCDDATADIR DDRD
4
#define LCDDATAPIN PIND
5
6
// control port, LCD signals RW, EX, I/OC1, I/OC2
7
#define LCDCTRLPORT PORTD
8
#define LCDCTRLDIR DDRD
9
//#define LCDCTRLPIN PIND
10
#define LCDPIN_RW 7 //alt PD13
11
#define LCDPIN_IOC1 6
12
#define LCDPIN_IOC2 4
13
#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
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
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.
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
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....
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.
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...
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
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.
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)
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.
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.
Thomas K. schrieb:> Mensch, das hatte ich doch mal geschrieben und dann nachher nicht mehr> genutzt. Ich habe die Quellen mal angehangen.
Danke Thomas K.
Die Header Datei angepasst, und es lief.
Zum Glück findet man immer mal wieder so etwas, auch wenn der Thread
schon ein bisschen älter ist.
Hallo und zuerst mal Dank an alle die sich mit dem M50350
herumgeschlagen haben und ihre Erkenntnisse hier gepostet haben. Es war
sehr informativ.
So, nachdem ich mir 2 Nächte um die Ohren geschlagen habe läuft mein
SAMSUNG 2138A LCD das auch auf dem M50530 basiert. Das Samsung 2138A ist
ein 8 x 24 LCD, der M50350 unterstützt zwar nur 4 Zeilen, aber
Hardwaremässig ist das LCD so aufgebaut, dass es vom M50530 als 4 x 48
LCD angesehen wird. Dabei werden je 48 Zeichen auf die Zeilen 1&5, 2&6,
3&7 resp 4&8 aufgeteilt. Das nur als Info für die Interessierten.
Ursprünglich wollte ich das Busy Flag testen um festzustellen wann der
M50530 wieder ready ist neue Daten zu empfangen. Aber das hat einfach
nicht geklappt (daher auch die 2 Nächte). Nachdem ich es dann einfach
mit Delay Loops zum Funktionieren gebracht habe, bin ich auf die Suche
nach "Busy und M50530" gegangen und auf diesen Thread gestossen.
So wie es aussieht haben alle die hier ein M50530 basierendes LCD zum
Laufen gebracht haben entweder auch mit Delay Loops gearbeitet, oder
aber die Abfrage nach dem Busy ist mit so vielen Delays vor, zwischen
und nach dem setzen und löschen von EX versehen, dass es auch keine
Rolle spielt. Einzig nach einem CH Befehl verlangt ja der M50530 mehr
als 20usec um seine Arbeit zu erledigen (was dann erklärft warum die
Initialsierung funktioniert, aber der sofort anschliessend geschriebene
Text nicht, sondern nur Text der nach einem Delay von etwa 1.2ms
geschrieben wird)
Ich habe sogar extra im Code abgefragt, wie oft das Busyflag getestet
werden muss bevor der Controller Ready wird, aber ich kann machen was
ich will, es kommt immer 0 zurück. D.h. temp nach Aufruf von waitbusy
ist immer 0.
1
wait12c:
2
;
3
; Wait 12 Cycles including the 3 cycles of the rcall
4
; at 7.68MHz this is equivalent to 1.5usec
5
;
6
nop ; 1 cycle = 130ns
7
nop
8
nop
9
nop
10
nop
11
ret ; 4 cycle
12
13
waitbusy:
14
cbi LCDEX ; EX = Low
15
; rcall wait12c
16
cbi LCDIOC1 ; IOC1 = Low
17
cbi LCDIOC2 ; IOC2 = Low
18
clr temp ;
19
out porta,temp ; Clear Port A
20
out ddra,temp ; Set all 8 bits Port A as input
21
sbi LCDRW ; RW = High -> Read
22
waitbusy010:
23
rcall wait12c ; IOC Setup
24
sbi LCDEX ; Raise EX
25
rcall wait12c ; Wait
26
sbis LCDDATA,7 ; Skip if Busy
27
rjmp waitdone ; Busy = Low -> done
28
cbi LCDEX ; EX = Low
29
inc temp ; Count
30
rjmp waitbusy010 ; Execute RB again
31
waitdone:
32
cbi LCDEX ; Ex = Low
33
ret
Ich weiss der Thread ist schon über 6 Monate alt. Aber wer weiss
vielleicht findet sich jemand der mein Problem bestätigen kann,
respektive mir erklären kann warum das Lesen des BUSY immer Low zurück
gibt. Ich würde eigentlich lieber mit der BUSY FlagAabfrage arbeiten,
damit es F_CPU unabhängig wird. Über Hinweise bin ich dankbar.
Wie gesagt, mit Delay Loops entsprechend den Angaben im Datenblatt läuft
mein LCD einwandfrei. D.h. es ist alles richtig verkabelt, der Code
macht auch was ich will; bis auf die Abfrage des Busy Flag.
Autsch, das tut weh. Jetzt fällt es mir wie Schuppen aus den Haaren.
LCDDATA=PORTA, dort müsste natürlich PINA stehen. Und nun, Wunder oh
Wunder, funktionierts wie ich mir das schon immer vorgestellt hatte.
Thread beobachten
Seitenaufteilung abschalten