On Thu, Mar 3, 2011 at 3:16 PM, Harsha Chenji <[email protected]> wrote:
> I am trying to work with endianness in the blip/tinyos platform on an > epic mote. The mote sends a simple struct consisting of 0x1234 in a > uint16_t field to fec0::64. Now, when I run ip-driver to listen on > fec0::64 and use netcat to dump hex, I see the following: > network order is big endian. On the mote if you use network types ie. nx_uint16_t etc. nx_struct. then it will automatically put the bytes in network order and allow you to reference the data cells normally. The compiler takes care of accesses. > > If I use htons(0x1234) in the tinyos code before sending, I see "34 12" > If I don't, I see "12 34" > the epic is what kind of byte order? > > Now isn't it the convention that network traffic has to be big endian? > Therefore, shouldn't we see "12 34" in netcat's output if I use htons in > the mote code? I am a little confused since it is actually the other way > around. > I'm not sure what is going on. Where is netcat picking up the data from? > > My question is: Does ip-driver do any kind of byte manipulation or does > it just create an interface and read from it? Does the blip stack do > htons automatically before sending and receiving data on the mote? > To do that the blip stack would have to somehow know the format of your data. Not likely. So I'm going to say no. To really answer this question you will have to follow the data down the stack and see what things look like in memory and how it is organized. > > Thanks, > Harsha > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
