[En-Nut-Discussion] USART DEFAULT COOKEDMODE

[Harald Kipp]

Matthias,

yeah, I can imagine that these kind of problems are
quite bothersome.

But setting binary mode by default would break the
standard behavior, IMHO. Most systems require to
explicitly set the binary flag to switch of cooking:

   _open(name, _O_RDWR | _O_BINARY)

or

   fopen(name, "r+b")

Also note, that there is no such thing like

   fopen(name, "r+c")

for explicitly switch on cooking.

Harald


At 12:05 28.05.2004 +0200, you wrote:
>Hi there.
>
>We just spend several days hunting for a bug in our communication to the 
>bluetooth which is
>done over the usart driver of the atmega128.
>
>Problem was, that the driver was set to COOKED_MODE per default, which 
>means that he just adds some
>\r to every \n you send. Sure, for a terminal that's nice, but our 
>bt-module really didn't appreciate it.
>
>Proposal:
>- Put a BIG WANRING sticker into the description of the usart driver OR
>- Let's set the default mode to RAW (I would argue that most people using 
>an UART driver on an embedded
>system would find quite naturally)
>
>I do understand, that it was set to COOKED_MODE because that's standard on 
>linux.
>But in my opinion, it already sucks on linux and could be different in 
>nut/os ?
>
>(Polemic: Did you ever try writing some bytes to a serial port, and did 
>copy & paste almost
>one page of c code just configure the port.. ? if not you may also have a 
>look into dev/unix_devs.c
>where I try hard to tell unix just to be RAW. so this BUG also didn't 
>occur in the unix emulation)
>
>yours truly,
>matthias
>
>_______________________________________________
>En-Nut-Discussion mailing list
>En-Nut-Discussion at egnite.de
>http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion