Thanks for the detailed explanation.
But just one thing... doesn't atmega128 use little endian?
Did something happen behind the scene even before
nx types were introduced?
I thought all mica, mica2, micaz, telosb, tmote,
intel-processor PC's, and stargates used little endian.
I've experienced big endian only on some mac books...
The 'behind the scene handling' thing is nice, but it would have
been nicer if they were also supported on the host softwares.
Due to nx structures, it became more difficult to share
same c codes and header files across motes and PC's.
(or is there an easy way to do this?)
But still, I am trying to get used to it since I do believe
that transferring data over the network using network-type
byte ordering is a fundamentally correct thing to do.
Thanks
- jpaek
Kevin Klues wrote:
They've been in use since about May of 2005 and were introduced as
part of nesC 1.2.
http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/2005-May/000884.html
Anything compiled with nesC > 1.2 can use them, anything with older
versions of nesC will have compile time errors. They've are used
extensively throughout tinyos-2.x since nesC 1.2 is required for it.
Anywhere they've appeared in tinyos-1.x was for 1.2 and not 1.1.15.
That is one of the things that set the new version apart (many parts
of it it require nesC > 1.2 to compile correctly).
The main purpose of them is like Jeongyeup says -- they are like ntoh
and hton -- but handled behind the scenes so you don't have to
explicitly call these functions on them. Since the atmega128 (big
endian) and the msp430 (little endian) have different endianness,
packets exchanged between micaZ and telos, for example, require all
their fields to be nx_types. This was the primary motivation behind
introducing it.
Kevin
On Oct 30, 2007 9:38 PM, Michael Schippling <[EMAIL PROTECTED]> wrote:
One can, I suppose, "get used" to many things in a short time,
but it's nicer to not have to be surprised by inconsistency
at every turn. I'm not good at paying attention to new regimes
so I must have just missed the big announcement about how the
'network' types were going to fix everything. Probably in T2, eh?
I searched for nx_ types and came up with a few TEPs, but none
that mentioned that the byte ordering was going to be differently-
abled.
thanks for answering my question with actual information
MS
Jeongyeup Paek wrote:
Well, I don't know exactly who and when this started...
but yes, it is a default-like thing across all platforms.
It is dependent on 'nesC' rather than 'tinyos',
and I think people started to use it since tinyos-1.2 (not 1.1.15).
MoteIV/Boomerang used it, and it became a standard thing in T2
ever since Phil wrote his T2 programming manual.
Relevant doc might be Phil's book... and maybe some TEPs? I don't know.
If you think about it, it is just ntoh, hton thing,
and it's not too bad once you get used to it.
it took me a week :-)
Thanks
- jpaek
Michael Schippling wrote:
Yes, I'm using T1. And yes the CountMsg uses nx_ types,
and the telos/AM.h header in T1.1.15 does not.
So is the big-endian nx_*int* thing a default behavior
across all platforms? Do you know in what TOS version
this started? And can you point me to relevant doc?
I have to assume that this was done just to confuse me
and make TOS that much harder to deal with...
thanks
MS
Jeongyeup Paek wrote:
You are using T1 right?
In T1, the TOS_Msg struct does not use nx types.
So, all TOS_Msg header fields (e.g. addr) are
in host format, which will be little endian in Tmote sky.
Although I haven't seen CountUart demo, probably
their payload is using a nx struct with nx_uint16_t fields.
Then these will be transmitted in big endian.
If you want to avoid this, find the file that
defines the payload structure, and modify nx_uint16_t to nxle_uint16_t.
Hopefully, everything will show in little endian.
Thanks
- jpaek
Michael Schippling wrote:
I have apparently confused myself with new code...
I'm just starting to do useful work with Boomerang and Tmote sky.
I believe this means TOS1.1.15 plus now-defunct Moteiv addons.
Running the CountUart demo, I get this data stream from Listen:
04 00 00 00 00 00 7E 00 04 7D 00 1C 00 01
04 00 00 00 00 00 7E 00 04 7D 00 1D 00 01
04 00 00 00 00 00 7E 00 04 7D 00 1E 00 01 ...
^ ^ ! !
According to my reading of the telos/AM.h file, the bytes marked
with the hats ^ (bytes 6 & 7) are the destination address, which
for the UART is 0x007E. This value seems to be in little-endian
format. The bytes marked with bangs ! (bytes 10 & 11) are the
count value from the CountMsg payload, but this seems to be in
big-endian format, as does the next value (the mote source ID)
of 0x0001.
What am I looking at wrong here?
thx
MS
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
--
Jeongyeup Paek
Ph.D. student
Embedded Networks Laboratory
Department of Computer Science
University of Southern California
http://enl.usc.edu/~jpaek
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
