Gibt es Bootloader für atmega, die per Bus(RS485) neu Programmierung unterstützen?

[-HanJo- (Gast)]

Hallo ins Forum,

ich beschäftige mich zurzeit mit einem Projekt, dass mit einem RS485-BUS 
und mehreren ATmega betrieben wird. Jetzt wollte ich mal wissen, ob es 
schön Lösungen zur neu Programierung der µC über so einen Bus gibt?
Die Geschwindigkeit ist fast neben Sache, würde das Firmware ubdate 
erleichtern.

Liebe Grüße

HanJo

[Georg G. (df2au)]

Auf Basis eines der vorhandenen RS232 Bootlader sollte das schnell 
machbar sein.

[Thomas W. (diddl)]

Richtig.
Bzw. es dürfte gar kein Unterschied sein, denn RS485 ist nur eine 
Hardware Spec von RS232?

[Bastian W. (jackfrost)]

Da RS485 nur Halbduplex ist musst bei deinem Sender oft prüfen ob XOFF 
gesetzt wurde. Ggf musst du dir ein kleines Programm schreiben das die 
Daten auf den Bus gibt.

Gruß JackFrost

[Pandur S. (jetztnicht)]

Ja, das doofe an RS485 in dieser anwendung ist, dass bei bidirektionaler 
Kommunikation die Richtung jeweils umgeschaltet werden muss.

In diesem Kontext ist es dann auch noch wichtig, ob man sich in einer 
Multimaster- oder Master-Slave Umgebung bewegt.
Bei einer Master-Slave Umgebung kann der Master per Protokol bestimmen, 
wann umgeschaltet wird, denn im Firmware Uploadfall ist der zu 
Programmierende wahrscheinlich der Slave, jedenfalls ist die Zuordnung 
dann fest.
Das bedeutet das Umschalten ist vorgegeben.

Ein Multimaster Protokoll im Bootloader erscheint mir etwas 
uebertrieben.

[-HanJo- (Gast)]

es ist ein Single-Master-System, die Programme/Firmware in den 
Controllern ist recht "einfach". Die kann ich verstehen, aber einen 
Bootloader auf RS485 umprogrammieren, ist mir leider zu "hoch". Hoffe 
darauf, dass es sowas schon gibt.

Gruß

HanJo

[Roland E. (roland0815)]

Bastian W. schrieb:
> Da RS485 nur Halbduplex ist musst bei deinem Sender oft prüfen ob XOFF
> gesetzt wurde. Ggf musst du dir ein kleines Programm schreiben das die
> Daten auf den Bus gibt.
>
> Gruß JackFrost

RS485 gips auch Vollduplex.

[Philipp K. (philipp_k59)]

Da es ja anscheinend kein RS422 ist wo man nur ein bisschen 
Signalwandeln müsste solltest Du sowieso einen Rs232/RS485 Chip auch 
wegen einer Galvanischen Trennung vom Bus nehmen.

Sonst rauchts im Atmega... und im uC bleibts dann einfaches Uart.

[Otto (Gast)]

Ja gibt es. Musst du nur machen.
Ich habe für mich als Bascom mensch den MCS serial Bootloader auf 485 
umgeschrieben. War nicht schwer.
Ich muss vor dem Programmieren allerdings alle anderen Avr's am bus mit 
einem Befehl zum schweigen bringen. Dann über einen weiteren Befehl den 
zu beschreibenden Avr reseten.
Und dann klappt das sehr gut.

[Joe G. (feinmechaniker)]

-HanJo- schrieb:
> Lösungen zur neu Programierung der µC über so einen Bus gibt?

Bitteschön:
https://www.chip45.com/avr_bootloader_atmega_xmega_chip45boot2.php

Zitat:
AVR ATmega Xmega Bootloader - chip45boot2
Unterstützung von RS485 halb-duplex Schnittstellen

[Jörg (Gast)]

Der Bootloader von Chip45.com unterstützt RS485 (habe ich allerdings in 
dieser Betriebsart selbst noch nicht getestet). Einfach mal ansehen, 
vielleicht passt es ja. Gegen einen kleinen Obolus gibt es dort auch die 
Quelltexte, um z.B. den Pin für die Richtungsumschaltung auf die 
verwendete Hardware anzupassen.

Jörg

[Marcus H. (Firma: www.harerod.de) (lungfish)]

Hi,
Anfang des Jahres habe ich für einen Kunden sowas für STM32 MCU 
umgesetzt.
Das Embedded-System hat einen Mastercontroller, der per USB VCP an einen 
Host-PC angeschlossen wird.
Intern kommunizieren die STM32 über einen Halbduplex-RS485-Bus.
Anhand der vom Host gesendeten Adresse erkennt der Master, wo das Ziel 
eines Datenpakets liegt.
Ist er selber der Adressat, wird das Paket intern verarbeitet.
Ist ein Slave das Ziel, wird das Paket auf den RS485-Bus umgesetzt.

Da ein Firmware-Update nur unter kontrollierten Bedingungen in der 
Wartungshalle statt findet, war hier ein sehr einfaches Protokoll 
umsetzbar:
Es wird vom Host zunächst mitgeteilt, welche MCU der Empfänger ist.
Ist es der Mastercontroller, dann findet während des Updates nur eine 
Kommunikation auf dem USB VCP statt. Die Slaves bekommen das ggf. 
garnicht mit.
Soll ein Slave eine neue Firmware bekommen, so wird ein "Initialisiere 
Update für Slave x" Kommando geschickt.
- der angesprochene Slave wartet dann auf neue Firmware
- die übrigen Slaves gehen in einen Schlafmodus
- der Master fungiert nur als Bridge zwischen USB und RS485
Nach dem Update wird das System neu gestartet.

Der Vorteil an diesem Verfahren ist, dass während des Updates ein 
anderes Protokoll, auch mit anderer Baudrate, auf dem RS485-Bus gefahren 
werden kann, als während des Normalbetriebs.

Zur (Übertragungs-)Sicherheit / Fehlererkennung:
- Bootloaderansprung über Passwort
- RS485 mit Parity
- Prüfsummen im Update-Paket
- Festspeicherprüfsummen

Insbesondere letztere sorgen für Rücksprung in den geschützten 
Bootloader, wenn beim Systemstart Fehler erkannt werden.

Grüße,
 marcus