Bei der Verdrahtung gibt es keine meintewegend GND mal mitzählen oder auch nicht.
Trenn mal GND auf und dann kommt eine Station an ein Netzteil mit Erdung und eins befindet sich in Schwebe ohne GND ist es da eher Zufall wenn was richtiges ankommt.
Dann müsste man mit diferentiellen Signalen ohne Bezugspotential arbeiten. Da hätte man dann für TX und RX aber 4 Leitungen.
Hat aber auch nichts mit dem Protokoll zu tun.
Hilft aber es zu wissen, bei bestimmten Problemen.
Die Indikator LEDs sind hilfreich wenn man keinen Logikanalyzer oder zweikanalosziloskop zur Verfügung hat.
Das Problem das hier vorliegt, ist genau das man sich um nichts kümmern muß und damit auch aufhört sich darüber Gedanken zu machen.
Es gibt einen Prozess der Daten leifert, einen Prozess der Daten sendet, einen Prozess der Daten empfängt und einen der Sie verarbeitet.
Nimmt man einfach mal im Gedankenmodell vier durchsichtige Schlauchstücke mit verschiedenen Durchmessern die man mit Adaptern untereinender hängt und gießt oben Wasser ein, merkt man sofort das man oberhalb eines Engpasses einen Überlauf bekommt.
Nimmt man jetzt anstelle von Wasser farbigen Sand, und jede Farbe stellt ein Byte dar, dann stellt man noch fest das einzelne Bytes beim Überlauf verloren gehen.
Man also nicht weis ob der Sendepuffer überhaupt eine Bytefolge enthält die ein zusammengehöriges Datagramm bilden oder nur Datenmüll aus zwei, drei oder mehr Datagrammen des liefernden Prozesses.
Oder halt der Empfangspuffer wenn man Leitngsstörungen hat und sich nicht um Kontrollmechnismen gekümmert hat (Parity auf Bitebene, Modulo 11 auf Byteebene etc.)
Einfach nur sagen dreh die Baudrate runter, ist ein erster Ansatz der eine direkten erfolg bringen kann, aber ohne das grundlegende Verständniss beim TE wie die Zusammenhänge sind und wie das ganze funktioniert, wird der TE immer nur murks zusammenbasteln der scheinbar oder temporär, zufällig funktioniert in Wahrheit aber ein unendlicher Quell für Fehler sein wird.
Und eine Möglichkeit ist zum beispiel nicht nur TX und RX zu nutzen sondern das ein langsamer Zielprozess ein TRS oder CTS signalisiert. Damit werdne dann Überläufe beim Sendepuffer vermieden und man braucht kein NOP (delay) das bei veränderungen am Programmablauf plötzlich nicht mehr passt, weil es ja nichts prüft.
Ich habe hier grade erst ein Projekt für einen Energieversorger abgeschlossen wo es um nichts anders ging als zu prüfen ob unter allen Bedingunen, von Schutzgeräten wirklich die korrekten Daten in der Leitwarte ankommen.
Da waren auch jungdynamische Softwareentwickler am werke, die so Basics mal schnell im Grundstudium durchgewunken haben.
Nur bei einer Kaskadenabschaltung quer durch Europa sind die Folgen halt etwas anders wie bei unseren Hobbyprojekten.
Schlimm wird es nur wenn da dann Leute dabei sind die, genau weil bei ihnen privat so zusammenklick und fertig Projekte bisher noch keine größeren Auswirkungen hatten, denken so kann man auch bei einer kritischen Infrastruktur arbeiten.
Schlimm ist hier gewesen, das ich mit Realschulabschluß aber halt vor der Klickmich Ära gelernt, einem Doktor der Informatik so was erklären muß.
Hier wäre es jetzt vermutlich egal, aber wen nder TE für sich was lernen will und sich verbessern will, gereicht es Ihm nicht zum Nachteil wenn er ein mehr an Informationen erhällt.
Auch wenn es einige KISS verfechter gibt, zeigt mir mein Berufsaltag, daß das mit deutlicher Mehrheit schief geht.
Bei der Implementierung sollte am ende natürlich KISS unter dem Gesichtspunkt der Performance und der Wartbarkeit rauskommen. Aber halt nicht beim Gedanken darüber machen ob man alle Eventualitäten abdeckt die das gewünschte Ergebniss verhindern können.
(Meteoreinschläge oder andere eher unwarscheinlichen Worst Case Szenarien mal außen vor gelassen, da ich nicht denke das hier im Forum jemand eine HA Umgebung auf höchstem Niveau fürs Hobby entwickelt)
Zitieren
Lesezeichen