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?
'The problem is that it doesnt leave the delay routine'
you just cannot help killing yourself, can you?
Ashley,
Why don't you just help the poor chap?! Come on, the guy suffered enough (I would if I could!)
"Why don't you just help the poor chap?! Come on, the guy suffered enough (I would if I could!)"
tammy: for the same reason that I have given up on you.
at some point, a person is deemed beyond help.
<QUOTE>tammy: for the same reason that I have given up on you.</QUOTE>
i remember tapeer as a stewdent. to teech him i used code like this
while ( still_breathing ) { send_message( to_tapeer, "read abi, page x, section y" ); receive_message( from_tapeer, msg ); if ( is_response_an_insult ( msg ) ) { // msg prob from tapeer if (! is_response_like ( msg, "you are wrong, r0 is not preserved") ) { // tapeer might at finally be listening if ( is_response_like ( msg, "im very good, you dont know anything") ) { // tapeer found information but too stubborn to admit help was good break; } } } } do_some_real_work ( ); }
always yo're freind.
Zeusti
"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.
"">www.microchip.com/.../fb.ashx
i got some "internal error" when i clicked on that link.
anybody else?
Link works for me.
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.