| Re: SWCOM HWCOM Problem mit BUFFER Kategorie: Verschiedenes (von Andre Morgenstern - 16.02.2010 16:40) | ||
| Als Antwort auf Re: SWCOM HWCOM Problem mit BUFFER von Christian - 6.01.2010 16:16 | ||
| ||
|
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!. | ||
Antwort schreiben Antworten: | ||