Overclocking a PIC

Skill Level: Intermediate

by Nate August 01, 2004 | 5 comments

Ever since Microchip introduced the 20MHz line of uCs, people have been pushing their 4MHz rated PICs up to 20MHz.

Why stop there?

If you haven't heard of overclocking CPUs, you are missing out on some fun reading. From an infamous jet-powered beer cooler to the mini-fridge cooled processor setup, these guys are crazy. Take a look at Tom's Hardware and Extreme Overclocking.com.

The theory is pretty simple. If you've ever taken Electromagnetics or PCB design you understand what high frequency does to a system. Basically, when Cray designs a super computer, they design it to operate at 400 gazillion hertz. Then they plug it in and test it. When they find out it doesn't work, they turn down the dial to 345 gazillion hertz where it begins to work.

The same is true for AMD and Intel. While there are over 10 different speed Athlon processors, they are all pretty much the same inside. The same silicon layout goes into the 800MHz and 1400MHz chips. The difference is when they test the chips - some run stable at 1400MHz and are sold for $50 more than the same chip at 800MHz.

But the reverse is not always true. What if there was a large demand for 800MHz chips? AMD will stamp the 800MHz approval on perfectly good 1400MHz chips to serve the demand. This is where overclocking steps in.

By pushing the clock frequency up on chips, you can effectively get more out of your processor. If you've got a good piece of the big wafer, you can really push it. But there are side effects that include much higher operating temperatures, instabilities, and possible out-and-out failure.

But that's for CPUs :)

For PICs, according to the Microchip datasheet, if a part is rated at 20MHz, you can run it at anything up to 20MHz. As the processing speed increases, so does the operating current. If you are worrying about a PIC heating up - don't. You would have to pump some serious current through the DIP package for it to heat up, and at that point the PIC would be vaporized regardless.

Since the majority of us are hobbyists or students, we don't have to worry about instabilities within the system - we aren't building 100,000 units of a product. Of course a good little engineer should always follow the maximum ratings dictated by the manufacturer's datasheet. But then again, we aren't normal engineers :)

The last thing we have to worry about is failure. By pushing the PIC too fast for too long, there is the possible chance of killing the PIC. So don't blame us if your controller goes up in flames (not really) - this article is only here for edu-tainment purposes.

So the weapon of choice is the PIC 16F873A. There was no rhyme or reason for the selection - it was the thing that was currently in our breadboard at midnight, when the testing began.

We had four separate crystals:

We then had to have some code to test to see if everything was working correctly. While we could have used the onboard UART, we don't have an MAX232 chip on the breadboard so we decided to use our RS232 bit-banged routines. Oh, and we too lazy to even put in the Microchip recommended stabilizing capacitors. The crystals were simply plugged into OSC1 and OSC2.

Bit-bang test code: (Hex, Asm, C)

20 MHz Test:

If you look at the code, you will see a value inside the rs_wait function. The function dictates the baud rate. Depending on how many cycles the rs_wait loop goes through changes the width of the rs232 pulses - ie baud rate. For 9600 bps with a 20MHz crystal, this value is 36. Sho' nuff, we got hyperterminal to read the text that was being sent from the PIC.

24 MHz Test:

Well if 36 worked for 20MHz, and 24 is 120% of 20, then 120% of 36 should work for the new rs232 pulse width delay - 1.2*36 = 43.2. You have to extend the delay for a higher crystal frequency to get the equivalent 9600bps wait time.

44 actually worked better. The PIC seems to operate just fine. What should we be looking for? Popping? Hissing? Nope. Just endless text output on the hyperterminal screen.

27 MHz Test:

Okay, now we are up to 135% of the original 20MHz. A new delay value of 1.35*36 = 48.6 or 49 was used. No problem. 27MHz works just fine.

32 MHz Test:

How about pushing a 20MHz part to 160%? - give'r all she's got. At 32MHz, 1.6*36 = 57.6 or 58 was used. Sweet! No problems! The 16F873A is now outputting 9600bps operating at 32MHz at 5V. We have gone from a 200ns instruction cycle @ 20MHz to a 125ns instruction cycle @ 32MHz.

Conclusion -

As you can see in the table, the operating current when up almost linearly with the clock speed increase. The current readings are with all of the default power-on hardware settings - a lot of stuff could be turned off to save some juice, but that wasn't the point of the experiment.

I don't think we had a magical PIC by any means. If your project requires some serious or horrendous calculations, you might want to consider pushing up the clock speeds. I wouldn't dare put an overclocked PIC into anything that requires dependability. But for tinkering purposes, it seems to work just fine. I've been running the test circuit at 32MHz for over two hours now without a single blip on the output screen.

I figured we would have errors or problems over 30MHz but we have yet to discover any problems at 32MHz. There is plenty of ratings in the Timing Parameter Symbology section under chapter 15: Electrical Characteristics within the Microchip datasheet. But I am way too tired to try to figure out unstable configurations and the like at this time of the morning. I guess we will just have to get some bigger, scarier crystals to see where the story ends.