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.htmlArduino 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.
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?
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.
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.
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.
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.
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.
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.
