[Tinyos-devel] message_t: starting to tease AM away from Serial and Radio

[Vlado Handziski]

Hi Eric,

this sounds great. Having a real prototype code will help considerably in
pushing this towards a reasonable conclusion. The set of assumptions seems
like a conservative combination of the encap/decap ideas of both Jan/Miklos
proposlas and the more static approach that Martin proposed.

Until we sort the version control system migration issue, I would be
reluctant to handle this via a branch in the CVS tree for now. How about
creating a git branch that we can pull, maybe hosting it at
http://hinrg.cs.jhu.edu/git/ if John does not have anything against?


Vlado


On Sat, May 30, 2009 at 23:58, Eric Decker <cire831 at gmail.com> wrote:

> I'm starting coding to tease the AM code away from the Serial and Radio
> stacks to make AM encapsulation more independent from the h/w encapsulation.
> The intent is to support the AM encapsulation while moving in the direction
> of Jan's and Miklos' suggestions.  I need something like this because I'm
> doing dynamic switching of queued packets.  Also I want to understand better
> the impact on packetAck and other pinch points with respect to what we are
> discussing with regards to encapsulations and the packet buffers.
>
> I'm using the following principals/goals:
>
> 1) Packet formats don't change.  The resultant code will be completely
> compatible with existing motes with respect to the wire/transmission.
> 2) Additional control cells are added to the message structure, (encap,
> encap_offset (where the current encapsulation starts), length, etc.)
> 3) One principal is given a packet one should be able to unwrap the packet
> just by looking at data in the current header.
> 4) Header information still resides in the header section of the message
> buffer.
> 5) Application data resides in the current data area.  encap_offset points
> at what should currently be considered data for the component that is
> currently working on the packet.  When the packet gets to the application
> layer, encap_offset will point at the data for the application.
> 6) All packet data is maintained contiguously, there is no wrap around.
>  1st structures have to be contiguous.  Splitting data fields including
> application data is problematic and needs to be avoided.
>
>  One thing I'm added first off is a newPacket module that is used to
> access the packet/message control cells.  It will provide all the usual
> Packet interfaces, any new ones will be added to a new interface spec called
> oddly enough newPacket.
>
> This is a prototype to explore some of what we are talking about and to
> gain better understanding of how changes propagate.
>
> I could use some folks looking over my shoulder and commenting on code,
> better ways to do things, etc.  Especially on better ways to do things,
> where to put things, naming etc.
>
> Thoughts,
>
> eric
>
> --
> 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/20090531/50a46db8/attachment.htm