[Tinyos-devel] Proposed UART Changes

Philip Levis pal at cs.stanford.edu
Thu Jun 18 17:40:15 PDT 2009


On Jun 18, 2009, at 3:50 PM, Trevor Pace wrote:

> Hey Phil,
>
> That's pretty much exactly what I was thinking. If there is  
> something common amongst all chip sets why not provide it to  
> developers to use?
>
> Most, if not all, of the chips currently have commands like these  
> defined in HPL so it would be very easy to simply wire them through.
>
> A question then would be whether it would be better to allow the  
> user to do something like:
>
> CFLAGS += -DPLATFORM_BAUDRATE=9600L

Except that it's not clear what that baudrate is for. A node can have  
multiple UARTs. A better way to do this would be on a chip basis  
(e.g., UART0_BAUDRATE, UART1_BAUDRATE), with defaults for a platform  
that can be overridden. Setting the default baudrate based on what  
sensor board is connected worries me: I'd rather see a sensor driver  
do it. The default approach above assumes the UART is not arbitrated.  
If the UART is arbitrated, then you have to do it at runtime, as below.

>
> or force them to call a command after Uart has started up:
>
> call StdControl.start();
> call setSpeed(TOS_UART_9600);
>
> I would argue that both be implemented because even though the MCU  
> might not explicitly support a baud of lets say 10100 someone still  
> might have a device that functions at that (albeit rare) baud rate.  
> So they might be willing to accept the error rate that might come  
> with that.

Eh. I am not that worried about such special cases: you would have to  
modify the serial driver to support a weird baud rate (since the HIL  
UART call won't have hardware-specific parameters in it) already, so  
a further change of adding such a parameter would not be a big deal.  
Let's not over-generalize. That being said, it's up to a chip  
developer to decide which baud rates they support.

Phil


More information about the Tinyos-devel mailing list