Helpful ReplyLockedWhen will XC8 have a "delay" function?

Page: 12 > Showing page 1 of 2
Post
Microcontrollers
Starting Member
2012/09/02 16:26:58
It seems that either XC8 does not have any function along the lines of "delay_ms" or "delay" etc. (despite the manual saying there is) or the manual simply does not list which include files you need.
 
Any ideas?
Thanks
meikled
Super Member
Re:When will XC8 have a "delay" function? 2012/09/02 17:16:50
The delay macros in XC8 work for me - for baseline and mid-range PICs, anyway.
 
See lesson 1 in either my baseline or mid-range PIC C tutorial series, for working examples with delays.
 
 
sasa72
Super Member
Re:When will XC8 have a "delay" function? 2012/09/02 19:38:05
Microcontrollers
It seems that either XC8 does not have any function along the lines of "delay_ms" or "delay" etc. (despite the manual saying there is) or the manual simply does not list which include files you need.
Any ideas?
Thanks

 
It is necessary to ensure proper _XTAL_FREQ definition, then delay macros will be accepted. Ensure proper underscores as well, e.g.:

#define _XTAL_FREQ 20000000

#include <xc.h>
#include <p18f4550.h>
...
void main(void) {
   __delay_us(10);
   __delay_ms(10);
}

 
NKurzman
A Guy on the Net
Re:When will XC8 have a "delay" function? 2012/09/02 23:14:45
#include <xc.h> // required
#include <p18f4550.h> // not needed, and a bad idea, remove it. the IDE tells the compiler what to use.
BigGaz
New Member
Re:When will XC8 have a "delay" function? 2012/09/03 02:38:50
Sorry to hijack the post and please tell me bug out if its bad form.
 
I have a newbie question if i have a xtal of 20Mhz and want a delay of say 100msec how do I do this? as I get an error (see below) with the code
 
__delay_ms(100);

 
I assume the maths involved cannot handle such a large number associated with such a big delay period.
 
Would I have to write my own function to loop around 10 x __delay_ms(10);
 
The same goes for delays in seconds I guess
 
I guess I could just replace the Xtal with a 4Mhz one.
 
source/main.c:39: error: inline delay argument too large
 
Regards
Garry
sasa72
Super Member
Re:When will XC8 have a "delay" function? 2012/09/03 03:27:54
The _delay (x) inline function is limited slightly over 3 * 256 * 256 (two full nested loops with in 3*200ns instruction per cycle). That is around 39ms. For larger delay with 20MHz crystal can be used variety of functions declared in <delays.h>, or make your own based on existed.
post edited by sasa72 - 2012/09/03 03:46:53
BigGaz
New Member
Re:When will XC8 have a "delay" function? 2012/09/03 06:28:04
Thanks Sasa,
 
I will have a poke about and see what I can find and program.
 
Regards
 
Garry
NKurzman
A Guy on the Net
Re:When will XC8 have a "delay" function? 2012/09/04 09:34:11
Would I have to write my own function to loop around 10 x __delay_ms(10);
 
 I usually code a function like delay_ms( unsigned int milliseconds)
 
If to want it inline yo will need to do several __delay_ms() one after another.
someoddthing
New Member
Re:When will XC8 have a "delay" function? 2012/10/09 02:34:01
Microcontrollers

It seems that either XC8 does not have any function along the lines of "delay_ms" or "delay" etc. (despite the manual saying there is) or the manual simply does not list which include files you need.

Any ideas?
Thanks



i too am having this problem, and on two different desktop machines with different OS. (Win XP and Win 7)
i am using MPLAB X IDE v1.41 with XC8 v1.10 (in free mode) for a PIC16F1937
it also does not like any of the __Config()  lines that i use, but i did find the appropriate #pragma config line  (i believe - it doesn't throw it out.)
 
here is my code:
 
#include <xc.h>
#pragma config CPD = OFF, BOREN = OFF, IESO = OFF, FOSC = INTOSC, FCMEN = OFF, MCLRE = ON, WDTE = OFF, CP = OFF, PWRTE = OFF, CLKOUTEN = OFF
 #define _XTAL_FREQ 20000000    

