[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