Hi, Ich suche ein Kommunikationsprotokoll für einen zuverlässigen Datentransfer über die Serielle Schnittstelle. Das ganze sollte eine CRC16 oder CRC32 beinhalten, ACK und NACK verschicken können sowie Auto-Retransmissions. Im Prinzip möchte ich sowas wie CAN oder sogar CANOpen aber mit einer Seriellen Schnittstelle. Gibt es sowas?
Gast
#7068237
Hm...modbus. Aber du kannst dir ja auch einfach was eigenes ausdenken. Implementieren musst du es ja sowieso selber. > Im Prinzip möchte ich sowas wie CAN oder sogar > CANOpen aber mit einer Seriellen Schnittstelle. Dann nimm doch einfach CAN und verwende eine serielle Schnittstelle. Das hat dann ja immerhin den Vorteil das du die Lowlevelhardware fertig in der MCU haben kannst. Olaf
Bert S. schrieb: > Im Prinzip möchte ich sowas wie CAN oder sogar > CANOpen aber mit einer Seriellen Schnittstelle. Gibt es sowas? X,Y,Z Modem. Alt, aber bewährt.
Moin, TCP/IP ueber PPP. Millionen Modems koennen nicht irren... Gruss WK
Gast
#7068372
Kermit. Was sonst.
Bert S. schrieb: > Im Prinzip möchte ich sowas wie CAN Dann nimm CAN, da macht alles schon die Hardware. Ein zuverlässig funktionierender UART-Stack kostet einige 1000 Codezeilen, bzw. einige 10kB an Binärcode.
Gast
#7068392
Bert S. schrieb: > Ich suche ein Kommunikationsprotokoll für einen zuverlässigen > Datentransfer Was ist (für Deine Anwendung) "Zuverlässig"? Du musst Dir erst mal im Klaren sein, was Du überhaupt willst. > Das ganze sollte eine > CRC16 oder CRC32 beinhalten, ACK und NACK verschicken können Warum? Welche Anforderung/Überlegung führt zu dieser Lösung?
Gast
#7068490
Dergute W. schrieb: > Moin, > > TCP/IP ueber PPP. Millionen Modems koennen nicht irren... > > Gruss > WK Ich würde ebenso auf ein Modell nach ISO/OSI aufsetzen - nichts anderes! Siehe Screenshot (entnommen aus https://de.wikipedia.org/wiki/Serial_Line_Internet_Protocol) Scheint vielleicht übertrieben, aber da haben Generationen von Spezialisten nicht wenig Hirnschmalz investiert - ergo spart man sich da einiges an Programmier/Dokumentations-Aufwand. Nicht zu vergessen den Testaufwand: Das sind bekannte Protokolle, und da gibt es fertige Analysatoren für. Alternativ zu PPP (RFC1661) könnte ich mir auch SLIP (RFC1055) vorstellen. Im RFC findet sich die C-Implementierung von send_packet() und recv_packet(). IP (das legt sich über SLIP/PPP) findet man in RFC791, TCP (legt sich über IP) in RFC793. Wer will, packt noch ein ICMP (RFC792) dazu. Oder tauscht TCP gegen UDP, oder beides gleichzeitig. RFC1180 bietet einen guten Überblick, oder eine Anfrage bei duckduckgo nach "TCP/IP" ... Just my 2ct
Angehängte Dateien:
Wie wär´s mit Modbus ? Wahlweise auch lesbar als ASCII.
Gast
#7068951
Schorsch X. schrieb: > Wie wär´s mit Modbus ? Olaf schrieb: > Hm...modbus.
Gast
#7069884
Bert S. schrieb: > Ich suche ein Kommunikationsprotokoll für einen zuverlässigen > Datentransfer über die Serielle Schnittstelle Wenn du beide Enden programmierst ist es ziemlich egal welches Protokoll - ein vorhandenes zu nehmen spart eigenes Gehirnschmalz, und wenn es tatsächlich genutzt wird kann man auch davon ausgehen, dass es zuverlässig funktioniert. Manche Vorschläge hier wie Kermit stammen aus der Steinzeit, aber das ist auch egal, die serielle Schnittstelle ist ja auch uralt (und funktioniert trotzdem). Georg
Ack/Nack ist Schrott. Vergiss die. Mach das Protokoll Master-Slave. Es gibt einen Master, und der sendet, und der Slave antwortet, immer. Der Slave sendet nicht von selbst. Dann benoetigst du noch : Jede Anfrage, oder Command kriegt eine Reply. Die kann auch keine Daten beinhalten. Ist eine leere Meldung. Wenn nichts kommt, ging die Meldung, resp das Command verloren und wird wiederholt. Deshalb sind alle Commands und Replys zustandslos. Das bedeutet es gibt keinen inneren Zustand zu den Meldungen. Bedeutet : Das Auslesen eine grossen Speicherblocks geschieht mit Blockadressierung im Command. Dann kann man jederzeit ein Command wiederholen. Bei einer Kommunikation mit einem inneren Zustand waere das dann : Ein Command nach einem grossen Speicherbereich wir in 20 sukzessiven Bloecken uebermittelt. Wenn dann einer ausfaellt, muss man wieder von vorne beginnen. Es gibt Bespiele die zeigen den Nachteil von inneren Zustaenden noch besser. Die sollte man also vermeiden. Und eine Antwort sollte maximal schnell kommen, auf keinen Fall warten. Bedeutet, man arbeitet mit Zustandsvariablen. Wenn der PC einen ADC Wert will, wird der nicht erst gewandelt, das wuerde zu lange dauern. Es wird immer gewandelt, und das Command liest den letzten aus.
Gast
#7069924
HDLC?
AX25?
Gast
#7070045
Purzel H. schrieb: > Ack/Nack ist Schrott. [...] > Deshalb sind alle Commands und Replys zustandslos. Yep, endlich mal einer der sich auskennt. Idempotenz ist der Schlüssel zum Erfolg. Und wenn man mit ASCII in menschenlesbarer Form zurecht kommt, steht dem Erfolg nichts mehr entgegen und die Angst-CRCs sind dann auch Geschichte. > Der Slave sendet nicht von selbst. Kann man machen, muss man aber nicht. Der Slave kann (s)einen (Teil-)Zustand auch ständig raushauen, muss sich ja niemand dafür Interessieren... Entscheidend ist Idempotenz. Request/Response muss nicht sein.
Spärliche Infos. * Soll das nur für 2 Teilnehmer funktionierten? * Oder soll das Bussfaehig sein? * Gibt es funktionel eh schon sowas wie einen Master und der/die anderen sind funktionel Slaves?
Gast
#7070580
Wahnsinn, dieses Feedback des TO ...
Gast
#7070946
Bevor ich mit ein Protokoll ausdenke oder auswähle, kläre ich die Anforderungen. Wie schnell müssen wie viele Daten übertragen werden und kommt es auf minimale Latenz an oder ist das egal? Wie tragisch wäre ein nicht erkannter Übertragungsfehler? Wäre schön, wenn sich der Bert nach 2 Tagen mal wieder an seiner eigenen Diskussion beteiligen würde, sonst verschwendet er hier bloß unsere Zeit.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.