0x11 über RS232 verschluckt?!

[lutscher (Gast)]

Ich betreibe eine RS232-Verbindung zwischen einem Mega88 und einem PC.
Einstellungen: Baudrate 9600, 8Bit und Even Parity.

Jetzt kommt der Gag: Jedesmal wenn ich das Byte 0x11 in den 
Ausgangspuffer packe, wird es verschluckt, es kommt nie an. Alle anderen 
möglichen Bytes hingegen kommen einwandfrei beim PC an.

Frage: Was könnte dafür die Ursache sein?

Danke

[edson (Gast)]

lutscher schrieb:
> Frage: Was könnte dafür die Ursache sein?

Die Firmware auf dem Mega88.

[Marius W. (mw1987)]

Hast du in deinem Empfänger die Flusssteuerung deaktiviert? 0x11 ist 
nämlich Xon, das könnte der Empfänger einfach verschlucken...

MfG
Marius

[ingo (Gast)]

Im ASCII dient 0x11 auch als Steuerzeichen XON:
http://de.wikipedia.org/wiki/XON#Software-Flusssteuerung.2C_Software-Handshake.2C_Software-Protokoll_oder_X-ON.2FX-OFF
wenn im seriellen Treiber die SW-Flusskontrolle aktiv ist, dient dieses 
Zeichen, um dem PC zu siganalisieren, das das andere Gerät daten 
empfangen kann.
mfG ingo

[Karl H. (kbuchegg)]

Das du am PC Software Handshake aktiviert hast.

0x11   <==>  ^Q   <==>   XON

(0x13 müsste auch verschluckt werden, das ist das Gegenstück zu XON)

[lutscher (Gast)]

> Die Firmware auf dem Mega88.

auf die antwort habe ich gewartet. manchmal dürfen hochnäsigen 
vollchecker hier auch davon ausgehen, dass der gegenüber nicht 100% 
bescheuert ist, und einiges bereits selber ausgeschlossen hat. der eine 
oder andere will halt nur mal wissen, ob jemand schon ähnliche phänomene 
beobachtet hat, oder eine erklärung auf physikalischer ebene kennt.

reicht dir das?


_RS232_SendByte:
  lds r16, UCSR0A
  sbrs r16, UDRE0
  rjmp _RS232_SendByte

  sts UDR0, r17

  ret

[lutscher (Gast)]

vielen dank an die anderen, das wird es sein. :)

[Simon K. (simon)]

lutscher schrieb:
>> Die Firmware auf dem Mega88.
>
> auf die antwort habe ich gewartet. manchmal dürfen hochnäsigen
> vollchecker hier auch davon ausgehen, dass der gegenüber nicht 100%
> bescheuert ist

Nö, davon darf man nie ausgehen. Und du hast auch keinen Hinweis darauf 
gegeben, was du schon ausprobiert hast.

100% dein eigenes Verschulden.

[lutscher (Gast)]

>Nö, davon darf man nie ausgehen. Und du hast auch keinen Hinweis darauf
>gegeben, was du schon ausprobiert hast.
>
>100% dein eigenes Verschulden.

komischerweise konnten 3 leute unkompliziert helfen. wie gesagt, nochmal 
vielen dank an diejenigen. :) ich wäre nie darauf gekommen...

der rest kann sich weiter sich selbst und seiner überlegenheit widmen.

[edson (Gast)]

lutscher schrieb:
> manchmal dürfen hochnäsigen
> vollchecker hier auch davon ausgehen, dass der gegenüber nicht 100%
> bescheuert ist

Ok, was ist damit:

Karl Heinz Buchegger schrieb:
> 0x13 müsste auch verschluckt werden, das ist das Gegenstück zu XON

wenn man davon ausgeht, dass diese Aussage:

lutscher schrieb:
> Alle anderen
> möglichen Bytes hingegen kommen einwandfrei beim PC an.

nicht nur so dahin geschrieben war, sondern du wirklich

lutscher schrieb:
> einiges bereits selber ausgeschlossen

hast?

Alle möglichen "anderen Bytes" bedeutet alle Werte von 0x00 bis 0xFF 
ausschließlich 0x11. Was ist mit 0x13? Hätte ja auch verschluckt werden 
müssen.

[lutscher (Gast)]

edson schrieb:
> lutscher schrieb:
>> manchmal dürfen hochnäsigen
>> vollchecker hier auch davon ausgehen, dass der gegenüber nicht 100%
>> bescheuert ist
>
> Ok, was ist damit:
>
> Karl Heinz Buchegger schrieb:
>> 0x13 müsste auch verschluckt werden, das ist das Gegenstück zu XON
>
> wenn man davon ausgeht, dass diese Aussage:
>
> lutscher schrieb:
>> Alle anderen
>> möglichen Bytes hingegen kommen einwandfrei beim PC an.
>
> nicht nur so dahin geschrieben war, sondern du wirklich
>
> lutscher schrieb:
>> einiges bereits selber ausgeschlossen
>
> hast?
>
> Alle möglichen "anderen Bytes" bedeutet alle Werte von 0x00 bis 0xFF
> ausschließlich 0x11. Was ist mit 0x13? Hätte ja auch verschluckt werden
> müssen.

klugscheißer....
nein, 0x13 es wurde nicht verschluckt (ich habe alle getestet, sonst 
hätte ich die aussage nicht getroffen!), und zwar weil sich die 
flusssteuerung separat (Xon/Xoff) ein-/ausschalten lässt.

zum fehler: in meinem C-projekt auf dem PC habe ich an CreateFile keine 
festen werte für die software-flussteuerung gesetzt. er scheint dann 
etwas voreingestelltes bzw. aus der letzten kofiguration zu nehmen, 
deshalb ging es wohl vorher auch nur zufällig.

[edson (Gast)]

lutscher schrieb:
> klugscheißer....
> nein, 0x13 es wurde nicht verschluckt (ich habe alle getestet, sonst
> hätte ich die aussage nicht getroffen!), und zwar weil sich die
> flusssteuerung separat (Xon/Xoff) ein-/ausschalten lässt.

Sag mal, merkst du eigentlich nicht, dass DU hier permanent mit 
Ausdrücken um dich wirfst?

[Simon K. (simon)]

edson schrieb:
> lutscher schrieb:
>> klugscheißer....
>> nein, 0x13 es wurde nicht verschluckt (ich habe alle getestet, sonst
>> hätte ich die aussage nicht getroffen!), und zwar weil sich die
>> flusssteuerung separat (Xon/Xoff) ein-/ausschalten lässt.
>
> Sag mal, merkst du eigentlich nicht, dass DU hier permanent mit
> Ausdrücken um dich wirfst?

Vor allem: Woher sollen wir denn wissen, dass du direkt über die WINAPI 
arbeitest und nicht mit einem Terminalprogramm...