Hallo, die ATTinys haben ja bekanntlich keinen Bootloader support. Was unser aber dennoch nicht davon abhält dafür Bootloader zu entwickeln (siehe FastBoot). So etwas ähnliches will ich momentan auch machen, nur bräuchte mein Bootloader zwingend Interrupt support, da ich VUSB im Bootloader verwenden will... Klar könnte ich einen ATmega oder so nehmen und dann wäre alles problemlos, aber wo bleibt dann da der Spaß? Zumal die gefertigte Platine schon neben mir liegt. Ohne Interrupt tut der Bootloader wunderbar (zumindest mit den LEDs blicken) aber sobald ein Interrrupt kommt steht die Kiste, da sich die zugehörigen Sprung Positionen ja immer noch am Flash anfangen befinden. Meine Frage wäre jetzt, kann man die mit einem Linker Skript (von dem ich zugegebenermaßen keine Ahnung habe) irgendwie an die passenden Stelle schieben, so das der Bootloader und dann später auch die App Interrupt support haben? In der Frage drückt sich schon meine Verzweiflung aus, weil ich nicht denke, dass man mit so nem Skript die Hardware Sprungadressen umbiegen kann... OK, klar könnte ich am Anfange des Flashs meinen Bootloader Sprungvektor bei jedem Powerup hin kopieren und danach den original kurz vor verlassen des Bootloaders wieder zurück schreiben. Das wären aber 2 Schreibzugriffe auf den Flash; was nach 5000x Strom anlegen den Tot der AVRs zur folge hätte... Ideen? Gruß Jürgen PS: Ich will eigentlich nur an den Reset Pin und nen HighVoltage Programmer hab ich leider nicht... (zudem würde das auch wieder ein anderes Platinen Layout nach sich ziehen....)
Rein theoretisch könntest du den Bootloader am Anfang platzieren (und die ursprünglichen Reset-Vektoren belegen), und in den Interrupthandlern dann direkt zu einem festen Offset weiterspringen, sofern der Bootloader nicht gerade aktiv ist. Du müsstest dann im Linker-Script deiner Anwendung alles um besagten Offset verschieben ... Andere Baustelle: Kriegst du keine Probleme mit V-USB wenn du mitten in der Verbindung anfängst, den Flash neu zu schreiben? V-USB mag es nicht, wenn seine Interrupts oder usbPoll() zu sehr verzögert werden - Und der Flash-Vorgang dauert schon einige Millisekunden ... Es gibt [1] aber wohl eine Implementierung die wohl funktionierend wird, sonst würde sie vermutlich nicht als Beispielprojekt aufgeführt ... mfG Markus [1] http://www.obdev.at/products/vusb/bootloadhid.html
Hallo Markus, danke für die schnelle Antwort. Auf den gleichen Gedanken bin ich nach dem posten auch gekommen. Der Bootloader vorne und dann Methoden für alle Interrupts aufsetzten die dann mit nem RJMP auf die RJMPs der App verweisen. Dann müsste man nicht mal das Linkerscript anpassen... Zwei Probleme sehe ich auf mich zukommen: 1) Wie bereits erwähnt mag VUSB es nicht sonderlich wenn man Interruptsverzögert 2) Wie soll ich im Bootloader ISR, der von der App ausgeführt werden erkennen das ich nicht im Bootloader bin? Evtl vielleicht irgendein Register setzen das ich nicht brauche?! Ich teste das mal aus und halte dich auf dem laufenden. [1] funktioniert, da er sich den Interrupt Vektor zu seinem Bootloader Start kopieren lässt. Ist ein Atmega und kein Tiny... Gruß Jürgen
Ich hatte mich wegen des Timings auf [1] bezogen, nicht wegen der Interruptvektoren. Und doch, du musst das Linkerscript anpassen, das der App nämlich, um diese hinter den Bootloader zu verschieben. 2) Ist das Hauptproblem an der Geschichte, hierfür sehe ich zwei Möglichkeiten: a) Du benutzt eines der General Purpose Register GPIOR0-2 b) Du siehst dir auf dem Stack an, ob die Rücksprungadresse im Bereich des Bootloaders oder der Anwendung liegt. Übrigens, weil es mir gerade auffällt: Du bekommst noch ein weiteres Problem mit V-USB. Du musst dort den Quellcode dahingehend modifizieren dass deine Umleitungs-ISR den Interrupthandler in V-USB aufruft. Der Original-Quellcode erwartet in der Konfiguration nur den Namen eines Interruptvektors und belegt diesen selbst. Außerdem kannst du dann nur hoffen, dass du keine Timing-Probleme durch die Umleitung bekommst ... mfG Markus
Auch mit Interrupts muß das USB damit klarkommen, daß die CPU beim Schreiben angehalten wird. Die ATtiny haben nämlich keine RWW-Sekton. Peter
Probleme über Probleme und so wenig Zeit... Ich muss zugeben in Anbetracht des Vorschrittes des Wochenendes habe ich mich damit abgefunden keinen USB Bootloader zu haben. Ich verwende nun einen kleinen Adapter für den USB Stecker und den FastBoot Bootloader von Peter. Funktioniert einwandfrei ;) Wenn ich mal vieeeeeel Zeit habe und es bis dahin noch nicht vergessen habe werde ich mich dem Problem des "Interrupt weiterleitens" einmal widmen... Gruß Jürgen
Hallo Jürgen, kannst du mir sagen, wie du den bootloader an's Laufen bekommen hast? Bei mir funktioniert er nur im two-wire modus, nicht im one-wire modus. Benutzt du die gcc oder die asm Version?
Hi meinst du den FastBoot? Naja ist zwar etwas off-topic, aber ich hab das build29 genommen, configuriert, kompiliere und drauf geladen. Fertig. One Wire hab ich allerdings noch nie probiert... Hast du den Schaltplan mit den Dioden? Ich hab die GCC toolchain, aber der Bootloader ist eigentlich komplett in asm. - Ich denke ich verstehe deine Frage nicht 100% richtig... Gruß Jürgen
Die Frage war, wie du den one-wire Modus an's laufen gebracht hast. Da du das nicht gemacht hast, kannst du mir da leider nicht weiterhelfen. Aber danke für deine schnell Antwort. Ich finde den bootloader bis jetzt auch sehr gut, will aber nicht zwei pins opfern.
avion23 schrieb: > Bei mir funktioniert er nur im two-wire modus, nicht im one-wire modus. Für die Suche: One-wire modus funktioniert einwandfrei. Lösung siehe gcc thread.
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.