Hallo, ich hoffe jemand von Euch kann mir helfen. Ich versuche gerade ein 2 Zeiliges DOG-M Display (von Reichelt) über SPI in Betrieb zu nehmen. Wenn ich das richtig gesehen hab, ist der Clock im passiven Zustand auf HIGH und die Daten werden bei der steigenden Flanke übernommen. Ich versuche bisher die Initialisierung aus dem Datenblatt vom Controller auszuführen und hinterher eine kurze Zeichenkette auszugeben. Komischerweise wird die Zeichenkette jetzt ab und zu angezeigt, aber in den meisten Fällen wird nach nem Reset nichts oder nur Schrott ausgegeben. Ist da jemandem von Euch was bekannt, dass es da Probleme mit dem Timing oder ähnlichem geben könnte? Hoffe jemand kann mir helfen. Gruß Roland
Hallo Roland ! Scheint mir ein Timing-Problem zu sein. Hast Du das mal überprüft ?? LG Ron
Hallo Ronald, ich habe nur ein DOG-M 16-3 im 4 Bit Modus zum laufen gebracht. Ich weiß nicht, wie die SPI Version ist, aber beim "normalen" hatte ich erst auch einige Probleme, da es anders als andere Displays initialisiert werden muß. Bei mir war es erst so, daß das Display bein Power on nichts anzeigte. Nach einem Reset ging es plötzlich. Es hatte mit der Initialisierung zu tun. Die aus dem Datenblatt funktioniert bis heute bei mir nicht! Hier meine INIT des DOG-M 16-3 in C. _long_delay(); _lcd_init_write(0x30); _long_delay(); _lcd_init_write(0x30); _long_delay(); _lcd_init_write(0x30); _long_delay(); _lcd_init_write(0x20); _long_delay(); _lcd_ready(); // RS=0 _lcd_write_data(0x29); _lcd_ready(); // RS=0 _lcd_write_data(0x14); _lcd_ready(); // RS=0 _lcd_write_data(0x7A); _lcd_ready(); // RS=0 _lcd_write_data(0x51); _lcd_ready(); // RS=0 _lcd_write_data(0x6A); _lcd_ready(); // RS=0 _lcd_write_data(0x0C); _lcd_ready(); // RS=0 _lcd_write_data(0x01); _lcd_ready(); // RS=0 _lcd_write_data(0x06); // Zurück zur Tabelle 0:1 // _lcd_ready(); // RS=0 // _lcd_write_data(0X28); Vielleicht hilft es dir ja. Gruß Toby
Vielen Dank Euch beiden, ich werde mir meine Initialisierung nochmal anschauen und versuchen meine Leitungszustände mittels PullUps noch ein bisschen sauberer hinzukriegen. Hab mitm Oszi festgestellt, dass da ab und zu n paar ganz hässliche Spitzen beim umschalten drauf sind. Gruß Roland
Hi ich habe auch vor den 3x16 zu kaufen und über die SPI zu Steuern habe jedoch in der beschreibung keinerlei hinweise gefunden wie die SPI Schnittstelle zu betreiben ist könnt ihr mir da weiterhelfen DANKE!
zurück zu deinem problem in dem datenblatt http://www.electronic-assembly.de/eng/pdf/zubehoer/st7036.pdf steht "Bitte beachten Sie, dass aufgrund der COG-Technik die Strombelastbarkeit der Ausgänge begrenzt ist. Es kann dadurch bei größerer Buslast zu Signalverschleifungen und unsauberen Pegeln kommen. Im Zweifelsfall sind zusätzliche Pull-Down Widerstände (8051) erforderlich, oder es müssen zusätzliche Waits/NOP's eingefügt werden." Ich denke dass wird es wohl sein. Aber wie gesagt finde ich leider kein support über die SPI Schittstelle bitte um hilfe!!!
also ich kann nur sagen: mit der standard-initialisierung lt. datenblatt läufts via spi auch ohne pull-ups einwandfrei - nie ein problem gehabt. denba
Angehängte Dateien:
-
DSC00352.JPG
570 KB
Hallo, habe mir auch das DOG-M 163 über SPI angetan. Ich mach da jetzt schon seit Tagen rum, aber auf dem Display tut sich gar nichts. Nach dem Befehl Cursor ON müsste der ja eigentlich zu sehen sein. Meine Initialisierung hab ich unten aufgeführt. An der hab ich inzwischen keine Zweifel mehr. Display ON wait >40ms RS=0 0x38 wait >26,3µs 0x39 wait >26,3µs 0x1D wait >26,3µs 0x50 wait >26,3µs 0x6C wait>200ms 0x7C wait >26,3µs 0x0F wait >26,3µs 0x01 wait>2ms 0x06 und wie das auf dem Logik-Analyzer aussieht seht ihr im Anhang. Ich habe das CS- Signal allerdings noch etwas rausgezögert. Ich bin mir nur nicht sicher was den Clock im passiven Zustand betrifft. Der ist bei mir anders als im Datenblatt des ST7036 gefordert, LOW. Das müsste doch egal sein,oder? ich sollte vielleicht noch dazu sagen: Das SPI Bussignal wird hardaremässig mittels einem Microwire Interface Baustein (TP3465)erzeugt. Ich hoff mal, mir kann jemand weiterhelfen. Gruß, Forian
Hi Leute, ich hab' das Display mittlerweile auch zum laufen bekommen. Ich poste hier morgen mal meine Initialisierung und schau mal nach, wie ich die Pegel/Flanken an meinem SPI-Controller konfiguriert hab. Da das Teil jetzt schon seit längerem funktioniert hab ich das nicht mehr alles im Kopf. Ich verwende das integrierte SSI-Interface von einem Philips LPC2132-Controller. PullUps/-Downs verwende ich auch keine. Gruß Roland
Ich hab 2 Tage gebraucht, um einen SPI-Treiber für ein 16x2 DOG zu schreiben. Wenn mich nicht alles täuscht, stimmt eine Wartezeit im Datenblatt nicht(jedenfalls damals). Das Timing bei der Initialisierung ist relativ kritisch, danach funktioniert alles perfekt. Teilweise habe ich das Problem, wenn ich einen Reset mache, wird das Display nicht richtig initialisiert. Also nochmal das Timing prüfen...
Hallo Barti, das mit dem Timing hab ich mir auch gedacht. Deshalb hab ich auch da auch sehr drauf geachtet. Kannst du mir vielleicht mal dein Timing posten? Kann man auch zu lange Pausen setzen? Denk mal nicht, oder? Welche Frequenz hat denn dein Clock? Gruß, Florian
in der Doku steht wenn man probleme meiden möchte sollte man Pull Down Widerstände verwenden. Beim Neustart oder nach einem Reset soll es ab und zu zuunsauberen Pegeln kommen.
Wie gewünscht meine "quick'n'dirty" Initialisierung für ein 16x2 DOG mittels AVR: void LCD_Init(BYTE display) //LCD initialisieren { DDRB = (1<<RS) | (1<<CSB) | (1<<SPI_MOSI) | (1<<SPI_SCLK); PORT &= ~(1<<CSB); SPCR |= ((1<<SPE) | (1<<MSTR) | (1<<CPOL) | (1<<CPHA)); //SPI (Master) aktivieren mit CPOL = 1 und CPHA = 1 und fosc = 1/4 _delay_ms(40); PORT &= ~(1<<RS); LCD_SendCmd(0x38); //8-bit Datenlänge, 2 Zeilen, Instruction Table1 LCD_SendCmd(0x39); //8-bit Datenlänge, 2 Zeilen, Instruction Table1 LCD_SendCmd(0x1C); //Bias Set: 1/4, 2-zeiliges LCD LCD_SendCmd(0x74); //Kontrast C3, C2, C1 setzen LCD_SendCmd(0x52); //Booster aus, Kontrast C5, C4 setzen LCD_SendCmd(0x69); //Spannungsfolger und Verstärkung setzen _delay_ms(200); //Wartezeit bis Spannung stabil >200ms LCD_Switch(display); //Display ein LCD_Clear(); //Display löschen, Cursor Home LCD_SendCmd(0x06); //Cursor Auto-Increment } Hoffe das hilft. MfG Barti
Wie wird eigentlich der Sourcecode hier ordentlich dargestellt? Da gab
es doch mal so eine Funktion...
Hier noch die wichtige LCD_SendCmd() Funktion vergessen:
void LCD_SendCmd(BYTE Command)
{
PORT &= ~(1<<CSB);
_delay_us(1);
SPDR = Command;
while(!(SPSR & (1<<SPIF)));
_delay_us(30); //kleine Wartezeit um SPI-Daten zu
schreiben
PORT |= (1<<CSB);
}
Moin zusammen, hab den code Barti mal durchprobiert. Ging nicht so richtig.... Ist die Verdrahtung so richtig ? ATMEGA DOG-M ------------------------------------ PB0 -> RS PB1 -> CSB PB4(MISO) -> SI PB5(SCK) -> CLK hat vielleicht jemand ein code der mit SPI richtig funktioniert ? komme leider mit SPI und LCD garnicht klar ? hab ne atmega8 8Mhz, benutze WinAVR, hab den SPI teiler auf 16, also 500khz Gruß FS1
>PB4(MISO) -> SI
ne, MOSI muss nach SI (DOG)
(master out, slave in: daten vom uc zum display.)
Bye, Simon
den fehler hatte ich auch schon gefunden, aber leider klappt das auch so nicht FS1
Du must auf das Timing achten. Du darfst nicht zu schnell hintereinander zwei Bytes senden. Das habe ich gelöst, in dem ich die Frequemz des SPI-Takt relativ klein halte.
moin, hab jetzt den Teiler auf 32, also 250kHz. Sind die Timings nicht vom SPI Clock abhänging ? Auf Seite 43 stehen "wohl" die Timings von 380kHz, muss ich die umrechnen ?
der SPI Programme hängt ja auch an den Pins vom Display... Wenn ich jetzt nun den Code an den uC schicke, dann leuchte paar Zeichen usw auf, nachher ist manchmal dir blinkende cursor zusehen. Ist ja komisch, das irgendwelche wirren Daten das Display initialisiern können, und mein prog schafft das nicht :) Gruß FS1
Ab Seite 26 stehen die Ausführungszeiten. Achte z.B. darauf, dass "Clear Display" über 1ms benötigt, in dieser Zeit darfst du kein weites Komando senden. Soweit ich weiß, hängt das nicht von SPI-Takt ab.
erstmal vielen dank an alle die mir hilfreich tipps gegeben haben.
Die initialisierung klappt jetzt so einigermaßen, jedefall sehe ich
jetzt ne blinkenden cursor.
juhu, das DISPALY lebt :)
naja jetzt muss ich noch wat ordentliches anzeigen lassen
Gruß FS1
Hallo, die DOG-Module sind ja mit der COG-Technik gefertigt. Dh. der Chip und die Leitungen befinden sich direkt auf dem Glas. Ich hatte das Problem, dass ich das Display beim Einlöten zu sehr beansprucht habe und einige Verbindungen gebrochen sind. Könnte ja bei dem ein oder anderen hier auch das Problem sein. Gruß, Florian
Angehängte Dateien:
-
danke.jpg
47 KB
Hi, wollt mich nochmals bedanken... @Florina Das mit dem einlöten sieht ganz gut bei mir aus, die Pins sind recht stabil Gruß FS1
@FS1: Kannst du deinen Source und die gemachten Einstellungen speziell des Taktes bitte einmal posten! Danke!!
Vielleicht kann hier ja einer der Experten noch Licht ins Dunkel bringen :-) Ich versuch jedenfalls mich in das DOG-Lcd am SPI-Bus einzudenken. Eigentlich dachte ich, dass SPI bei den ATMegas MOSI, MISO, SCK und je Slave ein Slave-Select-Pin verwendet. Schau ich mir die Doku für das DOG Lcd an, so sehe ich dort MOSI, SCK, Slave-Select und RS. Laut Info hier wie auch woanders wird RS an einen freien Pin von Port B angeschlossen (und nicht an MISO). - Was macht RS dann? - Und - newbie Frage, ich weiss - ist diese 4-Draht-Lösung orginal SPI, auch wenn ich statt MISO einen anderen Pin/Port belege? cu & danke, Michael
RS kannst du an jeden IO Pin am AVR anschließen, nimm einfach einen den du sonst nicht brauchst. RS bestimmt ob die Daten die der AVR gerade ans Display schickt Steuerkommandos sind oder darzustellende Zeichen. MISO heißt Master In Slave Out, da das Display nichts sendet brauchst du es nicht (soweit du nur das Display am SPI hängen hast). Wenn du den AVR also als Master only benutzt könntest diesen Pin auch für RS nehmen (hab ich aber nicht getestet, schau mal ins Datenblatt deines AVR unter SPI).
Hallo gibt es mittlerweile denn eine funktionieren Initalisierung in Assembler? Ich komme mit der SPI gar nicht zurecht. Es wäre sehr nett wenn ein Vorposter, oder natürlich auch ein anderer :-) , mal nen Code bereit stellen könnten. Benutz nen Atmega8515 wie gesagt mit Assembler. Vielen Dank schonmal an die Profis die das Display zum Laufen gebracht haben^^ MfG Michael
@danilo, so hab ich es auch verstanden. Danke für die Erläuterung. Nur ging ich bis jetzt davon aus, dass bei einer sternförmigen Verdrahtung ich bei SPI 3 (MOSI, MISO, CLK) + <n> Pins benötige. <n> ist hierbei die Anzahl der Slaves. Mit dem DOG-Display brauche ich jetzt aber: MOSI, MISO, CLK, <n> Slave Select + RS, also ein Pin mehr. Das soll bei meinem Fall nicht das Problem sein, wundert mich aber schon :-) cu, Michael
@Michael Z.: Ja, so ist das bei diesem Display :) @Michael: ich habe nur Code für den GCC... prinzipiell basiert der aber auch nur auf den schon geposteten Beispielen + ein wenig rumprobieren.
Tag zusammen, hat jemand einen funktionierenden Quelltext für den SPI-Mode vom Dog-Display in Verbindung mit Bascom?! gruss Norbert
Nein ASM zuerst bitte :-) Sieht so aus als wohl öfter Probleme mit dem Display auftreten. Bin immernoch verzweifelt am rumprobieren um irgendwie dieses Display zu initialisieren. Code in Assembler wird gerne angenommen^^
Hmm, also poste mal deinen Code, dann schau ich mal was evtl falsch ist. Mir ist aufgefallen, das man den SPI Takt vor dem Senden "manuell" hochziehen muss, sonst gehts nichts.
Ich versuche auch verzweifelt eine 5V-Version aber als 4Bit. Bei mir ist auch das Display tot. Hat da vielleicht eine in assembler/bascom abhilfe? Vielen Dank
mh, also ich habe andere pin-configuration. Muß deswegen der assemblertext verändert werden? weil bei mir klappt das nicht...
du kannst das Display entweder so anschließen wie es im Basic Quelltext steht oder du passt den Quelltext an. unter dem CLS muss natürlich noch dein text in Form von LCD "TEXTTEXT" kommen.
Kenn mich ja nicht so aus aber hab jetzt schon ewig rumprobiert und komm nicht weiter. Hier mal mein Code für die Initialisierung: LCD_Init: rcall delay40us ldi A,0x38 rcall datatakt rcall delay30us ldi A,0x14 rcall datatakt rcall delay30us ldi A,0x78 rcall datatakt rcall delay30us ldi A,0x5E rcall datatakt rcall delay30us ldi A,0x6A rcall datatakt rcall delay200ms ldi A,0x0F rcall datatakt rcall delay30us ldi A,0x01 rcall datatakt rcall delay2ms ldi A,0x06 rcall datatakt rcall delay30us end: rjmp end Sollte nach der Initialisierung nicht wenigstens mal ein Cursor oder so zu sehen sein?! Oder was mache ich falsch? Danke schonmal für Eure Hilfe!
Hmm, die Initialisierung sieht nicht so schlecht aus. Ich würde vermuten der Fehler liegt im Timing, oder die Pegel deines SPI sind anders als es das LCD erwartet!? Manche SPI Chips übernehmen Daten bei fallender, andere bei steigender Flanke des Taktes.
Werd mir das nochmal anschauen und rumprobieren und mich dann nochmal melden^^
Wie ist denn die maximale Frequenz für mein Clock-Signal? Kann im DB nix finden.
Naja, ich hab 16.000.000 als uC Takt und 128 als Vorteiler. Die Timings im Datenblatt von EA sind für 380kHz - 700kHz angegeben.
Hat denn hier wirklich niemand einen funktionierenden Code in Assembler für diese Display? Ich denke auch das es ein Timing Problem ist aber hab mich ans DB gehalten und darüber hinaus jetzt auch schon sehr viel rumprobiert aber es will einfach nicht. Nach meiner Inttialisierung sollte doch wenigstens eine Cursor zu sehen sein oder!? MfG Michael
Ja sollte... ich nehme zwar an du hast... mal die elektrischen verbindungen kontrolliert?
Ja hab ich...nicht unr einmal :-) Das sollte aber soweit passen....kein Plan an was es liegen könnte. Bei SPI muss ich ja D5-D0 + E + RW auf 3,3 Volt legen. Kann ich diese Pins denn auch direkt an µC Pins hängen und diese auf High schalten? Oder hat der zuwenig Power oder so? Würd sich auf Steckbrett halt anbieten...
Ich bekomm es einfach nicht hin... Meint ihr es würde etwas bringen EA mal direkt anzuschreiben? Eher nicht oder...?
Dachte ich mir schon :) Ich habs auch aufm Steckbrett laufen und diese Pins direkt an VCC (bei mir allerdings 5v). Hmm, die sagen meist nur "Distributor fragen". Aber versuchs doch mal...
Welche Version des Displays hast du denn? Hast du mit oder ohne Beleuchtung da manche ja anscheinend dringend eine Beleuchtung brauchen und andere nicht...
Hmm, soll keine Blöde Frage sein ,also nicht falsch verstehen: Hast du die Caps für den 3.3 Betrieb richtig rum verbaut? Und kannst du mal 5v testen?
Ist mir recht wenn jemand frägt, egal was solange es helfen könnte. Hab mir die Caps nochmal angeschaut aber das passt. 5V passiert genau sowenig wie 3,3 V....nämlich nix :-( Oh mann Oh mann....mach an diesem sch**** Display rum und nix passiert.
probier doch meinen Code aus, den gibts in C und Assembler für alle möglichen Ansteuerungen. ist für ein zweizeiliges display, sollte aber schnell umzuschreiben sein. Über die Suche sollte der zu finden sein. Dann kann man die Init evtl. ableiten oder teilweise direkt übernehmen und hardwarefehler aussschließen. (habe den beitrag hier nicht komplett gelesen, erahne daher nur, wo probleme liegen)
Ja, würde ich auch vorschlagen. Teste mal Wolframs Code. Kannst auch meinen haben, müsstest da aber das Delay anpassen, da ich FreeRTOS benutze und dort einfach den Task suspendiere.
Also der Code funzt leider nicht. Keine Ahnung was da nicht passt aber das Display macht absolut gar nix. Hab jetzt mal auf 8bit umgestellt aber geht leider auch nicht. Vermute fast ein Timing-Problem aber hab schon so viel rumprobiert. Im Datenblatt sind ja Ausführungszeiten der Befehle bei 380KhZ...540Khz....700Khz angegeben. Wie kann ich denn die Frequenz ändern bzw. einstellen? MfG Michael
Na das Timing bestimmst du durch deinen SCK. Die Länge einer Periode -> 1/"HIGH über Low bis wieder High" (in s). Nimm einfach 1ms für (fast) alles, damit hat das Display genug Zeit zum "arbeiten".
Ja das ist klar aber bin gerade am testen mit 8bit Da fällt CLK ja weg... Aber das Display muss ja auch irgendeine "geschwindigkeit" haben. Also ich kann ja meine Befehle wahrscheinlich nicht alle direkt hintereinander senden sondern muss ein paar nops und so einfügen. Wie schnell erkennt oder reagiert das Display auf Flankenwechsel usw. mein ich.
Seh glaub bald vor lauter Bäumen den Wald nicht mehr. Bin gerade am grübeln ob die 8 Datenleitungen so stimmen weil das im Datenblatt Seite 4 etwas komisch beschrieben ist. Kommt da an Pin D7 des Displays das Bit 7 oder das Bit 0 an?
lol bin jetzt wieder bei SPI da das mit den 8bit auch nicht funktionierte. Mit dem call "Hardware Reset" ist das trennen von der Spannung bzw. einschalten der Spannung ausreichend oder? Oder muss ich da erst mit nem Pin auf low ziehen und anschliessend wieder auf High setzen?
Hallo erstmal, habe eigentlich das selbe Problem wie die meisten hier, bin jetzt schon seit ein paar Tagen dran, aber ich bekomme das DOG nicht über SPI initialisiert, ich habe die 8bit und die 4bit Initialisierung am laufen aber SPI will einfach net. Ich habe zuerst mit dem integrierten SPI des Mega 8 gearbeitet und bin mittlerweile "back2basics" da ich es einfach nicht verstehe warum das nicht läuft. Hier mal meine Initialisierung: rcall delay50ms ldi temp,0b00111000 rcall SPI_MasterTransmit rcall delay50us ldi temp,0b00111001 rcall SPI_MasterTransmit rcall delay50us ldi temp,0b00011100 rcall SPI_MasterTransmit rcall delay50us ldi temp,0b01111111 rcall SPI_MasterTransmit rcall delay50us ldi temp,0b01010010 rcall SPI_MasterTransmit rcall delay50us ldi temp,0b01101001 rcall SPI_MasterTransmit rcall delay250ms ldi temp,0b00001111 rcall SPI_MasterTransmit rcall delay50us ldi temp,0b00000001 rcall SPI_MasterTransmit rcall delay50us Laut Datenblatt sollte sie so laufen, ich habe aber auch schon andere folgen versucht: (0x38)(0x39)(0x1C)(0x74)(0x52)(0x69)(0x0C)(0x01)(0x06) (0x38)(0x39)(0x14)(0x78)(0x5E)(0x6A)(0x0C)(0x01)(0x06) Meine Hardware ist ein Mega8@1MHz und das Dog hängt an: PB0-CSB PB1-RS PB3-SI PB5-CLK Die SPI_MasterTransmit habe ich nun mittlerweile auf die mir einfachste bekannte weise geschrieben: sbrs temp,7 bis 0 cbi PortB,3 sbrc temp,7 bis 0 sbi PortB,3 sbi PortB,5 nop nop cbi PortB,5 usw. Eigentlich ähnlich der vorgehensweise im original Datenblatt.. aber es kommt einfach nix :-( Ich habe mal meinen assembler code angehängt, vielleicht kann man gemeinsam was finden woran es liegt, wenn man ja erstmal so ca. wüsste was man dem Ding schicken muss und in welchen abständen. Gruß an Alle :-)
Ok, ich hab mir nur den Ausschnitt angeschaut, nicht den gesamten Source. Hast du schonmal versucht deinen Takt "umzutauschen". Also anzunehmen das die Daten bei High->Low (jetzt ist wenn ich das richtig sehe Low->High) übernommen werden?
Hallo, so habe noch mal alles etwas umgeschrieben sbrs temp,7 cbi PortB,SI sbrc temp,7 sbi PortB,SI cbi PortB,CLK rcall delay50us sbi PortB,CLK rcall delay50us mit der Steigenden Flanke wird alles übernommen, zumindest sind im Datenblatt Pfeile an der steigenden Flanke, ich warte jetzt auch nach jedem Byte 50ms und das CLK Signal lasse ich im 50us Takt ansteigen und abfallen, dann sollte doch jetzt alles gehen, aber es tut sich einfach nix.... Ich sende Bit 7 bis Bit 0 und das nun mittlerweile extrem langsam, aber einfach kein erfolg :-( Vielleicht findet ja noch wer was. Gruß Maggi @Danilo: Danke für den Tipp :-)
Muss es denn unbedingt SPI sein? Hatte das auch versucht aber wollte einfach nicht klappen. Wie auch du habe ich am timing rum gemacht und probiert aber kein Plan warum es nicht geht. Hab jetzt den Code hier aus dem Forum für 8bit benutzt und jetzt läuft das Display einwandfrei. Also wenn du eventuell auf SPI verzichten kannst versuch erstmal den 8bit Code. Kannst danach wenn es läuft ja versuchen mal nach SPI hin anzupassen. MfG Michael
Hi, 8bit und 4bit habe ich schon am laufen, würde aber gerne auch noch spi zum laufen bekommen, würde natürlich im gegensatz zu 4bit noch mal 3 Leitungen sparen, das ist ja bekanntlich immer gut ;-) Außerdem hasse ich es wenn etwas nicht klappt ;-) Also ich hoffe mal das hier jemand noch ne erleuchtung hat, kann ja net sein das das so schwer ist, das SPI interface soll ja eigenlich eine erleichterung für den Programmierer sein und nicht ein Alptraum! Gruß Maggi
Ja wenn das so ist :-) Wie gesagt ich habs nicht hinbekommen aber wenn es bei dir klappt würd ich mir gerne mal den Code bzw. die init mal ansehen^^ Viel Glück noch!
Hallo, Freudige Nachricht, habe es jetzt endlich mit meinem SPI hin bekommen, habe auch gleich die Routine für den internen SPI das Mega8 geschrieben, jetzt läuft endlich alles :-) Wer es testen möchte hier die Pinbelegung (Kann unter den Definitionen natürlich geändert werden): CSB PB2(SS) SI PB3(MOSI) RS PB4(MISO) CLK PB5(SCK) Timings sind für einen Mega8@1MHz Danke noch mal an alle die gepostet und geholfen haben :-) Gruß Maggi P.S: Wer den Init noch mal in der alten (Simplen Form (sbrc/sbrs) haben möchte bitte kurze Mail)
Danke für die ganzen Infos hier! Ohne die wäre ich wohl wirklich aufgeschmissen gewesen. Anbei für C++ als Eclipse-Winavr (workspace verzeichnis) meine SPI-Lösung. Ein Umbau auf C sollte eigentich kein Problem sein. Getestet auf einem atmega32 mit 1 Mhz und 16 Mhz. Der Code ist noch nicht richtig schön, einige Debug-Anweisungen (PC.7) sind noch drin. Aber das wichtigeste kann man hoffentlich erkennen. Vielleicht kanns ja jemand gebrauchen cu, Michael
@ALLE ein sehr nützlicher Thread, hat mir sehr viel Zeit erspart, den ST7036 im SPI Modus zu initialisieren. Danke Bernhard
Hi, hab leider auch noch Probleme und hab mittlerweile allesmögliche getestet. Vielleicht findet jemand ja die Zeit sich folgendes durchzulesen. Beitrag "Probleme mit DOG-M (128x64)" Danke ;-)
Ein lauffähiges Beispiel mit einem DOG-LCD 128x64 für einen Atmega8 in Assembler: Beitrag "DOG LCD 128x64 Initialisierung ATmega8 (Assembler)" Bernhard
Hallo Leute! Nach langem hin und her habe ich es geschafft meinen Bildschirm zum laufen zu kriegen. Dabei bin ich auf ein paar Merkwürdigkeiten gestossen die evtl. auch bei anderen vorkommen. Daten: DOGM 163 LCD 5V Hardware SPI Modus ATmega168 Dragon (USB Programmer) Ich habe festgestellt dass der Bildschirm sich manchmal initalisieren liess als er am ausgeschalteten (!) Programmer hing. Hab dann mal am RS Port des Bildschirms (hängt an MISO) die Pegel gemessen. Mein Messgerät hatte einen schwachen Akku also sind die Werte nicht exact. Am Programmer angeschlossen (vom PC getrennt) liegt high bei 2,8V und low bei 0V. Abgekoppelt liegt high bei 4,6V und low bei 1,8V! Die meisten anderen getesteten Ports erzeugen fast 0V bei low. Ist das eine Eigenheit des MISO Ports? Ich habe dazu nirgends was finden können. Na jedenfalls half dann ein Pulldown-Widerstand von etwa 600kOhm zwischen GND und MISO/RS um Pegel von 0V / 3,2V zu erreichen. Damit lässt er sich zuverlässig initialisieren. Belegung: RS -> MISO CSB -> Masse CLK -> SCK SI -> MOSI Initialisierung: sendcmd(0b00111001,0); //Instruction table 1 sendcmd(0b00111001,0); //Instruction table 1 sendcmd(0b00010101,0); //bias /frequency sendcmd(0b01110000,0); //power control 0b01010000 sendcmd(0b01101100,300); //follower control sendcmd(0b01111101,0); //contrast 0b01111101 sendcmd(0b00111000,0); //Instruction table 0 sendcmd(0b00001100,0); //display on, cursor settings sendcmd(0b00000001,5); //clear lcd sendcmd(0b00000110,0); //entry mode Hoffe das hilft einigen
Ist das eine ansteckende Seuche? Warum denkt dieses Wochenende jeder hier, dass man Schaltungen besser verbal als bildhaft rüberbringt?
HellStorm wrote: > Ich habe festgestellt dass der Bildschirm sich manchmal initalisieren > liess als er am ausgeschalteten (!) Programmer hing. > ... > CSB -> Masse Ja, das ist ja auch kein Wunder, daß es nur zufällig funktioniert, wenn Du CSB fest auf GND hängst. Damit fehlt jede Möglichkeit für LCD und AVR, sich zu synchronisieren. Die SPI-Pins des AVR sind ja nach dem Reset tristate, d.h. floaten wild rum. Daß dann das LCD synchron ist, ist reiner Zufall. Die Pulldowns entschärfen das leicht, aber zuverlässig ist das noch lange nicht. Mach mal ein Reset ohne Powerdown und wenn dabei grad das LCD angesteuert wurde, sind sie wieder asynchron. Wenns zuverlässig sein soll, muß man den CSB-Pin vom AVR mit ansteuern. Das hat dann auch den Vorteil, daß man weitere SPI-Chips (z.B. 74HC165/74HC595) mit ansteuern kann. Es hat schon seinen guten Grund, daß im SPI-Schaltbild im Datenblatt der CSB nicht direkt auf GND gelegt ist, sondern vom MC angesteuert wird. Ich hatte noch nie Probleme mit dem DOG-M, weil ich immer den CSB benutze. Peter
CSB hing vorher an einem Port. RESET hing an VCC. Ich musste CSB dann auf GND legen weil keine Ports mehr frei hatte und den RESET ansteuern wollte. In beiden Fällen, also auch mit CSB an SS, lief der Bildschirm nicht zuverlässig. Also künftig 5 Ports für den Bildschirm frei halten....
Laut Datenblatt kann man den RESET Pin doch einfach an Vcc hängen! Dann resettet das Display selbst, wenn zwischendurch der Saft weg war. Mehr braucht man doch nicht, oder?
Ja RESET kann normalerweise an VCC (dort hing er auch vor der Umstellung wie bereits erwähnt). Aber zu Testzwecken war es doch praktisch den anzusteuern um zu sehen wann sich der LCD initialisieren liess ohne ständig den Saft an und aus zu schalten.
Nach tagelanger Suche läuft nun auch mein EA DOGM162-A mit SPI (der Cursor blinkt, juhu!!), der Code von Maggi hat mir geholfen. Mein Fehler war, dass ich CSB per Atmega328 (10 MHz, 3,3V) gleich von Anfang an auf 0 geschaltet habe, ohne es vorher auf 1 zu schalten. Da passiert einfach gar nichts (Reset ist fest mit 3,3V verbunden). Meine Routine sieht nun so aus: CSB=1 40 ms warten für "VDD stable" CSB=0 Initialisierung so wie im Datenblatt von LCD-Module.de beschrieben. Die Wartezeiten nach den jeweiligen Befehlen (Function Set etc. siehe Datenblatt ST7036) dürfen auch deutlich länger sein, in meinem Fall sind es z.B. 26 ms anstatt der 26,3µs. SPI Geschwindigkeit hat bis 2,5 MHz funktioniert.
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.