-
        

Ergebnis 1 bis 9 von 9

Thema: UART mit 9 Bit am PC Terminal auswerten?

  1. #1
    Neuer Benutzer Öfters hier
    Registriert seit
    15.05.2012
    Beiträge
    12

    UART mit 9 Bit am PC Terminal auswerten?

    Anzeige

    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.

    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

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    32
    Beiträge
    2.261
    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
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  3. #3
    Neuer Benutzer Öfters hier
    Registriert seit
    15.05.2012
    Beiträge
    12
    Habe grade das gefunden:

    https://github.com/OpHaCo/hoverbot/b...ster/README.md

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

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    32
    Beiträge
    2.261
    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
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  5. #5
    Neuer Benutzer Öfters hier
    Registriert seit
    15.05.2012
    Beiträge
    12
    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
    Geändert von Sinnloserknopf (07.08.2017 um 13:07 Uhr)

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    32
    Beiträge
    2.261
    viel erfolg damit ... ich hätte jetzt vermutlich einfach mal mit even und odd parity verscuht um zu sehen ob er efhler spuckt
    Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
    nicht.

  7. #7
    Neuer Benutzer Öfters hier
    Registriert seit
    15.05.2012
    Beiträge
    12
    Versuchen kann ich das auch mal

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    59
    Beiträge
    2.355
    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)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  9. #9
    Neuer Benutzer Öfters hier
    Registriert seit
    15.05.2012
    Beiträge
    12
    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]

Ähnliche Themen

  1. [ERLEDIGT] Terminal HTerm empfängt nichts über die UART-Schnittstelle
    Von FrankR im Forum Robby RP6
    Antworten: 5
    Letzter Beitrag: 12.02.2013, 18:57
  2. [ERLEDIGT] LM75 Auswerten und Temperatur über terminal ausgeben?
    Von Ferdinand im Forum C - Programmierung (GCC u.a.)
    Antworten: 13
    Letzter Beitrag: 03.06.2012, 21:25
  3. UART(Eingabe) empfangen/auswerten
    Von TheDuke im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 12.09.2011, 11:24
  4. [ERLEDIGT] Über Uart Kommandos auswerten
    Von daniel.weber im Forum C - Programmierung (GCC u.a.)
    Antworten: 2
    Letzter Beitrag: 30.03.2011, 16:00
  5. Uart Receiver daten speichern und auswerten wie mach ich das
    Von malius im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 05.06.2005, 10:34

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •