0x11 über RS232 verschluckt?!

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

Die Firmware auf dem Mega88.

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

> 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

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

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

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.

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.

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?