It was these two members that started me down this garden path
and I wondered about:
uint16_t destpan;
uint16_t addr;
I don't know the significance of "destpan", but I presume the addr
(destination mote ID) is solely for the benefit of the software and
can be any-agreed-upon-ended. Good point on the fcfhi-fcflo thing.
ah, yessssss, standards, we all need standards...I should get some.
thanks
MS
Philip Levis wrote:
On Oct 31, 2007, at 10:27 AM, Michael Schippling wrote:
So...basically EVERY platform we are dealing with is little-endian,
-- unless you are still running on a 68K (Mac?) of some kind -- but we
force the network types to be big-end just to increase the processing
requirements?
Hey -- I'm just saying what all protocol standards bodies (IEEE, IETF,
etc.) do. You can debate their wisdom if you want. The general mindset
is that making packets easier to read is more important than the few
cycles you might save.
And the full extent of the doc on this is in the T2WG message that
klueska referenced -- which is just a list of things to do?
Actually those are just my usual snotty comments...I should be sorry...
The real question is about the CC2420 header, which in T1.1.15 is still
little-end. Does the radio chip interpret either of the int_16 fields?
Or would it be safe to convert the header to nx_ types as well, just
for consistency?
Look at it more carefully:
typedef struct TOS_Msg
{
/* The following fields are transmitted/received on the radio. */
uint8_t length;
uint8_t fcfhi;
uint8_t fcflo;
Note that since FCF is a 16-bit value at an 8-bit offset, it's been
split into two bytes, the first of which is "hi." This is emulating
big-endian.
Phil
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
