|
Anzeige
|
Gibt es Bootloader für atmega, die per Bus(RS485) neu Programmierung unterstützen?
Gast
#4745203
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 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.
Gast
#4745698
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 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.
Gast
#4745975
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. -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
Gast
#4745988
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 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 Antwort schreiben |
Anzeige
|
