Hi I want to implement delays in my code. Is there a predefined function like delay()?
Thanks
Not in our libraries, which are ANSI-compliant. See the following thread. You can search these forums and study some of the delay functions that have been written over time to solve this type of problem.
---Tom
Hello,
You do not say which MCU you are using. The attached collection of delay functions are suitable for the HCS08. For some of the methods, there is extensive use of inline assembly for tighter timing control. For a quick and dirty delay function -
void delay( int val)
{
for ( ; val; val--);
}
I seem to recall that the time per loop is about 22 cycles for the HCS08.
Regards,
Mac
The compiler is free to optimize away that whole function entirely, as it contains no side effects. "val" must be declared volatile to prevent that from happening.
Im sorry, but I don't understand. Could you please explain in more detail. Additionally, I tried to define val as a global variable with the following:
int volatile val;
But this did not change my errors. I did some looking and I read that the HCS08 has additional addressing options for LDHX command. Perhaps this is the problem?
Thanks agian,
Josh
User an hardware timer to generate a "tick" of 1 or 10 uS then just initialize and compare variable to this "tick" to generate a time delay
(I always have 1 timer dedicated to "tick" need a global tick counter 16 or 32 bit your call
Thank you very much for you delay functions. I am attempting to use them on my HCSO8, specifically the M9S08QG8. However I am getting an error when I do. I first copied the entire text of the Delay_HCS08.c file into my Main.c file, making sure they were outside the main function. Then I added the header to my includes folder, and added the necessary #include "Delay_HCS08.h"
However when I try to compile I get the following errors.
Error: C18103: Factor expected
Error: C18104: ')' expected
Error: C18123: end of line expected
All three errors point to the following line of code:
LDHX #(N1)
Additonally I get two warnings that the pragma No_ENTRY and NO_EXIT lines were not handled.
Any help would be greatly appriciated.
Thank you,
Josh
Hello Josh,
I found a number of minor problems with the code that prevented proper compilation.
Once these problems were fixed, I had no difficulty in compiling the code.
Lundin:
I presume that you are referring to the function:
void delay( int val)
{
for ( ; val; val--);
}
This function did not actually appear within the attached file, so was not the source of the compiling problem.
With respect to your intimation that the CodeWarrior complier may be free to ignore the programmer's wish to create a simple function, I find very hard to believe. In fact, we know this is not the case for the function in question. The reference guide "HCS08 Unleashed", by Fabio Pereira, does make use to this function in many of the tested examples, and I have never had a problem with CW generating the appropriate code.
I do not know what you specifically mean bt a "side effect", but might have thought that the used of the parameter within a for loop, empty or otherwise, would represent use of the parameter, certainly sufficient to prevent a compiler warning message about an unused parameter.
In terms of the need to declare a function parameter as "volatile", this is not a topic that I have ever seen covered by a general C text reference. Perhaps you may be able to enlighten. Maybe it is a C++ thing.
Juls,
I think that creating a timer interrupt at 1us or 10us intervals would be a bad idea. With a maximum bus frequency of 10MHz, the number of bus cycles between interrupts would be 10 or 100 cycles maximum. Since the minimum overhead for an ISR entry and exit will be about 25 cycles (not including the ISR code), this will give insufficient time to process the ISR, and do any other useful work. I would suggest that the periodic tick interval should be 100us absolute minimum - >= 1ms would be better.
Regards,
Mac
Oh I know that CW won't optimize it away. But I wrote the compiler, as in any compiler. Assuming that you wish to keep the code portable, so that you can reuse it in other projects in the future.
As the result of "val" is not used anywhere in the code, the compiler can optimize it away. Some compilers may just optimize away the whole loop and replace it with val=0;. And then, as val isn't used anywhere, it optimizes away that assignment as well. Whether or not such optimizations conform to the C standard may be argued, but many compilers do it. By declaring val as volatile, you enforce the compiler to perform each iteration of the loop.
Because accessing a volatile variable is a "side effect", which is C language gibberish for something that is changing the value of a variable. The -- operator is a side-effect too, though as the result of the -- is not used, the compiler may feel the urge to optimize the result away.
So the volatile declaration should be there to be on the safe side against certain compilers.