Vorweg es geht nicht um eine Arduino spezifische Frage/Problem. Ich habe ein seltsames Problem, das mich seit Tagen beschäftigt und wobei ich nahe an der Verzweiflung bin, weil ich keine Lösung finde. Eigentlich dürfte es das Problem gar nicht geben. Hintergrund Ich benutze häufig als HW im Einsatz für bestimmte Projekte Arduino-Boards. In der Regel Arduino Nano. Es erspart mir die Erstellung eigener PCB’s. Ich stecke sie, die Nanos, auf eigene Schield’s. Die Arduino-Boards werden nicht mit der Arduino-IDE oder Arduino Librarys programmiert. Der Bootloader ist entfernt und die Fuses sind entsprechend eines „normalen“ Atmegas gesetzt. Also das Arduino-Board dient lediglich als HW-Platform. Die Entwicklung und Testung des Codes wird auf einem SDK600 durchgeführt. Als IDE dienst AVR Studio 7. Funktiniert alles wird dann in der Regel via ISP mittels AVRONE! Oder Atmel-ICE auf das Arduino-Board geflasht. Und anschließend die Peripherie unter Beachtung der Arduino eigenen PORT Nomenklatur angeschlossen. So weit so gut und das hat bisher immer und ausschließlich zu 100% Funktioniert. Dieses Vorgehen soll hier bitte nicht Gegenstand einer Diskussion werden. Zum aktuellen Problem: Eine eigene Routine zum ansteuern LDC HD44780 im Mix aus Assembler und C, Core Routinen hauptsächlich in Assembler. Auch dieses Vorgehen soll bitte kein Diskussionsgegenstand werden, denn es ist unerheblich für das Problem. Es wird der 4-Bit Modus verwendet. Dafür werden die unteren 4 Bits des PORTC (PC0 – PC3) verwendet. RS liegt auf PC4, EN auf PC4. RW wird über PB0 angesteuert. Im Entwicklungssetting, Atmega 328P auf SDK600 läuft die LCD Ansteuerung auf diversen LCDHD44780 problemlos. Wird nun der Code auf ein Arduino-Nano Board geflasht. Ich habe 5 Verschiedene Probiert. Bei allen bleibt das LCD ohne Ausgabe. Auch bei einem Arduino Uno. Besonderheit: Drückt man wie wild mehrere male hintereinander den Reset-Button... erscheint gelegentlich mal ein oder mehrere Buchstaben der zu erwartenden Ausgabe Zeile „Hello World“. Hört sich nach Wackelkontakt an. Ist aber ausgeschlossen. Flashe ich aber nun mit der Arduino IDE und der Arduino eigenen LCD Bibliothek ein „Hello World“, was die selben Ports und Port-Bits verwendet so funktioniert das einwandfrei. Damit sollte ein eh schon unwahrscheinlicher HW Fehler eigentlich ausgeschlossen sein. Und alles schreit nach SW Fehler. Also das unangenehmere. Aber wie ließe sich ein SW-Fehler annehmen, wenn auf dem Setting Atmega328P auf dem SDK600 der LCD Treiber problemlos läuft??? Ich bin leider mit meinem Latein am Ende. Aber ich bin auch nicht besonders Klug. Ist vielleicht jemand pfiffiger als ich und hat eine Idee was dieses Phänomen begründen könnte. Vielen Dank, Thomas
Gast
#6342468
Schaltplan geheim. Programm geheim. Fuses geheim. Also: Du hast mein volles Mitgefühl! Aber helfen kann ich dir so nicht.
Aloysius P. schrieb: > Wird nun der Code auf ein Arduino-Nano Board geflasht. Ich habe 5 > Verschiedene Probiert. Weil es nur PC4,PC5 und PC6 auf den Headern des Nanos gibt? (Text ist mir zu lang um alles zu lesen)
Unterschiedliches Reset-Verhalten auf beiden boards? Was passiert, wenn das LCD langsamer angesteuert wird? MfG
Gast
#6342484
Philipp K. schrieb: > Text ist mir zu lang Nicht nur lang, sondern auch verwunderlich Aloysius P. schrieb: > RS liegt auf PC4, EN auf PC4.
Gast
#6342489
Sowas ähnliches hatte ich letzte Woche auch, Ursache war letztlich ein defekter Atmega auf dem Arduino. Das Ding war neu "out of Tüte" und zu allem Übel hatte ich den eingelötet, nicht gesteckt. Also wieder rausgefummelt, Buchsen rein und der Nächste bitte. Damit und allen anderen (hatte 10 geordert) ging es dann wie gewünscht. Gestern dann mit einem nackten Atmega328 (TQFP) (nix Arduino) auch nur Ärger, der Programmer sagt immer "kein Target" (oder so). Jede Leitung mehrfach durchgeklingelt, Spannungen gemessen, Quarz überprüft, alles bestens, doch die Gurke will nicht. Heute abend löte ich mal einen neuen auf, auch aus der Reicheltlieferung (ich ahne Böses) Ich muss mir mal einen der teuren Adapter beschaffen. Old-Papa
Hallo, vor Jahren mal bekam ich von Reichelt zwei angeschossene Mega88 geliefert. Beim Programmieren reagierten sie noch ein Stück weit, bis nichts mehr ging. Die Elektrostatik läßt grüßen. MfG
Gast
#6342506
Christian S. schrieb: > Hallo, > > vor Jahren mal bekam ich von Reichelt zwei angeschossene Mega88 > geliefert. Beim Programmieren reagierten sie noch ein Stück weit, bis > nichts mehr ging. Die Elektrostatik läßt grüßen. > > MfG Nun, ich hätte stutzig werden sollen.... Die haben 328er für 1,94 im Programm, aber auch einen gleichen ("Gurtware") für 1,51. Davon hatte ich wieder 10 geordert, eben den 2. getestet, "Kann Zielchip nicht erreichen". Wahrscheinlich mal wieder ein Griff ins "Reichelt-Klo" Old-Papa
Angehängte Dateien:
-
Zielchip-def.JPG
(230 KB)
Was ist denn auf den Nanos für ein Prozessor drauf? Oliver
Gast
#6342517
Oliver S. schrieb: > Was ist denn auf den Nanos für ein Prozessor drauf? Original: ATMega328P Gibt aber auch welche/Nachbauten mit MD-328D(und Vorgänger davon)
Old P. schrieb: > Sowas ähnliches hatte ich letzte Woche auch, Ursache war letztlich ein > defekter Atmega auf dem Arduino. Das Ding war neu "out of Tüte" und zu > allem Übel hatte ich den eingelötet, nicht gesteckt. Also wieder > rausgefummelt, Buchsen rein und der Nächste bitte. Damit und allen > anderen (hatte 10 geordert) ging es dann wie gewünscht. > > Gestern dann mit einem nackten Atmega328 (TQFP) (nix Arduino) auch nur > Ärger, der Programmer sagt immer "kein Target" (oder so). Jede Leitung > mehrfach durchgeklingelt, Spannungen gemessen, Quarz überprüft, alles > bestens, doch die Gurke will nicht. > Heute abend löte ich mal einen neuen auf, auch aus der Reicheltlieferung > (ich ahne Böses) > Ich muss mir mal einen der teuren Adapter beschaffen. > > Old-Papa Hallo und danke! Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der selben Ports läuft alles. Und ins. 6 Boards getestet. Thomas
Oliver S. schrieb: > Was ist denn auf den Nanos für ein Prozessor drauf? ATmega328P. Vielleicht ja auch sein Eigenbau Shield defekt. Leiterbahn gerissen, kalte Lötstelle etc. Ich hoffe das ist nur hier ein Schreibfehler. > Dafür werden die unteren 4 Bits des PORTC (PC0 – PC3) verwendet. RS liegt > auf PC4, EN auf PC4. RW wird über PB0 angesteuert.
Aloysius P. schrieb: > Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der > selben Ports läuft alles. Und ins. 6 Boards getestet. Na dann kann es doch nur an deiner eigenen Software liegen. Vielleicht ist ja nur die Initialisierung vom Display leicht fehlerhaft. Timing o.ä. Mehr gibt die Glaskugel nicht her.
Arduino Fanboy D. schrieb: > Oliver S. schrieb: >> Was ist denn auf den Nanos für ein Prozessor drauf? > > Original: ATMega328P > Gibt aber auch welche/Nachbauten mit MD-328D(und Vorgänger davon) 328P original selbe wie im SDK600 steckt
Veit D. schrieb: > Aloysius P. schrieb: > >> Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der >> selben Ports läuft alles. Und ins. 6 Boards getestet. > > Na dann kann es doch nur an deiner eigenen Software liegen. > Vielleicht ist ja nur die Initialisierung vom Display leicht fehlerhaft. > Timing o.ä. Mehr gibt die Glaskugel nicht her. Hab ich mir natürlich auch gedacht, denn meist ist es das ja. Aber warum läuft die Fehlerhafte SW im SDK600 auf diversen Atmegas... aber ich werde die timings noch mal durchgehen...
Veit D. schrieb: > Oliver S. schrieb: >> Was ist denn auf den Nanos für ein Prozessor drauf? > ATmega328P. > > Vielleicht ja auch sein Eigenbau Shield defekt. Leiterbahn gerissen, > kalte Lötstelle etc. > > Ich hoffe das ist nur hier ein Schreibfehler. >> Dafür werden die unteren 4 Bits des PORTC (PC0 – PC3) verwendet. RS liegt >> auf PC4, EN auf PC4. RW wird über PB0 angesteuert. Ist kein Eigenbau im Einsatz... LCD direct am Board
Beitrag #6342531 wurde von einem Moderator gelöscht.
Beitrag #6342535 wurde von einem Moderator gelöscht.
Arduino Fanboy D. schrieb: > Philipp K. schrieb: >> Text ist mir zu lang > > Nicht nur lang, sondern auch verwunderlich > > Aloysius P. schrieb: >> RS liegt auf PC4, EN auf PC4. Tipfehler! (RS = Register select) <-> PORTC PortBit 4 (EN = Enable) <-> PORTC PortBit 5
Invisible Man schrieb im Beitrag #6342535: >>> Ich hoffe das ist nur hier ein Schreibfehler. >>>> Dafür werden die unteren 4 Bits des PORTC (PC0 – PC3) verwendet. RS liegt >>>> auf PC4, EN auf PC4. RW wird über PB0 angesteuert. >> >> Ist kein Eigenbau im Einsatz... LCD direct am Board > > Hast Du einen Multiplexer drin, der PC4 wegen der Doppelnutzung > umschaltet und natürlich auch ein Latch? Sory war Tippfehler! (RS = Register select) <-> PORTC PortBit 4 (EN = Enable) <-> PORTC PortBit 5
Invisible Man schrieb im Beitrag #6342531: > So, wie Du das beschreibst, liegt es an AVR Studio 7. Ich habe den Dreck > auch wieder heruntergeworfen, weil er schwerfällig und fehleranfällig > ist. > > Mache Studio 4.19 drauf. Das haut hin. Halte ich für fast ausgeschlossen.... denn der Code läuft auf dem SDK600. Ich werde das ganze auch noch mal auf einen DIP 328P Flashen un auf dem Breadbord in minimalconfig xchecken..
Hallo, also das/die Shields sind keine Eigenbauten? Ansonsten solltest du nochmal in Kurzform notieren welche Software (deine oder Arduino) worauf funktioniert und wo nicht. Ich blicke aktuell nicht mehr durch.
Aloysius P. schrieb: > wird der 4-Bit Modus verwendet. Dafür werden die unteren 4 > Bits des PORTC (PC0 – PC3) verwendet. RS liegt auf PC4, EN auf PC4. RW > wird über PB0 angesteuert. Nochmal..wie schon vorher geschrieben der Nano besitzt kein PC0-PC3, an welchen Digital Pins sind die 4 Bits angeschlossen? Quelltext der LCD initialisierung?
Gast
#6342571
Aloysius P. schrieb: > Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der > selben Ports läuft alles. Also bist du der Meinung, dass es an der Software liegen muss. Wie sillen wir dir nun helfen, ohne dass du sie vorzeigst? Wie gesagt könnte es am Reset verhalten (insbesondere dem Timing) sein. Das Arduino Modul startet vielleicht schneller, als dein Entwicklungsboard und die Software von Arduino berücksichtigt dies angemessen, während es deine Software nicht tut. Das wäre ein mögliches Szenario.
Gast
#6342576
Philipp K. schrieb: > wie schon vorher geschrieben der Nano besitzt kein PC0-PC3 Dann guck mal auf das obige Bild in Beitrag "Re: HILFE Seltsames Verhalten Atmega 328P auf Arduino-Board mag Code nicht" Ich sehe sie dort auf der rechten Seite.
Philipp K. schrieb: > Nochmal..wie schon vorher geschrieben der Nano besitzt kein PC0-PC3, an > welchen Digital Pins sind die 4 Bits angeschlossen? Quelltext der LCD > initialisierung? Das ist wiederholt falsch. PC0 ... PC5 sind herausgeführt.
Ah ups sorry, hatte es auf dem Rechner verlegt und bin wohl bei google Bilder am Pinout des "Nano Every" vorbeigekommen. Bei den Nano Clone Boards ist wohl manchmal A0-A? verkehrt herum rausgeführt.. hatte ich nebenbei noch in der Bildersuche gesehen.
Philipp K. schrieb: > Ah ups sorry, hatte es auf dem Rechner verlegt und bin wohl bei google > Bilder am Pinout des "Nano Every" vorbeigekommen. > > Bei den Nano Clone Boards ist wohl manchmal A0-A? verkehrt herum > rausgeführt.. hatte ich nebenbei noch in der Bildersuche gesehen. Ich denke, dass kann es auch nicht sein, denn das Arduino kompilierte Beispiel läuft mit der selben PORT und Pin Zuordnung einwandfrei.
Stefan ⛄ F. schrieb: > Aloysius P. schrieb: >> Nein HW kann es nicht sein, denn: Über Arduino IDE unter benutzung der >> selben Ports läuft alles. > > Also bist du der Meinung, dass es an der Software liegen muss. Wie > sillen wir dir nun helfen, ohne dass du sie vorzeigst? Ich bin eigentlich nicht dieser Meinung. Denn auf dem SDK600 was nichts anderes macht als den 328P in Minimalkonfig zu beschalten läuft es. > Wie gesagt könnte es am Reset verhalten (insbesondere dem Timing) sein. > Das Arduino Modul startet vielleicht schneller, hab ich auch gedacht. Deshalb vor die Init 1000ms delay gepackt.. macht keinen unterschied. > als dein > Entwicklungsboard und die Software von Arduino berücksichtigt dies > angemessen, während es deine Software nicht tut. Siehe oben > Das wäre ein mögliches Szenario. Habe ich auch schon durch...
Gast
#6342613
Aloysius P. schrieb: >>> Nein HW kann es nicht sein, >> Also bist du der Meinung, dass es an der Software liegen muss. > Ich bin eigentlich nicht dieser Meinung. Na dann: Viel Spaß. Schön dass alles funktioniert. Kleiner Tipp: Überprüfe deine Annahmen, und zwar alle. Und fnde dich dami9t ab, dass wir dir nur helfen können, wenn du dein Projekt vorzeigst: Schaltplan. Fotos, Quelltext, Projekteinstellungen (falls du kein Makefile verwendest). Nur dann kannst du weiter kommen.
Aloysius P. schrieb: > Ich denke, dass kann es auch nicht sein, denn das Arduino kompilierte > Beispiel läuft mit der selben PORT und Pin Zuordnung einwandfrei. Dann schick doch wenigstens mal ein Foto vom Nano.. also lies sich nicht ganz ersehen.. ein Sketch der Arduino IDE lässt sich mit "über Programmer" hochladen und funktioniert auf dem STK600? Also im Prinzip das gleiche Programm in der IDE mit dem gleichem Programmer in der IDE, nur die Platine getauscht funktioniert? Dann ist es die Verdrahtung oder Quartz Taktung, bzw falsche Einstellung der Taktrate in Arduino. (FCPU)
Vielen Dank an alle die versucht haben zu helfen! Mittlerweile nach dem ich den schönen Tag anstatt draussen am Computer verbracht habe, bin ich der Sache auf die Schliche gekommen. Ich frage ja das Enable Bit ab, ob der 44870 noch busy ist. Hier ist bei einem Lo auf D7 des LCD frei. Ich mache die Abfrage über Pin5 PORTC. Offensichtlich klapp hier die Abfrage nicht. So das die Routine die Bussy checkt in eine Endlosschleife geht. Ich habe diese Abfrage durch ein delay von 0,5ms ersetzt und das ganze läuft nun fehlerfrei. In the end of the day tatsächlich weder HW noch SW Fehler, lediglich eine Inkompatibilität zwischen beiden in dem speziellen Fall. Ich werde mich jetzt mal auf die Suche machen und versuche herauszufinden warum offensichtlich PC5 auf den Arduino-Boards nicht durch den 44870 auf lo gezogen werden kann.
Gast
#6342684
Aloysius P. schrieb: > In the end of the day tatsächlich weder HW noch SW Fehler, lediglich > eine Inkompatibilität zwischen beiden in dem speziellen Fall. Da würde ich aber auch weiter nachforschen, sonst wirst du in Zukunft noch weitere mysteriöse "Inkompatibilitäten" bekommen, sie sich aufhalten. An PC5 ist bei diesem Board normalerweise absolut nichts besonderes.
Gast
#6342690
Stefan ⛄ F. schrieb: > An PC5 ist bei diesem Board normalerweise absolut nichts besonderes. Es könnte sich dort ein Pullup für I2C befinden.
Gast
#6342725
Arduino Fanboy D. schrieb: > Es könnte sich dort ein Pullup für I2C befinden. Und wenn schon? Stört nicht.
Beitrag #6342742 wurde von einem Moderator gelöscht.
Hallo Aloysius Vielleicht liegt es daran, wie du im 4Bit-Modus die Abfrage des Busy-Flags programmiert hast (siehe Bild). Gruß Rolf
Angehängte Dateien:
-
LCD-Busy_1_.jpg
(140 KB)
Aloysius P. schrieb: > (RS = Register select) <-> PORTC PortBit 4 > (EN = Enable) <-> PORTC PortBit 5 Aloysius P. schrieb: > Ich frage ja das Enable Bit ab, ob der 44870 noch busy ist. Hier ist bei > einem Lo auf D7 des LCD frei. Ich mache die Abfrage über Pin5 PORTC. Das E (Enable)hat nix mit der busy Abfrage zu tun. Im 8-bit mode ist das busy flag auf D7 des DATENBUS. Im 4-bit mode eben auf dem höchsten bit in der ersten Abfrage (Datenbus high nibble).
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.