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 ?
Hi >Ich habe z.Z. öfters einen Übertragungsfehler, welcher aber fatale >Auswirkungen haben kann. Schon mal nach den Ursachen gesucht? MfG Spess
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)
Habe mir schon ansatzweise selbst ein Protokoll ausgedacht, aber ich denke mal, für RS232 wird es schon sowas geben. Warum das Rad neu erfinden...
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?
:
Wiederhergestellt durch User
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
Haste denn schonmal überprüft ob die Baudrate zum Quarztakt passt oder ist sogar noch der interne RC Oszillator am laufen?
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
und dann ist da noch Fräse, d.h Motor, D.h. Spikes auf den Leitungen Masse-Architektur ----> Ausgleichstromschleifen.
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. ;-)
Ahh noch was: Probier mal den USB Adapter von Digitus, der verwendet einen FT323 Baustein, bisher das beste was ich finden konnte: Reichelt: DIGITUS DA-70156 http://www.reichelt.de/USB-Konverter/DIGITUS-DA-70156/3//index.html?ACTION=3&GROUPID=5253&ARTICLE=99617&SHOW=1&START=0&OFFSET=16&;
Ich meinte natürlich FT232 (Sorry) http://www.reichelt.de/USB-Konverter/DIGITUS-DA-70156/3//index.html?ACTION=3&GROUPID=5253&ARTICLE=99617&SHOW=1&START=0&OFFSET=16&;
Der Beitrag ist 4 Monate alt... Das Problem scheint nicht mehr akut zu sein...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.