void init(void)
{
    TRISB=0b00000000;
}

char counter;

void main (void)
{
    counter=0;
    init();
       
    while(1)
    {
        PORTB=counter;
                _delay(10);            /*  gives error "Unable to resolve identifier _delay"  */
        counter++;
    }
}
/* End of program */
 
 
i get the error "Unable to resolve identifier _delay."  i only get an error on the _delay() or __delay_ms() functions and any other variation.  i don't get errors on anything else now.
i read the manual and both of those delay functions should work.
i've tried and attached and included various headers and source files (i.e. pic.h htc.h delay.h etc.), but nothing makes the _delay functions work.  :(
any answers?
 
thanks
someoddthing
New Member
Re:When will XC8 have a "delay" function? 2012/10/09 02:36:23

 
i've read these tutorials, which are very well written by the way, but i just don't understand why i'm having this problem.  i'm more of a ccs person.
Billm336
New Member
Re:When will XC8 have a "delay" function? 2012/10/09 09:04:23
I created a new MPLAB X project and set the device to PIC16F1937. and the toolchain to use XC8 V1.1.
 
I copied and pasted your code into a blank C source code.  I did a Debug build within MPLAB X and it compiled just fine.  There was a warning about configuration word 0x8008 not being defined.
 
For your device, the compiler (or MPLAB X) should automatically define __PICC__ and __XC8.
 
The <xc.h> include should then include <htc.h> based on __XC8 defined.
 
The <htc.h> should then include <pic.h> based on __PICC__ defined.
 
If you open C:\Program Files\Microchip\xc8\v1.10\include\pic.h with a text editor, you will see the Built-in delay routine definitions starting on about line 148.
 
_delay is an intrinsic function so the compiler will generate in-line code for the delay based on a number of instruction cycles.
 
Right click on your project name in the Projects window of MPLAB X and select "Properties".  Make sure that the "Device" selection shows PIC16F1937. I think this is how MPLAB X decides to define __PICC__.  Without __PICC__ being defined, <pic.h> will not get included and _delay will not get defined.
 
I don't like so many nestings of include files, but you can track it down eventually.
 
Hope this helps.
 
NKurzman
A Guy on the Net
Re:When will XC8 have a "delay" function? 2012/10/09 09:51:29
__delay_ms(10);  // that is two underscores, It is not in the manual?
someoddthing
New Member
Re:When will XC8 have a "delay" function? 2012/10/09 15:23:00
NKurzman

__delay_ms(10);  // that is two underscores, It is not in the manual?

 
yes, that is two underscores, and it is in the manual, but the MPLAB X IDE source window underscores it in red and gives the error "Unable to resolve identifier __delay_ms"
 
The program does compile, and it runs just fine on the chip, which seems to prove that the _delay() or __delay_ms() functions DO indeed work, but it is very annoying being told there is an error when apparently there is none; this makes troubleshooting any program that i write very difficult.
someoddthing
New Member
Re:When will XC8 have a "delay" function? 2012/10/09 15:35:06
Yes, thank You, i was able to determine eventually that it will compile even with the _delay() error; i did not think it would.  i was able to get rid of any other errors or warnings by trying out different __config settings and such, but i haven't been able to get the _delay() error to go away, even though it compiles and runs perfectly fine it seems.
i changed my config line to:
__CONFIG(FOSC_INTOSC & WDTE_OFF & MCLRE_ON & CP_OFF & BOREN_OFF & LVP_OFF);
 #define _XTAL_FREQ 200000
 
no errors or warnings there now.
 
also, yes, i did find the delay functions declared in other files such as pic.h (i believe) and i tried manually including them and attaching them to the project in different combinations, but it never improved things.
so at the moment the program is working on the chip just fine, but in the MPLAB source window the _delay() is highlighted and says that there is a problem; yet it compiles with absolutely no errors or warnings.
is this a bug?
 
