You forgot to mention that big-endian numbers are MUCH easier to read in hex, and even octal, dumps...
I rue the day intel decided to one-up motorola and go little-ended. Computers will never be connected to one-another after all... Between that and the incredibly stupid p.match over CR/LF I'll bet the world GDP has been dinged by at least 10%. Given that the hardware message headers are NOT nx_ types and that there is (in all cases?) some kind of translator between TOS and e'net, IMHO it is just-one-more-confusion to add big-end numbers into the mix. But back to TOS... One possibility is that the Timer does not really use a full 32 bit value. Both atmega and msp have 16 bit counters -- maybe there is some software foo to extend that by counting the counts -- so a mis-aligned number _might_ wrap around and end up setting a "crazy" count value. Your experimental protocol seems to be the best approach. MS Eric Decker wrote: > > > On Mon, Jul 25, 2011 at 5:19 PM, Michael Schippling <sc...@santafe.edu > <mailto:sc...@santafe.edu>> wrote: > > hmmm....not sure.... "Normal" numbers on just about every > platform with which we deal are Little Endian, but for some > reason "they" decided to use Big Endian for the nx_types, > > > didn't think it through and not concerned about performance. > > prior to intel processors being as ubiquitous as they are big endian > processors were more prevalent. > > And the powers that be selected big endian for network transmission > order on the networks being worked on at the time. > > It made sense because big endian network order and big endian puters > played well. At least at the IP level. IEEE did it different and the > h/w guys did it different. Look at how we describe IPv6 h/w addresses > (like EUI-64). Its easy to wrap ones mind into squirrly little nots. > > Then intel came along and frankly having TinyOS network order be little > endian for custom protocols makes sense from a performance perspective > but in the presense of IPv6 and 6lowpan stuff it would still have to be > sent over big endian. So who know what is the right answer. > > > even though, e.g. the CC2420 hardware header values, are > still Little. But treating a small valued Big End int > as Little would make the value large -- I think I did > that right, in my head at least. > > > that is correct. Which doesn't explain the behaviour he is seeing. > And why I think playing computer or byting the bullet and debugging the > embedded system in a more reasonable way (like with a real debugger via > the jtag port) is the way to go. > > > > What I meant by reset(10) was to send a literal value > as an arg, rather than getting it out of your message. > Just to see that something works the way we want. > > > yep good suggestion. > > eric > > > > MS > > scatram...@gmail.com <mailto:scatram...@gmail.com> wrote: > > for going crazy I meant that the Timer<TMilli> MyTimer fires > every few milliseconds... > > > > I bet you are right saying that the app_period is not reconverted > to the right byte order. it would explain why the timer fires in few > millisec cos I usually set the app_period between 1 and 30 > > > > btw, what's "reset(10)" ? is not a Timer command, isn't it? > > > > > > cheers > > > > Davide > > > > > > > > On 25 Jul 2011, at 22:13, Michael Schippling wrote: > > > >> I don't have no intercourse with nx_types but it might > >> be that app_period is not being re-converted back to > >> the right byte order. Does it work with reset(10)? > >> > >> Also, please define "crazy timer".... > >> > >> MS > >> > >> > >> scatram...@gmail.com <mailto:scatram...@gmail.com> wrote: > >>> Thanks a million Michael > >>> there still is something that doesn't work: > >>> if I do: > >>> call MyTimer.startPeriodic(1024L * (uint16_t) > (sync_msg.app_period)); > >>> where 'period' is a 'nx_uint16_t' inside the struct 'sync_msg' > >>> everything works fine > >>> on the other hand, if I use a function like: > >>> reset((uint16_t) (sync_msg.app_period)) > >>> ... > >>> reset (uint16_t period){ > >>> call MyTimer.startPeriodic(1024L * (uint16_t) period); > >>> } > >>> the timer goes crazy > >>> any idea why? am I doing something wrong casting the value? > >>> Davide > >>> On 25 Jul 2011, at 17:14, Michael Schippling wrote: > >>>> long integer > >>>> > >>>> scatram...@gmail.com <mailto:scatram...@gmail.com> wrote: > >>>>> Hi, > >>>>> An easy question: > >>>>> What the 'L' stands for when assigning the period to a timer? > for example > >>>>> call MyTimer.startPeriodic(1024 * 10L); > >>>>> it starts a periodic timer that fires every 10 seconds but > what's the meaning of 'L' > >>>>> I couldn't find it in google... > >>>>> thanks > >>>>> Davide > >>>>> _______________________________________________ > >>>>> Tinyos-help mailing list > >>>>> Tinyos-help@millennium.berkeley.edu > <mailto: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 > <mailto: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 > <mailto: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 > <mailto:Tinyos-help@millennium.berkeley.edu> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
