Sketch / .hex upload über RS485

Hats jemand von euch probiert oder geschafft ein Sketch oder besser eine .hex über RS485 zu laden?

Hab das hier gefunden, dauert aber bisle bis ichs testen kann.
http://web.ed-solutions.de/dokuwiki/doc:pyfds-utility

DudeLib
SodaqMoja/optiboot
Xboot
chip45boot2
avr-multidrop-bootloader
mpmboot
tomekjaworski/atmega328p-rs485-bootloader
Update Tool für MX- und romod
USART/RS485 Bootloader для AVR
kreuzers/E_RS485_BCU

Hi

Schaut schon interessant aus und: Nein, keinerlei Erfahrung mit Update im verbauten Zustand.

Abo

MfG

Ich rate erstmal ab....
Oder besser: Idee nachbessern!

Ein RS485 Bootloader, an sich, ist kein echtes Problem, nur Fleiß.

Aber es ist eine Illusion anzunehmen, dass das immer störungsfrei funktioniert. Und damit sind wir an dem Punkt, weswegen ich den Weg bisher für mich immer abgelehnt habe.

Was passiert, wenn dabei ein Stromausfall seine Eigenschaften ausspielt?
Wand auf machen, und per ISP drauf. Denn eine solcher Upload manipuliert das Flash, die Anwendung ist kaputt.

Einen gangbaren (Um)Weg wüsste ich:
Das neue Programm per RS485 in ein EEPROM/Flash, oder was auch immer, spielen. Kann jederzeit abgebrochen/wiederholt werden.
Und wenn das dann fertig, überprüft, abgeschlossen ist, kann ein I2C Bootloader den Kram ins Flash spielen.

Das halte ich für erheblich stabiler.

Die Idee ist gut. So ähnlich geht OTA beim ESP ja auch vor, weswegen man bei OTA nur den halben Flash Platz hat. In die andere Hälfte kommt der Upload, wird geprüft und dann erst übergebügelt.

Deswegen halte ich die Aufteilung in der Version 2.4 der ESP8266-Software für den 16 MB WEMOS D1 Mini PRO fest mit 1 MB Flash und 15 MB SPIFFS schlicht für Verarschung. In 2.3 kann ich wenigstens noch 3MB Programm und 1 MB SPIFFS nutzen.

Gruß Tommy

Was sollte der Stromausfall anrichten? Der Bootloader geht ja dabei nicht kaputt, nur die Anwendung.
Da der Bootloader intakt ist, lässt man das Update nochmal starten.

Hi

Wenn aber dann beim Überspielen des Programm ‘was auch immer’ auftritt, ist immer noch Alles fritte.
Klar habe ich so erst Mal die Übertragung außen vor - erst, wenn Alles korrekt übertragen wurde, wird mit dem Überschreiben begonnen.
Was dann passiert … auf hoher See und beim Bespielen des Flash liegst Du in Gottes Hand :slight_smile:

MfG

