[Tinyos-devel] Proposed UART Changes

[Eric Decker]

So does enableRX/enableTX enable interrupts?  Or does it simply set things
up for byte send/receive etc.

So is the intent something like:

call xxx.enableRX()
call UartByte.receive()

call xxx.enableTX()
call UartByte.send(uint8_t byte)

eric


On Thu, Jun 18, 2009 at 6:39 PM, Trevor Pace <trevorpace at gmail.com> wrote:

> 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
>>
>>
>


-- 
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/e0cbb7fe/attachment.htm