UART mit 9 Bit am PC Terminal auswerten?

[Sinnloserknopf]

Hallo liebes RN,
ich habe ein Segway zerlegt weil ich den Motortreiber für ein anderes Projekt brauche.

In diesem Segway ist ein Gyroboard verbaut welches über Uart mit dem Motortreiber verbunden ist.
Nach langen recherchen habe ich herrausgefunden das es sich wohl um eine 9 Bit Uart handelt. :confused:

Um den Motor treiber jetzt gescheit ansteuern zu können muss ich dieses Komunikation entschlüsseln.
Dafür wäre es (zumindest für mich) am einfachsten mir die Komunikation am PC im Terminal anzeigen zu lassen...

Ich schätze mal das ich mit meinem FTDI FT232R nicht besonders weit komme. Könnt ihr mir evtl hefen? Vielleicht kann man ja einen Arduino oder so als übersetzer nutzen?

PS:
Zerreißt mich bitte nicht in der Luft falls ich mich ungünstig ausgedrückt habe ;)


Liebe Grüße
Christian

[Ceos]

sicher dass es 9n1 und nicht eventuell 8n2 oder 8o1 oder 8e1 ist ? (odd even parity bit oder 2 stoppbits) ... 9bit ist extremst untypisch

parity bit kannst du ganz leicht identifizieren, check einfach ob ein zusammenhang zwischen 9tem bit und der anzahl 1en oder 0en davor besteht

für stoppbits brauchst n oszi um die bitzeit zu messen, die 2 stoppbits müsste dauerhaft so lang wie 2 bits sein wenn darauf folgend ein neues byte folgt unabhängig von dem was vorher gesendet worden ist

[Sinnloserknopf]

Habe grade das gefunden:

https://github.com/OpHaCo/hoverbot/blob/master/README.md

Demnach ist es wohl 9n1 oder versteh ich das falsch? :)

[Ceos]

die bitzeiten sehen aber arg instabil aus auf dem salea auszug! sehr wackelig und wie zum geier der auf 170(MSB first nach der logik) kommt wenn er dann bei der verkürzten version der 0 auf 256(plötzlich LSB first ???) kommt erklärt sich mir auch nciht so recht

es sind jedenfalls keine 2 stoppbits, soviel ist ersichtlich

[Sinnloserknopf]

Ich hatte auf ein Standard Protokoll zwischen Sensorboard und Motorboard gehofft ^^ so ist die Aufgabe doch etwas hoch für mich xD


Edit:
werde es nacher mal mit meinem PI versuchen. Hab grade gelesen das die "pigpio library" wohl 9bits lesen kann.

LG

[Ceos]

viel erfolg damit ... ich hätte jetzt vermutlich einfach mal mit even und odd parity verscuht um zu sehen ob er efhler spuckt :D

[Sinnloserknopf]

Versuchen kann ich das auch mal :)

[Peter(TOO)]

Bei µCs gibt es verschiedene Verwendungen für das 9te Bit.
1. Wie schon geschrieben wurde, als 2tes Stopbit.
2. Parity. Wobei es nicht nur O und E gibt, sondern auch immer 0 oder immer 1 (damit kann man dann etwas ähnliches wie 3. machen. Die Adresse muss dann im Parity-Error-Handler ausgewertet werden.).
3. als MP-Bit. Man kann mehrere µCs an eine Leitung hängen. Man sendet dann eine Adresse mit gesetztem MP-Bit, wodurch alle UARTs einen Interrupt erzeugen. Typischerweise sind die ersten 8-Bit eine Geräte Adresse. Wenn die Adresse nicht stimmt, wird der Interrupt quittiert und es erfolgt erst wieder ein Interrupt, wenn das MP-Bit gesetzte ist. Der Adressat setzt dann den normalen Empfangsmodus und erhält für jedes gesendete Byte mit gelöschtem MP-Bit einen Interrupt. Diese Mechanismus wird durch die Hardware unterstützt.
4. Bei nur zwei Empfängern kann man das 9te Bit als Geräteadresse verwenden.

