[Tinyos-devel] parameterization of UartStream

Eric Decker cire831 at gmail.com
Mon May 5 12:34:22 PDT 2008


What is strange is the Resource and ResourceConfig are parameterized which
gives the impression
that the resource is arbritrated but UartStream and UartByte aren't.  But
not a big deal the fix
is pretty simple.  I coded up the parameterization of UartStream and
UartByte for the msp430.

Should I post them here for review or who should I send them to?

eric


On Mon, May 5, 2008 at 9:26 AM, Vlado Handziski <handzisk at tkn.tu-berlin.de>
wrote:

> Clients can also live with a non-parametrized functional interface
> (UartStream in this case) by making sure to ignore events if he they are not
> the current owner of the resource. But I agree that in this case, to
> minimize impact on existing client code, the best option would be to
> parametrize UartStream. This was probably not done in the first place by
> Jonathan because originally the serial stack was sitting on top of UartByte
> and Stream was added later, but before the parametrized SpiPacket.
>
> Vlado
>
> On Sat, May 3, 2008 at 3:46 PM, Kevin Klues <klueska at gmail.com> wrote:
>
>> I think this sounds right.  Any interface which signals events back
>> should be parameterized, while interfaces that only provide commands
>> don't necessarily have to be because these commands are only called
>> (presumably) by the current owner of the resource.  I assume this was
>> the same reasoning used for SpiPacket interface as it is parameterized
>> within an underlying Msp430SpiDma0P and then exported on a client by
>> client basis through the Msp430Spi0C component.
>>
>> I guess this never came up as an issue before because not that many
>> people use the UART interfaces on current platforms as they do the SPI
>> interfaces.
>>
>> Kevin
>>
>> On Sat, May 3, 2008 at 12:23 AM, Eric Decker <cire831 at gmail.com> wrote:
>> > I've run into a problem with how the uart is wired on the msp430.
>> >
>> > On the device we are building we have a serial multiplexer attached
>> outboard
>> > of UART1 on the msp430.
>> > This multiplexer switches between the serial line going to the PC and a
>> GPS
>> > unit.  Access to the UART
>> >  is controlled by a Resource Arbiter and works well.
>> >
>> > However, examining MSP430Uart1C revels that while Resource and
>> > ResourceConfigure are paramertized
>> > UartStream isn't.  Yet UartStream is what wires 3 events from the
>> interrupt
>> > system when tx and rx
>> >  events have occured.
>> >
>> > What I've observed is the GPS s/w will arbritrate for the UART and will
>> get
>> > the grant.  The GPS
>> > starts to send data and the interrupt system will hand the received byte
>> to
>> > the GPS code via the
>> >  event as it should.  The received byte will also be handed to
>> > HdlcTranslateC which has been
>> > wired in to UartStream via PlatformSerialC to handle packets being
>> received
>> > from the PC.  This
>> > is because of fan-out from the non-parameterized interface.
>> >
>> > I beleive the solution is to parameterize UartStream so the events are
>> > delivered to the proper
>> > owner of the interface.  I've coded up a fix for the MSP430 (my platform
>> and
>> > the telosb).  Should
>> > I post the diffs here?
>> >
>> > Thoughts?
>> >
>> > eric
>> > Eric B. Decker
>> > research associate
>> > Autonomous Systems Lab
>> > 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
>> >
>> >
>>
>>
>>
>> --
>> ~Kevin
>> _______________________________________________
>> 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/20080505/846778d9/attachment.htm 


More information about the Tinyos-devel mailing list