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
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
long integer
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
I'm not sure if this is standard C or not. I'm pretty sure it is but don't
want to go find it in the reference.
10L means make it a long.10UL would make it an unsigned long.
Basicaly 1024 * 10L is doing 32 bit signed arithmetic. The code really
should be 1024 * 10UL because time is never
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:
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 wrote:
Thanks a million Michael
there still is something that doesn't
for going crazy I meant that the TimerTMilli 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
hmmmnot 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,
even though, e.g. the CC2420 hardware header values, are
still Little. But treating a small valued Big End int
as Little would
unlike Michael, I have intercourse regularily with nx_types.
they are implemented as big endian byte arrays. And referenced using well
known byte swappers on little endian machines automatically.
On Mon, Jul 25, 2011 at 2:13 PM, Michael Schippling sc...@santafe.eduwrote:
I don't have no
On Mon, Jul 25, 2011 at 5:19 PM, Michael Schippling sc...@santafe.eduwrote:
hmmmnot 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
On Mon, Jul 25, 2011 at 5:19 PM, Michael Schippling sc...@santafe.eduwrote:
hmmmnot sure Normal numbers on just about every
normal is as normal does.
The word is Native. There is no normal when you are on the hardware :-)
platform with which we deal are Little Endian, but for
11 matches
Mail list logo