NKurzman
A Guy on the Net
Re:When will XC8 have a "delay" function? 2012/10/09 17:29:38
MPLab X is known to give false warnings for delay.  If the Compiler compiles with no errors ignore the MPLab X warning.
Noggin
Junior Member
Re:When will XC8 have a "delay" function? 2012/10/26 06:19:12
I'm running MPLAB X 1.41 and XC8 1.10.  I'm not getting any warnings/errors/red underscores for __delay_ms(10);  Are your tools up to date?  Maybe you could try to put extern void __delay_ms( unsigned char or unsigned int ); at the top of your source file or in a header file that everything includes such as main.h
JorgeF
Super Member
Re:When will XC8 have a "delay" function? 2012/10/26 07:29:44
Hi
 
The "extern" declaration if it is a function, or the declaration if it is a macro should be in the corresponding include file.
The errors/warning during text edition are not from the compiler, they are from the text parser that is trying to warn you of "typos" on the code.
Ususally including the "h" files in the project, even the standard ones, can solve those warnings. The text parser will have a chance of scanning them and find the declarations for library functions like "delay" and others.
 
 
Just my 2 cents
 
Best regards
Jorge
 
powerpsy
New Member
Re:When will XC8 have a "delay" function? 2012/10/27 10:42:10
Hi,
if you include htc.h and define the _XTAL_FREQ:
 
#include "htc.h"
#define _XTAL_FREQ 4000000
 
Then you can use the delay function:
__delay_ms(1);
 
It is still underlined in the IDE as not recognized, but it works and can be compiled.
eduard
New Member
Re:When will XC8 have a "delay" function? 2012/11/12 12:43:38
I'am using a pic PIC16F877A.
Try in both MPLAB 8.88 and MPLAB X 1.50 to use the delay routine "__delay_ms(500)" to get a delay of half a second. I have set the frequentie with "#define _XTAL_FREQ = 20000000". And using XC8 v1.11 compiler in Lite modus.
Still it gives me the compiler errors.
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Error   [195] D:\MPLab8_88\16F877A_CPP\BlinkingLED\BlinkinLED.c; 44.31 expression syntax
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
in MPLAB 8.88 and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
:0: error: undefined symbol:        __delay_ms(dist/default/production\BlinkingLed.X.production.obj)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
in MPLAB X 1.50
 
With right clicking on "#include <xc.h>" and using the 'navigate --> Go to declaration' menu I came from <xc.h> to <htc.h> to <pic.h> where I found this code on row 146:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
#ifdef __PICCPRO__
/****************************************************************//* Built-in delay routine *//****************************************************************/#pragma intrinsic(_delay)extern void _delay(unsigned long);
// NOTE: To use the macros below, YOU must have previously defined _XTAL_FREQ
#define __delay_us(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
#endif
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
every text between '#ifdef __PICCPRO__' and '#endif' is light gray.
I wonder if it is because I using the light "FREE" version of XC8?
If it is WHY it is, I think is silly.
When writing "_delay(5000000);" I got what I want although with the earlier mentioned warning. The code is more 'readible' when using "__delay_ms(x)", so I prefer that.
eduard
New Member
Re:When will XC8 have a "delay" function? 2012/11/12 13:02:37
By the way,
 
why do I have to define the Xtal speed if I already have set in the config "#pragma config FOSC = HS" this already telling the frequency or not?
sasa72
Super Member
Re:When will XC8 have a "delay" function? 2012/11/12 13:20:06
Please notice your #define code:
eduard
#define _XTAL_FREQ = 20000000

That mean compiler will replace _XTAL_FREQ with "= 20000000"!
 
eduard
By the way,

why do I have to define the Xtal speed if I already have set in the config "#pragma config FOSC = HS" this already telling the frequency or not?

FOSC configure only the way is generated clock for the PIC, not the frequency itself. HS mean High Speed frequency source and usually assume precise external crystal oscillator over 4MHz.
post edited by sasa72 - 2012/11/12 13:48:47
Paul Kirby
Starting Member
Re:When will XC8 have a "delay" function? 2013/01/08 21:04:47
Hello All
 
This is confusing me a little bit, I am new to XC8 but have used C18 for a while now.
I am moving all my code over from C18 to XC8, MPLAB 8.x to MPLAB X and I am having issues with the delay as well.
I understand that I need to use __delay_ms(...) and __delay_us(...) but when ever I try to use them I have issues.
 
