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

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

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

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

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.

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.

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.

-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

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