Programmcode über Funk an µC senden

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 ...

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).

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 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.

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

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.

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.

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:
> 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.