Hallo, ist es realisierbar, dass ein Mikrocontroller (konkret STM32) als USB MIDI Device fungiert, aber mit einem eigenen Bootloader dann als USB CDC Device arbeitet, um entsprechend ein Firmware-Update durchzuführen? Und zwar ohne das Gerät ab- und anzustöpseln. Beispiel: Das Gerät ist mit einem Windows Host als Midi Device verbunden. In einem extra Windows-Programm kann der User auf "Update Firmware" klicken. Das Windows-Programm sendet ein MIDI Sysex an das Gerät. Das Gerät bootet neu, und hat zB in einem Register der RTC einen speziellen Wert stehen, so dass der Bootloader in einen Firmware-Update-Mode geht. Dadurch meldet sich das Gerät als USB CDC Device an und kann entsprechend Daten empfangen. Ist das realisierbar? Alternativ könnte der Bootloader sich ebenfalls als Midi Device melden und dann schickt man das ganze Firmware-Update als Sysex rüber.
Gast
#6450753
Warum keine DFU Device class?
Weil ich aus Speicherplatzmangel (nur 64K Flash) keine HAL Treiber verwenden kann, und an fertigen (von anderen entwickelten) platzsparenden Treibern habe ich nur MIDI und CDC zur Verfügung.
Thorsten S. schrieb: > Ist das realisierbar? Klar. Wenn der USB-Pull-Up-Widerstand schaltbar ausgeführt ist, kann sich ein Device vom PC auch wieder abmelden, ohne dass es physisch ausgesteckt wird.
Thorsten S. schrieb: > Beispiel: Das Gerät ist mit einem Windows Host als Midi Device > verbunden. In einem extra Windows-Programm kann der User auf "Update > Firmware" klicken. Das Windows-Programm sendet ein MIDI Sysex an das > Gerät. Warum schickst du nicht gleich die Firmware selbst per Sysex? So machen es Synthesizer sehr oft. Dann braucht man noch nicht mal ein spezielles Programm, sondern nur eins, das Dateien per Sysex senden kann.
Rolf M. schrieb: > Warum schickst du nicht gleich die Firmware selbst per Sysex? Weil er nicht genug Flash hat die neue Firmware zwischenzuspeichern: Thorsten S. schrieb: > Weil ich aus Speicherplatzmangel (nur 64K Flash) Nimm einen µC mit mehr Flash. Dann könntest Du entweder oben angesprochene Lösung fahren - der eigentliche Bootloader kopiert dann nur die Firmware von "neu" auf "alt". Oder Du hättest genug Platz um einen CDC Bootloader vernünftig implementieren zu können. USB braucht Platz im Flash für das notwendige EP0 Handling. Ich hatte auch schon mal eine Lösung gesehen die die Firmware in einem externen SPI oder I²C EEPROM speichert. Größerer µC ist aber normalerweise billiger (weniger PCB space, weniger Bauteile).
Ich habe schon beide Varianten realisiert. Update per Sysex und Update per CDC. Wenn du genügend Flash hast um erst mal eine Schattenkopie anzulegen kannst du die UsbMidi Interface Deskriptoren und die CDC Interface Deskriptoren in einem Compound Device zusammenfassen, dann brauchst du nicht mal ein Sysex Befehl zum umschalten. Dein Updater schickt die FW dann in freie Flashpages, wenn alles runtergeladen ist wird die FW umkopiert und kurz ein reconnect ausgelöst. Die umkopiersoftware muss dazu natürlich im Ram liegen. Das ist quasi DFU für Arme braucht aber im Gegensatz zur DFU class keinen Kernel Treiber den Win ja immer noch nicht bietet.
Jim M. schrieb: > Rolf M. schrieb: >> Warum schickst du nicht gleich die Firmware selbst per Sysex? > > Weil er nicht genug Flash hat die neue Firmware zwischenzuspeichern: Aber per CDC hat er ihn?
Gast
#6451506
Thorsten S. schrieb: > ist es realisierbar, dass ein Mikrocontroller (konkret STM32) als USB > MIDI Device fungiert, aber mit einem eigenen Bootloader dann als USB CDC > Device arbeitet, um entsprechend ein Firmware-Update durchzuführen? Und > zwar ohne das Gerät ab- und anzustöpseln. Ja. Du musst nur in der Hardware die Möglichkeit vorsehen, das sich das Teil sozusagen selber ab- und anstöpseln kann. Absolut trivial. Jedenfalls, wenn man die grundsätzliche Funktionsweise von USB begriffen hat...
Ich habe mich inzwischen für die Variante per SysEx entschieden. Zu diesem Zweck bekommt der Bootloader ebenfalls eine USB-Midi Device. Ich vermute aber, wenn das Hauptprogramm einen Reset durchführt um den Bootloader zu starten, muss trotzdem ein USB-Reconnect durchgeführt werden, damit der Treiber im Bootloader initialisiert wird?
Thorsten S. schrieb: > Ich > vermute aber, wenn das Hauptprogramm einen Reset durchführt um den > Bootloader zu starten, muss trotzdem ein USB-Reconnect durchgeführt > werden, damit der Treiber im Bootloader initialisiert wird? USB erfordert das nicht. Die USB-Peripherie des STM32 wahrscheinlich auch nicht (ich weiß nicht, ob die bei allen gleich ist). In den Bootloader wechseln wird nicht soviel Zeit kosten, dass man in einen Timeout läuft. Aber: Die Zustandsmaschine des USB-Devices im Bootloader wird komplizierter, wenn schon verschiedene Zustände bei seinem Start vorliegen können. Ich würde also einen USB-Reset machen.
Gast
#6452161
Welcher µC ist es denn? Hat er einen internen USB-Bootloader? https://tomeko.net/miniscope_v2e/ Vielleicht kann das eine Vorlage sein?
Bei der Sysex Übertragung kann es bei langen Sysex Folgen zumindest unter Win7 zu Übertragungsfehlern kommen. Usbaudio.sys scheint da irgendwo einen Bug zu haben. Unter win10 hab ich das bisher nicht beobachtet. Eine Blocksicherung ist daher sehr zu empfehlen. Ich hab für die Übertragung Intel Hex benutzt auch wenn es etwas länger dauert. Damit umgeht man sehr elegant das 7bit Problem. Ob überhaupt ein Bootloader notwendig wird hängt von der FW Größe ab wenn diese und deinem Fall < 32k ist kann man das Update auch direkt anstoßen und die Daten erst Mal im freien Flash speichern. Falls das nicht möglich ist würde ich ev. sogar über ein kleines SPI Flash nachdenken oder halt einen Controller mit mehr Flash einsetzen. Die Lösung mit speichern im freien Flash hat auch den Charme, dass CRC Validierungen vor dem Flashen möglich sind. Der Vorteil bei einer Bootloader Version würde ich darin sehen, dass die Hauptfirmware die Sysex Folgen nicht darauf filtern muss ab das durchgereicht werden soll oder an den Updatecode geleitet werden muss.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.