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