So zurück zum Thema, die Idee mit dem Dauerplus ist zwar eine gute Idee, aber irgendwann raucht der Mikrocontroller ab und gibt den Geist auf wenn er 24Std läuft.
Zündungsplus ist auch eine nette Idee, jedoch was passiert mit Warnlicht wenn die Zündung aus ist? Nichts!
Was die Spannungsschwankungen angeht, wird vor dem Mikrocontroller ein 5V Spannungswandler gesetzt, der konstante 5V wiedergibt, da die Autobatterie je nach Wirkungsgrad/Alterung/Zündung zwischen 11,7 V und 14,5 V bringt.
Warum sollte der Mikrocontroller abrauchen? Wenn dann ist dort irgendwo am falschen Ende bei der Planung/Realisierung gespart worden. Ein Spannungswandler reicht hier nicht aus!!
Gute seite! Das mit dem Schweißen war mir nicht bewusst.
Nunja da es zu viele Risiken mit Zündung und Dauerplus mitbringt ist es auch keine Lösung.
Das was bei der original LED ankommt ist immer reguliert.
Also was ich jetzt vorhabe ist, ich kaufe mir einen Arduino UNO und nutze den als ISP Programmer.
Jetzt muss ich herausfinden wie ich den bootloader loswerde beim starten, ohne das er Prüft ob ein PC per IDE angeschlossen ist, sondern direkt bei 0 mit dem void setup und void loop loslegt.
Der bootloader soll ja nicht zwingend gelöscht werden, es reicht ja aus, dass er garnicht erst startet. Somit muss ich herausfinden welche Fuse ich beim 328er einstelle.
Nichts, ich brauche ihn ja nicht, ich versuche gerade zu verstehen wie ich den Bootloader loswerde.
Kann ich mit dieser Anleitung:
Mit einem Skatch den bootloader überschreiben?
D.h. ich spiele ein Skatch per Arduino ISP auf mein Mini und dabei wird der bootloader überschrieben?
Und eine erneute nutzung des Arduino IDE meines Mini Pros ist nur mit erneuter aufspielung des Bootloaders per Arduino ISP möglich? Richtig?
Sofern der Bootloader fehlt, spielt der Arduino ohne nachzudenken mein skatch ab?
Der Bootloader ist nur dafür da, dass du den Atmega328P beim Uno, Pro Mini, ... ohne ISP Adapter über die UART Schnittstelle (Rx/Tx) programmieren kannst. Einen Vorteil sehe ich an der ganzen Bootloader Sache sowieso nicht.
Sinnvoller wäre es wie bei den neueren Arduino ARMs, dass auf dem Arduino selber bereits ein Programmer onBoard ist, der die Atmel µC beschreibt. Aber das war vermutlich irgendwo eine Kostensache. Denn man hätte einen ISP auf dem Board setzen müssen. Wobei ich mir nicht sicher bin, vermutlich wäre dazu sogar der 16U2/8U2 in der Lage.
Dann könnte mman das Board auch direkt als "Brennstation" für blanke Atmega168/328/ nutzen.
Ich hänge ein Bild an mit dem Screenshot von den bereits aktivierten Fuses.
Welchen Haken muss ich entfernen?
BOOTRST, damit der Bootloader bei Spannungseingang nicht startet?
Wenn der Bootloder über Fuses ausgeschaltet ist, ist es möglich weiterhin IDE zu nutzen? Oder sind Skatches über ISP zu schreiben?
Ich flashe mit USBasp aus der IDE, ohne irgendwelche sonstige Einstellungen zu machen und es geht wie ich mir vorstelle. Sofortiger Start, kein Hochladen über Com mehr möglich, d.h. BL ist deaktiviert, aber NICHT gelöscht.
Nun, was bringt die manuelle Fuserei, wenn ich den Speicherplatz vom BL nicht für den Sketch brauche?
Dein "sofortig" unterscheidet sich erheblich von meinem "sofortig".
, d.h. BL ist deaktiviert, aber NICHT gelöscht.
Falsch!
Der Bootloader ist gelöscht, aber nicht deaktiviert.
Das führt dazu, dass:
du oben Speicher verplemperst (dümpelt ungenutzt oben rum)
der Bootloader TROTZDEM angesprungen wird
Zu 2:
Der Platz, wo mal der Bootloader war, ist leer, also jetzt mit 0xFF gefüllt.
Atmel sei Dank, wird FF als NOP (No Operation) interpretiert.
Nach einem Reset werden also erstmal ein Haufen NOPs ausgeführt, bevor der PC (Programm Counter) seinen Wraparound (Atmel sei Dank) zur Adresse 0 macht, und die eigentliche Anwendung startet.
Du verlässt dich also 2 Mal auf "Atmel sei Dank".
wenn ich den Speicherplatz vom BL nicht für den Sketch brauche?
So lange geht es gut.... (einigermaßen)
Aber sobald die Anwendung bis da oben geht, wird nach einem Reset mitten in die Anwendung gesprungen, völlig unkultiviert.
Scherben wird es geben!
Der Bootlader kann nicht gelöscht sein, denn wenn ich danach wieder den BL brenne, schreibt er nur ein Byte und voila, der Bootlader ist wieder da und funzt.
Wenn der Bootlader wirklich geflasht wird, dauert es einige Sekunden, bis er drauf ist, z.B. bei neuen Chips.
ElEspanol:
Der Bootlader kann nicht gelöscht sein, denn wenn ich danach wieder den BL brenne, schreibt er nur ein Byte und voila, der Bootlader ist wieder da und funzt.
Ich bin ja nicht unbelehrbar, und gebe auch zu, dass ich mich noch nicht wirklich tiefergehend mit dem Thema beschäftigt habe.
Aber warum dauert es manchmal etliche Sekunden, und man sieht den Fortschritsbalken langsam länger werden um den BL zu brennen und manchmal eben ist er "sofort" gebrannt. Dies hat mich verwirrt und zu entsprechnender Annahmen verleitet.
Ich werde es mal nach deiner Anleitung nachvollziehen.
Aber warum dauert es manchmal etliche Sekunden, und man sieht den Fortschritsbalken langsam länger werden um den BL zu brennen und manchmal eben ist er "sofort" gebrannt.
Tja....
Das kann ich dir leider nicht sagen...
Könnte etwas mit den momentanen Befindlichkeiten deines Computers/USB/Chipsatz zu tun haben....
Dies hat mich verwirrt und zu entsprechnender Annahmen verleitet.
Ja, es ist schwierig etwas falsches wieder aus dem Schädel zu bekommen.
Und wenn es dann noch im Schädel eines anderen steckt, ist da so gut wie kein ran kommen.
Mit Annahmen sollte man vorsichtig sein...
Aber das ist ein ganz anderes Thema.
Habe ich mich mal (mathematisch/logisch/philosophisch) mit beschäftigt...
Also, erster Versuch: Flashen mit USBasp einen kleinen Sketch:
Der Sketch verwendet 2.612 Bytes (8%) des Programmspeicherplatzes. Das Maximum sind 32.256 Bytes.
Globale Variablen verwenden 240 Bytes (11%) des dynamischen Speichers, 1.808 Bytes für lokale Variablen verbleiben. Das Maximum sind 2.048 Bytes.
C
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: auto set sck period (because given equals null)
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
Writing | ################################################## | 100% 1.31s
avrdude: 2612 bytes of flash written
\build850530977475224165.tmp/BlinkWithoutDelay.cpp.hex contains 2612 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.78s
avrdude: verifying ...
avrdude: 2612 bytes of flash verified
avrdude done. Thank you.