Hey,
danke allen für die Beteiligung!
Ja, es geht darum, auch zu wissen, welche Station gerade sendet, durch bloßes Mithören verliere ich diese Information (= Eindrahtbus).
Die Idee mit dem Widerstand und Polarität des Spannungsabfalls find ich gut, werd ich mir zunächst mal auf dem Oszi angucken. Ist halt ein Open-Collector-Bus, da fließt nicht allzu viel Strom. Aber vielleicht reicht es ja...
Wie könnte ich aber diese Information dann in den µC bekommen? (Auf einfache Weise, ohne eine aufwändige Komparatorschaltung.)
Serielle Dekodierung und Logging im Oszi ist vorhanden, aber wie ich schon schrieb, hält sich die Komponente nicht an das normale LIN-Protokoll. Daher kann der integrierte Lin-Decoder das nicht parsen.
Was könnte mir ein Logianalyser sonst noch bieten für diesen Use Case?
Schon allein, dass manche Bytes des Masters manchmal ein neuntes Bit haben, bzw. das Stop-Bit low ist, ist schon komisch.
Zum Eindrahtbus: Ja, der Bus ist ein Draht, aber hinter dem Transmitter (TJA10200) auf TTL-Seite nicht mehr, der hat einen TX- und RX-Pin. Deshalb sind es 4 Pins: Master RX rein, an den Slave TX raus und von Slave RX rein an den Master TX raus.
Und diese beiden Datenflüsse getrennt mitlesen, aber verzögerungsfrei weiterreichen ist die Aufgabe. Verzögerungsfrei ist relativ, wie geschrieben: eine Sub-Bit-Verzögerung wie bei digitalRead/digitalWrite wäre kein Problem, aber ein ganzes Byte schon.
Das Herauslesen aus den Daten kann man machen, wenn man das Protokoll verstanden hat. Aber darum geht es ja eben erst. Und da ist es überaus hilfreich, die Frage von der Antwort unterscheiden zu können. Oder anders gesagt: Alle Information, die ich sicher bekommen kann, muss ich nutzen, um möglichst wenige noch zu enträtselnde Parameter zu haben. Wenn ich nicht mal weiß, wer was "gesagt" hat, wird es erheblich schwerer.
Ein erster Ansatz ist ja, dass der Master ohne angeschlossenen Slave von alleine Dinge sendet. Er sendet alle 8 ms ein Byte (manchmal 9 bit lang), und dazwischen meistens High, aber manchmal auch zwei etwa bytelange Strecken "low".
Das Syncbyte (0x55) kommt ab und zu, aber ist auch nur eines der Bytes, die alle 8 ms kommen. Nicht direkt ein Byte vor dem ID-Byte, wie es der Standard vorsähe.
Für sämtliche vom Master gesendeten Bytes ist die Paritätsprüfung des LIN-Protokolls erfolgreich.
Jetzt könnte ich vermuten, was bei angeschlossenem Slave sich mit dem deckt, was der Master ohne diesen eh sendet, kommt vom Master. Ist aber auch nur eine Mutmaßung. Der Master könnte ja etwas anderes senden, wenn ein Slave da ist / anwortet.
Deshalb is es für mich keine Option, auf die Information zu verzichten, wer was sendet.
Ich denke, der Weg mit dem Widerstand in Reihe könnte was werden.
Idee hierzu: Ich gehe doch zurück zur Analyse mit meinem Oszi (scheiterte bisher an der fehlenden Information, wer gerade spricht), aber hole mir auf dem zweiten Kanal die Polarität an diesem Widerstand dazu.
Ansonsten fiele mir noch ein: mit digitialRead/digitalWrite durchreichen, und im Rest der Zeit mit einem Softwareserial entschlüsseln.
Hier wäre die Frage: Muss ich mir eins schreiben, oder gibt es eine Bibliothek, die die Signale zu Bytes parst, aber die Pins trotzdem für mein eigenes Read/Write bzw. einen Interrupt offen hält?
Das habe ich noch nicht probiert, probiere ich vielleicht mal mit SoftwareSerial.h. Beim HardwareSerial habe ich genau da einen Konflikt: Nach
Serial1.begin(19200, SERIAL_8N1, LIN_SLV_RX, LIN_SLV_TX);
Serial2.begin(19200, SERIAL_8N1, LIN_MAS_RX, LIN_MAS_TX);
kann ich nicht mehr
digitalWrite(LIN_SLV_TX,digitalRead(LIN_MAS_RX));
digitalWrite(LIN_MAS_TX,digitalRead(LIN_SLV_RX));
machen.
Kann man das evtl. irgendwie lösen?
Danke Euch allen schonmal sehr für den Input!
