[Tinyos-devel] Proposed UART Changes

[Vlado Handziski]

Hi Trevor,

the msp430 platforms have HAL interfaces like the Msp430UartConfigure,
Msp430SpiConfigure that allow the client to reconfigure the serial HW when
they are granted access to the shared resource. Take a look at the
msp430_uart_config_t, there are two bits there that control if the TX or the
RX modules are enabled.

The PlatformSerialC currently supports only platform independent data path
interfaces but not control and all applications that need to reconfigure the
HW have to tap to the HAL  and use the interfaces exported there. Note that
according to the HAA, the HAL is a public API just as the HIL, but as you
point out the resulting code will be chip/platform specific.

So at the moment I propose that you factor your code in a platform
independent part and a small platform specific part that will tap to the
different HALs. The core WG did discuss if we would like to have a HIL
control interface for the UART. For the msp430 platforms at least, the
current setup has proved flexible enough to handle the existing use cases so
this was not further pursued. We can definitely revisit this, but I would
argue that the need to control the TX/RX interrupt and the module is a low
level issue that is better left to the platform-specific APIs.

Vlado


On Wed, Jun 17, 2009 at 21:56, Trevor Pace <trevorpace at gmail.com> 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.
>
> Trevor Pace
>
>
>
> On Wed, Jun 17, 2009 at 3:51 PM, Eric Decker <cire831 at gmail.com> wrote:
>
>> Hi Trevor,
>> I watch this list also but do not speak for the core group.
>>
>> That said.  What you've proposed below closely mirrors similar interfaces
>> that have been implemented for the MSP430 based platforms.
>>
>> Take a look at tos/chips/msp430/usart/HplMsp430Usart1P.nc
>>
>> there is enableTxInt and enableRxInt and friends.
>>
>> eric
>>
>>
>> On Wed, Jun 17, 2009 at 9:10 AM, Trevor Pace <trevorpace at gmail.com>wrote:
>>
>>> I am currently working as a research assistant for Dalhousie University
>>> and I have been given the task of interfacing a Glucose Meter with a
>>> Crossbow Iris mote. I have written private modules that request and process
>>> data using the UART0 module on the Iris Atmega128 processor. However, I ran
>>> into a few issues with UART and TinyOS.
>>>
>>> FIRST:
>>>
>>> The Glucose Meter communicates at 9600 baud however the default baud rate
>>> for the iris mote is defined in /platforms/micaz/hardware.h as such:
>>>
>>> enum {
>>>   PLATFORM_BAUDRATE = 57600L
>>> };
>>>
>>> This means that in order for me to use a different baud rate I must
>>> change that to 9600L, which is not good. My proposed solution to this (that
>>> I am currently using) is to use pre-compiler defines:
>>>
>>> #ifndef PLATFORM_BAUDRATE
>>> #define PLATFORM_BAUDRATE 57600L
>>> #endif
>>>
>>> That allows me to just add to my makefile:
>>>
>>> CFLAGS += -DPLATFORM_BAUDRATE=9600
>>>
>>> And sure enough it works for that program only, as it should.
>>>
>>> SECOND:
>>>
>>> The way the glucose meter is setup it is only possible to do Half-duplex
>>> communication, and whatever I transmit using UartByte.send() will be
>>> received; throwing the event UartStream.receivedByte(). This means that I
>>> must disable reception for the UART module (not just interrupts because the
>>> module will still be buffering the received data). However, there exists no
>>> command to disable/enable either the receive or transmit modules at the
>>> PlatformSerialC abstraction (which provides common interfaces to all types
>>> of motes supporting UART communication).
>>>
>>> My solution for this was to write a function to disable reception and
>>> then send a byte, though this only will work for ATM128 processors:
>>>
>>> CLR_BIT(UCSR0B, 4);
>>> call UartByte.send(byte);
>>> SET_BIT(UCSR0B, 4);
>>>
>>> My proposed solution for this is to create a new interface called
>>> UartControl which provides at least the following commands:
>>>
>>> command void disableRx();
>>> command void enableRx();
>>> command void disableTx();
>>> command void enableTx();
>>>
>>> They could of course return errors if need be. This interfaces would be
>>> provided from the HPL abstraction to the PlatformSerialC module which would
>>> then pass it on. Thus providing the ability to disable/enable reception or
>>> transmission of the UART module.
>>>
>>> I am just wondering whether this is an area you feel that TinyOS should
>>> move towards. Surely there are other devices which may want to communicate
>>> using serial communication so these ideas won't apply to just my own
>>> situation. If you feel that this is something you would like to see I would
>>> be more than willing to write the code to implement this.
>>>
>>> Trevor Pace
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090617/3d234ee3/attachment-0001.htm