mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bootloaderproblem (AVRUB 4..5) bei RS485


Autor: Thomas Böhm (cakebox)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich möchte ein mit einer RS485 Schnittstelle versehenes Gerät mit einem 
Bootloader versehen. Schnittstellentreiber ist ein ADM485 am Atmega32 
und ein USB/485 Umsetzer auf der PC-Seite.
Der Datenaustausch klappt auch hervorragend, ein Bascom-Code im Gerät 
und HTerm auf dem PC sprechen auch bei hohen Baudraten miteinander. Also 
setze ich mal voraus das die Hardware ok ist.

Ein installierter AVRUB (avrubd.googlepages.com/avrub.htm) Versionen 4.1 
bis 4.5 bricht allerdings nach der Übertragung von 80 Bytes immer mit 
der Fehlermeldung "Too many retry" ab.
Die 80 Byte im Flash stimmen, Connect des Bootloaders klappt auch.
Im Anhang mal die "bootcfg.h" die zum kompilieren benutzt wurde (sowie 
viele weitere erfolglose Versuche).
Die Fuses scheinen zu stimmen, eine direkte Verbindung von RXD und TXD 
mit dem jeweiligem Pin am USB-Wandler ohne jeweils den 485-Wandler und 
zb. Peter Daneggers Bootloader funktioniert fehlerfrei.

Hat schon jemand mit dem AVRUB unter RS485 gearbeitet? Ähnliche Probleme 
gehabt? Gelöst? ;-)

Kann mir jemand einen anderen 485-fähigen Loader empfehlen? Habe lange 
gegoogelt aber noch nix brauchbares gefunden.

Vielen Dank und Grüße vom Thomas

