[Tinyos-devel] parameterization of UartStream

Vlado Handziski handzisk at tkn.tu-berlin.de
Mon May 5 09:26:34 PDT 2008


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


More information about the Tinyos-devel mailing list