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

[Razvan Musaloiu-E.]

Hi!

On Sun, 31 May 2009, Vlado Handziski wrote:

> 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?
>

Sure. One more branch is not a big burden. :-)

--
Razvan ME

> 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
>>
>>
>