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!
<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
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
how can it 'work' when "The problem is "
for the first delay you depend on whatever is in TL1 for your delay no autoload takes place before the timer roll over. for the next delay you will get the autoload value plus whetever counts happened before TR1=0. You are confusing the whole issue by using autoload. With a lot of feniggeling I have no doubt this could be done with autoload but why use auotoload when only one run in the routine. Using illogical modes does nothing but make the issue confusing, complex. less maintainable, less understandable, and error prone.
why not just straight code
void delay() { TMOD = 0X10; /*Timer 1 operation in mode 1*/ TH1 = 0xff; TL1 = -184; TR1 = 1; while(TF1==0);/*Polling mode is used instead of interupt mode*/ TR1 = 0; TF1 = 0; }
Erik
"why not just straight code"
it doesn't fundamentally solve his problem - that the code doesn't return (for some extremely strange reason, in my view) to main().
your code will have the exact same "problem" - if the code didn't return from his "while (TF1==0);", it wouldn't return from your "while (TF1==0);". thus why i called your line of thoughts "secondary".
at this point, I am inclined to think this is a user (observational) problem.
Erik,
I am beginning to suspect that Ashley is Jack Sprat's mother in law...
TR1 = 1; while(TF1==0);/*Polling mode is used instead of interupt mode*/
will continue, a running timer (0 or 1) will (eventually) set TF to 1.
Are we sure that we have the full source code?
It was quite some time since I used an 8051 but isn't TF1 auto-cleared if interrupts are used with the timer, while manual-clear without interrupts? So a program that does enable an interrupt handler for this timer but just have an empty ISR would get an interesting competition between the interrupt logic of the chip and the TF1 polling code.
'will continue, a running timer (0 or 1) will (eventually) set TF to 1.'
that's the point of the entire discussion, erik: his code, as well as yours, SHOULD work. but he reported it didn't work.
both of you used exactly the same return mechanism "while (TFn==0);". so if his code, for whatever reason, didn't return from that, your code wouldn't return from that either. using mode 1 vs. 2 does NOT matter at all from that perspective.
jesus! is it really that unreasonable to expect people to have some minimum reading comprehension?
"I am beginning to suspect that Ashley is Jack Sprat's mother in law..."
tammy, as long as i am not YOUR mother or mother in law, i'm ok, :)
Tamir; Ashley is a guy or a shim. He may be Jack Sprat. Bradford
"He may be Jack Sprat."
Or maybe even a Zeusti.
But he/she definitely also hides behind the names Qili, Millwood, and fdan00 on other forums to name a few.
it does work, I have a sneaky suspicion that autoload mode confuses the simulator. Not the first time the simulator has 'simulated' instead of 'replicated'. If it confuses the chip the chip is defective.
why on earth not just see what happens with non-autoload the OP has it right at his fingertips and trying it instead relying on bile from the homewrecker would take, at most 5 minutes.
"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