| Ich nutze: C-Control II Unit, OSOPT V3.1 |
Ich benutze die aktuelleste OS Version aus OSOPT_V3.1b1_64kConst.zip
mit sys0002.hex.
Auch die aktuellsten User und System Libraries.
Im gegebenen Beispiel hatte mit verschiedenen Puffergrö�en ausprobiert,
aber das Verschiebt das Problem nur auf Zeit.
Also je grö�er der Buffer umso später passiert es.
Ã?brigens: nach einem FLUSH sieht alles wieder OK aus, aber ich kann nicht eben FLUSH benutzen
in Kritische Anwendungen wo ständig Daten geschickt werden. Das wäre nur so ein Workaround für spezielle Fälle
aber eine Lösung ist das nicht.
Hier die Puffergrö�en zum Test.
speed 9600B.
byte pufferH[200];
hwcom.setbuf(pufferH,200);
byte pufferS[1024]; //Nur übertrieben damit der Fehler später auftritt, sonst puffer soll auch 200 sein
swcom.setbuf(pufferS, 1024);
Mit dieser Einstellungen und mit HyperTerminal am Laufen wie in der letzen Nachricht beschrieben:
Habe in Notepad bereit Datenblöcke vorbereitet
0000000nr
1111111nr
2222222nr
3333333nr
4444444nr
5555555nr
6666666nr
7777777nr
8888888nr
9999999nr
insgesamt 100 bytes.
ich sende dieses Block, über COM2, also wird von swcom empfangen und weiter geleitet an HWCOM und anschlie�end
sehe ich es auf dem Terminal von COM1.
Nach jedem Block sieht die Antwort am Hyperterminal so aus
00000000
11111111
22222222
33333333
44444444
55555555
66666666
77777777
88888888
99999999
ich mache eine Pause von Paar Sekunden und wiederhole der Versand.
So etwa nach dem 14. Versuch, sieht aber die antwort so aus:
00000000
11111111
22222222
33333333
44444444
55555555
66666666
77777777
88888888
9999999
hier fehlt schon das letzte Zeichen. Aber ok, das Zeichen ist nicht verloren gegangen, wird später geschickt sobald
die C-Control weitere Daten empfängt. So z.B. ich sende einfach das Zeichen "X".
Dann kommt nicht "X" raus, sondern zuerst die fehlende "9"
ich schicke weitere 2x "X", also "XX", und es sind noch keine X zu sehen auf COM1, sonder wie im letzten Muster schon
angebeben, es kommt "nr", also 13 und 10 Decimal vom letzten Datenblock.
ich schicke ein 4.tes "X", und dann endlich sehe ich ein X auf dem Bildschirm.
So, jetzt kann ich irgendetwas schicken, ich werde zuerst die alten "X" empfangen.
Sollte ich einfach weitere 100Byte Blöcke schicken, so werde ich feststellen, das nach ein Paar wiederholungen noch mehr fehlende
Zeichen festzustellen sind. Und es werden mehr und mehr,
Das Problem wie bereits erklärt, die Daten sind nicht verloren, C-Control aber denkt es gibt keine weiter Zeichen im
Puffer zum auslesen, sonst würde ja rxd() was positives liefern. Wenn das Verhalten so bleibt, wird aber irgendwann
der Puffer doch VOLL werden ohne das C-Control es merkt, und dann kann ich schon mit Datenverluste rechnen.
Ideen???? Soll ich die Puffergrö�e anders Wählen?? Ich werde inzwischen gleich einfach mit dem Standard Puffern testen und sehen
wie er sich verhält.
Antwort schreiben
Antworten:
Re: SWCOM HWCOM Problem mit BUFFER (von David M. - 2.09.2009 17:23)Re: SWCOM HWCOM Problem mit BUFFER (von Christian - 6.01.2010 16:16)Re: SWCOM HWCOM Problem mit BUFFER (von Andre Morgenstern - 16.02.2010 16:40)