Hallo zusammen, mir ist desöfteren schon aufgefallen, wenn ich Arduinos programmiert habe, dass direkt nach dem Einschalten bzw. Flashen, der Arduino für etwa 3 Sek. in einem undefinierten Zustand verharrt. Dies hat z.B. bei meinem Roboterarm (gesteuert über Servos) die Folge, dass er erst mal aus seiner x-beliebigen Position zusammenklappt wie ein nasser Sack und unsanft auf die Standplatte blumst. Ebenso das Phänomen bei einem kleinen Grafikdisplay (OLED in Briefmarkengröße). Nach dem Einschalten zeigt das Display erstmal für etwa 3 sec. völlig willkürliche Pixel. Hat jemand eine Idee, wie man dieses vermutl. Booten des Bootloaders(?) überbrücken kann und die Peripherie erst dann "freigibt", wenn der Controller dazu auch bereit ist? Ich hoffe, ich habe mich einigermaßen ausgedrückt um die Problematik rüberzubringen. Danke im Voraus! Konrad.
Nunja... Du wirst den Bootloader entsorgen müssen(wenn er dich stört). Also Fuses ändern, und nur noch per ISP Adapter programmieren. Tipp: Eine passende Boarddefinition suchen, oder selber eine erstellen. ------ -> Ironie=ON Natürlich ist mal wieder der Arduino geheim, Schaltplan, und auch der Code. Aber am Code kanns ja nicht liegen. Denn der ist bestimmt Fehler frei. Gleiches gilt natürlich auch für den Schaltplan. Der ist ebenfalls perfekt. Völlig Fehlerfrei. -> Ironie=OFF
Was für Servos verwendest du? Der Bootloader fasst die meisten Pins nicht an (höchstens den für ne onbaord LED) soweit ich weiss. D.h. sie bleiben so wie der Microcontroelr sie nach einem Reset automatisch setzt. Bei AVRs ist das meistens als "Input". D.h. mit einem externen Widerstand nach Ground oder VCC kannst du den Pegel festlegen. Frage ist halt was die Servos mit so einem Pegel machen. Würde für Robotik empfehlen BUS-gesteuerte Digitalservos zu verwenden und keine PWM gesteuerten. Die sind inzwischen nicht mehr so teuer und haben geniale Gimmicks wie integrierte Verbrauchsmessung wodurch du z.B. einen automatischen Notaus einleiten kannst wenn das System blockiert. Z.B. https://de.aliexpress.com/item/Robot-Bus-Servo-intelligent-serial-communication-digital-servo-all-metal-gear-high-torque-19-5KG-240/32818038692.html Arduino Fanboy D. schrieb: > Nunja... > Du wirst den Bootloader entsorgen müssen(wenn er dich stört). > Also Fuses ändern, und nur noch per ISP Adapter programmieren. Das ist aber eher den letzte Ausweg... Man könnte den Bootloader ja auch ändern, sollte da wirklich was drin sein was stört. Der ist einiegrmaßen gut komentiert soweit ich gesehen hab.
:
Bearbeitet durch User
Ein paar Pullups/Pulldowns an den richtigen Stellen wirken Wunder.
Frank M. schrieb: > Ein paar Pullups/Pulldowns an den richtigen Stellen wirken Wunder. zumal einige Pins erst mal in den Input (quasi tristate) gehen bevor der Bootloader beendet ist und das Hauptprogramm high oder low an den Ports setzt! In der boot zeit ist alle angeschlossene Elektronik ja im luftleeren Raum, mal high mal low mal flatternd. Schaltung richtig durchdacht? 3 Sekunden ist aber lang, irgendwelche delay im startcode?
:
Bearbeitet durch User
Alex G. schrieb: > Das ist aber eher den letzte Ausweg... Vielleicht... Ich vermute ja auch, dass die Ursache woanders steckt. z.B. die (schon erwähnten) fehlenden Pullups an den /CS Pins. (welche auch für ICSP vorhanden sein sollten/müssen) Aber dennoch können diese 3 Sekunden stören. Ein Bootloader mag schon bequem sein, aber wirklich nötig ist er nicht. Alex G. schrieb: > Man könnte den Bootloader ja auch > ändern, sollte da wirklich was drin sein was stört. Ja. Um die Pause wird man allerdings nicht wirklich rum kommen. Aber das Gezappel an Pin 13 (SPI-Clock + LED_BUILTIN) könnte man unterbinden. Auch gibt es verschiedene Generationen an Bootloadern in der Arduino Welt. Die moderneren Optiboot, warten nur nach einem Hardware Reset auf serielle Daten. Nach einem Poweron Reset oder Brownout starten sie schneller durch. Ein Wechsel könnte evtl. also schon reichen.
Arduino Fanboy D. schrieb: > Um die Pause wird man allerdings nicht wirklich rum kommen. Eigentlich schon. Die dient ja zum feststellen ob der Arduino an einem programmierwilligen Rechner hängt. Nun kann man das einfach mit einem Taster verschalten. Will man programmieren, hält man den Taster gedrückt; sonst nicht und der Loader startet das eigene Programm sofort. Arduino Fanboy D. schrieb: > Auch gibt es verschiedene Generationen an Bootloadern in der Arduino > Welt. > Die moderneren Optiboot, warten nur nach einem Hardware Reset auf > serielle Daten. > Nach einem Poweron Reset oder Brownout starten sie schneller durch. > Ein Wechsel könnte evtl. also schon reichen. Sicher ein guter Hinweis.
Alex G. schrieb: > Nun kann man das einfach mit einem > Taster verschalten. Das ist aber eher der letzte Ausweg...
Arduino Fanboy D. schrieb: > Alex G. schrieb: >> Nun kann man das einfach mit einem >> Taster verschalten. > Das ist aber eher der letzte Ausweg... Wieso? Damit hat man doch das Beste aus beiden Welten finde ich.
Ein, für andere Zwecke, verlorener Pin. Wie auch immer... Bis jetzt fehlen wesentliche Informationen für "richtige" Vorschläge.
Ok, wo sollte man denn im Beispiel der willkürlich angezeigten Pixel nach dem Einschalten des Arduinos eurer Meinung nach z.b. die Pullups/-downs verdrahten? Wie im Link habe auch ich mein Display verdrahtet: http://blog.simtronyx.de/ein-096-zoll-oled-display-i²c-mit-128x64-pixel-und-ein-arduino/ Leider wird im Netz nirgends mein beschriebenes Problem zum Thema "Einschalten - undefinierter Zustand" thematisiert. Wenn ich mir vorstelle was passieren könnte, wenn man jedwelche "schweren Lasten" am Controller angeschlossen hätte und den Controller einschaltet.... Ich hoffe auf Lösungsvorschläge.
Konrad schrieb: > Ich hoffe auf Lösungsvorschläge. ohne Schaltplan? ich verfolge nun nicht deine Anschlüsse und suche mir das Datenblatt raus, OK SDA und SCL sind low aktiv also 10k pullup kann schon mal fürs Display reichen, ggffs. noch VCC schaltbar machen das VCC & Init zum Display erst nach der Bootphase kommt. Ein Display ist kein Servo oder Roboterarm!
>ohne Schaltplan? Im Link ist der "Aufbau" (sofern man diesen so nennen mag). Es sind vier Drähte. VCC, GND, SDA und SCL, mehr nicht. >ggffs. noch VCC schaltbar machen das VCC & Init zum Display (...) Was meinst du mit "Init zum Display"?
Eigentlich ist das ungewöhnlich. So ein Display stellt normalerweise erst bei Übermittlung eines Protokolls etwas sinnvoll dar und SCL/CLK haben physische pull Widerstände schon auf dem Board. Kannst du ja mal im ausgeschalteten Zustand gegen ground und VCC messen. Oft sind es 10k. Was passiert wenn du das Display nur an Strom anschließt und SCL/CLK per Widerstand an GND aber ohne Mikrocontroler? Würde vermuten dass es dann auch flackert weil das Display Datennmüll aus seinem Buffer darstellt. In dem Fall hilft dann nur VCC mit einem Mosfet durch einen weiteren Pin des Mikrocontrolers verzögert einzuschalten.
:
Bearbeitet durch User
Angehängte Dateien:
-
IMAG0681_web.jpg
83 KB
Konrad schrieb: > Was meinst du mit "Init zum Display"? also ich nutze gerne mal Portpins für VCC solange VCC nicht übermäßig belastet wird. setup VCC (und ggffs) GND Pins einschalten, warten... dann Init vom Teil aufrufen denn ohne Software spielt ja nichts! läuft dein Display ohne Init? oder kommt was im setup code, Ich nehme mal an VCC und GND hängen direkt an Power und GND, also kann das Display schon mal was blinken lassen Vielleicht steht auch noch Schrott im Display der erst mal gelöscht werden muss halt init cls oder clearscreen aber wie gesagt man kann VCC ja auch bei kleinen Lasten aus einem PIN nehmen und solange der Input ist speist er auch kein Display.
Konrad schrieb: > Leider wird im Netz nirgends mein beschriebenes Problem zum Thema > "Einschalten - undefinierter Zustand" thematisiert. Da ist nix undefiniert. Die Pins sind schlicht nach einem Reset als Input/Tristate geschaltet, und was die angeschlossene Hardware damit anfängt, sollte in ihrem Datenblatt stehen. Wenn dein Display sich vom Rauschen angesprochen fühlt und Müll anzeigt, dann verhindere das mit einem Pulldown, fertig.
Was mir bei dem OLED Display noch aufgefallen ist: Es kann nur gelb und blau darstellen, egal welche Textcolor man setzt. Auch im Adafruit-Beispielcode von Adafruit ist dies der Fall. Der obere Bereich (ca 20 px vom XY-Punkt = 0 gerechnet) ist die Darstellung gelb, der Rest (egal welche Farbe man vorgibt) alles blau...seltsam.
fuer zweimark und fuenfzig kriegst eben nicht mehr. is doch klar .
Konrad schrieb: > Es kann nur gelb und blau darstellen, egal welche Textcolor man setzt. das ist so und auch so etwas undeutlich beschrieben, geschwindelt ist es nicht, keiner sagt das alle Pixel gelb oder blau sein können.
Angehängte Dateien:
Konrad schrieb: > Was mir bei dem OLED Display noch aufgefallen ist: > Es kann nur gelb und blau darstellen, egal welche Textcolor man setzt. >...seltsam. Joachim B. schrieb: > das ist so und auch so etwas undeutlich beschrieben Was ist daran seltsam oder undeutlich beschrieben. Echt Leute ein OLED Display welches mit den Wahlmöglichkeiten [x] blau welb [ ] weiß [ ] blau verkauft wird, kann keine andere Farbe. Konrad schrieb: > Nach dem Einschalten zeigt das Display erstmal für > etwa 3 sec. völlig willkürliche Pixel. Das ist normal. Das Display enthält RAM Speicher für die Bilddaten. Der ist nach dem Einschalten uninitialisiert, hat also zufällige Werte(=zufällige Pixelfarbe). Wenn der Mikrocontroller nach dem einschalten 3 Sekunden lang wartet und das Display nicht initialisiert, dann ist das eben 3 Sekunden lang so. Konrad schrieb: > Roboterarm (gesteuert über Servos) die Folge, > dass er erst mal aus seiner x-beliebigen Position zusammenklappt Modellbau-Servos ohne Eingangssignal (= passendes Puls-Längen-Moduliertes Signal) fahren typisch in eine der Endanschläge. Ist nicht bei allen so, aber oft. Egal ob deren Eingangssignal vom uC auf High-, Low- oder Hi-Z(Tristate) gesteuert wird. Steht manchmal auch im Datenblatt des Modellbau-Servos. Eine Lösung wurde von Alex G. schon genannt: Digital-Servos verwenden.
void schrieb: > Modellbau-Servos ohne Eingangssignal (= passendes > Puls-Längen-Moduliertes Signal) fahren typisch in eine der Endanschläge. Servos ohne Signal fahren in der Regel nirgendwohin, sondern bleiben ohne jede Stellkraft einfach dort stehen, wo sie gerade sind.
Servo schrieb: > Servos ohne Signal fahren in der Regel nirgendwohin, sondern bleiben > ohne jede Stellkraft einfach dort stehen, wo sie gerade sind. 1) Erzähl "in der Regel" mal den RC Servos in meiner Grabbelkiste. Vielleicht finden sich da aber auch mehr Ausnahmen drin... 2) Ohne Stellkraft ist bei mechanisch belasteten Roboterarm jedoch auch nicht hilfreich.
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.