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 program below is for generating square wave of some delay. I have taken F0 as eg to
check for small duration. When I run the program in step mode, the TL0 increments directly
to F3 and then the timer stops in autoload mode.The same set of instructions function in mode 1 I use keil Uvision 2.
#include <reg51.h>
void delay(); sbit mybit = P1^5; main(); { while(1) { mybit = mybit^1; delay(); } }
void delay() { TMOD = 0x02; TH0 = 0xF0; TL0 = 0xF0; TRO = 1 while(TF0==) TR0 = 0; TF0 = 0; }
"The program below"
that's a great piece of code.
keep up the good work!
This is one of the better lines:
while(TF0==)
I have to assume that the while loop should run until TFD becomes NULL.
I am simply amazed how many people who are supposed to be savvy at least with computers, fail to grasp the advantage of using "copy-paste" (but they apparently use it with success in their homework!) and re-type their "code". Stunning.
"Stunning."
as they say, stupidity is without limit.
/*Program for generating sqwave on pin 7 of port 2*/
#include <REG51.h>
sbit mybit = P2^7; void delay();
main() { while(1) { mybit = mybit^1; /*Invert mybit to toggle between 0 and 1*/ delay (); } }
void delay() { TMOD = 0X20; /*Timer 1 operation in mode 2*/ TH1 = -184; TR1 = 1; while(TF1==0);/*Polling mode is used instead of interupt mode*/ TR1 = 0; TF1 = 0; }
It works in autoload mode and the TL1 starts intially from 00 and later gets
loaded by the value in TH1 register.The problem is that it doesnt leave the delay routine
to go back to main program again where "mybit" is inverted to generate square wave of
50%duty cycle. The timer starts again after overflow and step mode execution is stuck at
while(TF1==0). But when it runs in mode 1, everything functions smoothly and the delay
routine returns to the main program.
'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.
View all questions in Keil forum