I use Keil sometimes and while using a timer in autoload mode, the TH0 is loaded with the calculated value but TL0 starts incrementing from 00 instead of the calculated value F0.Am I missing something while using or configuring the keil simulator?
"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.
what is more useless is that even after 40+ posts, you still haven't realized why that suggestion was useless.
when the OP finally followed my suggestion, he posted
The code sent by Erk will work as it functions smoothly in mode 1.
what is usesless about fixing the problem? As opposed to the homewrecker I am not interested in long theoritical discussions when a simple solution exist.
IF the homewrecker had not argued against my solution which solved the problem this thread would have been a whole lot shorter.
Erik
"what is usesless is that about 3 posts down I posted "get rid of autoload""
Posting queries on this forum is useless.
what is usesless is that about 3 posts down I posted "get rid of autoload" and it took you about 40 more posts to do so.
Trivial questions deserve trivial answers!
Posting queries on this forum is useless.One hardly gets answers except abusing each other and pointing at trivial issues
"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.
"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.
"... 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. 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.
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.
"">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?
Link works for me.
i got some "internal error" when i clicked on that link.
anybody else?
"Ashley,
Why don't you just help the poor chap?!"
A leopard can't change its spots. It's just not Ashley's way. Here is today's example of Ashley's ("millwood" and "fdan00" on the Microchip forum) gentle hand being helpful:
www.microchip.com/.../fb.ashx
So you see, it's a disorder of sorts ... and it does get worse over time.