Autor: vielleicht so (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schnell (kbyte/s) kannst du denn das Flash schreiben ? Wie schnell 
(kbyte/s) kommen die Daten denn daher ? Falls die daten schneller 
transferiert wie geschrieben werden, wie gross (kbyte) ist der RAM 
speicher und wiel lange (s) reicht der ?
Ich hab mal als Ein-Block transferiert und fand eine Limite bei 9600 
baud. Bei kleineren Bloecken kann man schneller uebertragen.

Autor: Thomas Böhm (cakebox)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf der PC-Seite arbeitet die AVRUBD.exe beim flashen, verschiedenste 
Baudraten bis hinunter zu 2400 habe ich probiert. Natürlich mit 
entsprechender Anpassung auf der Atmega-Seite.
Da dort der Unidirektionale Betrieb vorgesehen ist sollte das mit dem 
Datennachschub klappen...hoffe ich.
Ein flashen mit Peter's RX/TX gekoppeltem Loader läuft bis 64kBaud 
fehlerfrei, größer habe ich nicht probiert.

Gruß Thomas

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab einen open source Bootloader so modifiziert, dass er im ATMega32 
läuft. Das geht über den Uart, du kannst es also mit RS485 Treibern 
verwenden. PC-seitig läuft es mit AVR PROG aus dem AVR-Studio.

Mein Bootloader hat aber keine Fehlererkennung.

Wenn deiner eine hat, solltest du den verwenden bei langen Kabeln und, 
oder Übertragungsproblemen.

Aber deine Probleme verwundern mich prinzipiell. RS-485 ist normal viel 
robuster als RS-232 und kann bis zu mehreren km überbrücken.

Hast du die Abschlusswiderstände im jeweiligen Empfänger drin?
Ist das Kabel geeignet? (Wellenwiderstand ca. 120 Ohm, symmetrisch und 
geschirmt)?
Ist deine Baudrate eventuell zu hoch für die Länge 
(Bandbreitenlängenprodukt des Kables beachten)?

Gerne stell ich dir meinen Bootloader zur Verfügung, auch wenn das nicht 
unbedingt eine sichere Übertragung ist, aber er ist recht langsam bei 
der Übertragung, also prinzipiell nicht besonders fehleranfällig.

Viele Grüße,

Peter

Autor: Thomas Böhm (cakebox)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

erst einmal vielen Dank für Antwort und Angebot.
Die Schnittstelle selbst ist i.o. (terminiert, Kabel ist ok und sehr 
kurz usw.)
Ein normaler Datenaustausch funktioniert ja auch bis hin zu hohen 
Baudraten.

Das Problem für den Bootloader scheint die unidirektionale Betriebsart 
der 485-Treiber und die nötige Richtungsumschaltung zu sein.
Die meisten Loader können das nicht, deshalb hab ich ja den AVRUB 
verwenden wollen, der unterstützt das explizit. Leider funktioniert das 
aber nicht (richtig).
Die Version 4.1 soll laut Autor ein Problem im 485er Betrieb gehabt 
haben.
Ab Version 4.2 gefixt, bei mir verhalten sich aber alle Versionen 
gleich...

Kann Dein Loader diese Betriebsart? Dazu müsste er dann ein 
Richtungsumschaltport (pin) bedienen können damit der Datenstrom seine 
Richtung findet. Wenn ja würde ich mich sehr freuen wenn ich den 
nachnutzen könnte.

Gruß Thomas

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte das Problem, dass die PC-Dongle-seitige 
Senderichtungsumschaltung erst nach einem Timeout nach dem letzten Byte 
greift. Basis des Dongles ist ein FT232R. Meine (schlechte) Lösung ist 
derzeit eine Warteschleife von ein paar ms bis zur Response...

Die Doku von FTDI ist in diesem Punkt äußerst mies.
Hat denn hier jmd. Erfahrungen mit RS485 Halbduplex und dem FT232?


VG,
Hendrik

Autor: Peter Diener (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin davon ausgegangen, dass die Kabel für Vollduplex ausgelegt sind, 
also keine Richtungsumschaltung nötig ist. Prinzipiell könnte man eine 
Umschaltung  auf MC Seite schon dazubauen, ich weiß aber nicht, ob 
AVR-PROG das kann und mag.

Im Moment kann mein Loader das nicht, man könnte daran lediglich, wie 
ich bereits gesagt habe, mit 4 Drähten ein RS-485 Vollduplex bauen.

Ich kann dir morgen mal den Code reinstellen, vielleicht kannst du ihn 
ja geeignet modifizieren.

Viele Grüße,

Peter

Autor: Thomas Böhm (cakebox)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Henne, hallo Peter,

hätte ich Vollpfosten ja auch gleich schreiben können das es 
Halbduplexbetrieb ist, sorry.

Ein Timeoutproblem auf der PC-Seite könnte stimmen. Auch bei mir ist ein 
FT232R verbaut. Da werde ich mal weiter in dieser Richtung schauen.

Am Code wäre ich aber trotzdem interessiert, ist wesendlich besser eine 
Vorlage zu haben als alles neu zu (Er)finden.

Danke und Gruß vom Thomas

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Bootloader-Code kann ich Dir nicht geben.

Eventuell kannst Du aber etwas mit meinem RDM-Code anfangen:
http://www.hoelscher-hi.de/hendrik/light/openrdm.htm

RDM ist die Abkürzung für remote device management und ermöglicht über 
eine Halbduplex-Erweiterung des DMX Protokolls eine ferngesteuerte 
Überwachung und Parametrierung von Geräten aus der Lichttechnik.

Falls Du eine Lösung für zur Reduzierung des Time-Outs oder auch nur die 
genaue Dauer erfährst, wäre ich Dir für einen Tipp dankbar.

Viel Erfolg,
Hendrik

Autor: Thomas Böhm (cakebox)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ihr zwei (drei),

die Lösung war viel Einfacher. Det Tipp mit dem schlechten Datenblatt 
des FT232R war Gold wert, schon liest man genauer nach.
Die Applikationsschaltung für RS485 Betrieb schaltet den RX-Enable 
Eingang des 485-Treiber auf L wenn USB connected hat (also immer). Somit 
"hört" der PC (das Bootloaderprogramm) sein eigenes TX-Echo und mag das 
offensichtlich nicht.
Also RX-EN mit TX-EN am 485-Treiber verbunden und die Verbindung zum 
FT232R gekappt und der Bootloader läuft!

Danke für den Wink mit dem Pfahl ;-)

Gruß Thomas

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.