Hallo zusammen, ich hätte gerne gewusst, ob man sein Quellcode, den man für einen Mikrocontroller programmiert hat, über Funk an diesen µC senden kann. Man könnte sich dadurch das mehrmalige Nutzung eines Programmers sparen. Geht das überhaupt? MfG
Ja, geht! Den Quellcode solltest du vorsichtshalber noch für den uC passend compilieren, solange du kein Interpreter darauf laufen lassen wilst.
Welchen uC hast du denn? Über welche Distanz möchtest du denn funken? Ansonsten gilt das selbe wie für drahtgebundene Bootloader.
Ja, nennt sich "OTA" für (over the air) und wird meist per WLAN erledigt. Z.B. die ESP8266 können das. Allerdings wird da nicht der Programm-Sourcecode hingeschickt, sondern das (binäre) Compilat (Maschinencode). Es muss genug Speicher vorhanden sein, um das Programm zunächst zu empfangen, zu puffern und zu verifizieren. Außerdem eine Firmware/Bootloader (die üblicherweise von der Veränderung ausgenommen bleibt), die dann nach einem Reset das neue Programm aus dem Puffer in den Programmspeicher (meist Flash) kopiert und startet ...
:
Bearbeitet durch User
mukel schrieb: > Welchen uC hast du denn? Spielt keine Rolle. Die Frage war eher allgemein formuliert. Es können 8, 16 -oder oder 32 Bitter sein. mukel schrieb: > Über welche Distanz möchtest du denn funken? Ich dachte an einige km mit Lora. Ich spiele gerade mit einem Pycom Modul und mir ist die Idee mit der drahtlosen Übersendung des Programmcodes eingefallen. MfG
Frank E. schrieb: > Ja, nennt sich "OTA" für (over the air) und wird meist per WLAN > erledigt. Z.B. die ESP8266 können das. Das haben auch einige STM32 auch oder? Ich könnte meinen, ich habe es aus einem Datenblatt mal gelesen.
R2D2 schrieb: > Frank E. schrieb: >> Ja, nennt sich "OTA" für (over the air) und wird meist per WLAN >> erledigt. Z.B. die ESP8266 können das. > > Das haben auch einige STM32 auch oder? Ich könnte meinen, ich habe es > aus einem Datenblatt mal gelesen. Die Funktionalität wird z.B. duch eine Lib "gegeben", die mit allen MCs benutzt werden kann, die über die Arduino-IDE programmierbar sind (und Netzwerk-Anschluss haben).
R2D2 schrieb: > ich hätte gerne gewusst, ob man sein Quellcode, den man für einen > Mikrocontroller programmiert hat, über Funk an diesen µC senden kann. > Man könnte sich dadurch das mehrmalige Nutzung eines Programmers sparen. Dafür brauchst du kein Funk. Mit einem geeigneten Bootloader, den du einmal per Programmer auf den µC gespielt hast, kann der µC seinen eigenen Programmspeicher neu beschreiben. Den Code kannst du ihm z.B. über eine serielle Schnittstelle zuschieben. IMHO alle Arduinos können das.
Wolfgang schrieb: > R2D2 schrieb: >> ich hätte gerne gewusst, ob man sein Quellcode, den man für einen >> Mikrocontroller programmiert hat, über Funk an diesen µC senden kann. >> Man könnte sich dadurch das mehrmalige Nutzung eines Programmers sparen. > > Dafür brauchst du kein Funk. > > Mit einem geeigneten Bootloader, den du einmal per Programmer auf den µC > gespielt hast, kann der µC seinen eigenen Programmspeicher neu > beschreiben. Den Code kannst du ihm z.B. über eine serielle > Schnittstelle zuschieben. IMHO alle Arduinos können das. Naja, vlt. will der TO aber gerde KEIN Kabel dranstecken. Hat schließlich auch seine Vorteile bei Geräten, die bereits im Einsatz sind (Updates).
R2D2 schrieb: > Ich dachte an einige km mit Lora. Bei der geringen Bandbreite von Lora braucht man da aber viel Geduld.
R2D2 schrieb: > ich hätte gerne gewusst, ob man sein Quellcode, den man für einen > Mikrocontroller programmiert hat, über Funk an diesen µC senden kann. > Man könnte sich dadurch das mehrmalige Nutzung eines Programmers sparen. > Geht das überhaupt? Den Quellcode wohl kaum, den müsste der uC danach noch für sich selbst compilieren. Den compilierten Binärcode schon, das ist nicht so viel anders als das serielle downloaden eines neuen Programms auf einen uC mit Bootloader, wie ihn der Arduiono macht. Stichwort bootloader: Der muss halt, neben dem seriellen entgegennehmen des neuen Binärcodes, auch noch etwas Verwaltung treiben, damit das mit einer prinzipell unsicheren Funkverbindung auch noch klappt. Synchronsieren etc. Und du brauchst den Sender, also deinen PC, der hat eigentlich kein Funk. Selbst bluetooth wird nämlich den uC überfordern, der will eher 433MHz auf RF12 Basis oder so. Alles ins allem also eine umständliche Idee, man nimmt lieber ein USB Kabel. Wie wäre USB kabellos ? Wireless USB gab es mal, https://www.giga.de/extra/usb/specials/wireless-usb-geraete-ohne-kabel-verbinden/ Dann sitzt zwar auf Empfängerseite ein weitere uC der nur den Empfang regelt und die Daten seriell an den Arduino-USB Host schickt der dann den Arduino programmiert, also 3 uC in Reihe, davon 2 nur damit der letzte programmiert werden kann, aber es wäre wenigstens fertig. R2D2 schrieb: >> Über welche Distanz möchtest du denn funken? > > Ich dachte an einige km mit Lora. Ähm, na ja, nimm GSM.
:
Bearbeitet durch User
R2D2 schrieb: > Spielt keine Rolle. Die Frage war eher allgemein formuliert. Es können > 8, 16 -oder oder 32 Bitter sein. Oh doch! Ohne diese Info kommst du nicht weit! Bei einem 80c535 hast du z.B. keine Changse.
Moin, Bei embedded Controllern von 8-32bit macht man das normalerweise so: Der µC braucht erstmal einen Bootloader, der den eigenen Flash beschreiben kann, können fast alle. Dann eine Funkverbindung, sei es Lora, BT oder was auch immer. Kommt das Kommando "OTA-Update", springt der Bootloader an und empfängt die neue Software, natürlich wie geschrieben besser den fertigen Binärcode. Keine Intel-Hex mit Overhead und Quellcode schon gar nicht. Das speichert der Bootloader dann erstmal, meist in externem Flash. Wenn das geklappt hat (mit CRC usw.), schreibt er die Software aus dem externen Flash in den Eigenen. Das ist so der Mittelweg der Sicherheit. Unsicherer wäre es, den eigenen Flash direkt von Funk zu beschreiben. Bricht die Funkverbindung ab, ist irgendeine Grütze drin und es ist unsicher, ob der Bootloader überhaupt noch eine zweite Chance hätte. Das macht man eigentlich nur per Kabel. Sicherer ist es, dem Bootloader mehr Grips zu verpassen und im externen Flash Platz für die "alte" und die neue Firmware zu haben. Die neue Firmware wird nach erfolgreichem Empfang in den internen Flash geschrieben. Wenn dann alles gut ist - ok. Wenn nicht, kann der Bootloader die alte Firmware wieder in den Flash schreiben (Rollback). Dafür muss der Bootloader aber wie gesagt etwas üppiger ausfallen, das dauert bzw. braucht mehr Rechenleistung - macht man dann eher nur auf 32-bittern. Gruß, Norbert
Norbert S. schrieb: > Dafür muss der Bootloader aber wie gesagt etwas üppiger ausfallen, das > dauert bzw. braucht mehr Rechenleistung - macht man dann eher nur auf > 32-bittern. So ein Unsinn. Die Rechenleistung spielt überhaupt keine Rolle für dieses Problem. Das Einzige was wirklich wichtig ist: genug von irgendeinem Speicher am Ziel, um die neue Firmware vollständig puffern zu können. Und das kann man auch auf dem allerkleinsten 8-Bitter ohne jeglichen externen Speicher sicherstellen. Bedingung ist dann nur, dass die Firmware kleiner ist, als die Hälfte des verfügbaren Flash. Man muss dann halt einfach nur den passenden µC wählen, für den diese Bedingung gegeben ist. Habe ich also z.B. eine Firmware, die einen Tiny25 knapp füllt, dann nehme ich einen Tiny45 und schon habe ich mit Sicherheit genug Flash, um diese Firmware zu buffern. Das ist doch kinderleicht.
Johannes S. schrieb: > Bei der geringen Bandbreite von Lora braucht man da aber viel Geduld. Ohne Flei' kein Prei'. Bei Lora kommt es zusätzlich sehr auf die Frequenzbelegung und, insbesondere bei mehreren Clients, auf das verwendete Protokoll an. Mit Symphony Link soll ein OTA-Update erheblich schneller als mit z.B. LoRaWAN sein.
Raph schrieb: > Oh doch! Ohne diese Info kommst du nicht weit! Bei einem 80c535 hast du > z.B. keine Changse. Und warum sollte der das nicht können? Mit einem sektorweise löschbaren Flash wie dem 29F010 ging es wunderbar. Selbst mit müden 9600Bd war das immer noch bequemer als 100km zu fahren.
Michael B. schrieb: > Und du brauchst den Sender, also deinen PC, der hat eigentlich kein > Funk. Selbst bluetooth wird nämlich den uC überfordern, der will eher > 433MHz auf RF12 Basis oder so. > Alles ins allem also eine umständliche Idee, man nimmt lieber ein USB > Kabel. Kabel? R2D2 schrieb: > mukel schrieb: >> Über welche Distanz möchtest du denn funken? > > Ich dachte an einige km mit Lora. Michael B. schrieb: > Wie wäre USB kabellos ? Wireless USB gab es mal, > https://www.giga.de/extra/usb/specials/wireless-usb-geraete-ohne-kabel-verbinden/ habe ich und zum Arduino nur mit verminderter Baudrate <=57k6 sicher und nur innerhalb im Zimmer 5m, nicht weiter.
Johannes S. schrieb: > R2D2 schrieb: >> Ich dachte an einige km mit Lora. > > Bei der geringen Bandbreite von Lora braucht man da aber viel Geduld. Ja das ist so. Die NASA hat beispielsweise bei den Voyager Sonden mehrmals die Software aktualisiert und das bei einer Datenrate von 160bps. Wenn sie die Software abgeschickt hatten, ging es 26 Stunden bis die Antwort von den Sonden zurückkam, ob diese korrekt empfangen wurde. https://www.additude.se/bloggar/thomas-lovskog/firmware-update-over-the-vacuum/
Bei Homematic Endgeräte Update ist das Standard. Funktioniert immer tadellos, dauert natürlich mitunter sehr lange ...
Grundsätzlich kannst Du an jeden µP senden, was Du willst. Das kann Deine Liebeserklärung an das kleine Hufeisen sein (vielleicht in ASCII) oder der Programmcode für selbigen. Wichtig ist hierbei eigentlich nur, dass der "Empfänger" sich selber Programmieren (FLASH) kann, oder Programm im RAM ausführen kann. In letzterem Falle kann es aber leicht passieren, dass er beim nächsten Stromausfall unter digitaler Amnesie leidet. Gibt es die Möglichkeit sich selber zu programmieren, so hat bestimmt irgendein Cleverle einen "bootstrap loader" geschrieben, mit dem sich dieses Prozedere automatisieren lässt. Wenn nicht sogar der Hersteller des µP die meisten dazu nötigen Mechanismen in der Hardware vorgesehen hat. Übrigens: Es ist egal, ob das "neue" Programm über einen Programmieradapter, eine wie auch immer geartete serielle Schnittstelle oder durch Funken übertragen wird.
Die Controller und Basisstationen beim HTC Vive System werden auch komplett Kabellos aktualisiert.
:
Bearbeitet durch User
Sebastian S. schrieb: > Übrigens: Es ist egal, ob das "neue" Programm über einen > Programmieradapter, eine wie auch immer geartete serielle Schnittstelle > oder durch Funken übertragen wird. Egal ist das ganz bestimmt nicht. - Bei Programmierung über einen Programmieradapter (ISP) braucht man nicht mal einen Boot-Loader. - Bei Programmierung per Bootloader über die serielle Schnittstelle wird gewöhnlich die Übertragung des Programms und der eigentliche Programmiervorgang nicht getrennt, d.h. bei fehlerhafter Programmübertragung gibt es kein Backup. - Bei Programmierung über Funk wird man immer erst das Programm übertragen, auf Fehler prüfen und erst dann vom alten Programm auf das neue umschalten, d.h. man braucht doppelten Speicher.
Wolfgang schrieb: > - Bei Programmierung über Funk wird man immer erst das Programm > übertragen, auf Fehler prüfen und erst dann vom alten Programm auf das > neue umschalten, d.h. man braucht doppelten Speicher. Auch wenn das natürlich der potentiell sichererer Ansatz ist (ich würde jederzeit dazu raten), zur Not geht es aber natürlich auch ohne diesen. Der Nachteil ist eigentlich nur eine unkalkulierbare Downtime der Anwendung. Die wird dann halt, nachdem der Update-Prozess einmal gestartet ist, solange nicht benutzbar sein, bis es dem Bootloader gelungen ist, das komplette neue Image herunter zu laden. Natürlich muss der Bootloader bei so einer "Notlösung" dafür sorgen, dass nicht durch irgendwelche Umstände das zwischenzeitliche Gemisch aus neuem Image (verfiziert), neuem Image (unverifiziert) und altem Image gestartet wird. Das ist aber kein Hexenwerk, sondern stinknormales, völlig unspektakuläres Programier-Handwerk. Tatsächlich funktionieren sehr viele Bootloader genau nach diesem Prinzip, weil es einfach zu teuer wäre, doppelten Speicher nur für das (relativ seltene) Update vorzusehen.
Wolfgang schrieb: > d.h. bei fehlerhafter > Programmübertragung gibt es kein Backup. Hierbei schreibt man nur das Programm. Die Funkverbindung und die Programmierung übernimmt der Bootloader. Wenn der Programmierlauf schief gegangen ist, schreibt man einfach nochmal.
c-hater schrieb: > Tatsächlich funktionieren sehr viele Bootloader genau nach diesem > Prinzip, weil es einfach zu teuer wäre, doppelten Speicher nur für das > (relativ seltene) Update vorzusehen. Solche Bootloader ohne doppelten Speicher funktionieren so, daß man bei Fehlern oder Stromausfall nur noch ein Stück Elektroschrott vor sich hat. Bei Konsumergeräten ist das ein Vorteil für den Hersteller, er kann dann teuer Ersatz verkaufen. Bei Profigeräten wird man immer mindestens doppelten Speicher haben. Der Bootloader kann auch nach einer Anzahl von Bootversuchen oder nach einer bestimmten Zeit wieder auf die alte Applikation zurück schalten, wenn keine Funkverbindung mehr zustande kommt. Wenn der MC nicht soviel Flash hat, kann man ja seriellen Flash anschließen.
Brummbär schrieb: > Hierbei schreibt man nur das Programm. Die Funkverbindung und die > Programmierung übernimmt der Bootloader. Wenn der Programmierlauf schief > gegangen ist, schreibt man einfach nochmal. Wenn sicher ist, das sich am Funkprotokoll und am Programm für das OTA-update nie was ändert, kann man das natürlich machen.
Johnny B. schrieb: > Wenn sie die > Software abgeschickt hatten, ging es 26 Stunden bis die Antwort von den > Sonden zurückkam, ob diese korrekt empfangen wurde. Wenn ich die Aussagen im Link richtig interpretiere, ist das nur die Latenz für ein einziges Datenpaket mit Bestätigung. Da ist dann noch nicht ein einziges Byte Software übertragen (d.h. die Zeit dafür kommt erst noch obenauf).
Markus F. schrieb: > Johnny B. schrieb: >> Wenn sie die >> Software abgeschickt hatten, ging es 26 Stunden bis die Antwort von den >> Sonden zurückkam, ob diese korrekt empfangen wurde. > > Wenn ich die Aussagen im Link richtig interpretiere, ist das nur die > Latenz für ein einziges Datenpaket mit Bestätigung. Da ist dann noch > nicht ein einziges Byte Software übertragen (d.h. die Zeit dafür kommt > erst noch obenauf). Ja ich denke Du hast recht. Habe selber mal ein wenig gerechnet. Zur Zeit ist Voyager 1 rund 21.7 milliarden Kilometer von der Erde entfernt: https://voyager.jpl.nasa.gov/mission/status/ Verrechnet man diese Distanz mit der Lichtgeschwindigkeit, dann ergibt sich daraus bereits eine Dauer von über 20 Stunden, nur für einen Weg. Das heisst, wenn man etwas schickt, dann geht es mindestens 40 Stunden bis eine Antwort kommen kann. So betrachtet müsste es wohl Wochen gehen, bis man ein Softwareupdate machen könnte. Oder mache ich einen Überlegungsfehler?
Johnny B. schrieb: > So betrachtet müsste es wohl Wochen gehen, bis man ein Softwareupdate > machen könnte. Oder mache ich einen Überlegungsfehler? Zwischen 2 Planeten hat man ja auch seeehr viel Zeit, die Voyager sind ja jetzt 40 Jahre unterwegs. Georg
Johnny B. schrieb: > Verrechnet man diese Distanz mit der Lichtgeschwindigkeit, dann ergibt > sich daraus bereits eine Dauer von über 20 Stunden, nur für einen Weg. > Das heisst, wenn man etwas schickt, dann geht es mindestens 40 Stunden > bis eine Antwort kommen kann. > So betrachtet müsste es wohl Wochen gehen, bis man ein Softwareupdate > machen könnte. Oder mache ich einen Überlegungsfehler? Du machst einen Denkfehler. Man wird sich natürlich nicht jedes einzelne Datenpaket bestätigen lassen, bevor man das nächste schickt, sondern Datenpakete munter rüberschicken, vorzugsweise mit FEC, und aynchron dazu ggf. Blockrückfragen schicken. Dann kann die Datenstrecke fast ununterbrochen mit voller Übertragungsrate arbeiten und es entstehen, außer bei unkorrigierbaren Fehlern in den letzten Blöcken, keine Pausen wegen der Round-Trip Zeit.
> Johnny B. schrieb: > Oder mache ich einen Überlegungsfehler? Such mal nach X-Modem Protokoll. Schon in der Steinzeit gab es da praktikable Lösungen. Ich habe fast 20 Jahre lang einen 50km entfernten Rechner per Funk mit 9600Bd mit Updates versorgt. Mit etwas Überlegung geht das sauber. Besuche waren eigentlich nur nach Blitzeinschlägen mit Hardwareschäden notwendig.
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.