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 hab leider keine Hilfe für dich, aber ich hab das selbe Problem. Exakt wie du beschreibst. > Es funktioniert super, bis zu einem bestimmten Punkt der nicht immer gleich ist. > > Allerdings kann ich bei mir mit flush() arbeiten. > Ich empfange erst nach Anforderung einen neuen Datenblock ->Protokoll!!! > > Ich hab nicht weiter experimentiert... > > Falls jemand eine Lösung hat, ich wäre auch dankbar. > > > > Ich würde mit inbuffercount() prüfen, ob noch "verschluckte" Zeichen im Puffer sind und die ggf. > > > aus dem Puffer holen, bevor wieder neu gesendet/weitergeleitet wird. > > > RS232 ist eben asynchron, weshalb man meist Protokolle verwendet, um solche Fehler zu vermeiden. > > > > > > > > > > Sehr mysteriös. Inbuffercount() zeigt mir 0 obwohl ich weiß, dass Zeichen in buffer versteckt sind. > > Also in Prinzip inbuffercount() sag mir das gleiche wie rxd(), denn in diesem Punkt zeigt mir rxd() auch 0 > > obwohl etwas drin ist. > > > > Was war meine nächste überlegung. Da ich weiß, dass ein Zeichen in puffer versteckt ist, dann hole > > ich es mir raus mit get() und fertig!. > > > > FALSCH!. und das ist das erstaunliche an die Sache. > > > > get() liefert auch wieder 0x00, also das typische Verhalten, wenn der Puffer in wirklichkeit leer wäre. > > > > Aber ich weiß, dass mein Zeichen noch im System versteckt ist. > > > > Ich versuche nochmal, ich sende noch ein Zeichen und statt, dass ich dieses zurückbekomme, > > dann erhalte ich gerade mein verlorenes Zeichen wieder!, aber jetzt ist die zuletzt gesendete Zeichen > > auch weg, denn hole ich mir später raus. > > > > Weiß jemand ob es noch ein anderer Puffer im Controller ist, wo mein Zeichen steht?. > > > > Hier nochmal das Problem ander dargestellt. > > > > Stellt euch vor dieses System. > > > > [ PC1 ----- RS232 ---- SWCOM --- CC2 --- HWCOM --- RS232 --- PC2 ] > > Das einfachste Beispiel. Die CC2 sei einfach eine Brücke zwischen 2 PCs. Alles was von PC1 an CC2 > > geschickt wird, wird automatisch an PC2 weitergeleitet und umgekehrt. Das ist die beste Art um das > > Problem zu reproduzieren. > > > > thread testcom > > { > > loop > > { > > while(swcom.rxd()) > > hwcom.put(swcom.get()); > > while(hwcom.rxd()) > > swcom.put(hwcom.get()); > > yield; > > } > > } > > würde das System implementieren. > > oder auch das: > > > > thread serialIN > > { > > loop > > { > > while(swcom.rxd()) > > hwcom.put(swcom.get()); > > yield; > > > > } > > } > > > > thread serialOUT > > { > > loop > > { > > while(hwcom.rxd()) > > swcom.put(hwcom.get()); > > yield; > > > > } > > } > > egal ob nur 1 Thread oder 2 parallel das System beschreiben, komme ich zum gleichen Ergebnis: > > > > es geht um RS232 Speed: 9600, keine Parität, 8,1, Standard. > > > > Egal ob ich den Standard Buffer oder meinen eigenen definiere für HWCOM, da gibt es kein Problem. > > D.h. Alles was PC2 an hwcom sendet, wird problemlos an PC1 weitergeleitet über SWCOM. Also hier > > sieht der Eingangspuffer von HWCOM super gut zu funktionieren. > > > > Von der andere Seite ist nicht so gut. Alles was von PC1 an PC2 geschickt wird, kommt an anfang gut an. > > Aber ab einem bestimmten Punkt, der irgendwie abhängig von Buffergröße scheint, dann geht ein Zeichen > > verloren. Egal ob ich einen super großen Puffer definiere oder den standard für SWCOM. > > > > Sagen wir so. > > Am anfang sende ich 200 Zeichen von PC1 zu PC2.. alle kommen gut an und sofort. > > und plötzlich, sagen wir ab Zeichen 250 z.B. > > dann gibt es ein Phänomen wie ein Schieberegister inzwischen. > > > > Ich sende ein Zeichen A, der kommt aber nicht an. > > ich sende jetzt Zeichen B, und jetzt auf einmal kommt das Zeichen A raus!, > > das Zeichen B ist aber nirgendswo zu sehen. > > schicke ich jetzt einen C-Zeichen, dann bekomme ich aber B raus! , usw..... > > > > Mache ich hier weiter.... irgendwann nach etwa wieder 250 z.B. dann sind jetzt 2 Zeichen die > > verspätet in irgend puffer bleiben. > > > > also, d.h. Sende ich HALLO , es kommt aber nur HAL an. > > ich sende jetzt einfach 2 mal leer Zeichen, und es kommt das fehlende "LO" an. Die Leerzeichen sind > > irgendwo gespeichert. > > > > Und hier nochmal. Obwohl ich weis, dass 2 Zeichen noch drin sind, die ich sicher bekommen werde wenn > > ich noch etwas schicke, trotzdem gibt mir CC2 folgende Infos: mit swcom.get() bekomme ich nur 0x00 > > als ob der puffer leer ist. > > swcom.inbuffercnt() liefert ebenfalls 0 zurück. > > > > Weiß jemand, wie das Problem gelöst werden kann? > > > > flush zählt nicht, da Zeichen dabei verloren gehen, obwohl das System wieder stabil startet. > > Manchmal muss ich auf eine Antwort warten die länger ist die genannten 250 Bytes.... > > > > apropo, hier ist 250 nur ein Beispiel, ich habe manchmal mit 1000 oder 5000 ausprobiert. Es scheint alles > > doch irgendwie abhängig von Puffergröße zu sein, aber bis jetzt unvermeidbar. > > > > Hilfe!.
