Moin, liebe gcc-Profis! Folgende Aufgabe stellt sich mir: Ich möchte meinen ATMega644 via WLAN (ZG2100) flashen, das WLAN soll in der Anwendung weiter genutzt werden können. Im Grunde genommen eine Anwendung, in der nach dem Flashen eine Teilfunktionalität erhalten bleibt bzw. ein Bootloader, der sich Ressourcen mit der Anwendung teilt. Vielen Dank, schon im Voraus
:
Verschoben durch Moderator
Und Du hast das Gefühl jemand zauber Dir die Software und nen Schaltplan herbei oder was ?
Manchmal sind die Träume größer als das eigene Vermögen normalerweise nimmt man dies, um das eigene Vermögen zu vergrößern
Freund schrieb: > Ich möchte meinen ATMega644 via WLAN (ZG2100) flashen, das WLAN soll in > der Anwendung weiter genutzt werden können. Ok. Dann viel Erfolg. > Vielen Dank, schon im Voraus Gern geschehen. PS: Nächstes Mal solltest du nach der Einleitung deines Postings vielleicht noch eine Frage stellen. ;-)
@ Marco Ne, Schaltplan ist nicht notwendig. Die Übertragung läuft bereits. Trotzdem: Danke für den hilfreichen Beitrag. @Marcus B. Ja, da hast Du wohl recht, das ist wohl manchmal so. Sehr gut! @Noch'n Freund Ausgehend von der Tatsache, dass die WLAN Übertragung bereits funktioniert und die Anwendung bereits fertig ist, kann man nach dem Flashen via WLAN selbiges in der Anwendung weiterhin verwenden? Wie kann ich dieses Ziel erreichen bzw. was habe ich für Möglichkeiten? (Bitte versucht das Gedisse aus diesem Thread zu lassen. Es muss doch möglich sein, sich hier vernünftig und sachlich zu unterhalten.)
Vielleicht solltest Du erst einmal ausführlich und vor allem verständlich dein Problem und deine Fragen formulieren. Das erhöht die Wahrscheinlichkeit auf kompetente Hilfe ungemein.
@Chris :) Hab ich auch schon bemerkt. Doch darauf kann man auch anders reagieren, oder?
Es ist wesentlich einfacher, die Routinen für das WLAN erneut einfach mit zu compilen, anstatt den Flash irgendwie zu recyceln
@Marcus B. Ja, das auf jeden Fall. Jedoch müsste die WPA2-verschlüsselte Verbindung beim Einschalten erneut hergestellt werden. Das dauert ca. 30 - 45 Sek. Also mind. 1 Minute. Auch kann ich nicht gerade mit Programmspeicher um mich schmeißen. Es geht so wie Du sagst, doch da müsste es doch elegantere Lösungen geben, oder?
ok, das mit dem Recconect ist unschön. Ich würde das so regeln: Die Updateroutine läd via WLAN, das neue Hex-File( in einen externen Speicherbaustein, ggf. SD-Karte) [nach Verifizierung] wird dann in den Bootloader gesprungen, der die WLAN Verbindung hält und den Flash beschreibt. Danach wieder aus dem Bootloader in das Programm gehen
Ich sehe den Vorteil des externen Speichers noch nicht. Also wenn ich Dich richtig verstehe, rätst Du mir zu einem Bootloader. Dieser ist in der Lage WLAN "zu sprechen". Wenn ich nun die Anwendung starte, braucht diese ja wieder eine WLAN-Verbindung, welche wiederum aufgebaut werden muss. Was aber zu lange dauert, denn das Gerät wird häufig an und ausgeschaltet und sollte möglichst direkt verfügbar sein. Ich habe bereits überlegt, ein paar Flags (damit die Verbindung nicht neu aufgebaut wird) zu setzen, und immer wieder den BL aus der Anwendung heraus aufzurufen. Doch dafür müssten beide (Anwendung und BL) auf eine Speicheradresse zugreifen. Schön ist diese Lösung aber auch nicht.
Hi, Freund, > Wenn ich nun die Anwendung starte, braucht diese ja wieder eine > WLAN-Verbindung, welche wiederum aufgebaut werden muss. > > Was aber zu lange dauert, denn das Gerät wird häufig an und > ausgeschaltet und sollte möglichst direkt verfügbar sein. Aber doch nicht jedesmal mit Bootloading, oder? So mache ich es: 1. Im EEPROM eine Variable Bootstart. Der Bootloader fragt sie im Bootvorgang ab. Ist sie gesetzt, leitet er den Bootvorgang ein. Eben ohne Aufbau irgendeiner Verbindung. Andernfalls ruft er das Anwendungsprogramm auf. 2. Auf Kommando setzt Dein Anwendungsprogramm die Variable Bootstart auf "Bootloading". Anschließend startet sie den Prozessor, dieser beginnt mit dem Bootloader. 3. Nach dem Bootvorgang testet der Bootloader, ob alles korrekt gebootet wurde. Erst nach erfolgreichem Test wird die Variable Bootstart in den Zustand "Anwendung" gesetzt. Andernfalls wird der Bootvorgang so lange wiederholt, bis er korrekt abgeschlossen wurde. Ich hatte das mal gemacht für eine Anwendung, wo der Prozessor unzugänglich verbaut war, der Zugang sogar mit Vogelsch..sse verdreckt. Ich hatte den Bootloader in C geschrieben für einen Atmega128 und Kommunikation über UART. Wegen einiger Service-Aufgaben wie Setzen der IO-Pins war in der Bootloadersection nicht mehr viel Platz. Deswegen würde ich die Fehlersicherung für das Booten eher nach Art eines ARQ-Protokolls angehen, also kleine Pakete, jedes mehrfach übertragen und jede Übertragung eigens gesichert. Ciao Wolfgang Horn
Man sollte Interrupts in einem Bootloader vermeiden. Die machen alles sehr unuebersichtlich. Die ist einfach, da der Bootloader eine kleine und uebersichtliche Mail-Loop, die aus einer einfachen Zustandsmaschine besteht, haben kann. Moeglicherweise ist man dann nicht mehr so schnell in der tatasaechlichen Applikation und man sollte Interrupts verwenden. Dh man schreibt die funktionalitaet nochmals.
@ Wolfgang Ahh, das ist eine wirklich elegante Lösung. Da hätte ich eigentlich selbst drauf kommen können. Vielen Dank für den Tipp. So will ich es mal versuchen. @Oktal Oschi Ja, Interrupts verkomplizieren die Sache. Ich versuche diese zu vermeiden. Dann setz ich mich mal an die letzte Hürde. Danke Euch.
So, nun hab ich mal den Treiber und das Protokoll in meinen Bootloader eingebaut und siehe da: 6100 Bytes groß :( Sieht so aus als müsste ich das ganze in 3 Teile zerlegen, so dass der Bootloader nur als Switch dient, welcher die Programme (SubBootLoader oder Anwendung) aufruft. Seht ihr dabei Probleme, die mir nicht auffallen? Noch mehr praktische Tipps?
Hallo, Profis, ich habe nun also den Atmega folgendermaßen bespielt: Addr: 0x0000 Anwendung Addr: 0xCE00 Bootloader beschreibt den Anwendungsbereich Addr: 0xFE00 Switchloader entscheidet, ob Bootloader oder Anwendung gestartet wird BOOTRST ist gesetzt, Interrupttabelle verbleibt auf 0x0000. Das funktioniert soweit auch ganz gut. Doch um nicht jedesmal den kompletten Chip beschreiben zu müssen, wenn ich den Bootloader aufspiele habe ich die Adresse ein wenig weiter nach unten verschoben. Addr: 0x0000 Anwendung Addr: 0x0500 Bootloader beschreibt den Anwendungsbereich Addr: 0xFE00 Switchloader entscheidet, ob Bootloader oder Anwendung gestartet wird Das Flashen läuft auch wesentlich schneller nur ist die Funktionalität komplett weg(offenbar springt er nicht an die Adresse) auch bei der Adresse 0x0600 funktioniert es nicht. Bei 0x1000, 0x0200 oder 0x0000(also ohne Anwendungsteil) funktionieren wieder alles. Kann mir jemand sagen, ob das irgendwelche Adressen sind an die ich nicht springen darf oder was da sonst falsch laufen könnte?! Was ausgeschlossen werden kann ist der Chip, den habe ich schon testweise ausgetauscht und das Programm welches ja in den anderen Bereich läuft und auch im Assamblercode zur richtigen Adresse springt. Zudem sind auch alle Kompilerflags richtig gesetzt (Ttext für den Bootloader) und des Programm steht im Mega an der richtigen Adresse(hab ich ausgelesen). Hat da einer ne Idee warum das so ist bzw. was da falsch läuft? Nen Workaround hab ich ja schon, ich will nur wissen warum ich an die Adressen nicht springen kann.
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.