aus dem Puffer holen, bevor wieder neu gesendet/weitergeleitet wird.
RS232 ist eben asynchron, weshalb man meist Protokolle verwendet, um solche Fehler zu vermeiden.
> Ich wollte noch zusätzliche Daten hinzufügen.
>
> 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 Christian - 6.01.2010 16:16)Re: SWCOM HWCOM Problem mit BUFFER (von Andre Morgenstern - 16.02.2010 16:40)