Searching \ for 'PIC 16F84 overclocking' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=clock
Search entire site for: 'PIC 16F84 overclocking'.

Truncated match.
PICList Thread
'PIC 16F84 overclocking'
1999\02\08@182426 by Sam Laur

flavicon
face
There was recently some talk about what a 16F84 could do, in speed. So I made
a simple test program (toggle a bit in PORTB to drive a LED, with a delay
loop), and made a simple test jig. Note that the sample is statistically
rather small (insignificant) and comes from the same lot (date code 9809SAN),
so your mileage may vary greatly.

First, I tested with crystals. Started out using the HS oscillator, but when
some individuals failed to work at 16 MHz, I tried the XT oscillator for fun.
And it seemed to work after that... Most of them could also be pushed to
18 MHz but 20 MHz wouldn't work with any of the processors that I tried it on.

The second test was a bit more scientific. I took an RF signal generator,
hooked it up to a simple transistor amplifier stage, and that through a
couple inverter stages (in a 74HC04) to make the signal neat and square.
Then it was only a matter of turning the knob to find out how fast it would
go. I just did this five minutes ago, so I've not had a chance to test it
with more than one processor; I found out with this individual, that it
would operate up to 18.8 MHz, then start acting erratically (LED flashes
irregularly), then stop working altogether at 19.1 MHz.

This is such a simple test, though, that _anything_ could be happening within
the processor; for example, the adder might not work at above 16 MHz, or the
like. The test loop doesn't exercise all sides of the processor. So... any
suggestions on how to improve on the tester, and still have a strong visual
clue to whether it works or not?

1999\02\08@184331 by dave vanhorn

flavicon
face
>This is such a simple test, though, that _anything_ could be happening within
>the processor; for example, the adder might not work at above 16 MHz, or the
>like. The test loop doesn't exercise all sides of the processor. So... any
>suggestions on how to improve on the tester, and still have a strong visual
>clue to whether it works or not?

This is interesting, since I think it indicates a fair margin of timing,
and therefore reliability, but to DESIGN a device with a clock faster than
the CPU is stamped for is INSANE.

No matter what, in 15 years, I have not had to overclock a CPU to achieve
design goals.
I took one design, 12 Mhz processor overclocked to 12.288, (and barely
getting things done) and rebuilt the software so that it worked just fine
at 3.575. I also dropped back to the 8 mhz version and saved some money :)

I overclock my PCs too, but that's my choice as the end user, with full
knowlege of the implications.
In order to qualify your devices to really be usable at the higher speed,
you'd have to run them at the min and max specified voltages, with min and
max pin loads, min and max temperatures, and excersize all on-chip
functions. This is very much non-trivial.

The idea of just using an LED as indicator is fine though, you just need to
check things internally, and then account for the fact that a processor
driven insane by your testing could possibly crash into the "blink an LED
for success" code.

It's still a useful test though, and one that I've been known to make on a
processor I don't have any experience with yet.. It lets you know where the
walls are.

1999\02\09@012554 by Mark Willis

flavicon
face
In building embedded system RTOS's {Real Time OS's} for safety
avionics, you will ALWAYS (AFAIK) see a bunch of routines in there that
specifically test each and every opcode the processor has, the real-time
OS will schedule these one after another "in the background", so only
one to ten opcodes get tested every "timeslice", but all get tested
inside of a second or so <g>  (Details depend on system design, of
course!)  You also do things like checksumming system ROM and re-testing
that checksum, a chunk at a time, testing address lines for
shorts/opens, etc. etc.  This might be a good way to more thoroughly
test here for overclocking - also, adding a heat sink would probably be
a good way to improve overclocked characteristics of a PIC (I've heard
from my Microchip FAE about someone running a 20 MHz chip at 50 MHz
IIRC, with a *good* heat sink.)  Thermal grease would be good, too, if
messy on a /JW part! <G>

 Speed isn't always king, IMHO, but overclocking isn't evil either
IMHO.

 Mark

Sam Laur wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...