[En-Nut-Discussion] 9 bit uart thoughts

Harald Kipp harald.kipp at egnite.de
Tue Dec 9 22:10:15 CET 2003


Hi Brett,

Don't worry about delays, we all know there's another universe
beside Ethernuts. :-)


>1)  The first uses addressing and Im only interested in frames addressed 
>to me (the 9th bit is set and then I look for 15 possible values that Im 
>to read - ie. not a single byte value for the address.   In idle (normal) 
>states, the 9th bit is set on 2 out 4 bytes transmitted. (on average) - 
>ie. short conversations.

At least the address/data mode switching may not
harm you.


>2) The other usage requires me to scan every byte and address byte is key 
>as this allows me to decode/sniff the conversion of all devices on the 
>"network". In idle (normal) states, the 9th bit is set on 2 out 4 bytes 
>transmitted. (on average) - ie. short conversations.

Yes sniffing is an argument against the ioctl()
method I'm implementing.


>3) Finally, the third is a data only protocol using 9 bit transmissions 
>where the data values are readings from equipment and 9th bit is set 
>according to external intrument readings

That's nine-bit data transfer, which is definitely
not possible with ioctl(). But does anybody really
need this? If yes, isn't this an extremely special
case in a byte oriented world?

Anyway, the problem with ioctl() switching is, that
the information of the ninth bit got lost during
receive, unless you switch to address detection
mode. In other words, if receiving all data (MCPM
off), you don't know whether the ninth bit is on or
off.

I have to think about it again.

Harald







More information about the En-Nut-Discussion mailing list