Nun kannst du es dir aussuchen.

MfG Peter(TOO)

[Sinnloserknopf]

Ich hab mal jemanden auf YouTube gefragt der da schon dran war:

[Zitat]
Ich hatte das Signal komplett digitalisiert und dann mühsamst mit Stift und Papier auf karriertem Blatt abgezeichnet, dann lange rätselraten und bekam so die 6 Byte raus, jedes Byte hat ein Startbit, 9 Datenbits und ein Stopbit also besteht aus insgesamt 11 Bit. Das Signal wo das Orginal Gyro macht lässt sich nicht mal auf nen Oszi triggern da dort random Pausen zwischen den Bytes sind. Ich habe Gyro Boards komplett mit nen Pic nachgebaut und die Software zu selbst geschrieben, in der nachprogrammierten Version habe ich eine feste Pause alle 6 Bytes, das lässt sich mit Oszi super triggern und man kann jedes Byte erkennen und dazu auch jedes Bit, das machte Debugging viel leichter. Auf die genaue Bitrate komm ich mit dem Pic zwar auch nicht aber ich komme genau genug ran dass das Motor Board alles fehlerfrei zuverlässig erkennt und durch einen kleinen Trick und indem ich den usart Empfänger im Pic jedes mal resette und Bytes die leicht verschoben empfangen werden verwerfe kann ich das eine Byte das vom Motor Board kommt auch immer zuverlässig empfangen.*Das usart rx und tx vom Motor Board ist niemals syncron, das hat ne leicht andere Baudrate, wenn das Gyro Board die Daten syncron zu den empfangenen Daten sendet steigt das Morotboard aus mit "gyro board fehler" daher darf das nicht miteinander syncronisiert werden, die zu sendenen Daten können langsamer oder schneller als die zu empfangenen Daten gesendet werden aber nicht gleich schnell und nicht syncron, ich selbst sende sie viel schneller, mit der selben Geschwindigkeit wie das Orginal Board die Daten sendet aber mit einer festen Pause alle 6 Bytes und nicht wie das Orginal Board mit Random Pausen zwischen 3-4 Bytes. In den Pausen frage ich dann immer die Gyro Chips ab, die Berechnungen mache ich zwischen Byte1 und Byte2 das gesendet wird. Habe eine Software für veröffentlicht, die "finale" Version von die meiner Meinung nach weitaus besser zu fahren ist als das Orginal werde ich irgendwann noch veröffentlichen, ich programmiere daran immer wenn mir was einfällt noch ne kleinigkeit um. Ganz wichtig, die Daten haben 3.3 Volt Pegel und es darf auch nur mit 3.3 Volt Pegel gesendet werden, ich versorge dazu einen Pic einfach mit 3.3 Volt.*Gruß*Robert
[\Zitat]

[MacMike]

Habe grade das gefunden:

https://github.com/OpHaCo/hoverbot/blob/master/README.md/test (http://tintenstrahldrucker-abc.de/)

Demnach ist es wohl 9n1 oder versteh ich das falsch? :)

Nein, die Bitzeiten passen nicht..

[Peter(TOO)]

@Sinnloserknopf

Das Timing ist nur für einen Block aus Start-, Daten- und Stopp-Bits fest und ist die Baudrate.
Es ist dann aber egal ob man diese Datenblöcke direkt hintereinander ausgibt oder nur jede Stunde ein Zeichen.

Die variierenden Abstände zwischen den Daten kommt vom Programm auf der Senderseite, weil es zwischen den einzelnen Daten noch anderes macht. Spricht normalerweise dafür, dass das UART über Polling Betrieben wird oder das UART per Software simuliert wird.
Betreibt man das UART über Interrupts, bekommt man Problemlos die minimal möglichen Abstände zwischen den einzelnen Datenblöcken hin.

Für einen Pulling-Betrieb spricht auch, das das Teil nicht gleichzeitig senden und empfangen kann.