• AVR Freaks

Helpful ReplyHot!_XTAL_FREQ for PIC18F26K22

Author
mouchuanlin
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2019/01/23 12:41:10
  • Location: 0
  • Status: offline
2019/05/05 18:29:12 (permalink)
0

_XTAL_FREQ for PIC18F26K22

Hi,
I am trying to use those xc8 compiler provided delay functions. Seems the code need _XTAL_FREQ definition. How can find those value? From the MCC generated config code, it is define 1000000. Is it correct?
 
Thx
Dick
 
 
#define _XTAL_FREQ 1000000
 
__DELAY_MS, __DELAY_US, __DELAYWDT_US, __DELAYWDT_MS
Synopsis
__delay_ms(x) // request a delay in milliseconds
__delay_us(x) // request a delay in microseconds
__delaywdt_ms(x) // request a delay in milliseconds
__delaywdt_us(x) // request a delay in microseconds
#1
Bob White
Super Member
  • Total Posts : 260
  • Reward points : 0
  • Joined: 2010/11/06 19:52:38
  • Location: Denver, Colorado
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 18:43:54 (permalink)
4 (1)
Although the define uses "XTAL" is is just the frequency of whatever oscillator your are using.
#2
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 19:28:49 (permalink)
4 (1)
As above.
It's only correct if you have selected "1 MHz" for the internal oscillator, or are using a 1 MHz external crystal or oscillator.
 

Nearly there...
#3
Mysil
Super Member
  • Total Posts : 3326
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 20:20:19 (permalink)
5 (3)
Hi,
You, or MCC may define _XTAL_FREQ  to be any value you need it to be.
MCC will calculate _XTAL_FREQ according to what Oscillator  settings have been made in the GUI,
both Configuration bit settings, and oscillator control registers.
 
Edit:
_XTAL_FREQ  1000000     // As calculated by MCC is correct:
If you use MCC, and do No Change or Selection  of clock settings in 'System Module'
then 16 MHz Internal Oscillator Divided by 16 is used.
 
Strictly, _XTAL_FREQ is a misleading term, since what is actually meant, is the frequency of the system clock signal, after PLL frequency multiplier and whatever frequency divider and clock signal selector that may be used.
 
If you program oscillator control registers manually,
or change oscillator control registers from what is used when MCC generated code,
then you should recalculate the _XTAL_FREQ value, taking all clock register settings into account.
If you select different settings in MCC user interface, and Generate updated code, _XTAL_FREQ will be recalculated and updated.
 
Note, that you may change oscillator control register settings by program when the MCU is runing, 
but _XTAL_FREQ is a macro that cannot be changed after program have been compiled, and device have been programmed.
So if you do Clock Switching in runtime, you may need to recalculate delays and peripheral settings.
 
Also, __delay_ms(x), and siblings, are Macros that are calculated by the Compiler,
they are Not functions, so cannot be changed in the running program.
If you need a variable delay, then you will need to make a loop, with a variable loop counter, around one of the fixed delay macros.
Or use a Timer with a variable register setting.
 
Be aware that _XTAL_FREQ  == System clock frequency, is different from Instruction frequency.
All 8-bit PIC microcontrollers, PIC10..., PIC12..., PIC16... and PIC18..., use 4 clock periods for each instruction.
 
    Mysil
post edited by Mysil - 2019/05/05 21:17:58
#4
mouchuanlin
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2019/01/23 12:41:10
  • Location: 0
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 20:33:55 (permalink)
0
We setup OSCCON to 0x68. According to datasheet, should be 8 MHz. I think define _XTAL_FREQ  to 8000000 should be right.
 
    OSCCON = 0x68  // 0110 1000
 
bit 6-4 IRCF<2:0>: Internal RC Oscillator Frequency Select bits(2)
111 = HFINTOSC – (16 MHz)
110 = HFINTOSC/2 – (8 MHz)
 
Thanks,
Dick
#5
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 20:51:18 (permalink)
4 (1)
A few lines of code, turning an LED off and on with __delay_ms(500) calls in between should give an exact 1 Hz flash rate if you have it right.

Nearly there...
#6
1and0
Access is Denied
  • Total Posts : 9495
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 21:10:14 (permalink)
4 (1)
Mysil
Strictly, _XTAL_FREQ is a misleading term, since what is actually meant, is the frequency of the system clock signal, after PLL frequency multiplier and whatever frequency divider and clock signal selector that may be used.
 

Agreed.  It should be _SYS_FREQ or _OSC_FREQ. ;)
 
#7
NKurzman
A Guy on the Net
  • Total Posts : 17611
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 22:44:49 (permalink)
4 (1)
When they coined it every one used Crystals. Changing it now would break a lot of code.
Unless they supported both.
#8
1and0
Access is Denied
  • Total Posts : 9495
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 23:17:51 (permalink) ☄ Helpfulby cobusve 2019/05/09 23:09:33
4.5 (2)
Deprecate and phase it out over newer compiler versions, and display in Output window when it's used:
Advisory: The _XTAL_FREQ macro has been superseded by the _SYS_FREQ macro.

LoL: LoL
#9
davekw7x
Entropy++
  • Total Posts : 1791
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Left Coast, USA
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/05 23:40:53 (permalink) ☄ Helpfulby cobusve 2019/05/09 23:09:52
4 (1)
mouchuanlin
We setup OSCCON to 0x68

