Timer in autoload mode

"">www.microchip.com/.../fb.ashx

that's a pretty entertaining discussion, :)

my favorite:

union {
    float f;
    unsigned long ul;
 } u;

 unsigned char a, b, c, d;

 u.ul = (a << 24) | (b << 16) | (c << 8) | d;

is that representative of PIC programmers?

"">www.microchip.com/.../fb.ashx

that's a pretty entertaining discussion, :)

my favorite:

union {
    float f;
    unsigned long ul;
 } u;

 unsigned char a, b, c, d;

 u.ul = (a << 24) | (b << 16) | (c << 8) | d;

is that representative of PIC programmers?

in terms of speed, the "left shift" approach takes 340 - 415us, on a 89c51 running a 24Mhz crystal, to convert four unsigned char types into a floater.

in comparison, the "union" approach (assigning the values to four members of the union) takes 4us under the same condition.

for a speed differential of 85 - 100x, against the "left shift" approach.

per's pointer-conversion approach takes 8us to finish.

totally non-scientific.

The "left shift" approach depends a lot on the used compiler. Some compilers detects the shifts of n*8 bits as byte-addressing. Some compilers may further notice if the bytes are of the correct order relative to the processor, in which case everything can merge into a single assign.

Next thing is that older processors may suffer a lot from shift operations, while newer processors often have barrel shifters in which case the number of steps to shift doesn't matter.

In the end, the runtime speed is seldom a problem if the type conversion between bytes and a float or double is caused by a serial transfer. The code size difference may be more important.

"... while newer processors often have barrel shifters in which case the number of steps to shift doesn't matter."

Some FPGA soft-core processors are nice in that you can enable inclusion of a barrel shifter if your application benefits from it; otherwise, not having one leaves resources free for other things.

"The "left shift" approach depends a lot on the used compiler. "

and hardware too. I compiled it for the cortex-m3 chips (on mdk and iar) and the speed differential is considerably smaller - makes a lot of sense.

I guess the 8-bit devices incur a large penalty in processing wider data types.

"I guess the 8-bit devices incur a large penalty in processing wider data types."

A strict 8-bit processor shouldn't not need any penalty since a decent compiler should manage to detect that the operation is four 8-bit reads and four 8-bit writes. The cost should mainly be the ability to work with pointers.

With a bad compiler and no barrel shifter, the cost can be tremendous, but it is a disgrace if the compiler does not contain logic for detecting shifts resulting in 8-bit aligned reads and writes.

"but it is a disgrace if the compiler does not contain logic for detecting shifts resulting in 8-bit aligned reads and writes."

the pic24f family (probably the h and e families too) has a shifter block that can do up to 15 bit shifts in hardware.

as a result, the shift approach on those chips are only 4x longer than the union approach.

but the fastest really is to use a (double) pointer to point to the unsigned long / unsigned char array representation of a double: that takes about 1/4 of the time of the union approach.