![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
freedom
Joined: 10 Jul 2011 Posts: 54
|
when, why and how much delay_ms and delay_us |
Posted: Tue Jun 16, 2015 3:14 am |
|
|
Dear all.
I have searched in this forum and even ccs compiler manual to find out and understand a basic things on delay_ms and delay_us function.
I just know this functions are used to delay as on given parameter.
But I don't know when it should be used ? If used then how much to delay ?
But I don't know when it MUST be used ? If used then how much to delay ?
I have seen many example program where this function is used. To do same thing some one use delay_ms(5) , some one use delay_ms(2), some one use delay_us(50), some one use delay_us(10) etc etc... |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Tue Jun 16, 2015 5:01 am |
|
|
delay_ms(xxx) is a set of instructions that CCS cut to give a specific amount of delay.As such this is 'inline' code, meaning that once called, the PIC will stay there and do NOTHING else until the time is up.
one great example is...
...
delay_ms(500);
lcd_init();
...
This delay is required to allow the LCD module time to 'organize' itself BEFORE the PIC accesses it. All peripherals need a finite time(specified in the datasheets) before accessing them. The ADC within the PIC is no different.
Delays can be used in 'main' or 'functions' to control overall timing of the program but NEVER,EVER use delays inside an ISR(Interrupt Service Routine) ! ISRs are to be short, fast code. Set bits(flags), simple tests, etc. but NO delays !!
Jay |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Jun 16, 2015 5:06 am |
|
|
What ????????????????????????
Is this a serious question?
Are you browsing the CCS manual and are you trying to understand each command?
Short answer: if you don't know if you need a delay, then you don't need one.
For all other situations the specifications of your project or hardware will tell you when a delay is required and how long it should be. |
|
![](templates/subSilver/images/spacer.gif) |
freedom
Joined: 10 Jul 2011 Posts: 54
|
|
Posted: Tue Jun 16, 2015 6:41 am |
|
|
Quote: | delay_ms(xxx) is a set of instructions that CCS cut to give a specific amount of delay.As such this is 'inline' code, meaning that once called, the PIC will stay there and do NOTHING else until the time is up. |
Thanks to reply
I know the delay function and used many times in my code.
But my question is that when this delay function should be used ? And how long this delay should be?
Suppose I know the delay must use before LCD initialize, before read and write eeprom etc.
May be there are also many field of code where this delay should or must be used. |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Tue Jun 16, 2015 8:50 am |
|
|
freedom wrote: | May be there are also many field of code where this delay should or must be used. |
There are many, many, many times when it could be used . That doesn't mean it should be used. When delays can be used is nearly always about the hardware around the PIC, and only a few times about the PIC itself.
Once example of a PIC related delay is whenever a new ADC channel is selected, a conversion should not be attempted until a short time has passed. That short time is to allow the ADC hardware to "settle" to the right, new voltage. The time varies from PIC to PIC, and is typically 4-15us. Newer types tend to need less delay.
This time can be waited for using a delay:
Code: |
select_adc_channel(3);
delay_us(10); // This time depends on the PIC.
reading = read_adc();
|
But many newer PICs can be configured to include the wait automatically, so the user doesn't need to put a delay in. The processor will still wait for the ADC to finish, just that it will take a bit longer.
There's no point wating for any longer than the required time. Often you'll see people have the processor wait for 100us or even more but it's just a waste of time, the result doesn't somehow get "better" the longer you wait.
Even so, using delays is wasting processor time, and for anything longer than a few us, there's often better, i.e. more productive, ways of using time. For example, its possible to be processing the result of the last ADC conversion while taking a new one. Longer delays, of ms, are better done using timers to generate a clock tick.
To find out if you need to use a delay, or you need to wait for something to happen, you've got to know what the hardware you are using needs. Read the datasheets, at least twice. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Thu Jun 18, 2015 8:40 am |
|
|
RF Developer's penultimate line, really is the critical bit:
"Even so, using delays is wasting processor time, and for anything longer than a few us, there's often better, i.e. more productive, ways of using time. For example, its possible to be processing the result of the last ADC conversion while taking a new one. Longer delays, of ms, are better done using timers to generate a clock tick. "
I almost never use delays. I'll have a few 'delay_cycles' instructions, possibly in interrupts, when doing some very fast hardware operation. Longer delays will always be done using a 'tick' interrupt, because this way the processor can be doing other jobs while waiting.
Structure throughout, is:
1) Do all jobs that _must_ be done. Handle hardware events, serial, etc., using buffers etc..
2) Do any minute delays where needed for exact timings.
3) Do everything else based upon times, using a 'tick' or counter, and while the time is not yet 'up', keep looping doing the other things.
Sitting 'delaying', is a single threaded way of working.
Instead:
Code: |
while (time_has_not_been_reached)
do_other_things.
|
|
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Thu Jun 18, 2015 3:15 pm |
|
|
System timers are your friend when you need delays.
here is an example.
Keep in mind - you can test other registers and pins in the PIC for a desired state change to terminate these delays early- which you can not do with the compiler generated delays.
http://www.ccsinfo.com/forum/viewtopic.php?t=53857 |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|