One alternative to using delay.h is to use the rtc peripheral which can have a fixed clock of 32kz (internal, or external if you have a 32k crystal). Simply changing F_CPU to 3333333ul, will get you accurate delays for now (assuming fuse is OSC20M).

If you use delay.h, then you will have to set F_CPU to a value that matches what the cpu clock will be. If you do not define F_CPU, then your delay will be ~3 times faster (delay thinks you are at 1MHz, but your cpu is at 3.33MHz). So when you inform delay.h your cpu is running at 20MHz, but is actually 6 times slower, your delay will be 6 times slower. If you want something other than DIV6, then you have to set the PDIV and PEN as needed (a CCP protected register). Out of reset, the clock CLKCTRL.MCLKCTRLB prescaler is ALWAYS enabled and set to DIV6, which means you get 3.33MHz or 2.66MHz depending on the FREQSEL fuse bits. Its up to you to make sure F_CPU matches the actual clock speed.Ī 4809 (or any avr0/1) has two options for the cpu clock out of reset, set by the OSCCFG.FREQSEL fuse bits to either OSC20M or OSC16M. If you do not define F_CPU, then delay.h will still produce code but will assume 1MHz and warn you that F_CPU is not defined. Since delay.h creates code at compile time and has no idea what your clock is set to, you have to inform it via the F_CPU define. What's going on? A documentation error or something that I should learn / understand?į_CPU is used by delay.h to compute delay periods and has no effect on your actual cpu speed. but if I replace F_CPU with _XTAL_FREQ (which does not even appear in the compiler guide), the delay appears to work correctly! Document 'MPLAB® XC8 C Compiler User’s Guide for AVR® MCU' (DS50002750C), page 133, section 7.5.1 states: 'The macro F_CPU should be defined as aĬonstant that specifies the CPU clock frequency (in Hertz).' (It also mentions that optimizations need to be enabled for 'accurate delay times'. In addition to very low delays, the compiler also messages: #warning 'This file has been moved to. Issue: _delay_ms() macro runs about 5 times slower than it should.

Delay in mplab xc8