[Tinyos-devel] Parameterization of UartStream interface in UART abstraction on all platforms?

[Eric Decker]

I've been here before in previous lives (industry, cisco, HP).
If it done now the problem is the changes to the Atm code, possible
destabilization,
and required regression testing needed to verify the new code changes.  The
benefit
is the consistency of the structure which promotes understanding how things
work
and what one is supposed to do to get correct arbritration and function.

If the changes aren't done to the Atm code the cost is how will the Atm code
change
in the future when the need for more shared components.

My gut feel is leave the Atm code changes for later.  Possibly put a
gravestone (marker)
in that refers to the msp430 code and how to do it.  A TEP might be in order
too.  I'll help
write it if desired.

eric


On Wed, May 21, 2008 at 3:36 PM, Kevin Klues <klueska at gmail.com> wrote:

> So I started looking at the Atm128Uart stuff and noticed that it is
> not enabled for Resource arbitration at all.  The changes to the
> Msp430Uart components were rather straight forward since an arbiter
> was already used to arbitrate across the UartByte interrace, and all
> that was needed for UartStream was to parameterize it and wire in the
> correct client id in order to enforce arbitration.
>
> It would be somewhat straightforward to introduce Resource arbitration
> to the Atm128Uart component, but this raises issues for the users of
> this component since they are implemented with the assumption that
> there is no arbitration and for that matter currently don't wire in a
> Resource interface to take control of the uart.  The primary place
> where I noticed this will cause issues is in the PlatformSerialC for
> any atm128x based platforms.  In order to operate they will
> (minimally) need to now have a PlatfromSerialP component (similar to
> how telos does it) and perform an immediateRequest on the Resource.
>
> My question is whether it is worth it to make these changes now or
> wait until after the release.  The changes would require testing on
> all atm128x platforms and changing the semantics of any components in
> tinyos that use the Atm128Uart0C component.
>
> Kevin
>
> On Thu, May 15, 2008 at 7:56 AM, Vlado Handziski
> <handzisk at tkn.tu-berlin.de> wrote:
> > As discussed in the thread here started by Eric Decker, parametrization
> of
> > the UartStream interfaces exported from the UART abstraction can simplify
> > the event handling logic in the user components. Eric has sent patches to
> > this end for the msp430 which Kevin will test and incorporate in the
> tree,
> > as agreed at the teleconference yesterday.
> >
> > I am not sure who is currently maintaining the UART components for the
> > atm128 but the current implementation does not support multiple users
> > through arbitration. Although this is not currently needed, we never know
> > when a platform might come that needs this functionality, as in Eric's
> case
> > for the msp430. In principle all HIL level abstractions should by default
> > support arbitrated operation, and buses in particular. So maybe this is a
> > good opportunity to line up the abstractions on the different
> > microcontrollers?
> >
> > Vlado
> >
> >
> >
> > _______________________________________________
> > 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
>



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