On Mar 31, 2006, at 1:41 PM, Joe Polastre wrote:
Network types are your friend. :)
Except for the fact that they add over 2k of program space to my
applications. Sigh. Any chance network types are going to become
somewhat more efficient in the future?
Efficient in CPU cycles, RAM usage, or code size? There are tradeoffs
there. The first concern in the network type design was optimizing
RAM usage. David Gay's evaluations were the tradeoff between CPU
utilization (energy) and RAM. E.g., copying to native structs could
save energy for common accesses, but would require allocating another
struct.
Then, with the advent of telosb and derivatives, code size suddenly
became an issue. It's not a problem on any other platform. That
wasn't an original design consideration, given the commonly noted
direction that microcontrollers are taking to have more program
memory. I think it's safe to say that this wasn't anticipated.
It sounds like you want to do 1 of 2 things, both of which are
completely within your power and really outside the scope of the
compiler (but perhaps within its toolchain):
1) Prevent gcc from inlining the conversion functions. This will mean
that there's only one copy, saving code space, but invoking it will
be a function call, costing you CPU cycles and possibly making
interrupt paths too long (my guess is that this wouldn't be an issue
in the CC2420 stack, though, as it shouldn't be worrying about this
kind of thing too much). You could do this by suppressing the
inclusion of nesc_nx.h and linking against another C object.
2) Do all of your operations on native structs, then copy them over
when they're ready to send. This would be a bit of a pain, though,
and might require some restructuring of programming interfaces.
Actually increasing the "efficiency" of the functions is difficult. I
mean, here's a sample function:
static __inline uint16_t __nesc_ntoh_leuint16(void *source){
uint8_t *base = source;
return ((uint16_t )base[1] << 8) | base[0];
}
If you can think of a way to optimize that -- or some other
suggestion that isn't preferential to one architecture over another
-- I'm sure David would be happy to check it in when he returns from
paternity leave.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
