PIC16F Oscillator Selection

[GoldenKiwi]

Hi, i'm doing some exploratory learning and development for detector timing using the PIC16F family. I'm currently using PIC16F1829 with 32Mhz Internal Oscillator, but may switch to a different PIC16F device, or perhaps PIC24F/32F - but i don't yet have need.

I believe external Crystal or Oscillators are recommended for critical timing. I assume this would result in less jitter, perhaps less noise or more stable ADC measurements, threshold etc.

At the frequencies of interest for detectors and timing accuracy (currently Im limited to 125ns on PIC16F1829) is this of much concern or consideration?

Also, what are the selection considerations if so? I recall reading somewhere that crystals can be delicate and to consider impacts if you drop detector. is this true and would an alternative oscillator be better?

Any favorites for me to try!? (I tend to buy from Mouser)

Cheers!

[waltr]

I do use PIC and have since the 16F84 was the newest.
The internal oscillators are very good in PICs and I use them.

Check my HH2 project with PIC16F88 source code that uses the 8MHz internal oscillator:
https://www.geotech1.com/forums/show...ake-on-the-HH2
Read the comments in the source code to follow what it does.

For the detectors we build, PI or VLF, Accurate timing is not a requirement. It is the relative Timing and the repeatability that is important.
Accurate oscillator timing is a requirement if the PIC 'talks' to other devices with USB, Ethernet, etc. This is due to have both ends of the communications running at the same Clock rates and the faster the protocol the more accurate and less jitter becomes important.

For the older PICs I use that do not have an internal oscillator I use 3-pin ceramic resonators.
https://www.mouser.com/Passive-Compo...nators&FS=True

On my latest detector projects I have been using PIC32's.
For the PI detect it has been a PIC32MX170F256B-50 using the internal oscillator at 50MHz and in a 28 pin Dip package.
The Dip makes prototyping easy and is plenty fast enough with enough timing resolution for PI.

For the VLF I went to the PIC32MZ2048EF running internal oscillator PLL'ed to 200MHz.
This has 10nsec timing resolution and a Floating Point plus mips dsp cores for fast math.
Currently using a Microchip Curiosity 2. dev bd (144 pin TQFP chip) and a dev bd made by
Eclipse (forum member) with a 64 pin TQFP. Down side is these chp are hard to solder since
the pin spacing is SMALL.

I have posted code and code fragments for both these in this 'programming' sub-forum to show
how to use the OC (output compare) modules for hardware timing.

To your question diretly:
Internal oscillators in PICs are good so no reason not to use them.

If you go with external then use the CMOS oscillator modules. These are quite tough and not
easily damaged so no issues in a detector.
https://www.mouser.com/ABRACON/Passi...lators&FS=True

[GoldenKiwi]

Hi waltr, brilliant thanks! Very much appreciated.

That HH2 thread is a wealth of info thank you. I have started to code my tests using the same technique - using TMR0 and an interrupt - although like Car'ls im using C, via MPLab IDE.

Thank you very much for your experiences and thoughts on oscillators - as you've made clear it seems there is no good reason for me to use anything other than the internal oscillator for what I am doing! Better to reduce parts and keep it simple.

I had ordered a HPC Curiosity board and PIC18F27K42 PDIP to change to a 28 pin device as I decided I needed more pins, and the extra speed was attractive (64Mhz). Hmm... maybe I should have changed to the PIC32MX170F256B-50!

In the HH2 thread you mentioned possibility of outputting to LCD in the future. Have you done this? I haven't fully investigate yet but it appears driving the LCDs requires long delays, and clearly I wouldn't have time before the next interrupt (not sure if vectored interrupts would solve that..need to do much more reading!)

[waltr]

Your welcome.

The PIC18F27K42 PDIP is a good PIC to use. Also consider the 18K26Q10 for later upgrade.

I program the 16F series in assembler since easy instruction set and lower speeds need better controlled code timing.
I program the 18F and higher PICs in C using MPABX and the free GCC compilers. Do set the optimization level as high as the free version allows and the code does pretty well.
Yes, what I do in assembler and Carl's C code use the same method and this works well.

I have not added LCD to to my HH2. One reason is that all the TX and RX pulse timing is done within the ISR so NO time to do anything else. I do have a universal display PCB with a 28pin PIC that does all the display control and timing. This operates as either an SPI slave or UART RX that receives 'display commands' from the PIC doing the detector timing. The UART method is easiest and both PICs run an interrupt driven ring buffer for UART send and receive.

Do study my PIC16F88 'main loop' code for the HH2. In this all the 'slow' tasks are only done after some number of main loops (TMR1 interrupts) and a different task is done each time. This is a cheap trick to 'multi-task' in a lower end processor.
Actually also do this with the PIC32's, things like display update and 'is button pressed' are done at a much slower rate than the coil TX/RX.
The mid-range PICs (12,16 & 18s) all have much in common so pretty easy to port code from one to the next.
The high-range PICs, 24's & 32's are much different and take some time to learn how to program.

I do now have some experience with the PIC32MX170 and the PIC32MZ-EF. With these there is the OC (output compare) module that can be set to output pulses using only the PICs hardware (timers & interrupts) and do ADC measurements with hardware (timers and DMA) so the 'main' loop only needs to wait for ADC's DMA to finish then get the data and process.
I did post my PIC32 code here:
https://www.geotech1.com/forums/show...ng-in-hardware

I have a TFT display on the PIC32MZ-EF now with an SPI interface running at 16MHz. The display is updated every 40ms using 'blocking functions' but the coil TX/RX is all done in hardware so those keep going while display is written to. Haven't yet analyzed the time required to do various display writes. This might be better done with another PIC doing all the display timing and getting 'display info' on UART or SPI from the PIC32.

Vectored interrupts could help. The idea is assign the display interrupts to lower priority and the critical processes to higher priority and can interrupt the lower ones. The PIC 18's do have a high/low vector and the PIC32s have 7 levels of priority.

I have posted my univ-display board in the IDX-VDI thread since this designed for the VDI but made so it have multiple uses. Need to do the thread here in the programming section.