Serielle Schnittstelle zu schnell?

Moin

Ich vermute mahl, das es an der ausgabe auf den Monitor liegt die 
braucht zu viel zeit.

Leg einfach mal einen grossen puffer an, und schieb die daten nur da 
rein.
Ausgabe dann danach machen.
Auserdem versuch so viel wie möglich an daten von der schnittstelle auf 
einmal einzulesen, nicht jedes byte einzeln.

ggf ein kleines Protokoll drum rum basteln z.B. mit Length info im 
Header.
bzw über flow control nachdenken / ein paktebasiertes protokoll 
überlegen

Sind die HW und Software FIFOS im treiber eingeschalten? ggf hat sind 
die deaktiviert bzw zu klein eingestellt.

Mein Vorschlag wäre auch: Bildschirmausgabe erstmal rauskicken und nur 
in die Datei schreiben.
Wenn auch das nicht klappt, erstmal in einen großen Puffer schreiben und 
dann in Datei und auf den Bildschirm.
Schreib doch dann bitte noch mal, wenn es klappt (oder halt auch nicht 
klappt ;-) )

Man sollte nicht darauf vergessen dass bei der Komunikation über RS232 
immer wieder einmal ein Bit "umfällt" und es daduchr zu 
Übertragungsfehlern kommt.

Wenn die Daten binär (0x00 bis 0xFF) übertragen werden, sollte man nicht 
darauf vergessen dass die meißten Terminalprogramme Probleme mit den 
Steuerzeichen haben.
Also entweder vor der Übertragung die Werte in Ascci Zahlen umwandeln 
oder einen Terminal verwenden der die Werte Binär verarbeiten kann.

>Man sollte nicht darauf vergessen ...

Was bedeutet dies?

Wie kommen die Daten in den PC? Bei den Baudraten vermute ich per 
USB-Wandler? Die haben im Bezug auf RS232 so ihre eigenen Macken ....

Wie lang ist das Kabel von uC zum Wandler? Um die 230kBaud habe ich noch 
hinbekommen, drüber wurde es eng. Das lag aber auch am verwendeten uC, 
der dann so langsam schlapp macht.

>>  dcb.fRtsControl = RTS_CONTROL_ENABLE;
>>
>>Und?
>>Kümmert sich dein µC auch darum, wenn ihm der PC per CTS signalisiert,
>>dass er mal kurz mit dem Senden aufhören soll?

Aha, nein tut er nicht ^^. Wurde auf DISABLE gesetzt.

Ich habe jetzt noch das "writefile" zeugs rausgenommen und den buffer 
enorm vergrößert.
Jetzt funktionert es erstmal bis 57600 Bauds, dankeschonmal für die 
Hilfe von allen. ich teste nochmal fix weiter.

Ich kenn das probem eher umgekehrt, das der PC bei kontinuierlichem 
Datenempfang irgend wann mal aussetzt. umgekehrt ist das ja kein 
problem, was stören 10 oder 100 ms pause zwischen 2 bytes? dafür gibts 
ja start und stop bits. und dazwüschen geht ja wohl nicht, da das ja ne 
HW macht.

14Byte Empfangspuffer bei Bautrate n gibt eine gewisse zeit, in der der 
PC was anderes machen darf, bis es zu einem Buffer overrun kommt. Und 
das ein PC mal 7,8 ms was anderes macht als gerade die Anwendung 
auszuführen, die mit der RS232 Arbeitet, das kann durch aus vorkommen.

Wobei es gibt noch ein paar andere Besonderheiten bei der RS232 
Implementierung vom M$
Das warten auf Send buffer empty funktioniert nicht richtig. Meine 
vermutung, es wird der HW sende puffer nicht berücksichtigt. wenn die 
letzten Bytes an den HW puffer übergen wurden wird der Event ausgelöst.

Folge, umschalten der Baudrate nach einem Filewrite und wait for Buffer 
empty führt dazu, das ggf das letzte byte / die letzten byts in der 
neuen bautrate gesendet werden die danach gesetzt wird. ggf wird sogar 
mitten im byte die baudrate umgeschalten. bzw wenn die nachricht kurz 
genug ist die ganze nachricht mit der neuen bautrate gesendet.


Es gibt unterschiede im zeitlichen verhalten bei den OnBoard 
Schnittstellen, je nach dem ob PCI-ISA Bridge oder Legecy anbindung