My second perfect is imperfect !! SOLVED !!

mglsoft · Joined: 18 Feb 2008 Posts: 48

I need to make precise timing of a second, with millisecond accuracy.
For this purpose, a PIC18F26K80, I use the internal oscillator, placed at 16 Mhz and with PLL enabled, and I was really close to doing.

This is the configuration I use:

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

You don't show how you generate timing (at output pin?) in your application. A well considered usage of timer with output capture feature can be assumed to achieve clock cycle accurate timing.

mglsoft · Joined: 18 Feb 2008 Posts: 48

The precision of time is given by interruption of Timer4 that sets a flag running code inside the main () function.

Here the code of the interruption:

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

In a short, interrupt flag will be set cycle accurate, interrupt function will be executed with some jitter due to varying interrupt latency, LED output will be set in main with considerable more jitter. So what you observe is just normal operation.

There are some options to resync the event in main() by reading the actual timer value and perform a variable delay. But it's not so easy to do it exactly. IMHO you should have understand the timing problems involved with interrupt processing before to expect succes.

John P · Joined: 17 Sep 2003 Posts: 331

You mean the internal oscillator without a crystal? "Precise timing of a second, with millisecond accuracy" implies precision to one part in a thousand. I believe Microchip promises accuracy to 2% at 25C, and much worse over the full temperature range. See Table 31-8.

So be sure what you need, and whether you'll always get it.

mglsoft · Joined: 18 Feb 2008 Posts: 48

Thank you. I understand that there may be such differences.

Also I want to check, putting the external crystal and noting whether the difference persists or disappears.

My problem is that I can not run the external crystal as it should, and that is where I need your help.

Can you help with that?
_________________
MGLSOFT

mglsoft · Joined: 18 Feb 2008 Posts: 48

Any Help Me ??
_________________
MGLSOFT

SherpaDoug · Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA

Are you having problems getting your PIC to run from an external crystal? If so you need to look closely at the PIC data sheet Oscillator section and at the specs of your crystal. Also make sure your crystal wiring is short and direct. What sort of circuit board are you using?
_________________
The search for better is endless. Instead simply find very good and get the job done.

mglsoft · Joined: 18 Feb 2008 Posts: 48

The external oscillator section of the PIC18F26K80 data sheet is only 2 pages, and I read it about 20 times, without finding this answer.

Use long Mhz crystal 10 with the PLL PIC18F activated, making the work internally PIC to 40 Mhz.

This PIC start in reverse, first using the internal oscillator (which is excellent!) And now I want to use the external oscillator, like the inner set, but does not work for nothing.

Just finished measuring with the oscilloscope and a 10 MHz crystal type in another circuit breadboard is indicating a frequency of 10 Mhz correctly, but in my case the 16 Mhz I have at the PIC indicates no oscillation.
You change it twice (I have only 4 glasses, and I keep one without touching it) and to no avail, still the same.

In my poor conclusion in PIC accepts no settings that I do in the program, and does not enable the OSC2 pin and will not even start to oscillate.

Why I asked to review whether this well as I set it up to see if I'm doing something wrong, because at this point I have no objectivity to it alone.
_________________
MGLSOFT

mglsoft · Joined: 18 Feb 2008 Posts: 48

For now I have half result ...
I tried engrave configuration bytes using this option:

FvM · Joined: 27 Aug 2008 Posts: 2337 Location: Germany

Your reports aren't very clear.

Do you say, 10 MHz crystal works and 16 MHz doesn't?

Or clock switching from internal RC to HSPLL doesn't work?

Ttelmah · Joined: 11 Mar 2010 Posts: 19369

#use delay, makes no changes to configuration bits, if you use it's original syntax. So:

#use delay(CLOCK=40MHz)

Changes nothing. It assumes _you_ are correctly setting the fuses/PLL to generate this clock.

Where it makes changes, is if you tell it you want it to. So:

#use delay(INT=8MHz)

will automatically try to set the fuses for an internal oscillator at 8MHz.

#use delay(crystal=10MHz, clock=40MHz)

will try to enable a crystal oscillator, and a 4* PLL

This _is_ in the manual:

'type=speed', with 'type' equal to oscillator, osc, crystal, xtal, internal, int, or rc "The compiler will automatically set the oscillator configuration bits based upon your defined type".

They couldn't be much clearer.....

Unfortunately, with the sheer complexity of the possible settings on a lot of chips, this often doesn't work right. Also people habitually set confligting values in the fuses. Though the clock statement will _add_ the fuses needed for the specified option, it won't turn off other fuses that conflict....

In general, I feel (especially with recent chips), it is much safer to sit down and work out the fuse pattern needed yourself, set these, and use the 'clock=' option, rather than one that specifies an oscillator type.

Best Wishes

mglsoft · Joined: 18 Feb 2008 Posts: 48

Thanks for answering.
Equally confusing clarification.
# use_delay () changes or does not change the configuration bits?

You start saying it does not change if you use only the option clock = xx

But then goes on to say that if you change if we use other options.

In my case, I came to this state because I started using the internal oscillator and just now trying to xtal.

As I have been programming in assembler, I usually set starting configuration bits in a single block.
That also do at CCS. I never had this problem before.

So I try to let my best explained what happens when driving the speed change in this way.

I'm a big advocate of this compiler, I have solved many things since I use, but it also makes me critical when something does not work as I understand it does.
I think we lack information about these functions and scope. Nothing more.
_________________
MGLSOFT

temtronic · Posted: Fri Sep 14, 2012 5:51 am

Ok...I've been using the compiler since 1997 and though retired(haha) from the realworld,like to keep reasonably current..so..

One of the 'problems' with these newer PICs is the huge range of options they have, so documenting them in perfect detail is a challenge itself.I often have to read,reread and read again the datasheet to understand what's going on ,though nowadays I've stuck with only 2 versions of PICs to better get familiar and comfortable with them.

To better understand what Ttelmah has said about the
#use delay(options...)
you have to think like the CCS compiler.'Play computer'.

From what I gather, when the compiler 'parses' the #USE delay(.....) line of code, it will set the appropriate bits in various 'option' registers of the PIC as well as embed in the 'delay' function code the loop counter based on the 'clock' option. It's smart enough to only cut code/set bits for the options that you supply.Considering the number of options(clock..internal,external,HS,PLL,etc., speed...10MHz,40,2,etc.) it'd take a few pages to explain all of the combinations and not all PICS have the same features.

There is a learning curve to all programming and this compiler is no different EXCEPT CCS does supply a wealth of examples that can show how to use their product.Yes, you have to scan them ,or read the help files or just cut code and see what happens.The bottom line...the more you experiment the faster you'll see why so any of us are still using CCS.

hth
jay