Hi Nico, I just now realised that I posted this to the wrong mailing list... Sorry, probably much of the TinyOS lingo may not have made sense :-)
On 8/11/05, N. Coesel <[email protected]> wrote: > At 19:04 11-08-05 +0000, you wrote: > >Hello everybody: > > > >I am seeking advice about the best practices to design message > >structures for MSP430-based systems. (...) > >My conclusion from what I have seen so far is that all protocol layers > >should strive to declare even-sized headers, so that their payload > >fields are word-aligned... Insights from whoever "been there done > >that" are very much appreciated. > > I would go for a text based message format. Saves the hassle of writing > test tools. Besides that, text based formats can easely be extended. A > binary format is fixed and extending it usually means saying bye bye to > backward compatibility. Yes, but with the constraints of these wireless sensors platforms I think text based formats have too much overhead... For instance, the system (clock+radio) we are working with limits us to packets up to 32 bytes (sic!). Also bigger packets require more radio time, which costs precious energy, so to a reasonable extent we try to squeeze as much information per bit as possible. > If you really need to transfer binary information, you could transmit this > using bytes and rebuild the message from it instead of mapping a struct > over the input/output buffer. This would make the implementation platform > independant: > > uint16_t r; > r=inbuf[0] | inbuf[1]<<8; Now this seems an interesting idea to generalize marshaling/unmarshaling application data structures into/from byte streams. But it requires an extra copy to map the payload into the struct and vice-versa... -- /dima
