EA DOGM162 Problem

Bruno M. schrieb:

Hat jemand einen Tip?

Ja,

1. den verwendeten Code zeigen (Anhang),
2. den verwendeten Schaltplan anhängen (pdf),
3. die aufgebaute Schaltung zeigen (Foto),
4. das Datenblatt zum Display verlinken,
5. schreiben, welche Messmittel (Oszilloskop/Multimeter/Logikanalysator) zur Verfügung stehen.

Rick schrieb:

Bruno M. schrieb:

Hat jemand einen Tip?

Ja,

1. den verwendeten Code zeigen (Anhang),
2. den verwendeten Schaltplan anhängen (pdf),
3. die aufgebaute Schaltung zeigen (Foto),
4. das Datenblatt zum Display verlinken,
5. schreiben, welche Messmittel (Oszilloskop/Multimeter/Logikanalysator) zur Verfügung stehen.

Code, Schaltplan sind im aufgeführten Link, die Schaltung entspricht dem Schaltplan, der Hinweis auf den Controller findet sich im Link.

Signale habe ich mit einem analogen Oszi geprüft. Ich kann kein Problem erkennen.

Bruno M. schrieb:

Nach diversen Versuchen bin ich nun dahinter gekommen, daß das Display nur nach dem Flashen startet. Oft auch erst beim 2. Mal.

Mit welchem Takt läuft der Controller?

Hmmm schrieb:

Bruno M. schrieb:

Nach diversen Versuchen bin ich nun dahinter gekommen, daß das Display nur nach dem Flashen startet. Oft auch erst beim 2. Mal.

Mit welchem Takt läuft der Controller?

Wie von Bernhard angegeben: 1 MHz

Bruno M. schrieb:

Wie von Bernhard angegeben: 1 MHz

Dann solltest Du Dir das mal mit einem Logic Analyzer (billiger Saleae-Clone reicht) ansehen.

Dass es mal funktioniert und mal nicht, klingt nach falschem (zu schnellem) Timing.

Hmmm schrieb:

Dann solltest Du Dir das mal mit einem Logic Analyzer (billiger Saleae-Clone reicht) ansehen.

Das kann ich mal versuchen! Ich meine, ich habe noch irgendwo einen vergraben.

Wie kommt Bernhard S. auf die 10 us, bei einem CPU-Takt von 1 MHz?

1

; rcall 3 Takte                                                                 

2

;  ret  4 Takte                                                                 

3

;                                                                               

4

...

5

...

6

WAIT_10us:

7

ret

S. L. schrieb:

Wie kommt Bernhard S. auf die 10 us, bei einem CPU-Takt von 1 MHz?

1

> ; rcall 3 Takte

2

> ;  ret  4 Takte

3

> ;

4

> ...

5

> ...

6

> WAIT_10us:

7

> ret

8

>

Sei doch nicht so penibel. Bloß 30% zu kurz. Das stimmt doch fast ;o)

S. L. schrieb:

Wie kommt Bernhard S. auf die 10 us, bei einem CPU-Takt von 1 MHz?

Das ist zwar ein guter Hinweis, aber eine Änderung hat leider nichts gebracht. Ich habe mir in der Zwischenzeit auch noch mal die Timing-Vorgaben im Datenblatt angesehen. Eigentlich hat Bernhard überall sehr viel Luft gelassen: Soll Ist

• vor Initialisierung >40ms 100ms
• nach dem ersten Schritt >1,6ms 10ms
• danach jeweils >26,3us 1ms
• nach Initialisierung >26,3us 100ms + 1s bleibt noch das toggeln von EN, aber auch da ist mit 50us genug Zeit eingebaut.

Bruno M. schrieb:

• danach jeweils >26,3us 1ms

Clear Display und Return Home brauchen mindestens 1.08ms.

Bruno M. schrieb:

Ich habe mir in der Zwischenzeit auch noch mal die Timing-Vorgaben im Datenblatt angesehen. Eigentlich hat Bernhard überall sehr viel Luft gelassen: Soll Ist

• vor Initialisierung >40ms 100ms

Das ist oft ein kritischer Punkt, wenn man sein Gesamtsystem nicht überblickt. Was passiert auf den Leitungen, bevor der zuständige Treiber die Kontrolle darüber übernimmt?

Hier hauen gerne mal schlecht programmierte Bestandteile der ohne Sinn und Verstand zusammenkopierten Software rein. Oder auch genauso ohne Sinn und Verstand designte Hardware...

Bei der Identifizierung eines Problems in diesem Bereich hilft übrigens ein LA nicht. Da muss es schon wirklich ein Oszi sein.

... daß das Display nur nach dem Flashen startet. Oft auch erst beim 2. Mal.

Bernhard S. hat das LCD auf den Port B gelegt - über diesen läuft aber auch das Programmieren (Flashen). Was passiert, wenn stattdessen Port D benutzt wird?

Tja - ich nehme einen ATmega16 und ein uraltes 2*16 LCD, und es erscheint "HALLO", mit völlig unverändertem Programm.

Im 5V 4-Bit Modus ist Vin mit Vout zu verbinden und dort 5V einzuspeisen. Das DOGM163 läuft bei mir völlig problemlos, ich benutze aber SPI und 3,3V Betrieb.

Bruno M. schrieb:

Allerdings beschränke ich mich im wesentlichen auf ASM.

Ja, man kann sich auch selber Knüppel zwischen die Beine werfen. Was stört Dich an zuverlässig funktionierenden C-Beispielen?

Da die Leitungen auf dem Glas sehr hochohmig sind, sollte man Code mit Busy Rücklesen nicht benutzen, sondern nur welchen mit Delays.

Erstmal danke für das Interesse und die guten Ratschläge.

Ich habe den Fehler gefunden! Ist mir zwar peinlich, aber da muß ich jetzt durch!

Da ich übernommene Codes auch verstehen möchte, schreibe ich sie grundsätzlich neu, auch wenn ich nichts ändern will. So auch hier. Dabei habe ich aus Versehen das RS Signal vor der Initialisierung nicht auf low gesetzt. So nahm das Drama seinen Lauf!

Bruno M. schrieb:

Erstmal danke für das Interesse und die guten Ratschläge.

Ich habe den Fehler gefunden! Ist mir zwar peinlich, aber da muß ich jetzt durch!

Da ich übernommene Codes auch verstehen möchte, schreibe ich sie grundsätzlich neu, auch wenn ich nichts ändern will. So auch hier. Dabei habe ich aus Versehen das RS Signal vor der Initialisierung nicht auf low gesetzt. So nahm das Drama seinen Lauf!

Also, wie von mir vermutet: Das Problem lag vor der eigentlichen Initialisierung.

Oder anders ausgedrückt: die Intialisierung ist offensichtlich unvollständig. Wenn der Zustand von RS eine Rolle spielt, dann hat die Initialisierung sich natürlich auch um dieses Signal zu kümmern.