Why?  Why not let MCC's "Easy Setup" do it for you.  First attachment shows setup for 8 MHz.  And mcc_generated_files/device_config.h shows
#define _XTAL_FREQ 8000000

 
On the other hand...
When evaluating new CPUs I usually go for maximum speed.  The data sheet shows a maximum of 64 MHz system clock.  Second attachment shows this setup, and mcc_generated_files/device_config.h shows
#define _XTAL_FREQ 64000000

 
Note that setting the FRC bits OSCCON to a particular value only takes effect if you have selected "Internal oscillator block."  For example if you have selected "LP Oscillator" you get 1 MHz regardless of any FRC bit values that you manually set in the MCC (or any FRC settings you manually add to your code).  The configuration pragmas are generated by MCC in accordance with your selection of "Internal oscillator block" or "LP Oscillator."
 
In any case, to improve your understanding of the Data Sheet you can look at the configuration pragmas in mcc_generated_files/device_config.c and the OSCILLATOR_Initialize() function in mcc_generated_files/mcc.c to see how they do it.
 
Bottom line: MCC's System Module "Easy Setup" does it for you without you having to do anything in the "Registers" window.  Verify it as qhb suggested: Use __delay_ms() inside a loop to toggle an LED at some visually verifiable rate.  If the generated code has _XTAL_FREQ set to, say, 1000000 (1 MHz) and the actual system frequency is 8 MHz, the LED will blink at a rate 8 times as fast as you set up for.  Don't even need a 'scope.
 
Regards,
 
Dave
 
post edited by davekw7x - 2019/05/05 23:56:56

Attached Image(s)


Sometimes I just can't help myself...
#10
mouchuanlin
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2019/01/23 12:41:10
  • Location: 0
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/06 09:31:36 (permalink)
4.5 (2)
This is someone else code and doesn't seems to use MCC. I am trying to figure out why.
 
I have been used different forums - ST, NXP, Cypress...etc. By far, this is the most impressive forum I ever experienced.
 
Thanks for the great info. I really appreciate.
 
Thanks,
Dick
#11
mouchuanlin
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2019/01/23 12:41:10
  • Location: 0
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/07 15:56:40 (permalink)
0
Is there any side effect of using __delay_ms() function? I was told the delay functions have higher priority then interrupt.
 
Thx 
#12
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/07 15:58:36 (permalink)
4.67 (3)
mouchuanlin
Is there any side effect of using __delay_ms() function?

No. It simply runs a "do nothing" loop for a calculated number of times.
If interrupts occur, the delay will be extended by how long is spent servicing the interrupts.
If the WDT is enabled, then it CAN go off during your delay if it's too long.
 

I was told the delay functions have higher priority then interrupt.

I would stop taking advice from whoever told you this rubbish.
 

Nearly there...
#13
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/07 16:14:57 (permalink)
4 (1)
n.b. these are not "functions", they are "macros" that generate inline code to loop precisely the number of times required to get the specified delay. That is why the parameter cannot be a variable, it must be known at "compile time".
 

Nearly there...
#14
mouchuanlin
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2019/01/23 12:41:10
  • Location: 0
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/08 17:21:41 (permalink)
0
I got error using this marco for 25 seconds, even 10 seconds. What's the limit for this ?
 
I saw this from other doc saying the value should less than 179000 but do get a failure for 10000.
 
Anything I am not doing right?
 
"The delay argument must be a constant and less than approximately 179,200 for PIC18 devices and
approximately 50,659,000 for other devices."
 
#define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
 
I have _XTAL_FREQ define 8000000
 
Thx
Dick
 
 
 
#15
qhb
Superb Member
  • Total Posts : 9998
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/08 17:30:09 (permalink)
5 (1)
mouchuanlin
"The delay argument must be a constant and less than approximately 179,200 for PIC18 devices and
approximately 50,659,000 for other devices."

That means the argument to the "__delay" macro, which uses "machine cycles".
The "__delay_ms" macro simply calculates what parameter to pass to __delay(), and it is THAT number which is limited.
 
With an 8 MHz clock, a machine cycle is 1/(8MHz/4) = 500ns
so 179,000 cycles is about 89ms.
 
The delay macros for PIC18 devices were improved from XC8 version 1.40 to allow up to 50,659,000 cycles on PIC18 (=> 25.33 seconds @ 8 MHz).
 
So, you must be using a compiler older than v1.40.
If you want longer delays, just make a function to loop the required number of times, calling delay_ms to do a delay it can do, such as 50ms.
 
post edited by qhb - 2019/05/08 17:33:17

Nearly there...
#16
mouchuanlin
New Member
  • Total Posts : 20
  • Reward points : 0
  • Joined: 2019/01/23 12:41:10
  • Location: 0
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/09 14:43:41 (permalink)
0
Thanks for the info. Thx
#17
cobusve
Super Member
  • Total Posts : 493
  • Reward points : 0
  • Joined: 2012/04/02 16:15:40
  • Location: Chandler
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/09 23:11:30 (permalink)
5 (3)
Even if you are trying to figure out someone else's code, it is always easier to generate a small app with MCC and look at what it produced than it is to post an answer to a forum.
 
In this case you would have seen exactly how it works pretty quickly I think, and as you play with the clock setup you could see exactly how it is being changed/not changed for the different changes you can make.
 
Never underestimate the educational power of MCC :)

Also take a look at https://www.microforum.cc/ - a great resource for information on PIC and AVR microcontrollers and embedded programming in general. You can also post questions to the experts there.
#18
oliverb
Super Member
  • Total Posts : 204
  • Reward points : 0
  • Joined: 2009/02/16 13:12:38
  • Location: 0
  • Status: offline
Re: _XTAL_FREQ for PIC18F26K22 2019/05/21 11:04:21 (permalink)
0
FWIW if your source code is split across multiple modules you'll need to include mcc.h otherwise the _XTAL_FREQ value will be unavailable. This happened to me and left me with parts of the program seeing 32MHz from mcc and other parts (Including LCD driver, oops) seeing 8MHz inherited from the project configuration.
#19
Jump to:
© 2019 APG vNext Commercial Version 4.5