Hi, ich habe einen Arduino pro Mini für die Lüftersteuerung eines Netzteiles verwendet. Da das Netzteil das Tachosignal des Lüfters überwacht und der neue deutlich größere Lüfter so langsam dreht, dass es abschaltet, sendet der Arduino eigenes schnelleres Tachosinal, das bei einem Ausfall des echten Lüfters oder bei Übertemperatur abgeschaltet wird. Nun stelle ich (viel zu spät) fest, dass sich der Arduino sehr viel Zeit genehmigt, bis in setup() das pinMode(PULSEPIN, OUTPUT); analogWrite(PULSEPIN, 127); ausgeführt wird. Das Netzteil schaltet vorher mangels Lüftersignal schon ab. Kann man den "Bootvorgang" des Arduinos beschleunigen? Leider hat der Arduino Pro Mini keinen ISP-Header, sonst hätte ich das Programm an diesem Punkt in normales C überführt und den bremsenden Bootloader über Board geworfen. Eigentlich sollte das eine schnelle Lösung werden... :/ Gruß, Chris
Chris schrieb: > Leider hat der > Arduino Pro Mini keinen ISP-Header Ja und? Alle nötigen Signale liegen auch auf den Pinreihen.
ich glaube nicht, das der Bootloader allein für das von dir beschriebene Delay-Phänomen verantwortlich ist. Wenn du den als Dummy eines langsamen Lüfters für ein Netzteil das einen schnellen Lüfter erwartet, dann musst du nach dem Einschalten dem Netzteil einen schnellen simulieren... Aber ohne genauere Komponenten, Programm ist das was? Kristallkugel guggen... cu zipp
Chris schrieb: > Kann man den "Bootvorgang" des Arduinos beschleunigen? Ja, du kannst den Bootloader runter werfen. Der Rest der Verzögerung steckt in deinem Programm.
Hmm, dein Arduino müsste schneller starten als der eingebaute Mikrcontroler welches das Tachosignal prüft... Das könnte schwierig werden. Was heisst denn überhaupt sehr viel Zeit? Millisekunden oder Sekunden? Falls Sekunden, gab es mal einen älteren bootloader der vor dem eigentlichen Start, einige Sekunden auf ein mögliches USB Signal wartete.
:
Bearbeitet durch User
Alex G. schrieb: > Hmm, dein Arduino müsste schneller starten als der eingebaute > Mikrcontroler welches das Tachosignal prüft... Das könnte schwierig > werden. Nein muss er nicht. Auch ein kleinerer, realer Lüfter braucht eine gewisse Zeit zum Anlaufen. Der Arduino muss das Taktsignal nicht eher liefern wie auch der vorher eingebaute Lüfter Zeit gebraucht hat, um die erste Taktflanke zu liefern. @TO, hau erst mal den Bootloader raus und probiers so.
Paul H. schrieb: > Alex G. schrieb: >> Hmm, dein Arduino müsste schneller starten als der eingebaute >> Mikrcontroler welches das Tachosignal prüft... Das könnte schwierig >> werden. > > Nein muss er nicht. Auch ein kleinerer, realer Lüfter braucht eine > gewisse Zeit zum Anlaufen. Wahrscheinlich ist der Mikrocontroler darauf programmiert überhaupt einen einzigen ersten Impuls zu erwarten. Das kommt sicehrlich bei einem echten Lüfter im Bruchteil einer Sekunde. Die eigentliche Geschwindigkeitsprüfung kommt dann später.
Chris schrieb: > Nun stelle ich (viel zu spät) fest, dass sich der Arduino sehr viel Zeit > genehmigt, bis in setup() das pinMode(PULSEPIN, OUTPUT); > analogWrite(PULSEPIN, 127); ausgeführt wird. Das hat nichts mit setup() zu tun, sondern das ist die Zeit, die der Bootloader dir gibt, um das Flashen eines neues Programms anzustoßen.
Danke! Dann werde ich wohl doch Kabel an die ISP-Pins friemeln müssen. Das ist eben aufgrund der "baulichen Situation" nicht so einfach. Im Testaufbau (da wurde der Arduino per Labornetzteil gespeist und war somit immer vor dem Netzteil schon in Betrieb) hat der Aufbau gut funktioniert. Es liegt somit nicht an der simulierten Lüftergeschwindigkeit. In setup() kommt als erstes der Befehl für die PWM-Ausgabe. Schneller ist es nicht zu machen, die Verzögerung steckt eindeutig im Bootloader. Gruß, chris
Nur so ein Gedanke: Könntest du nicht durch Hardware ein Tachosignal (max-Speed) vorgaukeln, bis der Arduino gestartet ist? z.B. über einen Pull-Widerstand einen Duty Cycle von 100% "simulieren".
Alex G. schrieb: > Wahrscheinlich ist der Mikrocontroler darauf programmiert überhaupt > einen einzigen ersten Impuls zu erwarten. Das kommt sicehrlich bei einem > echten Lüfter im Bruchteil einer Sekunde. > Die eigentliche Geschwindigkeitsprüfung kommt dann später. Ja das stimmt schon ;-) Deshalb muss der Arduino trotzdem nicht schneller starten als der interne Mikrocontroller. Es reicht ja wenn der Arduino innerhalb der ersten paar 10..100ms die erste Taktflanke raushaut, und das ist problemlos machbar :-) Schlumpf schrieb: > z.B. über einen Pull-Widerstand einen Duty Cycle von 100% "simulieren". Lüfter hauen aber kein PWM-Signal variablen Duty Cycles raus sondern ein Taktsignal variabler Frequenz.
:
Bearbeitet durch User
Lüfter haben einen Open Collector Ausgang für das Tachosignal. Mein Netzteil hat einen Pullup nach 12V, d.h. unbeschaltet ist die Leitung High -> Netzteil schaltet ab. Lege ich sie fest auf GND, schaltet es auch ab. Da muss ein Takt vorhanden sein. Ich könnte versuchen, die Frequenz zu erhöhen, vielleicht reicht es dann ja gerade so.... wäre aber schon ein großer Zufall.
Chris schrieb: > Ich könnte versuchen, die > Frequenz zu erhöhen Welche Frequenz? Die Frequenz von µC?? Der Mikrocontroller startet je nach Fuse-Einstellung innerhalb von <1ms, das ist nicht das Problem. Mach es einfach "richtig" und dann funktioniert es auch. Der Bootloader erzeugt ein fixes Delay von 1..2 Sekunden oder so. Schmeiß den erst mal raus.
:
Bearbeitet durch User
Schlumpf schrieb: > Nur so ein Gedanke: > Könntest du nicht durch Hardware ein Tachosignal (max-Speed) vorgaukeln, > bis der Arduino gestartet ist? Der Arduino ist doch schon diese Hardware, die das gefälschte Tachosignal erzeugt. Im Zusammenhang mit einem ATMega328 überhaupt von einer "Startzeit" zu sprechen, ist höchst albern. Rein von der Hardware her braucht er wenige Millisekunden bis er läuft. Und das wird im wesentlichen durch die Taktquelle (Quarz, Resonator, RC - in Reihenfolge langsam zu schnell) bzw. die passend dafür gesetzten Fuses bestimmt. Daß sich der Arduino-Bootloader noch eine zusätzliche Gedenksekunde gönnt, ist ein reines Softwareproblem. Und wenn der TO zu faul ist, die ISP- Leitungen zu verdrahten, damit er den Bootloader runterwerfen kann, dann ist doch Hopfen und Malz verloren.
Chris schrieb: > In setup() kommt als erstes der Befehl für die PWM-Ausgabe. Schneller > ist es nicht zu machen ich denke, wenn du dir anguckst, was vor 'setup()' noch alles aufgerufen wird, kommst du zu dem schluss, das es doch schneller geht. so ganz ohne arduino overhead z.b.
Axel S. schrieb: > Der Arduino ist doch schon diese Hardware, die das gefälschte > Tachosignal erzeugt. Schon klar.. Es war nur die Idee, durch eine irgendwie geartete Schaltung z.B. Max-Drehzahl vorzugaukeln, bis der Arduino dann startklar ist. Einfach während des Bootvorgangs ein Singal zu erzeugen, welches eine Drehzahl vorgaukelt, die das Netzteil NICHT zum Abschalten bewegt. Ich hab mich aber mit dem Tachosignal nicht weiter befasst. Wenn das nicht einfach über einen Widerstand o.Ä, geht, ist die Idee natürlich hinfällig.
Schlumpf schrieb: > Es war nur die Idee, durch eine irgendwie geartete Schaltung z.B. > Max-Drehzahl vorzugaukeln, bis der Arduino dann startklar ist. Naja dann bräuchte man ja den Arduino auch nicht mehr :-D Whatever, der TO weiß jetzt bescheid, was er tun muss. Case closed.
Es gibt hier auch noch einen anderen Bootloader. Die Beschreibung liest sich so, als würde der schneller starten. https://github.com/Optiboot/optiboot
Chris schrieb: > Es gibt hier auch noch einen anderen Bootloader. Die Beschreibung > liest > sich so, als würde der schneller starten. > https://github.com/Optiboot/optiboot Das entspricht dem UNO Bootloader. Es ist möglich den UNO Bootloader auf den (5V 16MHz) Pro Mini zu spielen. Ab dem Zeitpunkt ist er dann, in der IDE, auch als UNO anzusprechen und zu nutzen. Beim PowerOn, BOD und WDT-Reset startet er fix durch. Nur beim betätigen des Reset, ob über DTR, oder per Knopf, wartet er kurz auf die serielle Verbindung zu Avrdude. Doof ist halt dann noch, dass die Quarz Einschwingzeit auf sehr lang stehen bleibt(was bei einem Quarz auch gut und richtig ist). Viele Pro Mini Clone haben einen Quarz, keinen Keramik Resonator. Das wird man auch wohl nur weg bekommen, wenn man auf internen Takt umstellt. Aber dann ist der UNO Bootloader nicht mehr nutzbar. Also, mein Tipp: Weg mit dem Bootloader.
Danke für die Info. Was passiert genau, wenn ich mit der Arduino IDE über einen ISP-Programmer flashe? Wird dann mein Sketch geflasht und der vorhandene Bootloader bleibt unberührt, oder erhalte ich dann einen Arduino ohne Bootloader?
Chris schrieb: > Wird dann mein Sketch geflasht und der > vorhandene Bootloader bleibt unberührt, oder erhalte ich dann einen > Arduino ohne Bootloader? Jain! Der Chiperase löscht den Bootloader. Aber die Fuses bleiben stehen. Die sollte man dann auch ändern. Den Resetvektor auf die Adresse 0 setzen Denn: Die 0xFF (eines gelöschten Flash) entsprechen einem Nop, aber die vielen Nops wollen auch erst durchlaufen werden. Unnütze Zeit. Und Zeit ist hier knapp.
Ok. Ich habe jetzt per ISP geflasht und der Lüfter startet sofort und das Netzteil bleibt an. Bei Gelegenheit teste ich mal Optiboot.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.