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 be
On Mon, Jul 25, 2011 at 5:19 PM, Michael Schippling wrote:
> 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 some
> reason
On Mon, Jul 25, 2011 at 5:19 PM, Michael Schippling wrote:
> 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 about perfor
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 wrote:
> I don't have no intercourse with nx_t
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 wo
for going crazy I meant that the Timer 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(1
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
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)
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 n
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 coul
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
11 matches
Mail list logo