How to check chip frequency

[Dave E]

Hello all,
I know that I can use CALIBFREQ to tweek the internal resonator frequency of a PICAXE chip but is there some way to read the frequency?

Possibly measure a PAUSE or some other time dependant command.

I was curious as to how temperature affected the frequency and need some way to actually measure it while the chip is in the fridge.

Any ideas anyone?

Dave E

 

[boriz]

You could:

-Scope PWMOUT.
-Use a second AXE as a frequency counter
-Scope two AXEs, dual trace, then change the temperature of one.
-Connect two AXEs PWMOUT together (use resistors) and then to an amp and speaker and listen to the beat pattern.
-Use a stopwatch and a long pause with a beep at each end.
-Bring a wire out and wrap it several times around a transistor radio. You might get a beat pattern.
-Disconnect the quartz drive circuit from a cheap alarm clock and send the timing pulses from the AXE.
-Use a bicycle speedo as a pulse counter.
-Program a delay with a beep at the end, then drop it from the top of a tower. If you hear the beep, you need a longer delay. (JK!)

 

[Dave E]

Thanks boriz.

Don't know why I didn't think of the PWMOUT command. That should do it.

Dave E

 

[westaust55]

If you look at the datasheet from the Microchip website corresponding to the PICAXE you have (see PIC type in Rev Ed manual 1) there will be a diagram showing the frequency error wrt supply voltage Vdd and temperature.

For the PICAXE 28X1 and 40X1 the datasheet Figure 17-2 covers HFINTOSC FREQUENCY ACCURACY OVER DEVICE VDD AND TEMPERATURE.

Keep in mind the temperature is the chip (junction temperature) and not the ambient (room) temperature). For the mentioned chips the frequency can vary by as much as 5% at chip/junction temps above 85 deg C.

 

[ciseco]

Dave not sure if this is true but it's what I came across on friday on one 28x1

Reason, 9600 coms, timing was out, was getting rubbish on the input.

I had to tweak calibfreq to -4 to get the thing right in some test code. I then reprogammed with the original app and all was fine, until I power cycled it. Seems the setting it only kept whilst the power is on (anyone yes/no)

If thats the case being able to read it might be kinda' pointless as it'll always reset unless you have it in code, and if you have it in code you'll already know that you put it there

So you could possibly do something like, pseudo code

symbol CALIB -4 (not sure if you can do a minus)
setfreq CALIB
sertxd ("Calibfreq setting",CALIB) as a reminder what you put into code

Miles
________
buy digital scale

 

[Dippy]

Miles.
If you read the manual (always a good start to prove you're looking) you will see that CALIBFREQ is a pseudo command and can accept the values -15 to 15.

"CALIBFREQ {-} factor
- factor is a constant/variable containing the value -15 to 15"

It writes to the OSCTUNE and the manual shows the Address if you wish to Poke.
You have to have that in your Code, the OSCTUNE register will power-up-reset and MCLR-reset to all the zeroes i.e. it's volatile and will reset to the centre frequency.

If you then look at the Microchip manual under OSCTUNE you can see how the bits are set. Seacrh on 90h in a microchip Data Sheet. This only works for the internal osc.

When setting Baud rates in PIC language you have to set bits in the Baud Rate Generator. There is always a slight error. Most of the times this can be ignored. But sometimes if you've done your BRG calcs based on a 4MHz xtal (say, using BRGH=0) and then move to a 20MHz crystal then you can get errors. Probably fine most of the time but nearer the 'edge' if the frequency drifts.
All these calcs and suggested values are in the Microchip Data Sheet.

I had a scenario a while back of 2-way asynch between PICAXE-PIC(10MHz xtal+PLLd). If I used the calcs to produce the correct Baud Rate it worked fine PIC-PC but intermittent PIC-PICAXE. After several hours I found values that were happy for PIC-PICAXE and PIC-PC. I'm just saying that it ain't magic and that sometimes you may need to twiddle.
I didn't try the PIC-PICAXE (+xtal), but I'm sure that would have been fine.

In fact if you plotted %data reliability vs BRG settings there was almost a Gaussian distribution, though my pencil may have slipped while I was joining the dots

 

[ciseco]

hehehehehe dippy,

I knew someone would know much more, his original post mentioned calibfreq, so just commented with what I'd observed when using it last week.

We get so much better answers from you guys than the manual normally supplies, wonder if they'd allow it to be wiki-fied by you and others, that'd be really useful and be much more informative as I've no idea what BRGH & PLLd actually mean.

One day I'll be worthy, till then please forgive the limited knowledge of a relative beginner

I didn't even know what a microcontroller was until 8 months ago

Miles
________
Yamaha YZ250F specifications