Understanding a Delay, for(j=0;j<1275;j++);, Crystal freq & 1275, 8051
I see countless uses of this basic Delay, usually for milliseconds.
Code:
void delay(int ms) //Produces a delay in msec.
{
int i,j;
for(i=0;i<ms;i++)
for(j=0;j<1275;j++);
}
I have not been able to find a good explanation (formula) of how the 1275 is derived, I'm pretty sure its a function of crystal frequency and clock cycles to execute a command. My projects use a 11.0952 and 12.0 mhz crystals.
if 8051 takes 11.0952 crystal
that is 11.0952 MHz signal generated and work with this frequency
In this frequencies each 12 cycles take 1 machine cycle
ie 11.0952 / 12 = 0.9246, = 926.6KHz
this means 926.6 instruction can be execute in second with the 11.952 mhz frequency .
we know the
Time period ,
T= 1/F
ie T = 1 /926.6
= 1.079us (it is the one machine cycle time )
taking this 1.079 micro second ., 1000mcro second is 1 millisecond
so that 1.079 X 1275 =1375
=1.375 milli second
In your case you need you need 927 instead of 1275 to get 1milli scecond delay
Because you pointed as your crystal is 11.0952MHz instead of 11.0592MHz (I think it is typing error :sad
Yes, a classical 8051 performs 1 instruction cycle per 12 clock cycles, resulting in e.g. 1 µs instruction cycle with a 12 MHz crystal.
But a single C code line is translated to many machine instructions, each of it taking one or two cycles.
See below how Keil C translates the inner loop of the delay routine. If you calculate execution time in detail, you'll notice that the shortest path through the loop takes already five cycles, one INC and two CJNE instructions. So the above calculations are simply wrong and the shown delay routine will never achieve ms delay on a standard 8051.
So with these facts in mind, I must ask why two different 8051 compatible MCUs (STC11F16XE, STC89C54RD+) would have a wildly different reaction to these basic Delay functions.
ie. Using a STC11F16XE a simple LED blink using delay like:
Code:
void delay(unsigned int itime) {
unsigned int i,j;
for (i=0; i<itime; i++)
for (j=0; j<1275; j++); // 1ms delay
}
gives a very close to 1Hz flash rate, with delay(1000), but using the same code with a STC89C54RD+ the blink rate is ~7 Seconds (7 sec on, 7 sec 0ff). Both having a 11.0592 crystal.
Using the internal Timer test code however the blink rate is no different, either mcu.
Code:
void delay() {
int count=0;
while(count!=500) //500ms to load TMOD, TH0 & TL0 values in while loop on each iteration + 500ms per count = 1 Sec
{
TMOD=0x01; //16-Bit timer selected
TH0=0xF8; // Loading high byte in TH
TL0=0xCC; // Loaded Low byte in TL
TR0=1; // Running the timer
while(!TF0); // Checking timer flag register if it is not = 1
TR0 = 0; // If TRO=1 stop timer
TF0 = 0; // Clear Timer Flag bit for next calculation
count++; // Increment count value
}
}
So the cycle divisor ratio I have been using above formula is 12 (with STC11F16XE).
The spec sheet of the STC11F16XE states:
With the enhanced kernel, STC11/10xx series execute instructions in
1~6 clock cycles (about 6~7 times the rate of a standard 8051 device). Enhanced 80C51 Central Processing Unit ,1T per machine cycle, faster 6~7 times than the rate of a standard
The user can configure the device to run in 12 clocks per machine cycle, and to get the same
performance just as he uses another standard 80C51 device that is provided by other vendor, or 6 clocks per
machine cycle to achieve twice performance. Enhanced 80C51 Central Processing Unit ,6T or 12T per machine cycle.
As far as I understand, the enhanced processors involve a more specific clock cycle to instructions mapping than a standard 8051, as already indicated by the 6~7 times specification. To time delay routines, you would want to caculate it exactly, referring to the instruction timing details in datasheet. Or determine it by an empirical measurement, as you already reported it in your previous post.
Personally I'm not using the said 8051 derivates and thus don't have this problem.
According to your reports, the 1275 loop count applies to STC11F16XE, but not for STC89C54RD or standard 8051. In so far the question has been solved.
Please forgive me.
But my line of questions seems like a logical progression of my original question discussion as it affects the cycle divisor ratio referenced in the first reply. I will create a new post.