I am using a PIC18F4550 with a 20MHZ Crystal, I have set the HSPLL_HS for the faster speeds due to what it needs to do.
What I do understand by reading the datasheet for the device is the 20MHz is divided by PLLDIV resulting in 4MHz, which is then fed into the 96MHz PLL resulting in 96MHz, this is then devided by OSC1_PLL2 (divide by 2) resulting in 48MHz.
My question is what do I set _XTAL_FREQ to?
I have tried 20000000 (20MHz), 48000000 (48MHz) which all results in the following error:
 

Microchip MPLAB XC8 C Compiler V1.12
Copyright (C) 2012 Microchip Technology Inc.
License type: Node Configuration
:: advisory: Employing 18F4550 errata work-arounds:
:: advisory:  * Corrupted fast interrupt shadow registers
main.c:15: error: inline delay argument too large
(908) exit status = 1
make[2]: Leaving directory `E:/Programming/PIC_PROJECT/delay_test.X'
make[2]: *** [dist/default/production/delay_test.X.production.hex] Error 1
make[1]: Leaving directory `E:/Programming/PIC_PROJECT/delay_test.X'
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
make: Target `build' not remade because of errors.
BUILD FAILED (exit value 2, total time: 2s)

 
How is 100 too large ?
I have created very basic code where I have the issue.

// Using a PIC18F4550 fitted with a 20 MHz Crystal.
 
#include <xc.h>
 
#pragma config PLLDIV = 5, CPUDIV = OSC1_PLL2, FOSC = HSPLL_HS
#define _XTAL_FREQ 20000000
 
int main(void)
{
    __delay_ms(100);
    Nop();
    return 0;
}

 
I never had any issues like this when I was using C18 with the delays.h header file, granted it took me a while to get the delay spot on but it worked.
 
Also what happens if I have multiple source files that need to have a delay in there, I cannot put multiple defines of _XTAL_FREQ in my code.
 
Any help would be great.
Thanks
Paul
mrp
Super Member
Re:When will XC8 have a "delay" function? 2013/01/08 21:42:53
_XTAL_FREQ should be set to Fosc, so:
#define _XTAL_FREQ (48000000ULL)
 
On the PIC18F series, the __delay_ms macro is limited to a delay of 179,200 instruction cycles (just under 15ms @ 48MHz clock).
 
You can just call it a few times in a loop:
for ( int i = 0; i < 10; i++ ) __delay_ms( 10 );
 
There shouldn't be any problem using #define _XTAL_FREQ multiple times.  Or you could put it in a common header file and include it from your multiple source files.
 
Also, I think the old C18 delay routines (Delay10TCY, etc) still work with XC8 if you #include <delays.h>.
 
Paul Kirby
Starting Member
Re:When will XC8 have a "delay" function? 2013/01/09 19:25:02
Thanks for the quick reply it has helped me understand how XC8 is handling the delays etc.
 
mrp
_XTAL_FREQ should be set to Fosc, so:
#define _XTAL_FREQ (48000000ULL)

On the PIC18F series, the __delay_ms macro is limited to a delay of 179,200 instruction cycles (just under 15ms @ 48MHz clock).

Well I just did some quick tests with _delay(...) and it seems when running at 48 MHz I can delay upto 197,120 cycles which works out to be approx 16.426 mS and a delay of 1 cycle is approx 83.333 nS, so no 1 nano second delay here :P
But will work fine for some of my projects that use IR Remotes which need to delay as fast as 560uS to detect the logic pulses etc which works out to be 6720 cycles @ 48 MHz so a _delay(6720); + a Nop(); gives me a 560uS delay (some reason it looses 1 cycle) and dont try and use _delay(1792); Should delay for 1792 cycles (149.333 uS) but insted it delays for 2560 cycles (213.333 uS) and a delay of 1793 results in a delay of 1792 cycles, but then again nothing is perfect.
 
mrp
You can just call it a few times in a loop:
for ( int i = 0; i < 10; i++ ) __delay_ms( 10 );

Great in theroy, but you won't get what you was hoping, the above worked ok ish a little bit out, but say I wanted say 560uS for decoding IR Remotes using the following you would think would work:
for (int i=0; i<56; i++) __delay_us(10);
Delays for 10uS 56 times so it should result in 6720 cycles (560 uS), however the for loop also takes cycles which results in 7281 cycles (606.75 uS) and for timing code that would be an issue.
 
Don't get me wrong using a loop to increase the delay is still a great idea as long as you cater for the amount of cycles each run of the loop takes, from there you can play about with values and adding one or two Nop() here and there works great :)
 
mrp
There shouldn't be any problem using #define _XTAL_FREQ multiple times.  Or you could put it in a common header file and include it from your multiple source files.

Also, I think the old C18 delay routines (Delay10TCY, etc) still work with XC8 if you #include <delays.h>.

Yeah, I could have a header file where I store all my defines and include that where its needed, I don't really like having to re-define stuff all over the place due to it causes issues when you need to change them and you forget some.
As for the C18 Delay functions still working in XC8, I wasn't too sure due to MPLAB X highlighting the functions red and greying them out in the header file.
 
Once again thanks for your reply it has helped me resolve the issue that I was having, I was starting to think maybe it would be better to stay with C18, but now I see how it works I am fine with my choice in moving over to XC8 and also the smaller assembly that it creates :)
 
Thanks
Paul
NKurzman
A Guy on the Net
Re:When will XC8 have a "delay" function? 2013/01/09 21:48:56
MPLabX is reported to complain about shuff that is fine.  If the Compiler is happy then it is fine.
 
the %error of
for ( int i = 0; i < 10; i++ ) __delay_ms( 10 );
compared to:
for ( int i = 0; i < 10; i++ ) __delay_us( 10 );
is a lot.
In fact I find
for ( int i = 0; i < 100; i++ ) __delay_us( 996 ); is a little better.
But that depends on the crystal.
If you need super accuracy, then you will need to check the timing.
Paul Kirby
Starting Member
Re:When will XC8 have a "delay" function? 2013/01/10 14:31:00
NKurzman

MPLabX is reported to complain about shuff that is fine.  If the Compiler is happy then it is fine.

the %error of
for ( int i = 0; i < 10; i++ ) __delay_ms( 10 );
compared to:
for ( int i = 0; i < 10; i++ ) __delay_us( 10 );
is a lot.
In fact I find
for ( int i = 0; i < 100; i++ ) __delay_us( 996 ); is a little better.
But that depends on the crystal.

This is true, the compiler may of still compiled fine, the IDE just confused me when it lit the function red etc.
I may just use _delay(...) for the odd small delays like the 560uS etc and use my own loop function for the larger ones, that way I know that they would be spot on the delay that I require.
 
NKurzman
If you need super accuracy, then you will need to check the timing.

Yeah, some stuff is ok and also depending on how the code is done so some times it can be a bit off.
 
Thanks
Paul
sombatsombat
New Member
Re:When will XC8 have a "delay" function? 2013/02/03 11:47:13
someoddthing

NKurzman

__delay_ms(10);  // that is two underscores, It is not in the manual?


yes, that is two underscores, and it is in the manual, but the MPLAB X IDE source window underscores it in red and gives the error "Unable to resolve identifier __delay_ms"

The program does compile, and it runs just fine on the chip, which seems to prove that the _delay() or __delay_ms() functions DO indeed work, but it is very annoying being told there is an error when apparently there is none; this makes troubleshooting any program that i write very difficult.


From my observation:
There is a #ifdef surrounding the macro definition of __delay_ms() and __delay_us() in pic.h , checking for __PICCPRO__ definition.
copied from pic.h:
#ifdef __PICCPRO__
/****************************************************************
//* Built-in delay routine */
/****************************************************************/
#pragma intrinsic(_delay)
extern void _delay(unsigned long);
// NOTE: To use the macros below, YOU must have previously defined _XTAL_FREQ
#define __delay_us(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000000.0)))
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
#endif
 
Could this be the cause of the error shown in source code window?
 
I manually put the line
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
 
then the error message has gone away.
 
sjb741
Super Member
Re:When will XC8 have a "delay" function? 2013/02/05 02:50:39
DS52053B-page 59
 
3.5.10 How Can I Implement a Delay in My Code?
If an accurate delay is required...using a timer to generate an interrupt is the best way...[otherwise] use the compiler’s in-built delay pseudo-functions: _delay, __delay_ms or __delay_us.  These all expand into in-line assembly instructions...The delay argument must be a constant and less than approximately 179,200 for PIC18 devices and approximately 50,659,000 for other devices.


We used to use in-house macros which were "crystal accurate"; they allowed for the time to call/return. Thus something like

 nop
 call    Delay2045uS ;Breakpoint
 nop                 ;Breakpoint

would show exactly 2045uS on the stopwatch. The short delays used W itself as the counter and other macros built on that. This was in the context of assembly programming however where the time to call & return was known for sure. The assembler was automatically generated from a template plus clock frequency and any user-required particular delays.

I wonder if the compiler writers could tweak the XC8 macros to also be "crystal accurate"?

An excerpt:
W_Delay_4N_Cycles macro    N        ;Delay (affecting only W) that takes 4N cycles, 1<=N<=255
    movlw    d'256'-N               ;A loop-back takes 4 cycles. Final pass takes 3 cycles.
    addlw     1                     ;However routine ititialisation (movlw..) takes 1 cycle.
    btfss    STATUS, Z              ;Therefore, number of cycles = 4N
    goto    $-2
    endm

;Only W (and some status flags) are affected
Delay_1023_Max    macro    N           ;Max delay is (4*255 + 3) = 1023 cycles
    noexpand
    errorlevel    -207              ;Ignore the warnings about label DelayVar
    variable DelayVar
    variable Remainder

    if N > .1023
        error "The MACRO 'W_Delay_N' was called with N>1023"
    endif
    if N < 0
        error "The MACRO 'W_Delay_N' was called with N<=0"
    endif

    DelayVar  = (N/4)

    if DelayVar > 0
    expand
       W_Delay_4N_Cycles    DelayVar
    noexpand
    endif

    Remainder  = N%4
    if Remainder == 1
     expand
       NOP                          ;NOP uses up 1 cycle
     noexpand
    endif
    if Remainder == 2
     expand
       goto    $+1                   ;GOTO uses up 2 cycles
     noexpand
    endif
    if Remainder == 3
     expand
       NOP
       goto    $+1                   ;GOTO uses up 2 cycles
     noexpand
    endif
    errorlevel    +207             ;"---------End of silly warnings-------------"
    endm


Ian.M
Super Member
Re:When will XC8 have a "delay" function? 2013/02/05 05:18:52
The _delay() 'function' generated by the linker is cycle accurate.    _delay(1) will give a NOP.   It uses various other forms as the delay gets longer.   That's why the delay parameter must evaluate to a constant.
apballard
New Member
☄ Helpfulby JasonK 2014/05/09 10:15:24
Re:When will XC8 have a "delay" function? 2013/08/27 22:54:43
I had same problem, MPLAB X IDE v1.85 with XC8 C compiler V1.20 (Latest at the time) 
 
HOW I FIXED __delay_ms PROBLEM:
edit the file pic.h and on about line 146 is the beginning of the block that defines __delay_ms.
change
#ifdef __PICCPRO__
TO
#ifdef __PICC__
 
Restart the IDE.
That removed the warnings and any compiler errors.  So far I've seen no side effects of the change.
Ian.M
Super Member
Re:When will XC8 have a "delay" function? 2013/08/28 00:50:59
Interesting. Obviously the MPLAB X editor's syntax parser must make some #defines to match the toolsuite so it can parse conditional code. It seems they missed that one! Whether it should be fixed in the IDE or the header is another matter.
Please file a bug report! wink
garyt
Starting Member
Re:When will XC8 have a "delay" function? 2013/12/13 13:22:03
OK I did the same and it worked for me as well.
However, since I am new to this, could somebody please explain what this change does.
I would like to understand why this fixed the problem?
garyt
Starting Member
Re:When will XC8 have a "delay" function? 2013/12/13 13:26:29
Sorry I forgot to list my change:
 
HOW I FIXED __delay_ms PROBLEM:
edit the file pic.h and on about line 146 is the beginning of the block that defines __delay_ms.
change
#ifdef __PICCPRO__
TO
#ifdef __PICC__
 
Restart the IDE.
That removed the warnings and any compiler errors.  So far I've seen no side effects of the change.

AlainBo26
New Member
Re:When will XC8 have a "delay" function? 2014/01/06 00:14:53
Hi,
I'm sorry to come back on this topic but I just have a little question.
 
__delay_us() and __delay_ms() are only defined for __PICCPRO__. I suppose it's related to compiler optimizations.
Does anyone had a look at the delay precision for standard and free editions?
 
Alain
Ian.M
Super Member
Re:When will XC8 have a "delay" function? 2014/01/06 00:34:46
same - same LoL
The linker's delay code generator for the _delay() psuedofunction is cycle accurate in all compiler modes.
The reason for the #ifdef __PICCPRO__ is obscure. Its probably an inheritance from HI-TECH C PRO for the PIC10/12/16 MCU, which even in Lite mode (the free mode) had that symbol defined at least as far back as v9.65PL1.   Unfortunately the MPLAB X syntax checker doesn't seem to know its defined by the compiler.
AlainBo26
New Member
Re:When will XC8 have a "delay" function? 2014/01/06 01:47:12
Ok Ian thks a lot.
 
So your advise could be to replace __PICCPRO__ by __PICC__ in the header file as I saw in this thread? Despite it's usually not a good practice.
 
Alain
Ian.M
Super Member
Re:When will XC8 have a "delay" function? 2014/01/07 06:40:30
As the compiler doesn't have any problems with it and I don't find MPLAB X a productive work environment, I frankly haven't bothered.  I only really use MPLAB X for its Config code generator wizard and prefer an external editor or MPLAB 8.
amaro
New Member
Re:When will XC8 have a "delay" function? 2014/01/09 18:37:12
Hello Everyone,
I think I found an interesting issue regarding the _delay() function (the function which __delay_ms() ibased). I tried to compile the following, using the MPLAB X with XC8 compiler, using _XTAL_FREQ = 32000000:
 
        __delay_ms(500);
        _delay(((500)*(_XTAL_FREQ/4000)));
        _delay(4000000);
        _delay(4294967295);
 
The compiler gives the error "inline delay argument too large" only on the first delays, but not on the fourth. Note that the first 3 intends to do the same delay of 500ms. The third uses 4000000 because it is the result of (500)*(_XTAL_FREQ/4000). Why 4000000 is to large for the compiler, but the value 4294967295 (that is even greater) is acceptable for the compiler? Note that 4294967295 is the max value for a long unsigned int.
NKurzman
A Guy on the Net
Re:When will XC8 have a "delay" function? 2014/01/10 13:59:26
The compiler generates the loop counters to get the right number on instructions to create the delay.
The Faster the Xtal the less the max delay is.
So what is the question?
1and0
Access is Denied
Re:When will XC8 have a "delay" function? 2014/01/10 17:08:16
amaro
I think I found an interesting issue regarding the _delay() function (the function which __delay_ms() ibased). I tried to compile the following, using the MPLAB X with XC8 compiler, using _XTAL_FREQ = 32000000:

       __delay_ms(500);
       _delay(((500)*(_XTAL_FREQ/4000)));
       _delay(4000000);
       _delay(4294967295);

The compiler gives the error "inline delay argument too large" only on the first delays, but not on the fourth. Note that the first 3 intends to do the same delay of 500ms. The third uses 4000000 because it is the result of (500)*(_XTAL_FREQ/4000). Why 4000000 is to large for the compiler, but the value 4294967295 (that is even greater) is acceptable for the compiler? Note that 4294967295 is the max value for a long unsigned int.
Comment off or fix the first three delays and I'll bet the compiler will flag the fourth one as an error.
 
Page: 12 > Showing page 1 of 2