What are downsides of using the fastest oscillator a PIC can handle?

[Pavius]

A guy i'm helping bases a lot of his new designs on designs from 10 years ago. He automatically uses a 4MHz crystal, even though the modern PIC he's using (16F884) can handle 20MHz.

To me this seems like free money - 5x the performance for very little cost. There are no special clock multipliers/dividers - only a 400kHz I2C and 9600/19200 RS232 (both can be derived from the 20MHz crystal).

Is this a safe assumption or are there any considerations against using the fastest crystal the PIC can handle?

 

[Nigel Goodwin]

As the vast majority of PIC programmes spend almost all their time sat in loops waiting for things to happen, a faster clock speed just means it spends even more of it's time spent in those loops.

It also increases current consumption.

If there's a need for it been faster, then use a faster crystal, but most uses are far too fast even at 4MHz.

 

[Pavius]

Thanks, Nigel.

Current consumption is indeed an issue as this is a battery operated device - are there documents out there describing average current consumption differences?

There is a hard real time deadline as the device processes a measurement packet every 16ms. All calculations on this data must be completed by the time the next packet fully arrives. The CRC calculation alone takes ~1.5ms.

 

[dougy83]

You can have a look at the PIC datasheet for a few examples of the current consumption at different supply voltages and oscillator frequencies. As a rough guide, the current may be said to increase somewhat linearly with frequency.

 

[Nigel Goodwin]

Thanks, Nigel.

Current consumption is indeed an issue as this is a battery operated device - are there documents out there describing average current consumption differences?

As dougy83 said, check the datasheet - but some PIC's allow you to switch speeds from within the program, which may be helpful?.

There is a hard real time deadline as the device processes a measurement packet every 16ms. All calculations on this data must be completed by the time the next packet fully arrives. The CRC calculation alone takes ~1.5ms.

What on earth are you doing to take 1.5mS for a CRC? - 1500 instructions at 4MHz.

 

[justDIY]

Current consumption is indeed an issue as this is a battery operated device - are there documents out there describing average current consumption differences?

The datasheet for the microcontroller has some current consumption data in it for the various clock speeds the device supports. However that's for the chip in a test lab with nothing hooked up to it.

You'll probably need to build a micro-ammeter and measure current draw of your circuit/project yourself. most of the modern pics support clock switching, if there's data every 16ms and it takes your pic 1.5ms to run the calculation at what, 4mhz, 16mhz, 64mhz, 80mhz? Once you're done calculating and whatever, switch to the lower power internal osc for the remaining ~14ms.

 

[dougy83]

There is a hard real time deadline as the device processes a measurement packet every 16ms. All calculations on this data must be completed by the time the next packet fully arrives. The CRC calculation alone takes ~1.5ms.

What kind of CRC are you using? A simple looping (no lookup table) CRC16 routine on 32 bytes (16ms @ 19200) should take <half that time @4MHz. If that's still a problem, you can process each byte as it arrives (in <25us) instead of performing a block CRC calculation.

 

[blueroomelectronics]

It's very roughly 1mA per Mhz

 

[Pavius]

Thanks a bunch for the very helpful info. I will check the datasheet.

The CRC is something proprietary for the project. I didn't care to understand the logic behind it, but it's something they have been working with for years and will probably never change. It takes 1.5ms @ 4MHz using the non optimized free version of the htsoft PICC compiler. I'm guessing an optimizing compiler will halve that time at least. As for working byte byte - it's possible but not necessary right now. I'm guessing we'll just leave it at 4MHz.

Thanks again!

 

[Nigel Goodwin]

The CRC is something proprietary for the project. I didn't care to understand the logic behind it, but it's something they have been working with for years and will probably never change. It takes 1.5ms @ 4MHz using the non optimized free version of the htsoft PICC compiler!

Right, you never mentioned you were writing it in C, that explains why it takes so long.