Hallo,
ich suche verzweifelt ein Protokoll für RS232, welches ich in mein
Delphi-Programm und meinen ATMEGA644 einbinden kann.
Ich habe z.Z. öfters einen Übertragungsfehler, welcher aber fatale
Auswirkungen haben kann.
Ich habe bei RS232 nur die Daten-Leitungen TXD und RXD zur Verfügung !
Die Übertragung sollte mit CRC & Message-Nummer protokolliert sein.
Sobald ich das Kabel abziehe, muß die Übertragung stehen bleiben (eagl
in welche Richtung) und beim "wiederverbinden" soll es mit der letzten
Nachricht weitergehen.
Ich denke mal, so was wird es schon geben, aber mir fehlen die passenden
Suchbegriffe. Ich finde immer viele nutzlose Ergebnisse
Kann jemand helfen ?
Ne, hat auch keine Zweck...
Die Übertragung muß über mehrer Stunden "sicher" laufen...
Der erste Fehler kommt meist erst nach ner halben Stunde, aber das ist
Glückssache...
MB schrieb:> Ne, hat auch keine Zweck...
Wie, nach den Ursachen suchen hat keinen Zweck?!
Eine stabile serielle Verbindung kann jahrelang(!) ohne
Übertragungsfehler funktionieren.
Hi
>Eine stabile serielle Verbindung kann jahrelang(!) ohne>Übertragungsfehler funktionieren.
Das meine ich auch. Aber lieber an den Symptomen herumdoktern.
MfG Spess
ich habe nur 3 m Kabel , am PC ist ein USB>RS232-Adapter, am AVR ein
MAX232.
Der "spontane" Fehler kommt vermutlich vom Adapter.
Die aktuelle Baudrate ist 9600
Du solltest dir selbst eins ausdenken.
Ich hatte mir mal sowas für die Übertragung von Firmware zum uC
ausgedacht. Prinzip: Blockweise Übertragung, Infos im Block-Kopf,
Adler32 Prüfsumme. Antwort von der Gegenseite mit "KQ" wenn ok oder "KR"
für Repeat usw.
W.S.
wie schon gesagt, ein MAX232 mit Elkos, wie du in jedem Schaltplan
findest...
Ich brauche ein sicheres Protokoll, da meine CNC-Fräse dran hängt...
Es ist immer sehr ärgerlich, wenn sich der Fräskopf irgendwann
unselbständig macht, nur weil mal ein Bit fehlt.
Das wird mit der Zeit teuer (Material und Fräser & Zeit)
MB schrieb:> Ich denke mal, so was wird es schon geben, aber mir fehlen die passenden> Suchbegriffe. Ich finde immer viele nutzlose Ergebnisse
Früher in den Mailboxzeiten gab es Dateitransferprotokolle wie
X/Y/Z-Modem oder Kermit für die gesicherte Übertragung von Dateien. Du
kannst Dir auch anschauen, wie PPP funktioniert. Zu all diesen
Protokollen gibts C-Quellcode kostenlos im Netz. Und X-Modem ist
eigentlich primitiv zu implementieren.
fchk
Ich hab mir auch mal eins ausgedacht :
http://www.ibrtses.com/embedded/shortmsgprotocol.html
Eine Message Nummer muesst mal noch einbauen. Wichtig ist aber, dass das
Protokoll zustandslos bleibt. Dh keine Vorgeschichte benoetigt. Ein
zustandsbehaftetes Protokoll ist nur noch muehsam.
MB schrieb:> Ne, hat auch keine Zweck...> Die Übertragung muß über mehrer Stunden "sicher" laufen...> Der erste Fehler kommt meist erst nach ner halben Stunde, aber das ist> Glückssache...
hmm. Würde es dich stutzig machen, wenn ich dir sage, dass wir in den
80-er Jahren zu fünfzehnt per jeweils einer RS232 an einer VAX hingen,
die 30 Meter entfernt im klimatisiertem Rechnerraum stand und Programme
entwickelt haben, ungefähr über 4 Jahre hinweg, und es in diesem
Zeitraum kein einziges mal zu einem Übertragunsfehler kam?
Wie war das jetzt noch mal mit der Fehlersuche und das die sinnlos wäre?
Hallo,
was fix und fertiges zum "Einbinden" und dazu noch für AVR und(!) Delphi
zu finden, könnte schwer werden.
Wie sicher soll es denn sein?
CRC & Message-Nummer ist ein Anfang, mit Handshake, Timeout
weitermachen.
Grüße. Michael
Hi,
man sollte bei allen USB-Seriell-Umsetzern auch deren notorische
Anfälligkeit für FIFO-Überläufe bedenken. Da keine Handshake-Leitungen
benutzt werden, sollte eine Nachricht des Protokolls immer komplett in
den FIFO des Umsetzers passen und dann der Handshake auf Protokollebene
erfolgen (also mit ACKs und NACKs oder so).
Da der USB keinen echten Hardware-Interrupt kennt, kann es auch schon
mal Pufferüberläufe bei großen Sendungslängen ohne Handshake geben. Bei
"richtigen" seriellen Schnittstellen passiert das eigentlich nie...
Gruß,
Oliver
Da sowas ohne Handshake abläuft und der Windowstreiber zwar so
freundlich ist, die Daten zu übernehmen, aber das Programm nicht
erkennen kann, ob die Daten schon raus sind, oder noch im FIFO des
Treibers/Bausteins vor sich hindümpeln, kann es schon dazu kommen, dass
man das Ganze irgendwann überfährt, oder der µC nicht hinterher kommt.
- Wie schon vorgeschlagen - jedes Datenpaket quittieren lassen - ist
zwar langsamer, aber dann weiß man das die Daten angekommen sind.
- Wenn man etwas quittiert haben möchte, wäre es gut dass nicht nur OK
zurückkommt, sondern vielleicht auch noch die Nummer des Datenblocks,
der quittiert wurde
- eine Prüfsumme kann auch nicht schaden
Damit müsste man dann schon einiges an Problemen erschlagen haben
Ich habe mehrere USB<->RS232 Adapter benutzt, über Jahre hinweg. Die
Teile waren sehr stabil und liefen problemlos bei 115Kbit/sec.
Ich würde eher darauf setzen, dass der Mikrocontroller da nicht ganz
sauber sendet (Baudrate, elektrische Pegel).
Da würde ich noch mal mit einem Oszi oder Logicanalysator beigehen.
Hi
Ich hab mal vor Jahren eine Datenverbindung nachgebaut. Dort wurde mit
den Nutzdaten ein Checkbyte mitgeliefert, welches einfach die Bytes der
Reihe nach Exclusiv Verodert hat. Der Empfänger hat natürlich die
einlaufenden Daten ebenfalls so verknüpft und schließlich das letzte
Byte mit dem Ergebnis auf Gleichheit geprüft. Im Fehlerfall wurde das
"Telegramm" halt wiederholt. Das setzt aber so eine Art "Frage und
Antwort" voraus.
µC - Daten anfordern
PC - Anforderung quittieren
PC - Antworten
µC - Antwort Quittieren
PC - Positiv: nächste
PC - Negativ: wiederholen
Aber, auch ich denke, das du ein Problem mit den Schnittstellen hast und
nicht mit der Übertragung. Entweder ist die Delphi-Routine nicht sauber
( käuflich erworben, selbstgestrickt oder von irgendeinem
Freeware-Paket? ) oder der µC hat's nicht drauf....
Bei 9600 Baud dürfte die Leitung überhaupt nicht kritisch sein.
Gruß oldmax
oldmax schrieb:> Das setzt aber so eine Art "Frage und> Antwort" voraus.> µC - Daten anfordern> PC - Anforderung quittieren> PC - Antworten> µC - Antwort Quittieren> PC - Positiv: nächste> PC - Negativ: wiederholen
So ein Protokoll ist mit modernen UARTs und USB-Seriell-Bridges recht
ineffizient, weil beide mit großen Sende- und Empfangspuffern arbeiten.
Bei "richtigen" UARTs lassen sich diese Puffer deaktivieren (was die
Interruptlast erhöht), aber bei USB-Seriell-Bridges geht das nicht ohne
weiteres.
Solche Eigenheiten sollten bei der Gestaltung eines Protokolls
berücksichtigt werden.
vielen Dank für die vielen Tips.
Ich werde mal versuchen, die Kabel in Nähe der Schrittmotore etwas
abzuschirmen und die RS232-Leitung anders verlegen.
Die Quarz-Frequenz ist an RS232 angepasst.
Habe leider keinen Oszi mehr, um mir die Signalqualität anzuschauen.
Allerdings werde ich mir trotzdem ein kleines Protokoll basteln.
Sicher ist sicher.
Hallo, pack mal in die TX Leitung vom uC einen 1kOhm Widerstand in
Reihe.
>Die Übertragung sollte mit CRC & Message-Nummer protokolliert sein.
Dann mach das doch.
>Sobald ich das Kabel abziehe, muß die Übertragung stehen bleiben (eagl>in welche Richtung) und beim "wiederverbinden" soll es mit der letzten>Nachricht weitergehen.
Einfach ein Alife Message jede Sekunde vom µC zum PC senden und vom PC
eine Quitierung zum uC senden, wenn diese fehlt, dann anhalten.
Andere Aspekte:
Hast Du womöglich eine Spannung <> 0 zwischen den Massen der Fräse und
des PC, die über einem 1k-Widerstand nicht auf ein paar mV
zusammenbricht? Wenn ja, würde ich RS422/485 oder gleich LWL ...
Und bist Du sicher, dass der AVR auch im ungünstigsten Fall die
empfangenen Daten rechtzeitig abholt? Ich hatte erst letztens wieder mal
mit so einem Floh in einer eigenen Machenschaft zu tun...
Ansonsten ist ein Software-Handshaking überhaupt nicht ineffizient. Ok,
es braucht ein paar Übertragungen mehr, aber die irritieren seit 20
Jahren keinen PC mehr. Zumindest nicht, wenn die App mit Delphi bzw.
Vorgängern geschrieben ist :-)
Das Software-Protokoll, das ich zwischen PCs und AVRs verwende, ist
übrigens IntelHex mit eigenem Handshaking je String. Gegenüber XYZ-Modem
die reinste Byteverschwendung, aber dafür hatte ich schon erprobte
Routinen in Delphi und AVR Assembler. Wenn Du mir eine mailto zukommen
lässt, suche ich Dir die Sources raus.
>Ansonsten ist ein Software-Handshaking überhaupt nicht ineffizient. Ok,>es braucht ein paar Übertragungen mehr, aber die irritieren seit 20>Jahren keinen PC mehr. Zumindest nicht, wenn die App mit Delphi bzw.>Vorgängern geschrieben ist :-)
Doch ist es, da er einen USB - RS232 wandler hat.
zwischen 2 USB Frames vergeht nunmal etwas Zeit und dann wirds langsam.
>>Ansonsten ist ein Software-Handshaking überhaupt nicht ineffizient. Ok,>>es braucht ein paar Übertragungen mehr, aber die irritieren seit 20>>Jahren keinen PC mehr. Zumindest nicht, wenn die App mit Delphi bzw.>>Vorgängern geschrieben ist :-)>> Doch ist es, da er einen USB - RS232 wandler hat.> zwischen 2 USB Frames vergeht nunmal etwas Zeit und dann wirds langsam.
Ich glaube nicht, dass eine weich händeschüttelnde 9600Bd-Schnitte, die
jeweils ein paar zig Bytes en bloc sendet, so viel davon merkt. Es sei
denn, die Pausen zwischen zwei USB Frames rechnen sich in halben
Sekunden - wobei ich mich allerdings fragen würde, ob es wirklich
sinnvoll ist, den Big-File-Transfer auf einen Stick oder eine externe
HDD ausgerecht dann zu starten, wenn ich gerade mit der Fräse oder sonst
einer kritischen Gegenstation kommuniziere :-)
>Das setzt aber so eine Art "Frage und
Antwort" voraus.
µC - Daten anfordern
PC - Anforderung quittieren
PC - Antworten
µC - Antwort Quittieren
PC - Positiv: nächste
PC - Negativ: wiederholen
Sowas ist viel zu ineffizient. Zum einen sollte man sich im Klaren wer
der Master ist, und wer der Slave. Der Master initiert einen Austausch,
der Slave reagiert, macht selbst aber nichts. Resp. Wer ist der Server
und wer ist der Client. Der Client darf etwas anfragen, der Server muss
antworten, macht aber von sich aus nichts. Bei mir ist der PC jeweils
der Master. Der Controller macht was er zu tun hat, auch ohne PC. Mit
dem PC kann man Parameter aendern, Den Prozess mitverfolgen.
Im obigen Ansatz ist es nun umgekehrt, das kann man machen. Was aber
Muell ist, ist dass fuer jede Anfrage zwei Meldungen versandt werde
muessen. Ich wuerd nur eine Transaktion vorsehen. Die antwort und die
Bestaetigung sind identisch. Das bedingt, die Antwort ist eigentlich
schon vorhanden, oder kann waehrend des Sendens erzeugt werden, oder man
hat genuegend Zeit zu warten.
In der obigen Anwendung wuerd ich den Controller als Slave/Server
aufsetzen, und ihm die Befehle im Voraus senden, sodass er sie Buffern
kann. Der Controller soll eine Befehlsliste bezueglich den
Anfahr-koordinaten haben, und die abarbeiten. Vom PC her sollte man
waehrenddessen anfragen koennen wo in der Liste er grad ist, und wie
lange welche Operation noch dauern wird.
Dass die Fraese den PC anfragt macht irgendwie keinen Sinn.
Hi Leute
Ich find es immer wieder gut, wenn man einen Beitrag verfasst, Bezug auf
eine (ur)alte Anwendung nimmt und dieses mal so als Beispiel
niederschreibt. Nicht lange, da hat es der erste aus dem Kontext
gerissen und seinen Senf dazu getan. Ist nicht weiter schlimm, aber
dennoch war es nicht der Sinn, hier etwas zum Besten zu geben, um
hinterher mitgeteilt zu bekommen, das dies Blödsinn ist. Klar, heut würd
ich vielleicht etwas anderes machen. Kommt immer darauf an, was kritisch
ist. Hab ich Zeit ohne Ende, dann kann ich viel in die Sicherheit der
Datenübertragung stecken. Muss ich in kleinsten Zeitfenstern denken,
kann ich nicht unendlich viele Daten hin und herschicken und prüfen, das
auch alles richtig ist. Lest doch bitte mal Zusammenhänge und nicht
solch herausgekasperte Zitate. Ich geh mal davon aus, das die meisten
hier schon eine Vorstellung von dem haben, was sie brauchen. Nur machmal
braucht es einen Anstoß von außen, um bestimmte Hirnströme mal in eine
andere Richtung zu schieben. Ich will dem Fragesteller doch nicht
aufdrücken, du mußt....
Gruß oldmax
Mal ein ganz anderer Ansatz:
Alle gehen sofort auf das Protokoll los,
es könnte auch ein Hardware Problem sein, gut mit einem entsprechenden
Protokoll kann man sowas umschiffen, ist aber der Weisheit nicht letzter
Schluss.
Setzte zuerst mal am AVR an:
1. ist dieser mit einem Quartz bestückt, nur mit Quartz kann eine
stabile RS232 Funktion gewährleistet sein, die internen Oszillatoren der
AVR's haben da meist nicht genügend Stabilität.
2. Die Taktfrequenz des Quarzes sollte entsprechen gewählt werden, damit
die Teiler im AVR auch auf die Baudrate entsprechend "sauber" herunter
teilen können. Ich hab schon so oft Controller boards mit seltsamen
Quartz Frequenzen gesehen bis ich erkannte dass dies mit a) Clock (Uhr)
und b) Baudrate (RS232) zusammen hängt.
Siehe Frequenzen und damit machbare Baudraten hier:
http://halvar.at/elektronik/kleiner_bascom_avr_kurs/uart_rs232_zum_computer/
Wenn das nicht hilft kann natürlich die Schnittstelle am PC auch noch
Probleme bereiten, dies ist aufgrund von Verwendung von Billigst
Bauteilen natürlich auch noch eine wahrscheinliche Fehlerquelle. Wenn Du
möglichst auf USB-Interfaces verzichten kannst, verwende doch mal eine
Multi I/O Karte (RS232FiFO) möglichst mit 16C550 Baustein (wenn sowas
noch erhältlich ist).
Ansonsten viel Glück...
Auch solltest Du die Leitungslänge zwischen PC und AVR berücksichtigen,
Abhängig von der Baudrate ist auch lei mögliche maximale Leitungslänge.
Im WIKI habe ich hierzu folgenden Beitrag gefunden:
Leitungslänge und Übertragungsrate:
http://de.wikipedia.org/wiki/RS-232
Alternativ könntest Du auch auf RS232 - RS485 = RS485 - RS232 Wandler
setzen
damit kannst Du dann deine Datenleitung um's Haus Wickeln und immer noch
sauber Daten empfangen. ;-)
