Internal Prescaler EX_FREQ.C

[Mike Walne]

You appear to have lifted your code straight from the CCS example set up to work with a 16F877 @ 20MHz.

I tried this simple test.

Connect T1 clock input directly to the MCU clock.

You SHOULD get EXACTLY the correct reading with no deviation.

With a 16F877 I got 20,000,002Hz.

With a 18F458 I got 20,002,246Hz.

(I don't have 18F25K22 to try.)

Food for thought.

Mike

[maria100]

Non-Working ( external crystal ) code:

[maria100]

I'll try the new test, thanks for help Mike but I don't know it will work...if even the led is not blinking properly.

[Mike Walne]

I can't check your code because I don't have 18F25k22's

When you use the internal clock, the data sheet tells you to expect errors of around 1%, plus loads of drift with temperature and time. 1% error equates to 40kHz, i.e. more than the difference between your reference frequency and the measured value. Asmboy told you about prescalers. With a 128 prescaler, you can't hope to get 100Hz resolution.

The system based on the CCS sample is your best offering so far. As it stands the code is good up to Giga Hz (maybe Tera Hz) without overflow problems.

This is basically how it operates:-

(1) The input frequency source is connected to T1 external clock input.
(2) T1 clock and the freqc_high are set to zero.
(3) T1 is enabled to count for one second, (the gating period).
(4) The gating period is determined by counting machine clock cycles very carefully.
(5) Every time the T1 overflows the overflow flag is reset and freqc_high is incremented.
(6) The machine clock count is adjusted to take care of the difference in execution times. (Like I said before I'm not a software expert, I have to admit I originally overlooked this bit.)
(7) At the end of the one second period the T1 contents are then merged with freqc_high (and a possible extra overflow) to give your frequency.


When I did my tests on REAL PIC's I:-

(1) Used the CCS code for a 16F877 exactly as is.
(2) Connected T1 clock input to the external clock.
(3) Got a readout of 2,000,002 Hz.

What that's telling you is that the during 5 million machine cycles T1 clocked 20,000,002 times. An error of half a machine cycle!

I then recompiled the '877 code as is for an 18F458 and got a measured frequency of 20,002,246 Hz. In other words the code is not totally portable across PICs. There's an error creeping in of around one part in 8900. Converting to a different PIC means taking the sample code apart, working out (in detail) how it functions, then modifying to suit. You may have to play at being a computer pushing numbers around to get there.

Have you actually got a crystal (or preferably a module) which works correctly as an external clock? If you have, you can use the reality check test. It doesn't matter what your real clock frequency is, you will always get the same apparent measured frequency of close to 20MHz when the system measures itself. You MUST start from KNOWN GOOD hardware, else you're wasting your time.

Mike

[maria100]

Ok, I noticed something. Ttell me if I'm right. I compile the software and when I import it in the PICKIT2 software...on the OSCCAL LINE..it does not say anything. Is possible that CCS do not export the fuses too?

[Mike Walne]

Sorry, can't help you. I don't have any version of PICKIT. I use MPLAB ICD2.

Mike

[maria100]

The main problem with the source code offered by CCS is that the controller can't do anything beside measure a frequency because it will "waste" a second. I need a way that I will read the timer and go along with my code (receiving serial data). Is that possible?

[Mike Walne]

Yes, of course you can.

I did not get that impression from your latest codings.

You see code of the delay_ms(xx) variety also ties up the PIC completely.

Some methods spring to mind.

(1) Polling.
(2) Interrupts.
(3) Hybrid of (1) & (2)

Polling.

In polling you perform ALL of your tasks in turn. Each task is designed to take a specific number of machine cycles. Each task must take the same number of cycles which ever code path it follows. For example the UART takes the same time whether there is anything to transmit/receive or not. The different tasks can have different allocated times.

Interrupts.

Make your tasks interrupt flag driven. Eases your timing problems, but they don't totally go away.

Hybrid.

Use a hardware clock to drive the polling timing, i.e. make each task give up after a fixed time. (Sort of multi-tasking approach.)



Which ever route you choose you will need to become familiar with watching your timings to the nearest cycle or so.

Good luck.

Mike

[Mike Walne]

OK. I've had time to think about it.

I'd use interrupts.

Assuming the PIC processor has priority interrupts.

For the frequency measurment gate timing I'd use high priority, everything else low.

Even if say a UART or ADC are being serviced, the high priority request will be dealt with promptly.

Then there are two major tasks to consider amongst others:-

(1) Creating the timing gate.
(2) Handling primary pulse counter overflow.

I'd use timer2 to create gate period. I find it's easiest for timer2 to generate non-power of 2 clock periods (makes the maths simpler).
Let the primary pulse counter overflow generate an interrupt.

At the end of the gate period, the issues to decide include:-

(1) Has the gate period been extended (or curtailed) for some reason? Is the gating period being affected by other activity?
(2) Is there a genuine primary pulse counter overflow to be handled? If you're clumsy you could miss a complete 65,536 count!
(3) Do you need to allow for the time taken to get into and out of interrrupt routines? Interrupt overhead can be greater than allowed error margins.

Deal with the above and correct.

Then TEST, TEST, TEST. Envisage ALL the possible situations which can arise under ALL possible conditions. Devise tests to provoke worst case scenarios.

If you don't, Sod's law will catch you out.

Mike

[maria100]

haha..you are kind of funny..regarding the project i will do as you told, and after that i promise to post my results..thank you:)

[Mike Walne]

The code below generates an interrupt driven 100ms gate period.

What happens is the start and stop both occur following a delay after a T2 overflow.

We don't need to know what that delay is, it does not matter as long as both are equal, hence the padding.

[Jhonny]

I would like to ask for help:
I use the word "EX_FREQ.C" code, but the sampling period of 1 second too long. What do you have to change to 1ms, 10ms and 100ms time be?
Possibly can be selection use the a constant to be switched to sampling time?
Thank you very much if someone would write a piece of code! (I use PIC16F886 @ 20MHz crystal)

[dyeatman]

Before jumping in here and asking for someone to write your code for you
how about READING the post just before yours. Mike has done most
of the work for you.

Take the time to READ and UNDERSTAND the code he has written, which is
well commented, and the answer should be fairly clear.

Changing Mike's code to any sample time is pretty straightforward if you
understand what he provided.
_________________
Google and Forum Search are some of your best tools!!!!

[Jhonny]

Dear dyeatman!

Thanx comment, but:
1., Mike uses 16MHz, but I use 20MHz
2., As I write now, I'm just a "EX_FREQ.C" code and I want to modify. I do not want another (new) code.
The rest is all true what you wrote. (The code is hard even for me to understand because I am an absolute beginner)

[dyeatman]

Are you here to learn or just finish a school project assignment?

If you are here to learn you need to understand the basics about how
frequency counting works.

The code basically does two things:
1. creates a measurement period
2. counts the number of cycles that occur within the measurement period.

The number of cycles counted during the selected measurement period
and a little math gives the frequency.

Examples: multiply cycles in 100ms by 10 to get number in a second (Hz)
multiply cycles in 500ms by 2 to get number in a second (Hz)

Shorter measurement periods typically give less accuracy.

The CCS version is much harder to understand because it uses delays rather than
a defined period like Mikes does. Mikes version is much cleaner and
easier to implement.
_________________
Google and Forum Search are some of your best tools!!!!