| Ich nutze: C-Control II Unit, eigenes Board, OSOPT V3.0 |
ich kämpfe schon recht lange mit einem Problem und bin hier im Forum auf ein paar Dinge gesto�en,
wobei ich nicht sicher bin, ob es für mich die Lösung ist.
Das Problem tritt auf, bei schnellem Senden über die hwcom.
Ich nutze hwcom zur Kommunikation mit dem PC. CC2 und PC verständigen sich über ESC
Sequenzen. Die Befehle sehen dann so aus: ESC Befehlsnummer Parameter-1 ... Parameter-n
wobei die Parameteranzahl bei einem Befehl immer gleich ist.
Z.B. sendet der PC: ESC 3 0 0 1 um die CC2 zu veranlassen, den ersten Port des PCF8574 auf high
zu setzen.
Jetzt habe ich den Fall, dass ich drei Doppel-LED vom PC aus über die CC2 schalten oder gar
blinken lassen möchte. Hintergrind (falls interessant): DIe drei LED sind in einem Licht-Taster
eingebau und zeigen mir den aktuellen Status verschiedener Licht-Bereiche und BM im Garten
an. Somit schalte ich mittels Taster 8 (sinnvolle) verschiedene Stati durch. Wenn in einem Bereich
ein Bewegungsmelder anspricht, so soll die LED entsprechend blinken.
Im schlimmsten Fall Sende ich 6*den o.g. Befehl um die LED(s) blinken zu lassen. Der Takt ist z.B.
1/2 s.
Das Problem:
****************
Wenn das ein paar mal passiert, so kommt es schon mal vor, dass die CC2 einfach nicht das letzte
Byte einlesen will, d.h. wait hwcom.rxd(); reagiert nicht.
Wird allerdings der nächste Befehl gesendet, so wird erst das letzte (vergessene) Byte eingelesen,
auf das die CC2 noch vom vorherigen Befehl her wartet und dann der Befehl ausgeführt.
Allerdings fehlt nun das letzte Byte des letzten Befehls usw.
Lösung?
**********
Im Forum bin ich auf die Funktion IncInbuffercnt() gesto�en, die den Empfangspuffer erhöht, so dass
auch wieder rxd() reagiert. Dies setzt allerdings ein gesichertes Protokoll voraus, d.h. mehr als meine
ESC Befehle :)
Diesen Befehl einzuführen würde für mich einiges an �nderungen kosten, so dass ich erst
Gewissheit haben möchet.
Die Foreneinträge verstehe ich so, dass das letzte Byte bei grö�eren Datenübertragungen
zwischendurch mal auftreten kann. Bei mir ist es allerdings so, dass wenn der Fehler einmal da ist,
dann hilft nur ein Resetz der CC2.
Wenn der Empfangsbuffer allerdings rotierend gefüllt wird, so könnte ich meinen Effekt nachvollziehen.
Wird dann IncInbuffercnt() aufgerufen, so würden danach alle Befehle wieder richtig verarbeitet.
Ist IncInbuffercnt() die Lösung für mein Problem?
Wenn dies so ist, dann ist da ja immer noch das Problem, dass man den Buffer nicht erhöhen darf,
wenn gleichzeitig auch etwas empfangen wird. Das wird dann bei Befehlen ohne Feedback an den
PC, wie ich sie derzeit verwende nicht möglich sein, da die Befehle einfach hintereinander in den
Buffer geblasen werden. Hier würde mir dann OS3.1 helfen.
Wann wird OS3.1 fertig sein? Andrè hat ja echt Land unter, da verstehe ich, dass es ggf.
noch etwas dauert.
Wenn IncInbuffercnt() tatsächlich die Lösung ist, dann kann ich endlich aufhören, den Fehler und die
Ursache zu suchen *Jippi*, daher Dank für alle Feedbacks
Klaus
Antwort schreiben
Antworten:
Re: hwcom Fehle im OS3.0 - IncInbuffercnt (von Detlef Bäthke - 28.06.2005 12:48)Re: hwcom Fehle im OS3.0 - IncInbuffercnt (von Klaus - 28.06.2005 21:46)