[En-Nut-Discussion] usartavr driver problem/bug

[Matthias Ringwald]

hi

the current usartavr driver calls AvrUsartDisable before changing the 
usart configuration
in the ioctl setspeed, setdatabits, AvrUsartSetStopBits, 
AvrUsartSetClockMode or setparity call.

at least for me, this leads to a problem. the usart tx functionality is 
actually disabled
in the AvrUsartDisable call and by this the TX pins are configured as 
given in the DDR.
so if no special actions were taken, the tx pin will be an input pin. 
for a connected
serial devices this can mean random noise data on the line. especially 
our bluetooth module
is very sensible here, so I spent friday afternoon figuring out, why I 
get an error, if
I change the serial speed from 115200 to 115200 (which obviously 
shouldn't do any harm)

ok, options to fix this are:
a) blame the user that he didn't configure the TX pin as output
b) store the current settings of the TX pin (DDR & PORT), set TX as 
output, disable usart, change port,
enable usart again, restore DDR & PORT settings
c) always set TX output on opening of the usart driver
d) don't disable usart tx in AvrUsartDisable
e) don't disable usart at all

I would prefer d).. don't disable tx in AvrUsartDisable, as I don't see 
any
problems with letting tx functionality on while we don't write new data 
to it anyway.

hm.. looking a bit more, I wonder if the usart functionality is ever 
disabled.
I see that it is implicitly activated by the setspeed call. But the 
AvrUsartDisable
function is never called from an higher layer. What about disabling the 
usart
on usart:close() ?



matthias