CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

when, why and how much delay_ms and delay_us

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
freedom



Joined: 10 Jul 2011
Posts: 54

View user's profile Send private message Send e-mail

when, why and how much delay_ms and delay_us
PostPosted: Tue Jun 16, 2015 3:14 am     Reply with quote

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...
temtronic



Joined: 01 Jul 2010
Posts: 9177
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Jun 16, 2015 5:01 am     Reply with 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.
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
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Tue Jun 16, 2015 5:06 am     Reply with quote

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.
freedom



Joined: 10 Jul 2011
Posts: 54

View user's profile Send private message Send e-mail

PostPosted: Tue Jun 16, 2015 6:41 am     Reply with quote

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.
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Tue Jun 16, 2015 8:50 am     Reply with quote

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.
Ttelmah



Joined: 11 Mar 2010
Posts: 19381

View user's profile Send private message

PostPosted: Thu Jun 18, 2015 8:40 am     Reply with quote

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.
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Thu Jun 18, 2015 3:15 pm     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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