Sorry, you're right, atmeaga128 is little endian as well. The reason the network types (or more appropriate -- platform independent types) are needed is because the msp430 expects all tw-byte variables to be word aligned (can only start at even addresses), while the atmega allows them to be byte aligned (i.e can start at any address). Making them network types allows all bytes to be packed consistently on either platform.
Kevin On Oct 30, 2007 10:35 PM, Jeongyeup Paek <[EMAIL PROTECTED]> wrote: > 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 > >>>>>> Tinyos-help@Millennium.Berkeley.EDU > >>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > >>>>>> > >> _______________________________________________ > >> Tinyos-help mailing list > >> Tinyos-help@Millennium.Berkeley.EDU > >> 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 > -- ~Kevin _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
