Hallo allerseits, ich suche ein Übertragungsprotokoll für eine Point-to-Point-Verbindung, nur zwei Teilnehmer. Hardware-mässig soll das ganze mit einem UART laufen. Am liebsten wäre es mir, könnte ich dem Protokoll einfach die zu sendenden Daten geben. Dieses sollte dann die Daten verschicken und auf eine Antwort warten, dass die Daten angekommen sind. Ist dies innerhalb eines gewissen Zeitrahmens nicht der Fall, werden die Daten nochmals geschickt, etc. Das ganze sollte also quasi auf den OSI-Layern 1,2,4 laufen, den dritten braucht es ja eigentlich nicht wirklich. Ich wäre froh, wäre das ganze keine 50KB-Horror-Library, weswegen ich auch nicht TCP nutzen möchte, sondern was kleines ;) Ich habe schon das hier gefunden, beide kümmern sich allerdings nur um layer 1 und 2. Glaub schonmal nicht schlecht, eigentlich für AVR ausgelegt, aber da fehlt ein Error-Handling https://github.com/min-protocol/min/wiki HDLC ist glaube ich etwas das gleiche, nur halt professioneller was? https://de.wikipedia.org/wiki/High-Level_Data_Link_Control Das sah eigentlich auch noch ganz nett aus, aber mir scheint das PPP auch nicht wirklich das wahre für mich ist. http://www.ethernut.de/en/documents/ntn-1_ppp.html Habt da irgendwelche Ideen für mich? Gruss und Dank Felix
Felix C. schrieb: > eine Point-to-Point-Verbindung, > nur zwei Teilnehmer. Dann nimmst Du das einfachste Protokoll das seit der Steinzeit existiert. Nannte sich LSV1. Da Du nur eine Punkt-zu-Punkt Verbindung hast brauchst Du den ganze Kram mit den Adresse überhaupt nicht. Ich würde das so implementieren: Senderichtung -> MASTER zum SLAVE (so scheint mir Dein Anliegen zu sein) STX Daten EXT BCC ( BCC = Block Check Character [1 Byte] , BCC Prüfsumme ist XOR über alle Bytes) Man kann, auch CRC16 hinten anhängen. Das geht am einfachsten über eine Tabelle. Aber das brauchst Du nicht bei dieser einfachen Kopplung. Danach kommt vom Slave entweder ein einzelnes ACK oder NACK an den Master zurück. Bei Timeout garnix. Bei NAK, muss der Master das Paket wiederholen. Wenn Du dann noch XON/XOFF darüber legst, hast Du auch noch die entsprechende Flußsteuerung. That's easy!
Ja wat denn nun Hardware-UART oder was eigenes ? Wenn Du seriell meinst gibt's z.B. schon I2C, One-Wire usw. Die haben alle Handshake, Adressierung, ACK/NACK und CRC kann man leicht implementieren. Aber wenn Du was eigenes willst dann überlege Dir was Du brauchst und male Dir eine Statemachine auf, die Du dann implementierst. Nur das Rad immer wieder neu erfinden macht eigentlich keinen Sinn.
Bei CAN geht das alles automatisch in Hardware inklusive Fehler Erkennung, da ist die Software simpel. Nebenbei auch sehr störunempfindlich und es ist simpel mehr als 2 Teilnehmer zu vernetzen. Nachteil: Geringe Datenrate, nur max. 8 Bytes pro Paket.
Dr. Sommer schrieb: > Geringe Datenrate, nur max. 8 Bytes pro Paket. Wie kann ich aus der Paketgröße die Datenrate berechnen, um zu beurteilen, ob das für eine bestimmte Anwendung reicht?
Schau Dir mal Modbus RTU an! Ist an sich sehr simpel aufgebaut und kann Paketgrößen bis 255 Words (512 Byte). Für das Übertragen von Prozessdaten nutze ich das gerne. Wenn es keine zyklische Prozessdatenübertragung sein sollte, dann sind andere Protokolle besser geeignet, wie das zum Beispiel bereits genannte HDLC. Viele Grüße! Sven
W.A. schrieb: > Dr. Sommer schrieb: >> Geringe Datenrate, nur max. 8 Bytes pro Paket. > > Wie kann ich aus der Paketgröße die Datenrate berechnen, um zu > beurteilen, ob das für eine bestimmte Anwendung reicht? Solche Fragen sind nichts für Dr. Sommer. Da muß man schon gezielt nach Zyklen oder so fragen.
Deine Anforderungen entsprechen ziemlich genau TCP/IP. Dafür brauchst du nicht 50KB. Der µIP Stack von Adam Dunkels ist keine 8KB groß und benötigt nur für ein Datenpaket Pufferspeicher. Natürlich hat man dafür funktional Abstriche gemacht - aber für deine Anforderungen reicht's immer noch. Sicher gibt es auch einfachere Protokolle. Ich wollte nur drauf hinweisen, das TCP/IP nicht unbedingt so groß und komplex ist, wie du denkst. Wenn du mit einer hohen Fehlerrate rechnest, dann schau Dir mal Z-Modem an. Das ist eigentlich zur Übertragung von Dateien gedacht, aber an der Beschreibung des Protokolls kann man einiges abgucken. Es ist nämlich ganz gut durchdacht.
Codix schrieb: > STX Daten EXT BCC erinnert mich an Siemens, aber der Name dafür fällt mir im Moment nicht mehr ein. Sollte übrigens ETX heissen. Georg
Ich finde das SMALL PROTOKOLL der LCDs von ELECTRONIC ASSEMBLY recht einfach und sicher. Die Implementierung sollte deutlich unter 1kB Flash benötigen. http://www.lcd-module.de/produkte/ediptft.html
Georg schrieb: > Codix schrieb: >> STX Daten EXT BCC > > erinnert mich an Siemens, aber der Name dafür fällt mir im Moment nicht > mehr ein. Du denkst vermutlich an 3964R: https://de.wikipedia.org/wiki/3964R
Codix schrieb: > Senderichtung -> MASTER zum SLAVE (so scheint mir Dein Anliegen zu sein) > STX Daten EXT BCC ( BCC = Block Check Character [1 Byte] , BCC Prüfsumme > ist XOR über alle Bytes) Genau! Für meine Datenübertragungen benutze ich so etwas in der Art auch: Startbyte (0x55)->(Adresse)->Längenbyte->Daten->Trennung-> Daten->Trennung....->Prüfbyte(s)(XOR)->Endmarkierung Rückgabe "OK"(+Rückgabewerte),"ERROR"(+Fehlercode) oder nix. Funktioniert hier einfach nur, auch in 433 MHz und mit mehreren Teilnehmern völlig schmerzfrei...
Hallo allerseits vielen Dank für all eure Antworten!! Codix schrieb: > Dann nimmst Du das einfachste Protokoll das seit der Steinzeit > existiert. > Nannte sich LSV1 Habe ich nicht gefunden, meintest du das da? https://de.wikipedia.org/wiki/Transport_Layer_Security ??? schrieb: > Ja wat denn nun Hardware-UART oder was eigenes ? Ich glaube, ich hatte mich eigentlich ziemlich klar ausgedrückt, dass ich einen UART verwenden will... W.A. schrieb: > Wie kann ich aus der Paketgröße die Datenrate berechnen, um zu > beurteilen, ob das für eine bestimmte Anwendung reicht? Ich habe sowieso nur wenige Daten, aber eigentlich wird bei einer kleinen Paketgrösse die Geschwindigkeit durch das Verhältnis Daten zu Header, Prüfsumme bestimmt. grundschüler schrieb: > einfachst, zuverlässig, flexibel: > > Beitrag "owx 1Wire Protokoll für Datenaustausch und Steuerung" xDDD, wie wärs wenn ich einfach auf diese ganze Elektronik verzichte und Flaschenpost verschicke ;) Codix schrieb: > Senderichtung -> MASTER zum SLAVE (so scheint mir Dein Anliegen zu sein) Ne ich will eigentlich, dass beide selbstständig sind, also kein Master/Slave-System. Die Lösung die ich nun verwende: https://github.com/min-protocol/min Wie bereits viele von euch vorschlugen, werden Frames mit Prüfsummen verwendet. Diese extrem kleine Lib erledigt dies für mich. So kann ich mir sicher sein, dass alle erhaltenen Daten stimmen. Weiter, jede meiner Daten hat eine eigene Kennnummer. Wird ein Frame gesendet, ist die Aufteilung der Bytes immer so: Kennnummer, Daten, Kennnummer, Daten etc. Werden Daten versendet startet ein Timeout, nach dessen Ablaufen die Daten wiederholt gesendet werden. Zu allen Daten gibt es eine "Ack_Kennnumer" so muss der Receiver immer wenn er Daten erhält, diese bestätigen. Selbst wenn die Verbindung nun komplett getrennt würde, also physikalisch, wäre also gewährleistet, dass die Verbindung ohne jegliche Reset-Routinen wieder läuft, also wenn man wieder das Kabel einsteckt zB. Btw. das ganze ist für ein ROV-Projetk (ferngesteuertes U-Boot ;)), ich habe also realitv kleine Datenmengen. Gruss Felix
Felix C. schrieb: > Wie bereits viele von euch vorschlugen, werden Frames mit Prüfsummen > verwendet. Zusätzlich schlage ich vor, ASCII-Text zu senden, keine Roh-Bytes. Das erleichtert das Debuggen sehr, und du musst keine Klimmzüge unternehmen, um Bytes zu senden, die wie CR, LF, STX, ETX usw. aussehen. Die grössere Datenmenge spielt nur sehr selten eine Rolle. Im Internet wird auch i.A. Text übertragen. J. L. schrieb: > Du denkst vermutlich an 3964R Genauuuu... ist aber eigentlich auch schon zu kompliziert. Georg
Georg schrieb: > erinnert mich an Siemens, aber der Name dafür fällt mir im Moment nicht > mehr ein. Sollte übrigens ETX heissen. Hatte ich geschrieben, dass es LSV1 genannt wurde. Und ja, es stammt von Siemens. Wurde in der TRANSDATA-Welt (80er Jahre)eingesetzt. Ja, sollte ETX lauten, danke für die Korrektur. Felix C. schrieb: > Habe ich nicht gefunden, meintest du das da? Darüber findest Du im Wiki und Google nichts. Ist schon zu alt. Felix C. schrieb: > Ne ich will eigentlich, dass beide selbstständig sind, also kein > Master/Slave-System. Kannst Du für beide Seiten verwenden. Dann solltest Du aber ein Protokoll-Schritt davor schalten. D.h. den Geräten eine Adresse zuweisen. Anhand derer kannst Du feststellen, ob der Gegenüber bereit ist zu empfangen. Warum machst Du es Dir so schwer, Du kannst Dir doch Dein eigenes Protokoll aus den Fingern saugen. Musst doch mit nix kompatibel sein.
Siemen USS https://cache.industry.siemens.com/dl/files/253/24178253/att_101236/v1/uss_24178253_spez_00.pdf wäre z.B. ein UART typisches Protokoll. Der Nachfolger geht über Ethernet und heißt Modbus.
Georg schrieb: > im Internet wird auch i.A. Text übertragen. Wo wird denn im Internet noch Text übertragen? HTML/CSS/JS wird quasi immer zlib komprimiert, Bilder sind sowieso binärdaten. Selbst wenn POP3 theoretisch Base64 codiert Anhänge überträgt, dann doch im normalfall verschlüsselt. Das Internet ist schon lange im 8-bit pro Byte Zeitalter angekommen.
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.