Hallo zusammen! Als erster Beitrag gleich mal was sehr Spezielles: In einem Projekt wird künftig, so geplant, ein RS485 Bus verwendet, welches einen Master (Hauptplatine) und 3 Slaves (unter anderem auch ein HMI) haben soll. RS485 wurde aufgrund der möglichen Kabellänge gewählt. Ich habe mich jetzt den halben Tag in die Thematik eingelesen und würde es wohl folgendermaßes verschalten: M4 Cortex von ST -> U(S)ART in asynchronen Modus -> RS232 auf RS485 converter mit RX, TX und RTS verdrahtet -> Leitungen A und B .... Das Einzige was ich nicht ganz einschätzen kann ist: Wenn ich HDLC zur Kommunikation einsetze, ist das dann overkill? Habe ich noch etwas vergessen, was in diesem Protokoll noch fehlt? Gibt es ein andere Protokoll, welches mehr Sinn macht? Mache ich mir zu viele Gedanken und sollte lieber anfange zu coden? ;) Grüße und schon im Voraus vielen Dank an Alle, die sich die Mühe machen zu antworten!
Florian T. schrieb: > Wenn ich HDLC zur > Kommunikation einsetze HDLC ist synchron, nicht asynchron. Normalerweise braucht man deshalb auch ein USART (mit S!), das HDLC kann. Georg
Hallo Georg! Ich habe aber z.B. auf Wikipedia (https://en.wikipedia.org/wiki/High-Level_Data_Link_Control#Asynchronous_framing) gesehen, dass beides gehen sollte.
Florian T. schrieb: > dass beides gehen sollte. Ich kenne aber kein IC, das asynchrones HDLC unterstützt - soll heissen, du musst alles, Frame Erkennung, Stuffing, CRC usw. zu Fuss erledigen, was ein USART in Hardware kann. Macht ja vielleicht Spass. Georg
Hallo Georg, sorry, wenn ich doof nachfrage..was genau meinst du mit "IC"? Ich habe converter (RS232 to RS485) gesehen die keine clock (CK) hatten, sondern ein ENABLE eingang (hieß z.B. TXE) Wenn es Übertragungen im Synchronen Modus gibt, soll mir das Recht sein, Pins gibt es aktuell noch genug, bzw. ein ENABLE pin fällt dann auch wieder weg. Was genau übernimmt der USART für Funktionen, die mir das Leben erleichern können? Gibt es da einen automatisch generierten CRC oder sowas? Ich hab da bisher nicht viel zu gefunden. Was genau passiert im converter? Wie gewärleiste ich, dass ein Frame korrekt übertragen wurde, auch nach dem Übergang ins RS485. Ich hab mir zwar viel angelesen, habe aber dazu recht wenig gefunden. Ich hatte fest damit gerechnet, dass ich das HDLC selbst umsetzen muss...sooo schwer ist das ja auch nicht. Wenn ich mir das sparen kann, dann bin ich natürlich dafür. ;)
Was mir auffällt..ich hatte noch nicht erwähnt, dass die Slaves allesamt auch von mir Entwickelt oder in Auftrag gegeben werden! Ich bin also noch völlig frei, was die Kommunikation angeht.
Florian T. schrieb: > was genau meinst du mit "IC"? Ein UART oder USART - egal ob als Einzel-IC oder in einem Controller. Florian T. schrieb: > Gibt es da einen automatisch generierten CRC oder > sowas? Um Frame Detektion, Bit Stuffing, CRC Generierung und Prüfung kümmert sich die Hardware. Man muss nur noch Interrupts abarbeiten (oder ev. DMA). Ganz so trivial wie du meinst ist HDLC fürchte ich nicht. Es ist auch ziemlich aus der Mode gekommen, daher wird es ja kaum noch unterstützt. Aber softwaremässig kannst du natürlich alles nachmachen, was früher mal die Hardware erledigt hat. Ist sicher eine interessante Aufgabe. Florian T. schrieb: > dass die Slaves allesamt > auch von mir Entwickelt oder in Auftrag gegeben werden! Das macht die Sache noch vieeel interessanter - du hast keine funktionsfähige Gegenstation, sondern musst beides parallel entwickeln und debuggen. Georg
Georg schrieb: > Florian T. schrieb: >> Gibt es da einen automatisch generierten CRC oder >> sowas? > > Um Frame Detektion, Bit Stuffing, CRC Generierung und Prüfung kümmert > sich die Hardware. Man muss nur noch Interrupts abarbeiten (oder ev. > DMA). Ganz so trivial wie du meinst ist HDLC fürchte ich nicht. Es ist > auch ziemlich aus der Mode gekommen, daher wird es ja kaum noch > unterstützt. Aber softwaremässig kannst du natürlich alles nachmachen, > was früher mal die Hardware erledigt hat. Ist sicher eine interessante > Aufgabe. Ich habe gerade nochmal die Doku des Cortex M4 gewälzt. Es gibt keinerlei Hinweise, dass die U(S)ARTs CRC checks von sich aus machen. Es werden aber ein paar Protokolle unterstützt wie z.B. LIN, IrDA, Smartcard und Multiprocessor Communication. Mit Ausnahme einer Parität sehe ich da aber beim normalen U(S)ART Betrieb nichts was die Datensicherheit gewärleisten könnte. Vielleicht hab ich aber noch immer nicht richtig hingesehen (ich schaffe es auch mehrere Tage lang den Wald nicht vor Augen zu sehen..in diesem Fall bitte ich um Gedult mit mir ;)) Aus diesem Grund bin ich auch der Meinung, dass ich selbst dafür sorgen muss, dass meine Frames ankommen. Ich hatte schonmal etwas sehr ähnliches die HDLC implementiert, aus diesem Grund bin ich auch sicher, dass ich das hinkriegen kann. Wenn ich es aber nicht muss, dann bin ich damit auch zufrieden. Was mir außerdem noch Gedanken bereitet ist der Übergang zu RS485...aktuell nehme ich an, dass dort auch nur die Bytes übertragen werden. > Florian T. schrieb: >> dass die Slaves allesamt >> auch von mir Entwickelt oder in Auftrag gegeben werden! > > Das macht die Sache noch vieeel interessanter - du hast keine > funktionsfähige Gegenstation, sondern musst beides parallel entwickeln > und debuggen. > > Georg Wobei eine Lib für ein Protokoll (vielleicht lasse ich auch einfach einen Teil weg), kann ja für jedes Gerät einfach verwendet werden. ;) Bis hierhin schonmal vielen Dank!
Florian T. schrieb: > der Übergang zu > RS485...aktuell nehme ich an, dass dort auch nur die Bytes übertragen > werden. Das ist reine Pegel-Umsetzung, der RS485-Treiber kennt nur Hi und Lo, aber keine Bytes, nicht mal eine Baudrate. Interessant ist daran nur, dass nur ein Baustein am Bus senden darf, dafür ist eben der Enable-Eingang da. Durch das Protokoll muss immer klar sein, wer gerade senden darf. Daher ist eine Master-Slave-Struktur am einfachsten - der Master spricht einen Slave an, schaltet dann seinen Sender ab, der Slave schaltet Senden ein und antwortet. Und so immer weiter. Georg
Ja, das ist richtig. Ein UART ist ein Schieberegister, das 8bit zeitgenau hinausschiebt und Start-, sowie Stopbit abnhaengt. Das Parity wird heute nicht mehr verwendet, weil es, glaubt man nichts bringt. Ja, Frames, mit Id, Laenge, Daten und CRC muss man selbst zusammenbauen. Das ist aber nicht schwierig. Ein spezielles Feature des HDLC ist das Escapen des Commands. Dies ermoeglicht, dass die Empfangsstatemachine in Fehlerfall schon beim naechsten Frame wieder lockt, waehrend, wenn man das nicht macht, ein paar Frames verliert. Ich mach das Escapen jeweils nicht. Das erlaubt mir dafuer das Frame auf dem Scope anzuschauen und visuell zu decodieren. Die Funktionalitaet eines UARTs im empfangsfall ist das Oversampling, bis zu 8fach, und doublebuffern der empfangenen Bytes. Es gibt bei jedem byte einen neuen interrupt. Standalone Uarts koennen bis zu 64 byte Rx&Tx Buffer haben, und erlauben auch bei sehr hohen Baudraten ein entspannteres Timing fuer die CPU. Wenn man die zwingende 3 leiter Funktionalitaet nicht benoetigt, und sich auch 5 Leiter goennen kann, empfehl ich RS422. Das sind die selben Treiber, man kann dank eines zusaetlichen Leiterpaares und je einem zusaetzlichen Treiber Vollduplex erlauben. Die moegliche Leitungslaenge bleibt auch gleich. Das Empfangen, resp, die Feldzuweisung beim Empfangen macht man ueberigens mit Statemachines, das sind Software konstrukte.
Georg schrieb: > Florian T. schrieb: >> der Übergang zu >> RS485...aktuell nehme ich an, dass dort auch nur die Bytes übertragen >> werden. > > Das ist reine Pegel-Umsetzung, der RS485-Treiber kennt nur Hi und Lo, > aber keine Bytes, nicht mal eine Baudrate. Interessant ist daran nur, > dass nur ein Baustein am Bus senden darf, dafür ist eben der > Enable-Eingang da. Durch das Protokoll muss immer klar sein, wer gerade > senden darf. Daher ist eine Master-Slave-Struktur am einfachsten - der > Master spricht einen Slave an, schaltet dann seinen Sender ab, der Slave > schaltet Senden ein und antwortet. Und so immer weiter. > > Georg Vielen Dank für die Info! Das mit dem Master / Slave hatte ich mir schon angelesen. Dass es nur ein Pegelumsetzer ist, war mir nicht bewußt. :) @jetztnicht Viele der Infos hatte ich ebenfalls bereits (ich hab eben ein gefährliches Halbwissen). Heißt das im Klartext: Jup..es MACHT Sinn, wenn ich HDLC nutze (auch wegen der Adressierung etc.). Ich habe einen freien Treiber dafür gefunden, den man evtl. nutzen könnte. Falls der nicht geht, finde ich es jetzt auch nicht sooo komplex. Das excapen würde ich vermutlich so oder so machen. ;) CRC sollte der Controller von sich aus können, ansonsten ist auch das machbar (habe ich vor langer Zeit auch mal gemacht). Unterm Strich: Würdet ihr es genau so oder ähnlich machen?
Florian T. schrieb: > Das excapen würde ich vermutlich so oder so machen. Die Frage ist, was willst du denn übertragen? Im Lauf eines langen Programmiererlebens bin ich zu der Erkenntnis gekommen, alles in Klartext zu übertragen, nicht binär, also nicht 2 Bytes für einen 15bit-Wert, sondern ASCII-Ziffern. Für das Protokoll verwende ich die vorgesehenen ASCII-Codes wie STX,ETX,CR usw. Da die im Text nicht vorkommen, muss man keine Sonderregelungen wie Escapes treffen, und der andere grosse Vorteil ist, dass man zum Debuggen mitlesen kann, ohne hexadezimal kopfrechnen zu müssen. Da Internet macht es auch so, beruht fast alles auf ASCII-Text. Dass mehr zu übertragen ist fällt nur selten ins Gewicht. Ein typisches Protokoll könnte also aufgebaut sein: STX Adresse Länge Daten CRC ETX Georg
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.