Hallo, hab mir zum Basteln ein DOG-M 16x2 geholt, welches per SPI an einen Mega2561 angeschlossen ist. Display funktioniert soweit, nur wird der Text an einer falschen Stelle wiedergegeben. Die Wartezeiten zwischen den Kommandos und Daten sind eigentlich großzügig überdimensioniert, der SPI läuft in der langsamsten Stufe. Was könnte ich übersehen haben? Habe mich an den hier zu findenen DOG-M Routinen und am Datenblatt des Displays orientiert.
Hallo, Karl-Heinz schrieb: > Was könnte ich übersehen haben? Habe dir mal meinen Code mit einem Atmega644V angehängt. Das ist zwar nur ein Software-SPI, dafür funktioniert er auf allen Atmegas... Zumindest kannst du den Code mit deinem vergleichen. Gruß XMEGA
Karl-Heinz schrieb: > Was könnte ich übersehen haben? Ich will dir mal das von dir gelieferte Informationsniveau an einem adäquaten Vergleich zeigen. "Mein Auto, VW Golf Baujahr 1992 ist defekt - weitere Informationen gebe ich nicht heraus - was muss ich machen, damit er wieder läuft?" Der ADAC-Mann wird bei dieser Informationsfülle nichts machen können. Darum: 1. Schaltung, Beschreibung 2. Bild von der Schaltung (Kabel, etc) 3. Source-Code (!) 4. Genaue Fehlerbeschreibung Diese 4 Punke sollen wir wohl erraten? Fragen wir die Glaskugel ... Nein im Ernst - bitte bemühe dich um eine konkrete Beschreibung, nur so können wir effektiv helfen.
> 1. Schaltung, Beschreibung > 2. Bild von der Schaltung (Kabel, etc) > 3. Source-Code (!) > 4. Genaue Fehlerbeschreibung Dachte eigentlich mit 4. hätte ich gedient. Für 1-3 müsste ich mehr Zeit investieren als ich in den Aufbau und Programmierung für einen Schnelleinstieg uC+Display gesteckt habe. Ich bastel das nun auf 4bit um, wenn der Fehler immer noch auftritt, weiß ich, wo ich suchen muß. Geht schneller... Danke XMEGA für den Sourcecode. Werde den mal anschauen, vielleicht finde ich noch was.
Hier ist auch noch Beispielcode - zwar für das DOGM163 an 5V via SPI, aber ist ja ähnlich: https://github.com/znuh/unsorted/blob/master/gm_counter/main.c
Hi >Diese 4 Punke sollen wir wohl erraten? Fragen wir die Glaskugel ... Unterlasse bitte dieses 'wir'. Es gibt hier mit Sicherheit nicht viele, die mit dir in einen Topf geworfen werden wollen. Und da Text auf dem Display erscheint, ist die Hardware uninteressant. Die funktioniert ja. >Was könnte ich übersehen haben? Habe mich an den hier zu findenen DOG-M >Routinen und am Datenblatt des Displays orientiert. Hast du dir auch das Datenblatt vom Displaycontroller angesehen? Das ist maßgebend. Manchmal gibt es da kleine, aber feine Unterschiede zum EA-Datenblatt. Poste mal deinem Code. MfG Spess
> Hast du dir auch das Datenblatt vom Displaycontroller angesehen? Das ist > maßgebend. Manchmal gibt es da kleine, aber feine Unterschiede zum > EA-Datenblatt. Ja, aber ich schau's mir nochmal durch. Vielleicht ziehe ich dem Display nach nem Kommando zu schnell RS/CS weg? Mal ausprobieren. > Poste mal deinem Code. Ja, erst noch etwas säubern. Der entstand so nebenbei bei nem Bierchen auf'm Balkon :-)
Wie lang ist die Verdrahtung? Steht ein Oszilloskop zur Verfuegung? Ist die Stelle immer konsistent gleich falsch? Ist bekannt dass die Addressluecke bei 44780-artigen Displays mitunter an bescheuerten Stellen liegt?
> Wie lang ist die Verdrahtung? 4cm. > Steht ein Oszilloskop zur Verfuegung? Mehrere. Sauberes Signal. Ist ja auch ein niedriger SPI-Takt. Wobei der SPI-Takt auf das Symptom keine Auswirkungen zu haben scheint. > Ist die Stelle immer konsistent gleich falsch? Nein. Der Text wird an der gewollten Stelle ausgegeben, gelegentlich wird ein falsches Zeichen dargestellt, entweder im Text oder an einer zufälligen Stelle. Vermutlich Timingproblem. > Ist bekannt dass die Addressluecke bei 44780-artigen Displays mitunter > an bescheuerten Stellen liegt? Ja. Das Display funktioniert ja auch soweit, nur tauchen, besonders bei schnellem Textwechsel diese Geisterzeichen auf. Ich muß mal noch mit nem Delay bei Register Select / Chip Select spielen. Kann sein, dass da der 16MHz Mega2561 das Display überrennt.
#define DOGM_DELAY_S 500 #define DOGM_DELAY_L 5000 _delay_us(DOGM_DELAY_L); SPI_Data(0x06); _delay_us(DOGM_DELAY_S); http://linux.die.net/man/3/_delay_us void _delay_us (double __us): ... The maximal possible delay is 768 us / F_CPU in MHz. Wie wärs mit _delay_ms ?
>SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0);
Der SPI mode ist falsch.
CPHA und CPOL müssen gesetzt sein (mode 3).
Sonst ist der Leerlaufpegel von SCK nicht high, so wie gefordert.
Siehe Seite 47 im Controllerdatenblatt.
Grüße,
Peter
@Igor: Das ist zwar unschön, dass _delay_us mit 5000 aufgerufen wird, führt aber schlimmstenfalls dazu, dass die Verzögerung länger ist, als erwartet. Siehe: http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html "If the user requests a delay greater than the maximal possible one, _delay_us() will automatically call _delay_ms() instead. The user will not be informed about this case." Daran wird es also vermutlich eher nicht liegen. Zudem lässt sich das mittels Oszi ja leicht prüfen. Grüße, Peter
Peter Diener schrieb: > Der SPI mode ist falsch. > CPHA und CPOL müssen gesetzt sein (mode 3). > Sonst ist der Leerlaufpegel von SCK nicht high, so wie gefordert. > Siehe Seite 47 im Controllerdatenblatt. SPI ist wohl nicht SPI, schon wieder was dazu gelernt. Werde das mal ändern. Heißt das auch, daß ich bei mehreren SPI-Slaves ggf. je nach Slave den SPI-Mode ändern muß? Vielen Dank!
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.