Für dieses Forum muß Javascript im Browser aktiviert werden!
Kommentar: Einfügen von HTML im Kommentar: Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a> Bild einfügen: <img src="BILDURL"> Text formatieren: <b>fetter Text</b> <i>kursiver Text</i> <u>unterstrichener Text</u> Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b> C2 Quellcode formatieren: <code>Quellcode</code> ASM Quellcode formatieren: <asm>Quellcode</asm> (Innerhalb eines Quellcodeabschnitts ist kein html möglich.) Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst ! > 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 > > 0000000\n\r > 1111111\n\r > 2222222\n\r > 3333333\n\r > 4444444\n\r > 5555555\n\r > 6666666\n\r > 7777777\n\r > 8888888\n\r > 9999999\n\r > > 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 "\n\r", 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. >
