On Thu, Dec 9, 2010 at 1:40 PM, Stephen Dawson-Haggerty < [email protected]> wrote:
> +devel > > On Thu, Dec 9, 2010 at 12:23 PM, Janos Sallai > <[email protected]> wrote: > > We don't have to worry about platform specific word alignment > > peculiarities as long as we stick to nx_structs and nx_unions. The > > cc2420x stack I wrote using rfxlink works on the both the msp430 and > > the atmega128 with the same message_t definition. > > Yep, and the metadata is nx_ structs now since they're part of the > message_t. It is generally better to avoid these for structures not > actually sent over the radio since using them results in additional > code overhead... > Does the metadata really need to be nx_structs. I vagely remember playing with this at one point and thought it worked to mix and it generates much better code. Worth trying again. > > > Regarding Packet.clear(): would it make sense for the new message_t to > > have a dirty flag in message_t which wouldn't allow the message buffer > > to be reused without calling Packet.clear() first? Sure, checking it > > would have a runtime overhead, but we could just have a define to turn > > that off for production builds. > > Hmm, I don't know -- this seems likely to break existing code and also > will be confusing for new users. Maybe if we were starting over, but > it seems like one of those things in the "if it ain't broke, don't fix > it" at the moment... Not changing it when it was already zero like > Miklos proposes seems likely to fix the edge case now, which is that > when people turn on packet link, things work differently. Currently, > the message_t's are cleared by crt0, so as long as we leave it zero we > shouldn't break much. > > I'm fine with this simple patch. > > Steve >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
