Mahlzeit zusammen,
ich habe auf meinen ATmegas einen STK500v2 kompatiblen Bootloader
laufen, d.h. ich kann mittels avrdude flashen.
Nach einem Reset wartet der Bootloader für eine definierte Zeit, z.B.
5s, danach wird in die Applikation gesprungen.
Soweit, so gut. Denke dieses Vorgehen ist mehr oder weniger Standard.
Wenn ich im laufenden Betrieb flashen will dann geht das nur
umständlich. Ich muss irgendwie in den Bootloader kommen, notfalls über
einen PowerDown Reset. Das erfordert physischen Zugang zum Gerät.
Schöner fänd ichs, wenn ich per Kommando mein Gerät resetten könnte.
Dann muss ich nicht erst an der Stromversorgung oder sonstwo
herummurksen.
Grundsätzlich geht das, denn meine Applikation beherbergt einen
Kommandointerpreter der UART-Kommandos ausführen kann. Unter anderem
auch einen Software-Reset.
Allerdings kennt avrdude diesen Befehl natürlich nicht.
Wie würdet ihr das also lösen?
Ich sehe nur die Möglichkeit:
- vorm avrdude-Aufruf schnell mit einem beliebigen Terminalprogramm den
Reset-Befehl absetzen. Ist halt Mehraufwand. Könnte man evtl. über ein
Shell-Skript lösen.
Kriegt man das geschickter hin? Bietet Stk500v2 irgendwie die
Möglichkeit? Oder kann avrdude auch "eigene Kommandos" irgendwie
absetzen?
>Du hast dir meinen Beitrag nicht durchgelesen, oder?
Wenn in deiner App stk500v2 Kommandos empfangen werden in den Bootloader
springen. Ansonsten steht es dir frei den Sourcecode
von avrdude zu modifizieren.
dummy schrieb:>>Du hast dir meinen Beitrag nicht durchgelesen, oder?>> Wenn in deiner App stk500v2 Kommandos empfangen werden in den Bootloader> springen.
Wäre eine Möglichkeit. Dann muss der stk500v2 Interpreter allerdings
auch noch in die Applikation mit rein. OK, Flash wäre noch genug
vorhanden.
Was mich bisl davon abhält ist dass auf UART0 momentan mein eingangs
erwähnter Kommando-Interpreter hört. Dann müsste dieser wieder
aufgebohrt werden um Kommandos als Stk500-Kommando zu identifizieren.
Unschön, aber liese sich machen.
> Ansonsten steht es dir frei den Sourcecode> von avrdude zu modifizieren.
Unschön, weil Insellösung. Es wäre ungeschickt, einen Stk500v2
Bootloader anstatt ein Eigengewächs zu verwenden um mit gängigen Tools
kompatibel zu sein, nur um dann diese Tools zu modifizieren :-)
Stellt mich alles nicht so recht zufrieden :/
Hi,
so ganz verstehe ich Dein Problem nicht. Jeder ISP Programmer zieht die
Reset Leitung auf low bevor (und während) er programmiert.
Oder meinst Du das flashen mit dem Bootloader?
Dann kannst Du mit avrdude so einen Reset schicken (Beispiel):
avrdude -p atmega32 -P /dev/ttyS0 -b 115200 -c avr910
(d.h avrdude ohne weiteren Befehl aufrufen)
Danach muß natürlich relativ schnell das Terminalprogramm ins Spiel
kommen.
Gruß
Andreas
Andreas B. schrieb:> Jeder ISP Programmer zieht die> Reset Leitung auf low bevor (und während) er programmiert.> Danach muß natürlich relativ schnell das Terminalprogramm ins Spiel> kommen.> so ganz verstehe ich Dein Problem nicht.
Nimms mir nicht übel, aber ich merks.
Entweder ich hab mein Anliegen so schlecht geschildert oder ich hab heut
einfach Pech mit meinen Antworten...
Ich suche mal die Schuld bei mir und versuche, alles nochmal genau zu
beschreiben:
1) Ich habe einen Bootloader der das STK500v2 Protokoll spricht
2) Dieser wird nach Reset grundsätzlich durchlaufen und startet nach
einer bestimmten Zeit die Applikation
3) Die Applikation spricht momentan kein STK500v2.
4) Die Applikation besitzt dafür einen "Kommandointerpreter", der es mir
unter Anderem auch erlaubt, einen Software-Reset durchzuführen
=> Ziel ist, aus dem laufenden Betrieb die Applikation zu flashen,
respektive in den Bootloader zu wechseln, ohne irgendwelche Tricks wie
"Netzstecker ziehen"
Die Lösung, per Terminal meinen Reset-Befehl zu senden und dann ganz
schnell avrdude aufzurufen würde gehen. Die bedingt aber ein zweites
Tool (Terminal) und ein genaues Timing (avrdude muss rechtzeitig
gestartet werden)
OK, dann versuche ich auch mal etwas deutlicher zu werden:
Fall 1: Bootloader flashen
Jeder ISP Programmer zieht die Reset Leitung auf 0, programmmiert und
interessiert sich nicht für ein laufendes Programm
Fall 2: Anwendung mittels Bootloader flashen
Eine Batch Datei erstellen, die via avrdude den AVR mit Programmer und
CPU Typ aufruft. Dabei wird Reset auf 0 gezogen. Anschließend wird in
dieser Batch Datei das Terminalprogramm aufgerufen.
Ich weiß allerdings nicht, was ein STK500 Protokoll ist (habe kein STK).
Somit kann ich also auch auf dem Holzweg sein. Aber für einen AVR, der
per ISP ansprechbar ist und auch einen Bootloader hat, der seriell
ansprechbar ist, wäre dies ein Weg.
Gruß
Andreas
Oder eine Batch-Datei bzw. Shell-Script machen, die folgendes tut:
* ein Script/Programm aufrufen, dass:
** den Reset-Befehl über UART absetzt
** wartet bis über den UART ein "Bootloader Ready" kommt
* avrdude aufrufen
Ben schrieb:> momentan mein eingangs> erwähnter Kommando-Interpreter hört. Dann müsste dieser wieder> aufgebohrt werden um Kommandos als Stk500-Kommando zu identifizieren.> Unschön, aber liese sich machen.
Das halte ich für die vernünftigste Lösung und keineswegs unschön. Je
nachdem wie Dein eigenes Protokoll aufgebaut ist (und Dein
Kommandointerpreter) sollte es überhaupt nicht schwer sein anhand der
ersten paar Bytes die reinkommen einen Verbindungsversuch des avrdude zu
erkennen und dann einen reset auslösen. Avrdude wird seinen
Verbindungsversuch mehrmals wiederholen.
Reset löst Du aus indem Du den watchdog auf die kürzeste Zeitspanne
stellst und dann while(1);
@Andreas B.
Ja du bist total auf dem Holzweg.
Es geht nicht um den üblichen Aufbau einer Schaltung mit AVR, sowie
einem zusätzlichen Programmieradapter.
Sondern die Schaltung hat KEINEN Programmieradapter. Stattdessen hat der
AVR eine Firmware, die ihn selbst flasht und einen STK500v2 Programmer
simuliert.
Aber das tut sie nur in den ersten Sekunden anch dem Reset. Danach wird
das eigentliche Programm der Anwendung gestartet die zu einem ganz
anderen Zweck seriell mit dem PC kommuniziert.
Der Serielle Port kann dann eben NICHT mehr zum Programmieren genutzt
werden.
Aber der PC kann über den seriellen Port einen Befehl absetzen, der die
Firmware im AVR dazu veranlasst, neu zu starten. Dadurch würde der
Controller für einige Sekunden lang bereit sein, Befehle eines
Programmieradapters anzunehmen.
Nun möchte er aber PC seitig nicht zwei Programme benutzen (eins um den
Reset-Befehl seriell zu senden, und ein zweites, um zu programmieren),
sondern gerne beides elegant kombinieren, am liebsten nur mit avrdude.
Jetzt verstanden?
Dann gibt es eigentlich nur diese Möglichkeiten:
- avrdude modifizieren, Reset + Warten auf Bootloader zu machen
- eigenen Com-Driver schreiben, der mit dem Weiterleiten der
avrdude-Kommandos wartet und vorher noch Reset sendet
- die Avr Software modifizieren, damit sie auf Programmer-Kommandos
resettet
- einen eigenen AVR auf dem UART mithören lassen und der macht einen
Hardware-Reset, wenn er Programmer-Befehle sieht :-)
- eine separate RESET-Leitung zur Zielschaltung
Ben schrieb:> Die Lösung, per Terminal meinen Reset-Befehl zu senden und dann ganz> schnell avrdude aufzurufen würde gehen. Die bedingt aber ein zweites> Tool (Terminal)
Ja, und?
> und ein genaues Timing (avrdude muss rechtzeitig gestartet werden)
Du kannst ja die Wartezeit im Bootloader passend einstellen. Aber wie
lange kann das schon dauern, nach "echo 'reset, bitte' >/dev/ttyS0" dann
avrdude zu starten?
Avrdude zu modifizieren halte ich wiederum für eine schlechte Lösung.
Es widerspricht dem KISS-Prinzip. "One job, one tool." Schließlich hat
man eine Shell genau für diese Art von Aufgabenstellung.
XL
Ben schrieb:> Die Lösung, per Terminal meinen Reset-Befehl zu senden und dann ganz> schnell avrdude aufzurufen würde gehen. Die bedingt aber ein zweites> Tool (Terminal)
Nein. Kein Terminal. Einfach ein simples Script das den seriellen Port
öffnet, die spezielle Reset-Sequenz sendet, den Port wieder schliesst
(wahrscheinlich reicht sogar ein simples echo, notfalls vorher noch die
Baudrate setzen) und dann avrdude startet. Müsste mit 2 oder 3 Zeilen
Bash gehen. Timing ist auch nicht kritisch denn obiges läuft in wenigen
Millisekunden ab während Du wahrscheinlich fast ne halbe Sekunde (also
ne halbe Ewigkeit) Zeit hättest.
