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 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!.
