Hallo, ich bin neu hier. Meine Erfahrung mit Microcontrollern stammt noch aus einer Zeit, als man Eproms mit UV geschlöscht hat und verbrannte ROMs in den Müll geworfen hat. Nun hab ich ich aber einige Ideen und Projekte die ich mit Logikbausteinen und analog Technik nicht lösen konnte. Ich hab mir also so einen Arduino Starterkasten gekauft. Programmiersprache, ist ja fast wie C, und die Peripherie funktioniert auch ohne unnötig zu qualmen! Dort also keine Probleme! Gestern kam die o.g. Platine und nach einigen Stunden hab ich es geschafft sie direkt via USB zu programmieren. Kurz nachdem ich mir einen AVR 51 bestellt hatte und während dem Warten einen UNO als ISP verwenden wollte... Aber es funktioniert auch so! Der Tiny steuert zwei Mosfets an, die jeweils eine 12V 12W Led ansteuern und über vier random Befehle unterschiedlich flackern lassen. Quasi eine sehr große (helle) Led Kerze. Leider braucht der Tiny durch den vorgegeben Bootloader ja 5bis7 Sekunden bis die Leds anfangen zu flackern. Ich will das ganze mit einem AKKU und einem Bewegungsmelder betreiben. Deshalb läuft der Attiny85 nicht permanent Standby mit. Kann mir jemand möglichst einfach und auf deutsch erklären, wie ich den Bootloader so ändere dass der Arduino möglichst schnell in den eigentlich Loop geht?
Hi >Kann mir jemand möglichst einfach und auf deutsch erklären, wie ich den >Bootloader so ändere dass der Arduino möglichst schnell in den >eigentlich Loop geht? Bootloader benutz man um das Programm einmalig in den Flash zu laden, aber nicht bei jedem Startvorgang. MfG Spess
spess53 schrieb: > Bootloader benutz man um das Programm einmalig in den Flash zu laden, > aber nicht bei jedem Startvorgang. nein. Es gibt sehr viele Geräte die den Bootloader zuerst starten und dann daraus das Programm. Das hat den großen Vorteil, das man wenn man ein defekte Programm geflascht hat, es jederzeit wiederholen kann. Alles andere währe irgendwie sinnlos. Man muss den Bootloader nur so anpassen, das er z.b. abhängig von eine IO-PIN schneller bootet.
Hi
>Alles andere währe irgendwie sinnlos.
Da gebe ich dir Recht. Ich halte diese ganze Bootloader-Manie für recht
sinnlos. Na ja, Arduino sei Undank.
MfG Spess
Kann es sein, dass du dein Programm jedes Mal neu auf den Arduino überträgst? Das könnte die 6 Sekunden Verzögerung erklären. Dein Programm wird auch bei jedem Reset oder neu einschalten, gestartet. Das dürfte dann höchstens (gefühlte) 6 ms Verzögerung haben.
pansen schrieb: > Das könnte die 6 Sekunden Verzögerung erklären. der bootloader muss doch eine Zeitlang warten, ob für ihn Befehle anliegen. Macht sogar jeden Fritzbox so. Wenn ihm die 6s zu lang sinn, muss er den Bootloader umschreiben, oder komplett auf ihn verzichten. spess53 schrieb: > Da gebe ich dir Recht. Ich halte diese ganze Bootloader-Manie für recht > sinnlos. Na ja, Arduino sei Undank. Ich habe keine Arduino aber verwende auch Bootloader, damit ich von ferne meine Geräte updaten kann. Da sie aber nur bei Stromausfall neu booten, ist die Bootzeit mir ziemlich egal.
Peter II schrieb: > Wenn ihm die 6s zu lang sinn, muss er den Bootloader umschreiben, oder > komplett auf ihn verzichten. Ja genau, der Micronucleus Bootloader wartet 6 Sekunden ob er neu beschrieben wird, oder nicht. Wie schreibe ich den Bootloader um, bzw. was schreibe ich rein?
>Wie schreibe ich den Bootloader um, bzw. was schreibe ich rein?
Du besorgst dir den Sourcecode und änderst diesen. Wird aber ohne
ISP Programmer nichts nützen. Der Bootloader kann sich nicht selber
neu flashen.
Hole dir einen nackten Attiny. Den kannste dann mit der ArduinoIDE, und dem UNO als ISP beschreiben. Ein Bootloader auf dem Tiny ist dafür nicht nötig.
Arduino F. schrieb: > Hole dir einen nackten Attiny. man kann den Bootloader auch löschen, dafür muss man nicht extra einen neue µC kaufen.
Peter II schrieb: > nein. > > Es gibt sehr viele Geräte die den Bootloader zuerst starten und dann > daraus das Programm. Das hat den großen Vorteil, das man wenn man ein > defekte Programm geflascht hat, es jederzeit wiederholen kann. > > Alles andere währe irgendwie sinnlos. > > Man muss den Bootloader nur so anpassen, das er z.b. abhängig von eine > IO-PIN schneller bootet. Quark... der Bootloader, zumindest bei einem AVR, liegt hinter dem Programmcode. Dieser Vector wird bei Reset, entweder Hardware oder Software via BOD, angesprungen. Dieser Zustand kann jedesmal erreicht werden wenn der µC in den Reset geht. Ob der Flash ab 0x00 nun beschrieben, Falsch oder sonstwas ist. Wird ein µC eingeschaltet, ohne aktives WDTON Flag, geht er IMMER bei 0x00 mit seinem Programm los. Deine Sicht der Dinge macht keinen Sinn, denn das würde heißen das man den µC reseten oder stromlos machen muss um dann die sechs bis sieben Sekunden zu warten bis man ihn flashen kann und danach ist wieder schicht... DAS macht keinen Sinn. @ Maximilian Anonym Zeig mal deinen Code her, ich denke du hast da irgendwie ne Schleife drinn, denn alles andere ist im Brei rumstochern.
Draco schrieb: > Wird ein µC eingeschaltet, ohne aktives WDTON Flag, geht er IMMER bei > 0x00 mit seinem Programm los dann sollte du mal die doku lesen > Alternatively, > the Boot Reset Fuse can be programmed so that the Reset Vector Reset is > pointing to the Boot > Flash start address after a reset. In > Deine Sicht der Dinge macht keinen Sinn, denn das würde heißen das man > den µC reseten oder stromlos machen muss um dann die sechs bis sieben > Sekunden zu warten bis man ihn flashen kann und danach ist wieder > schicht... DAS macht keinen Sinn. doch das macht sehr wohl sinn. Du hast ihn nur nicht verstanden. Man muss nicht 6 Sekunden warten, bis man ihn flashen kann, das geht sofort. Man muss 6 Sekunden warten, wenn man ihn nicht flashen will. (also das normale Programm starten)
Peter II schrieb: >> Alternatively, >> the Boot Reset Fuse can be programmed so that the Reset Vector Reset is > >> pointing to the Boot >> Flash start address after a reset. Ja halt einfach den BOOTRST Fuse auf 1 (aus). Aber dann überspringt er ja den Bootloaderbereich komplett. Das ist mir bei noch keinem Bootloader untergekommen, und schon garnicht bei einem Arduino-Loader (Und da würde ich so nen Unsinn als erstes erwarten) Peter II schrieb: > Man muss nicht 6 Sekunden warten, bis man ihn flashen kann, das geht > sofort. Man muss 6 Sekunden warten, wenn man ihn nicht flashen will. > (also das normale Programm starten) Nein, du verstehst nicht - was passiert NACH den sechs Sekunden? Nicht mehr Flashbar?! Nur noch durch Stromlosschalten und / oder Reset. Ja dann kann das auch gleich der Programmer / TTL Wandler machen, das ist ja mit Kanonen nach Spatzen geschossen. Sorry, aber das ist mir noch nicht untergekommen.
Draco schrieb: > Ja halt einfach den BOOTRST Fuse auf 1 (aus). Aber dann überspringt er > ja den Bootloaderbereich komplett. Das ist mir bei noch keinem > Bootloader untergekommen, und schon garnicht bei einem Arduino-Loader > (Und da würde ich so nen Unsinn als erstes erwarten) Was übrigens Standard ist. Da gibt es nur ein paar Ausnahmen welche mit einem DFU Loader ausgliefert werden, und das betrifft afaik nur die AT90USBxx und die Mega u2 und u4. Aber nicht den Tinyx5
Draco schrieb: > Nein, du verstehst nicht - was passiert NACH den sechs Sekunden? Nicht > mehr Flashbar?! doch, in den man von seinen eigenen Programm in den bootloader springt wenn man es will- > Nur noch durch Stromlosschalten und / oder Reset. Ja nein > dann kann das auch gleich der Programmer / TTL Wandler machen, das ist > ja mit Kanonen nach Spatzen geschossen. man kann von ferne den Strom abschalten, den Progammer kann ich nicht von Ferne anschließen. > Sorry, aber das ist mir noch nicht untergekommen. ja, scheinbar hast du den sinn eines Bootloaders immer noch nicht verstanden. Es ist ein Programm, was vor dem eigentlichen Programm gestartet wird. Es warten über eine Kommunikationsschnittstelle auf Befehle um den Flash neu zu schreiben. Wenn kein Befehlt kommt, wird das Programm gestartet. Vorteile: man kann Geräte über jede beliebige Schnittstelle (Seriell, Netzwerk, Funk) neu flashen ohne eine spezielle Hardware. Der Bootloader funktioniert auch noch wenn man Fehler im Programm hat, dafür muss man nur für ein Reset sorgen (z.b. Watchdog, Reset, Stromlos). Wie schon oben geschrieben, wird es in viele Geräte so gemacht. Eine fritzbox warten auch ein paar Sekunden nach dem booten auf eine FTP-Verbindung. Wenn keine Verbindung kommt, wird das normale System gestartet. Wenn man das nicht hätte, bräuchte man zum Flashen (wenn das System mal gar nicht mehr will) spezielle JTAG Hard und Software.
Peter II schrieb: > Draco schrieb: >> Wird ein µC eingeschaltet, ohne aktives WDTON Flag, geht er IMMER bei >> 0x00 mit seinem Programm los > > dann sollte du mal die doku lesen Auf den meisten anderen uC - 8051 und viele ARM - ist das genau so. Der Bootloader ist am Ende vom Flash und es gibt eine Hardware-Logik zu einem Boot-Pin, die nach RESET entweder zu 0x00 oder zum Bootloader springt. Eine Verzögerungszeit gibt es dabei nicht, es ist egal, ob der Bootloader drauf ist oder nicht. Weiterhin gibt es einen Assembler-Befehl, mit dem auch vom User-Programm der Bootloader aufgerufen werden kann, z.B. beim 8051 die undefined instruction 0xA5 und beim ARM ein SWI
holger schrieb: >>Wie schreibe ich den Bootloader um, bzw. was schreibe ich rein? > > Du besorgst dir den Sourcecode und änderst diesen. Wird aber ohne > ISP Programmer nichts nützen. Der Bootloader kann sich nicht selber > neu flashen. Doch der micronucleus kann sich selber updaten, wäre ja sonst auch witzlos, wenn man wieder mit Programmer und Fuses anrücken müsste: https://github.com/micronucleus/micronucleus Also einfach die Wartezeit rausmachen und stattdessen einen Pin vom Attiny85 prüfen, ob User Programm oder Bootloader gestartet werden soll.
>Doch der micronucleus kann sich selber updaten, wäre ja sonst auch >witzlos, wenn man wieder mit Programmer und Fuses anrücken müsste: Und wie macht er das? Er überschreibt das Flash aus dem er gerade selber ausgeführt wird? Das geht nicht.
holger schrieb: > Und wie macht er das? Er überschreibt das Flash aus dem er gerade > selber ausgeführt wird? Das geht nicht. Was Du schreibst ginge bei AVR nicht, aber so macht er es: https://github.com/micronucleus/micronucleus/issues/69
Maximilian A. schrieb: > Deshalb läuft der Attiny85 nicht permanent Standby mit. Du mußt den AVR nicht jedesmal neu resetten. Nimm einen Spannungsregler, der nur wenige µA verbraucht (z.B. MCP1702) und setze den AVR in Power-Down. Dann kannst Du ihn ständig an den 12V lassen und mit Pin-Change-Interrupt aufwecken.
Draco schrieb: > Zeig mal deinen Code her, ich denke du hast da irgendwie ne Schleife > drinn, denn alles andere ist im Brei rumstochern. Natürlich ist da eine Schleife drin und die läuft auch wie sie soll. byte links = 0; byte rechts = 1; byte x; byte y; void setup() { pinMode(links, OUTPUT); pinMode(rechts, OUTPUT); } void loop() { x=random(5)*50; analogWrite(links, x); delay(random(250)); y=random(5)*50; analogWrite(rechts, y); delay(random(250)); } Es funktioniert auch so wie es so soll. Und blinkt und blitzt pausenlos bis der Strom abgestellt wird. Nur eben vergehen zwischen einschalten der Versorgungsspannung (Bewegungsmelder) und dem dem Einschalten der Leds 5-6Sekunden! Und das hätte ich gerne einfach etwas schneller!
Maximilian A. schrieb: > Nur eben vergehen zwischen einschalten der Versorgungsspannung > (Bewegungsmelder) und dem dem Einschalten der Leds 5-6Sekunden! Und das > hätte ich gerne einfach etwas schneller! Tja. weg mit dem Bootloader, oder ihn modifizieren. Aber das wurde ja alles schon gesagt.....
Arduino F. schrieb: > weg mit dem Bootloader, oder ihn modifizieren Oder ganz anders: warum weiter mit AVR rumärgern? Dein Programm ist so einfach, das läuft auf anderen uC praktisch ohne Änderung genauso. Also warum keinen uC mit "verzögerungsfreiem" Bootloader nehmen? Ich nehme an Du hast Attiny85 DIP-8 Nimm stattdessen den hier. Ist etwas teurer und für die Anwendung leicht überdimensioniert, löst aber elegant Dein Problem: http://www.watterott.com/de/LPC810M021FN8FP
Lothar schrieb: > Oder ganz anders: warum weiter mit AVR rumärgern? Dein Programm ist so > einfach, das läuft auf anderen uC praktisch ohne Änderung genauso. Also > warum keinen uC mit "verzögerungsfreiem" Bootloader nehmen? weil die Verzögerung, sinn und zweck beim bootloader hat. Sie wurde nicht aus Spass reingemacht. Wenn er nicht wartet, kann man ihn auch keine Befehle erteilen um ihn zu Flashen. Das ganze ist so gewünscht und kein Problem der Hardware. Wenn man es nicht will, kann man es einfach ändern.
Man könnte den bootloader umschreiben und einen freien pin auf High abfragen, ansonsten direkt ins Programm. einen Pin beim Tiny zu opfern ist natürlich nicht so toll. Wenn das der USB Bootloader ist kann man ja den Reset nehmen.
Peter II schrieb: > Wenn man es > nicht will, kann man es einfach ändern. WIE? Philipp K. schrieb: > Man könnte den bootloader umschreiben WIE? und WAS muss ich reinschreiben??? Arduino F. schrieb: > Lothar schrieb: >> Ich nehme an Du hast Attiny85 DIP-8 > Hat er nicht! Ich habe den Digispark Attiny85 (allerdings die Micro USB Variante) https://www.roboter-bausatz.de/560/digispark-kickstarter-attiny85-usb-development-board-fuer-arduino
Maximilian A. schrieb: > WIE? und WAS muss ich reinschreiben??? §1: Du sollst nicht schreien. Wenn du nicht in der Lage bist den Bootloader Code zu finden, zu editieren, kompilieren, und wieder drauf zu schreiben, dann ist das nicht dein Weg. Du brauchst sowieso einen ISP Programmiergerät! Sowieso... Damit kannst du den Bootloader überschreiben. Fettich.
Maximilian A. schrieb: > WIE? und WAS muss ich reinschreiben??? eine andere Zeit https://github.com/micronucleus/micronucleus/tree/master/firmware bootloaderconfig.h #define AUTO_EXIT_MS 6000 da sind die 6 Sekunden definiert Scheinbar kann sich auch der bootloader selber neu schreiben. Ich würde ihn so abändert, das er nur die 6 Sekunden warten, wenn eine IO-Pin auf Low oder High gesetzt ist. Dann kannst du von außen das booten beeinflussen.
Arduino F. schrieb: > Du brauchst sowieso einen ISP Programmiergerät! > Sowieso... wozu? Im code steht etwas davon, das sich der Bootloader selber flashen kann.
Ich habe mir wie ganz oben geschrieben, ja bereits einen AVR 51 bestellt! Ich könnte aber auch meinen Arduino Uno verwenden, richtig? Wenn meine Frage ist, wie ich den Bootloader verändern muss um ein schnelleres booten zu erreichen. Und als Antwort erhalte, dass ich den Bootloader verändern soll... befinden wir uns glaub ich in einer Schleife
In der Bootloaderconfig.h kann man ab Zeile75 einen EntryMode mit Jumper setzen.. Vielleicht ist das die Lösung!
Peter II schrieb: > https://github.com/micronucleus/micronucleus/tree/... > bootloaderconfig.h > #define AUTO_EXIT_MS 6000 > > da sind die 6 Sekunden definiert > > Scheinbar kann sich auch der bootloader selber neu schreiben. Ich würde > ihn so abändert, das er nur die 6 Sekunden warten, wenn eine IO-Pin auf > Low oder High gesetzt ist. > > Dann kannst du von außen das booten beeinflussen. Vielen vielen Dank!
Maximilian A. schrieb: > Ich könnte aber auch meinen Arduino Uno verwenden, richtig? Wenn du den UNO als ISP verwendest, kannst du auf den Bootloader verzichten. Somit sind die 6 Sekunden weg. Aber das sagte ich doch ganz zu Anfang schon.... Arduino F. schrieb: > Den kannste dann mit der ArduinoIDE, und dem UNO als ISP beschreiben. > Ein Bootloader auf dem Tiny ist dafür nicht nötig.
#define ENTRYMODE ENTRY_ALWAYS auf ENTRY_JUMPER setzen dann kann man mit PB0 den Bootloader aktivieren sonst direkt rein. Das Programmierfenster wird mit weniger Millisekunden immer kleiner!
Philipp K. schrieb: > In der Bootloaderconfig.h kann man ab Zeile75 einen EntryMode mit Jumper > setzen.. ja sieht so aus, als ob das alles vorgesehen ist #define ENTRYMODE ENTRY_ALWAYS #define JUMPER_PIN PB0 #define JUMPER_PORT PORTB #define JUMPER_DDR DDRB #define JUMPER_INP PINB ENTRY_ALWAYS auf ENTRY_JUMPER ändern und den passenden Port eintragen.
Peter II schrieb: > Das ganze ist so gewünscht und kein Problem der Hardware. Wenn man es > nicht will, kann man es einfach ändern. Hatte ich ja ganz am Anfang schon geschrieben, wie man es ändern kann. Aber für einen Anfänger könnte es ja bequemer sein, statt den Bootloader auf dem Attiny85 zu ändern, den uC zu tauschen in einen, der werkseitig mit Pin Bootloader kommt. Lothar schrieb: > Doch der micronucleus kann sich selber updaten, wäre ja sonst auch > witzlos, wenn man wieder mit Programmer und Fuses anrücken müsste: > > https://github.com/micronucleus/micronucleus > > Also einfach die Wartezeit rausmachen und stattdessen einen Pin vom > Attiny85 prüfen, ob User Programm oder Bootloader gestartet werden soll Wie das geht steht alles im Code und die hast es ja jetzt auch ausführlich beschrieben: Peter II schrieb: > ja sieht so aus, als ob das alles vorgesehen ist
Oder einfach mit Bootloader entwickeln und wenn fertig ung zufrieden einen μC für "produktiven Einsatz" per ISP programmieren. Dann ohne Bootloader und ohne Wartezeit.
:
Bearbeitet durch User
Carl D. schrieb: > Oder einfach mit Bootloader entwickeln und wenn fertig ung zufrieden > einen μC für "produktiven Einsatz" per ISP programmieren. Dann ohne > Bootloader und ohne Wartezeit. Mein Reden ....
Oh mann. Wie schon gesagt, einfach über Pin-Change-Interrupt gehen, statt über Reset. Dann ist es schnurz, wie lange der Bootloader wartet.
Maximilian A. schrieb: > Kann mir jemand möglichst einfach und auf deutsch erklären, wie ich den > Bootloader so ändere dass der Arduino möglichst schnell in den > eigentlich Loop geht? Gar nicht! IIRC sind die 6 Sekunden den Eigenschaften der Arduino IDE geschuldet. D.H:, dass nach Erscheinen einer korrespondierenden Meldung in der IDE Konsole innerhalb dieser Zeitspanne ein manueller Reset ausgelöst werden soll. Wenn Dein Programm ausgetestet und funktionsfähig ist steht es Dir frei, für die endgültige Version die ISP-Schnittstelle zu nutzen, dann gibt es im Betrieb auch keine Warteschleife...;) ISP geht übrigens auch prima mit der IDE, der Bootloder ist nicht unbedingt notwendig. Mein Tip: USBASP! Geht auch mit Attiny85 -> Guloprog. Wirklich sinnvoll ist der Bootloader nur für fest eingebaute Installationen ohne Zugriff auf die ISP-Kontakte.
bianchifan schrieb: > Gar nicht! > IIRC sind die 6 Sekunden den Eigenschaften der Arduino IDE geschuldet. Hab ich auch schon geschrieben.. umso kleiner die Zeit ist umso weniger Triffst Du den Punkt zwischen "Treiber erkannt,Gerät fertig installiert" und dem Port/Gerät nach dem die Ide sucht.. Ich würde das mit dem Entry-Pin machen wenn du den Bootloader unbedingt drauflassen willst. Wenn Du eine Anleitung haben möchtest sag bescheid.. wo der Thread schon auf ist ;)
:
Bearbeitet durch User
Ich verwende bei allen Devices:
1 | #define ENTRYMODE ENTRY_ALWAYS |
Damit wird der Bootloader nur durch einen externen Reset aktiviert. Vorteile: - Es wird kein Pin durch den Bootloader belegt. - Der Bootloader wird im normalen Betrieb (Einschalten ohne Reset) nicht aktiviert. Nachteil: - Man benötigt einen Reset-Taster oder -Zugang. Beim normalen Digispark leider nicht gegeben.
Arg... Tim schrieb: > Ich verwende bei allen Devices: > #define ENTRYMODE ENTRY_ALWAYS Ich meinte
1 | #define ENTRYMODE ENTRY_EXT_RESET |
... muss wohl doch meine Login-Daten wieder heraussuchen.
PORF auswerten, wenn gesetzt dann den Bootlader Überspringen, der Reset über den Resetbutton startet den BL.
Merkt immer noch keiner, daß es eigentlich garnicht um den Bootloader geht, sondern darum, auf ein Signal schnell zu reagieren. Dazu muß man aber nicht am Bootloader drehen, sondern einfach nur den Lösungsansatz ändern.
Peter D. schrieb: > Merkt immer noch keiner, daß es eigentlich garnicht um den Bootloader > geht, sondern darum, auf ein Signal schnell zu reagieren. > Dazu muß man aber nicht am Bootloader drehen, sondern einfach nur den > Lösungsansatz ändern. sicher? > Ich will das ganze mit einem AKKU und einem Bewegungsmelder betreiben. > Deshalb läuft der Attiny85 nicht permanent Standby mit. er schaltet den Attiny85 komplett ab, wenn er neu startet startet der Bootloader der 6 Sekunden wartet und das ist sein Problem. Klar könnte man das so ändern, das der Tiny nur schläft, aber das will er ja nicht.
Peter II schrieb: > Klar könnte man das so ändern, das der Tiny nur schläft, aber das will > er ja nicht. Man kann sich natürlich in einem einmal gefaßten Lösungsansatz festrennen. Der Bewegungsmelder wird ja bestimmt auch Strom benötigen. Und für 24W LED-Last braucht man schon etwas Akkukapazität. Da könnte man leicht ausrechnen, ob ein ATtiny im Power-Down + sparsamen Spannungsregler überhaupt eine Rolle spielt.
Philipp K. schrieb: > Ich würde das mit dem Entry-Pin machen wenn du den Bootloader unbedingt > drauflassen willst. > > Wenn Du eine Anleitung haben möchtest sag bescheid.. wo der Thread schon > auf ist ;) Unbedingt würde ich nicht sagen... Über eine Anleitung würde ich mich sehr freuen! Im Idealfall bleibt der Tiny im Gehäuse und wird dort viele Jahre unberührt seinen Dienst erweisen. Die Kabel liegen unter Putz! Es liegen also nur "sporadisch" 12V an. Extra Versorgungsleitung vom Akku legen, fällt aus! Und einen zweiten kleinen Akku für den Tiny, will ich nicht. Technisch kann man das sicherlich besser lösen, Bautechnisch ist es nunmal so gelöst(worden)
Peter II schrieb: > Scheinbar kann sich auch der bootloader selber neu schreiben. Wenn das wirklich geht, dann Hut ab! Er müßte sich erstmal an eine andere Stelle kopieren, den Resetsprung dahin umleiten, dann den neuen Bootloader schreiben und dann den Resetsprung wieder auf den Start des neuen Bootloaders zurück setzen.
Maximilian A. schrieb: > Die Kabel liegen unter Putz! Es liegen also nur "sporadisch" 12V an. Muß nicht unbedingt ein Hinderungsgrund sein. Man könnte zu dem Sensorkontakt einen Widerstand parallel legen, so daß immer ~5V/5µA auf der Leitung liegen. Liegen dann starke 12V an, erwacht der MC aus dem Sleep und macht sein Ding.
HAHAHA BOOTLOADER Der Weg der Nichtskönner und Denkverweigerer.
Ach VERZEIHUNG. Natürlich der Weg der Leute, die keine Zeit haben, sich mit solche masochistischen Details wie der Funktionsweise eines ISPs zu beschäftigen. Immerhin hat man heutzutage ja auch weitaus wichtigeres zu tun. Z.B. alle 5 Minuten auf das dämliche Smart Phone zu schauen!
ASM Superprofi schrieb: > BOOTLOADER ... Natürlich der Weg der Leute, die keine Zeit haben, sich > mit solche masochistischen Details wie der Funktionsweise eines ISPs zu > beschäftigen Auf Industriestandard uC wie aktuelle 8051 oder ARM ist ISP = der werksseitige UART oder USB oder CAN Bootloader in einem ROM. Sowas wie einen Programmer gibt es dort schon lange nicht mehr, nur der veraltete AVR hat noch ein SPI "ISP" das bei den alten 8051 mal ICP hiess. Solche Bootloader sorgen nebenbei auch dafür, dass man auch noch in den uC reinkommt, wenn es mit Debugger nicht mehr funktioniert, weil entsprechende Pins abgeschaltet oder CPU CLK daneben gesetzt. Überigens bei Deinem PC mit dem Du grade Deinen Kommentar schreibst oder beim Raspberry Pi lädt auch der Bootloader den Kernel.
Wiedermal typisch. Wir reden hier von einer digitalen LED-Rumflacker-Schaltung die man unbedingt via USB programmieren können muss und dann MUSS es ja, wie üblich, so kommen, dass da so einer dahergelaufen kommt und mit erhobenen Zeigefinger als Vergleich die Titanen unter den Rechenknechten ausgräbt. Wahrscheinlich nimmst du einen RasPi, um eine LED zum blinken zu bringen.
Ich habe aus Versehen mal CPU CLK auf 4kHz gesetzt. Mit avrdude war das auch kein Problem, die DIV8 Fuse wieder richtig zu setzen.
Maximilian A. schrieb: > Im Idealfall bleibt der Tiny im Gehäuse und wird dort viele Jahre > unberührt seinen Dienst erweisen. > > Die Kabel liegen unter Putz! Es liegen also nur "sporadisch" 12V an. Ganz im Ernst.. Du möchtest zwei FETs mit zufälligen Spanungsmustern ansteuern, sofern der ATTiny eventuell mal bestromt werden sollte, richtig? Wozu benötigst Du da USB? Wozu einen ATTiny85? IMHO ist das ein Paradebeispiel für einen Tiny13. Der lässt sich ebenfalls über die Arduino IDE proggen, mit ISP und Pseudo-Bootloader für die IDE oder auch mit echtem Bootloader, da wird der Platz dann knapp... Keine Platine, nur ein kleiner Käfer mit 8 Beinchen
Hier stellt jemand eine Frage und sofort wird versucht seine Idee zu verbessern.. Das ist nicht Hilfreich sondern arrogant.. Ich mache das aus einfach nur Spaß auch so.. Attiny85V mit mikrousbbuchse und einfachem Programm.. Solange das Programm nicht zu groß ist und sich der Termin die Möglichkeit der nachprogrammierung offen lassen möchte ist das doch okay. Na okay, trotzdem hab ich auch nen eigenen 8Pin Sockel mit ner 10pol buchse für den Usbasp.. Ich Sockel sogar jeden tiny trotz USB.. Geht doch keinen was an wieso ich das so mache. Ich Jammer ja auch nicht rum das das Programm mit dem Bootloader nicht mehr reinpasst.. Das wäre verbesserungswürdig. Und zum sensor.. Ich habe selbst so ein Projekt.. Der bwm verbraucht idle auf Bewegung wartend 3-12v 5uA.. Da hält nen 9v Block Monate.. Wieso da den Tiny schlafen legen? Edit: der Trick ist dazu noch einen ldo mit dem ttl Output des bwm am enable pin zu aktivieren.. Verbraucht null zusätzlich.
:
Bearbeitet durch User
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.