[c++] Probleme mit libserial und MM232R USB - Serial UART

[gunknown (Gast)]

Hallo,

ich möchte eine einfache USART Übertragung von einem uc an den PC über 
das MM232R (http://www.ftdichip.com/Products/EvaluationKits/MM232R.htm) 
durchführen.

Wenn ich das (linux) Programm gtkterm (serial port terminal) zum 
empfangen der zeichen verwende klappt alles einwandfrei. Sobald ich aber 
die libserial verwende empfange ich nur komische zeichen (die 
Einstellungen in gtkterm und der libserial stimmen überein). An einer 
fehlerhaften Baudrateneinstellung liegt das Problem nicht.

Sobald ich beim senden von dem uc ein delay von 1ms einbaue klappt auch 
das empfangen über die libserial.

Hat jemand eine Idee woran das liegen könnte?

Hier der code meines libserial clients:

#include <iostream>
#include <SerialStream.h>

using namespace LibSerial;
using namespace std;

int main()
{
  SerialStream mySerialStream;
  mySerialStream.Open("/dev/ttyUSB0");
  
  //setze parameter (8N1)
  mySerialStream.SetBaudRate(SerialStreamBuf::BAUD_57600);
  mySerialStream.SetCharSize(SerialStreamBuf::CHAR_SIZE_8);
  mySerialStream.SetNumOfStopBits(1);
  mySerialStream.SetParity(SerialStreamBuf::PARITY_NONE);

  mySerialStream >> std::noskipws;

//mySerialStream << 'o';

while(true)
{
  unsigned char a;
  mySerialStream >> a;

        cout << a << flush;
}

return 0;
}

[Karl H. (kbuchegg)]

gunknown schrieb:

> Wenn ich das (linux) Programm gtkterm (serial port terminal) zum
> empfangen der zeichen verwende klappt alles einwandfrei. Sobald ich aber
> die libserial verwende empfange ich nur komische zeichen (die
> Einstellungen in gtkterm und der libserial stimmen überein). An einer
> fehlerhaften Baudrateneinstellung liegt das Problem nicht.
>
> Sobald ich beim senden von dem uc ein delay von 1ms einbaue klappt auch
> das empfangen über die libserial.
>
> Hat jemand eine Idee woran das liegen könnte?

In welcher Reihenfolge aktivierst du die 'Programme'?

Eine RS232 - Übertragung hat das Problem, dass sich ein Empfänger nicht 
in eine bereits ständig laufende Übertragung einklinken und sich 100% 
zuverlässig auf das nächste Zeichen synchronisieren kann. Erst eine 
kurze Pause in der Datenübertragung ermöglicht dem Empfänger zuverlässig 
den Start des nächsten Zeichens zu erkennen.

Daher: Immer erst den Empfänger scharf schalten und erst dann den 
Sender. Oder aber im Sender in regelmässigen Abständen eine kurze Pause 
einlegen, damit ein in der Zwischenzeit hinzugekommener Empfänger eine 
Chance hat, das Startbit eindeutig zu erkennen.

Daher die Frage, in welcher Reihenfolge du die Übertragung 'scharf 
schaltest', denn deine Symptome erinnern stark an dieses Problem.
Auf der anderen Seite ist es so, dass man ein Terminalprogramm meistens 
ständig mitlaufen hat, während man am Sender arbeitet. D.h. in dem Fall 
hattest du das Problem nicht, weil der Empfänger schon lief ehe der 
Sender zu Senden anfing.

[gunknown (Gast)]

Du hast recht.

Wenn der uc wartet bis der "empfänger" ein zeichen sendet, also 
verbunden ist, und erst dann beginnt zu senden, dann klappt es auch mit 
der libserial.

Aber trotzdem bleibt die frage, warum gtkterm in der lage ist sich zu 
synchronisieren, die libserial aber nicht.
Bzw., ist das ein grundlegendes problem der libserial, oder lässt sich 
das evtl. durch irgendwelche einstellungen in der libserial 
"verbessern"?

[gunknown (Gast)]

Karl heinz Buchegger schrieb:
> Auf der anderen Seite ist es so, dass man ein Terminalprogramm meistens
> ständig mitlaufen hat, während man am Sender arbeitet. D.h. in dem Fall
> hattest du das Problem nicht, weil der Empfänger schon lief ehe der
> Sender zu Senden anfing.

Das ist hier nicht der Fall. Das Terminalprogramm ist in der lage sich 
zu synchronisieren, auch wenn das programm auf dem uc schon lange 
sendet.

[Karl H. (kbuchegg)]

gunknown schrieb:

> Das ist hier nicht der Fall. Das Terminalprogramm ist in der lage sich
> zu synchronisieren, auch wenn das programm auf dem uc schon lange
> sendet.

Das ist interessant, weil das Problem kein Softwareproblem sondern ein 
Hardwareproblem ist. Und beide Systeme werden ja wohl dieselbe Hardware 
benutzen. Hmmmmm