Pulses Counter...

[ELCouz]

Hi,

I need to count pulses (total pulses, not referenced with time) so in my mind I had the INT_EXT/ INT_IC interrupt would fit perfectly...

However, I've already have some others interrupts running (RDA and TIMER2 at low freq)

How can I calculate when the INT_EXT/ INT_IC will take too much overhead to read the pulse?

How I can verify it will not "steal" all the MCU clocks for itself, making the other interrupt problematic?

[Ttelmah]

Obvious first comment. Why not let a CCP count the pulses?.
This is one of the jobs they are for.
It'll count the pulses with no overhead from the processor, all automatically for you.

Then, all depends on how fast your CPU is clocking?. However 250Hz, is easy with a couple of other interrupts running, even at a slow CPU clock like 4MHz. It does after all represent 4000 instruction times even at this rate. Provided your other interrupts follow the correct guidelines (do what is needed, and exit quickly), each should use less than 100 instructions.

On your chip, at 32MHz, 250Hz, is 64000 instructions. You could handle a dozen interrupts if they are written properly. HIGH_INTS is for a PIC18. On the PIC24, there are separate priorities, however 'not needed'.

[ELCouz]

[Ttelmah]

Your counter, can only count pulses. Exactly what the CCP does.

If you want 32bit, then you can interrupt on the overflow and increment a larger counter.

[ELCouz]

[PCM programmer]

What about using Timer1 configured for external clock ?
The PIC24FJ128GA010 data sheet says:

[ELCouz]

[Ttelmah]

It takes less instructions to poll a flag, but it does mean your code has to be sitting in the 'poll loop'. Only needed if you really do require really high speed.

Thing to understand about interrupts, is that they set the interrupt flag, and this _remains set till the interrupt is serviced_. So if (for instance) an event triggers while the code is inside another interrupt, the flag is still set, and the event will be handled as soon as the first interrupt handler exits. This is why the golden rule is to get out of handlers quickly. A serial interrupt handler, that just reads the character, stores it into a buffer, and exits, takes perhaps 100 instructions in total (including all the interrupt overhead). Even happening at 2000 times a second, it leaves loads of time for other events to be handled. As a 'typical' example, I've got code here, with two serial receive interrupts (9600 & 38400bps), two transmit interrupts, USB interrupts, and a timer, and all get handled without problems on a chip executing less MIPS than yours....
If you make the interrupt _just_ handle what the event implies, there is no problem. However imagine making the chip wait in a serial handler, for another character, or delay for a few uSec. Suddenly instead of 100 instructions for the handler, you are up into tens of thousands of instructions, and then problems appear.

On the timer, setup to use an external clock, it'll just count the pulses. Nothing else. It will generate an INT_TIMER1, when the counter wraps from 65535, back to 0, so if you have a handler for this, and in this increment a counter for the upper 16bits, then you have a 32bit counter, that only uses any processor time every 65536 counts. 65000 times better than trying to handle it with the external interrupt!.....

On the PIC24's, the functions are split up differently to the older PIC's. So the things that were done with the CCP (counter, compare, PWM), are now done by separate modules in the chip.

It's worth perhaps getting your head round just how powerful these PIC's are. Though 'tiny' by the standard of GHz PC's, a chip like yours is executing code about 30* faster than the first desktop computers (Things like the PET, TRS-80, and the first Apple), and has more ROM (the basic TRS-80, just had 16K), and as much RAM. Yet these managed to handle keyboard, serial, display, sounds, software generation/decoding of audio for data storage, etc. etc..

[ELCouz]