[Tinyos-devel] Proposed UART Changes

Eric Decker cire831 at gmail.com
Wed Jun 17 17:03:21 PDT 2009


Can we create an abstraction to do this.  It would have to some how denote
what port it is talking about.So I think the answer is no and hence it lives
at the Hpl/Chip level.

eric


On Wed, Jun 17, 2009 at 12:56 PM, 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
>
>


-- 
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/20090617/6fae9159/attachment.htm 


More information about the Tinyos-devel mailing list