| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, OSOPT V3.1 |
> 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:
Re: SWCOM HWCOM Problem mit BUFFER (von Andre Morgenstern - 16.02.2010 16:40)