[Tinyos-devel] Proposed UART Changes

[Trevor Pace]

Eric,

In this case enabled is referring to whether or not the MCU will be
listening on the receive line, or will start transmitting data when a byte
is loaded into the tx data register.

When it comes to interrupts no interrupt will get thrown if you disable
reception, same goes with any transmission-done interrupts. They won't even
get called when reception is enabled again because the MCU did not receive
and buffer the data.

As for what does this abstraction buy you, I would argue that it simply
provides more tools to users. Someone coming from regular C programming or
Assembly might be expecting the kind of control over the UART module that
they were used to. So for them to want to continue to use TinyOS they won't
want to dive in and start using HPL modules for very simply programs because
there is no way for them to quickly do half-duplexing.

Trevor Pace


On Thu, Jun 18, 2009 at 10:25 PM, Eric Decker <cire831 at gmail.com> wrote:

>
>
> On Thu, Jun 18, 2009 at 3:24 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>
>>
>> On Jun 17, 2009, at 12:56 PM, Trevor Pace wrote:
>>
>> > Hey Eric,
>> >
>> > The problem I am seeing right now is that I am developing a module
>> > which should in theory work on any mote that supports UART. However,
>> > there exists no hardware abstraction interface provided by all
>> > platforms that would allow me to disable/enable communication.  It
>> > does exist at the lower HPL but that is implemented per chip.
>> >
>> > So for me to shut-off my reception temporary I must wire a chip-
>> > specific HPL Uart module removing the possibility of compatibility
>> > with other chip sets. The Msp430HplUart you mentioned does support
>> > enabling/disabling for sure, unfortunately by the time it gets to
>> > the PlatformSerialC abstraction (which is available to all chipsets
>> > with UART) then I lose that ability.
>>
>> It seems we definitely want a UartControl or UartSettings interface.
>>
>> One constraint is that we want to catch bad settings at compile-time.
>> For example, trying to set the UART to a speed the MCU does not
>> support should be a compile-time error. The standard way to do this is
>> with enums: if you use an undefined enum you don't compile.
>>
>> How about something like
>>
>> interface UartControl {
>>   command error_t enableRx();
>>   command error_t disableRx();
>>   command bool rxEnabled();
>>
>>   command error_t enableTx();
>>   command error_t disableTx();
>>   command bool txEnabled();
>>
>
> Unfortunately this is ambiguos.   What does enabled mean?   The device can
> be turned on
> and capable of doing its function.  There is also the issue of interrupts
> being turned on
> or off.
>
> More detail is needed.  Another question is what does the abstraction buy
> us?
>
> eric
>
>
>>
>>   // TOS_UART_2400, TOS_UART_57600, etc.
>>   command error_t setSpeed(uart_speed_t spd);
>>   command uart_speed_t speed();
>>
>>   // TOS_PARITY_NONE, TOS_PARITY_EVEN, TOS_PARITY_ODD, etc.
>>   command error_t setParity(uart_parity_t par);
>>   command uart_parity_t parity();
>>
>>   command error_t setStop();
>>   command error_t setNoStop();
>>   command bool stopBits();
>> }
>>
>> Thoughts?
>>
>> Phil
>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
> UCSC
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090618/f594ebcd/attachment.htm