OpenSerialPort() - Data: Bits or Bytes?

[#Ton]

Code: Alles auswählen

OpenSerialPort(#SerialPort, SerialPortName$, Baud, Paritaet, Data, Stop.f, HandshakeModus, EingabePufferGroesse, AusgabePufferGroesse)

In der PB-Hilfe steht, dass Data in (7 oder 8 ) bytes angegeben wird.

Bei Wikipedia und anderen Quellen steht, dass die Worte bzw. Symbole in (7 oder 8 ) bits codiert werden.

Schreibfehler in der PB-Hilfedatei?


Gruß
Toni

[mk-soft]

Etwas undeutliche geschrieben, aber richtig... 'in Byte'

'Data' definiert die Datenlänge, in Byte (üblicherweise 7 oder . 'Stop' legt die Anzahl an Stop-Bits (1, 1.5 oder 2) fest. 'HandshakeModus' kann einer der folgenden Werte sein:

Handelt sich um die Datenbits die in einem Byte abgelegt wird.

[#Ton]

Hm ok. Aber anscheinend kann einem das egal sein, da unabhängig davon welche Werte ich für 'Data' verwende ich immer die selben Daten empfange.

Hat man bei einer Rate von 115200 Bauds und 10 bits pro Zeichen (8 bit + startbit & stopbit) eine Übertragungsrate von 11520 Bytes pro Sekunde?
Oder muss man da noch weitere Dinge beachten?

[Daffy0815]

So "egal" ist das nicht ob 7 oder 8 Bit eingestellt sind!

Was genau hast Du denn vor?

Gruß

Daffy

[#Ton]

Ich sende Daten vom Computer über einen Bluetooth-Dongle an einen Roboter.

Die serielle Schnittstelle befindet sich zwischen dem BT-Dongle und dem Computer.
Die über den SerialPort gesendeten Daten werden dann automatisch vom BT-Dongle gesendet.

Die gesendeten Daten enthalten nur ASCII-Zeichen im Bereich von 0 bis 127.

Code: Alles auswählen

EnableExplicit


#Port        = #Null
#COM         = "COM3"
#Bauds       = 115200
#Parity      = #PB_SerialPort_MarkParity
#DataBits    = 7
#StopBits    = 1.5
#ControlMode = #PB_SerialPort_RtsCtsHandshake
#BufferSize  = 32


Procedure.i SendData(Port.i, Information.s)
  
  Protected.i CharLen   = Len(Information)
  Protected.i CharIndex = #Null
  Protected.i Char      = #Null
  
  
  
  For CharIndex = 0 To CharLen-1
    
    Char = Asc(Left(Right(Information, CharLen-CharIndex), 1))
    
    If Char < 0 Or Char > 127
      ProcedureReturn -1
    EndIf
    
  Next
  
  
  ProcedureReturn WriteSerialPortString(Port, Information, #PB_Ascii)
  
EndProcedure



OpenSerialPort(#Port, #COM, #Bauds, #Parity, #DataBits, #StopBits, #ControlMode, #BufferSize, #BufferSize)

SendData(#Port, "test123 blablaaa")

Delay(30000)

Egal welche Werte ich für #DataBits verwende, ich empfange immer exakt die gesendeten Daten.

[Daffy0815]

Wenn nur 7-Bit Nutzdaten übertragen werden dann ist das bei diesen Einstellungen tatsächlich egal.
Der UART-Baustein im PC wird dann zwar wahrscheinlich einen Frame-Error detektieren aber wenn der PC-Treiber diesen nicht auswertet wird nichts weter passieren.
Mit jedem neuen Startbit synchronisiert sich der Receiver dann sowieso wieder neu.

Gruß

Daffy

[#Ton]

Was genau ist ein Frame-Error?

Dann sollte aber bei der Data-Einstellung von 7 Bits keine internen Errors detektiert werden - man muss es ja nicht unnötig provozieren, oder?

[Daffy0815]

@#Ton

Wie der Name schon sagt, der "Rahmen" stimmt nicht.
Bei einem UART-Baustein wird die Empfangsleitung "RXD" mit einem vielfachen der Übertagungsrate abgetastet (z.B. 16-fach).
Stellst Du z .B. 8 Datenbits, 1 Stopbit, kein Paritätsbit ein so ist der Abtastrahmen die Summe von 1 Startbit, 8 Datenbits und 1 Stopbit = 10 Bits lang.
Sendet der Sender jetzt aber mit 7 Datenbits so ist der "Rahmen" kürzer so das zwar die 7 Bit Daten trotzdem ankommen aber der UART zeigt auf seinen internen Statusbits einen Rahmenfehler an.

Das Problem dabei ist, das es UART-Bausteine (nicht bei PC's) gibt die gar keinen Rahmenfehler detetektieren können und das ein Großteil der UART-Treiber von PC's grottig schlecht geschrieben sind.
Ich kenne den aktuellen Stand nicht aber vor etlichen Jahren gab es bereits über 50 Revisionen der Schnittstellentreiber alleine bei Microsoft.
Dies ist auch mit der Grund warum es so viele externe UART-Treiber für Microsoft-Betriebssysteme gibt.
Natürlich abgesehen von den Treibern die für spezielle UART-Hardware geschrieben sind (z. B. Oxford).

Der "UR-PC-UART" war mal der INS8250 von National Semiconductor der heute in keinem PC mehr zu finden ist aber vom Funktionsumfang den Mindeststandard
definiert. Ein UART der mehr den heute verbauten Chips entspricht wäre z. B. der TL16C752C von Texas Instruments.
Heutzutage sind derartige UART's aber meist in den I/O-Chips der PC's mit hineinintegriert und leider in den letzten Jahren von den Mainboardherstellern garnicht
mehr "herausgeführt".
Die PC-UART'S basieren übrigens allesamt auf dem Uralt-Design der 8080er Reihe von Intel und haben sich damals mit der Rest-PC-Hardware als so ziemlich die schlechtesten Bauteile dieser Art am Markt durch die Marktmacht von IBM "mit durchgesetzt".

Wenn Du mehr wissen willst dann "googele" mal die beiden Chipbezeichnungen und schau dir die Datenblätter an

Aber mal ganz prinzipiell. Stelle doch einfach die richtigen Parameter für beide Seiten ein dann bist Du immer auf der sicheren Seite.

Gruß

Daffy

[mk-soft]

Wenn die Datenbits nicht richtig einstellt werden kommt nur Müll zurück.

Der UART muss ja den Zeichenrahmen richtig interpretieren...

[Daffy0815]

@MK-Soft

Schön wärs!

Ich habe da schon die verrücktesten Sachen erlebt.

Selbst so "namhafte" Hersteller wie Texas sind bis Heute nicht in der Lage einen Uralt-Baustein fehlerfrei "nachzubauen".

Hier mal ein Beispiel für Dich:

http://www.ti.com/lit/er/sllz058a/sllz058a.pdf

Den Fehler mit den Stopbits habe ich seinerzeit gefunden und fast ein Jahr gebraucht bis die hochnäsigen Herren mir das geglaubt haben und es endlich in Form einer Errata-Sheet dokumentiert haben.
Ich bin damals bald verrückt geworden wegen der Übertragungsfehler die das bei höheren Baudraten auslöste.
Und so ein Schrott ist millionenfach verbaut worden (und wird noch immer verbaut)!

Gruß

Daffy