PS: Ein gutes Argument (zumindest für mich als ‘per USB Aufspieler’ (oder ISP beim ATtiny)

Das sollte wohl so funktionieren, es könnte aber sein, dass Dein Programm irgendwas steuert, was definiert sein soll. Evtl. steuert das halb zerschossene Programm eine Spindel ins mechanische Aus oder was Dir an bösen Möglichkeiten einfällt.

Gruß Tommy

postmaster-ino:
PS: Ein gutes Argument (zumindest für mich als ‘per USB Aufspieler’ (oder ISP beim ATtiny)

Ach das OTA beim ESP8266 ist schon eine feine Sache. Es geht viel schneller, als per USB und Du musst das Teil nicht am Rechner haben.

Achtung: Version 2.4 hat OTA-Probleme.

Gruß Tommy

Lange rede kurzer sinn, ich brauch erstmal den RS485 Bootloader für Atmega8, 328, 324PA und 644PA.
Versteh nicht ganz wie ichs da machen muss und welcher Bootloader kleiner/besser ist.

skorpi080:
Was sollte der Stromausfall anrichten? Der Bootloader geht ja dabei nicht kaputt, nur die Anwendung.
Da der Bootloader intakt ist, lässt man das Update nochmal starten.

Der Bootloader startet die halb geschriebene Anwendung.
Und nein...

Male es dir auf!
Male ein Datenflussdiagramm, und du wirst sehen, dass du dir so mehr Probleme als Freude einhandelst.

Und das möchte ich nicht.

Beim Xboot ist doch was mit crc, heißt das nicht dass die Anwendung nach dem upload überprüft wird?

Ich will ja am Rechner sitzen und die Nodes auswählen können die ein update erhalten sollen.
Wie funzt das denn?

Beim Xboot ist doch was mit crc, heißt das nicht dass die Anwendung nach dem upload überprüft wird?

Kenne deinen Xboot nicht wirklich.

Aber crc bedeutet, dass im Programm sowas auch zu finden ist.

Also brauchst du ein Hilfsprogramm, welches die *.hex Datei mit der Prüfziffer versieht.
Und auf dem AVR, ein Programmteil, welches das dann testet.

Aber dennoch hast du zwischen dem ersten und dem letzten übertragenem Byte ein ungültiges/unfähiges/kaputtes Programm auf deinem AVR.

Ja, die Arduino IDE erlaubt dir PostLinkerHooks zu nutzen.
Ist eine interessante Baustelle.
Würde gerne sehen, wie das dann bei dir aussieht.

Also rein logisch will man doch alle Teilnehmer auf der gleichen Version haben, dann werden rein theoretisch (nach meiner Theorie) alle aufeinmal aktualisiert?!

Das halte ich für eine zu Fehlerträchtige Variante. Du kannst nicht garantieren, dass es bei allen funktioniert. Das würde ich etwa mit Russisch Roulette gleichsetzen.

Gruß Tommy

Hi

Mehrere Targets hat auch den Pferdefuß, daß wirklich auf Allen das Gleiche laufen muß.
Wenn aber ein Teil der Peripherie nur Aktorik trägt, dafür ein anderer Teil nur Sensoric, könnte ich mir vorstellen, daß eine darauf speziell zugeschnittene 'Firmware' 'besser passt'.
Auch hat man mehr Platz, wenn man die Aktorik nicht im Sketch abfrühstücken muß, man kann sich eher um speziellere Dinge kümmern - kA, ob Euch halbwegs klar ist, was ich meine :confused:

Beim 'Einzelgespräch' kann ich mir ja 'alle Zeit der Welt' lassen, um die Daten zum Target zu bekommen.
Sobald die Daten komplett und geprüft sind (ggf. schon während der Übertragung Einzelpakete prüfen, erspart ne Menge Müllbytes), kann mit dem Überschreiben begonnen werden - ab hier sehe ich keine größere Gefahr als am heimischen PC per USB - eine recht saubere Spannung braucht der µC eh - Das sollte also nicht zu einem Problem werden.

Da der Bootloader auch nur ein ausführbares Programm ist, kann ich Den doch ein externes EEprom (Fram :slight_smile: ) beschreiben und lesen lassen.
Dieser Chip muß ja nicht ebenfalls im Bus hängen (wobei ...)

MfG

Mich nervt es manchmal, dass jeder hier seine eigene suppe kocht.
Kann man nicht gut und günstiges Projekt starten (mit dem Ziel es zu beenden) womit alle zufrieden sein können?
RS485 wird oft genutzt, manche nehmen CAN. Also 2 Varianten fertig machen.
Da gäbe es noch eine Variante aber da sagen manche, wer Funk kennt nimmt Kabel.
Oder gibt es bereits Projekte an die man sich halten kann?
Homematic und FHEM ist kompliziert, verwirrend, relativ teuer und zu groß.
Das geht doch noch günstiger, einfacher und "leichter".

Nodes bestehen aus kleinen Arduinos, Master entweder Raspberry, ESP8266 oder Mega.
Modbus RTU ist ja mehr oder weniger standard, also nehmen wir doch den.
GUI funzt entweder über Raspi oder ESP.
Hab ich noch was vergessen?

Homematic CCU2, 90€
zB so ein RS485 Modul kostet 80€
Dazu 7 Relais, nochmal 120€,
Ein popeliger Busabschluss-Widerstand, 40€
Und das geht so weiter. Für den Preis hätte man das ganze Haus vernetzen können.
Es müssen sich nur die richtigen Leute finden, die das vorantreiben.
Ich kenn mich mit der Weboberfläche sogut wie null aus, so oft angefangen und nie richtig zuende gebracht.

CCU ist nur der Hauptrechner, es kommen noch viele Kleinteile dazu die ähnlich kosten.
Ich mach 20 Platinen mit Atmega und RS485 für die Taster, Raspberry hab ich schon hier, sind vielleicht 100€
Mir fehlt dann nur die GUI, wovon ich kein schimmer hab.

Das lernst Du auch noch. Selfhtml und W3Schools sind gute Einstiegs- und Nachschlagepunkte.

Gruß Tommy

Es besteht ja nicht nur aus Design, Javascript / Java zB ist da viel.
Deswegen die Frage, der eine kennst sich mit dem Webzeugs aus, der andere mit der Hardware und der dritte mit anderen dingen.

Javascript ja, ist manchmal sinnvoll. JAVA brauchst Du nur, wenn Du unbedingt einen javabasierten Ansatz fahren willst.

Webserver auf nem WEOMOS D1 mini pro, HTHL-, Javascript- und CSS-Dateien aufs SPIFFS und ab gehts.

Hier mal ein Grundgerüst mit AJAX.
Um die Files ins SPIFFS zu legen habe ich hier ein Tool gebaut. Das geht schneller, als mit der IDE, da die immer den kompletten SPIFFS beschreibt.

Ich bin kein besonders guter Gestalter, das kann man garantiert noch hübscher machen. Mir ging es nur um Darstellung der Technik.

Gruß Tommy