PWM + Сapture + Сomparison

[carworker]

Thanks for another lesson. I didn't know you could play with variables like that. I clearly have a problem with the compiler. FC8 is cracked. Haven't bought FC10 yet. Ordered 16f18877. So pause for now. The capture worked great on 16F887 16-bit Capture, max. resolution 12.5 ns CCP1, CCP2 input.
In theory, everything is correct and should work.
I really need to rest.

[mnfisher]

Okay - a little tidying. A silly mistake - t is a byte in Capture not a 16 bit word as it should be

I also disable peripheral interrupts around the print - pulse is also set to 0 to 'prove' that the signal is read..

Now a 2kHz square wave gives 956 / 959, 1kHz gives 1957. 5kHz gives 333.... (Note these are clock 'pulses' - rather than 'times')

8 kHz works - 9kHz locks the MCU requiring a power cycle..

Looking much better....

[mnfisher]

A bit more playing...

Setting capture to every 16th rising edge (CCP1CONbits.CCP1M = 0b0111; ) - and it is happily measuring pulses at 40kHz. Not bad for a 8Mhz MCU. It seems to be the max internal clock - can be externally clocked faster. - As it stands - clock is set as 32MHz but the 1s delay is running aa 4s (should have run a blinkie, my efforts to get it to PLL x 4 failed)

I currently also have a 12F1840 wired up - so might try that too (and that does run at 32Mhz)

Martin

[carworker]

Hi Martin! I have good news. The FK8 compiler agreed to cooperate and I launched your project with my 16F913 chip. In the macro, I changed the local variable to global. In the global settings, I have a 20MHz quartz, so what the display shows is a mystery. It is important that the capture works. This is a big plus in favor of the FK10. Now I need to launch a project where pulse duration measurement is implemented. In this project, the compiler does not understand expression CCP1CON.0=~CCP1CON.0; //change capture mode rising /falling front. Thank you

[mnfisher]

Looks like you just want to toggle bit 0

CCP1CONbits.NAME = ~CCP1CONbits.NAME

Where name is the name of the bit field should do this...

Martin

[mnfisher]

The display should show number of 'ticks' of TMR1 between measured interrupts - so this can be set to every rising / every 4th or every 16th for example.

The 'actual' time depends on the clock frequency - which will vary depending on FOSC.

The results I get are very consistent. It is worth disabling peripheral interrupts whilst displaying the count - the value could actually change whilst calling the PrintNumber routine (as it is a 16 bit value it will require at least two instructions - so an interrupt could occur between them - increasingly likely at higher frequencies being measures.)

What values are you getting - and is there a pattern for different measured frequencies?

Martin

[carworker]

Hi Martin! I use a generator with fixed frequencies of 400, 1000, 4000 Hz and with variable PWM. Depending on the frequency, the values ​​​​on the display change. For example, 400 Hz - 12504, 1000 Hz - 49933, 4000 Hz - 12293 with a clock frequency of 16F913 - 20 MHz. I have not yet dived so deep and am still studying how to get the real value of the TMR1 interrupt frequency on the display depending on the clock frequency of the chip.
I want to ask a stupid question. Which C record should assign the value of a register or register bit to a global variable?

[mnfisher]

The capture looks to time 1 (or 4 or 16) - interrupts. So although we have a delay - we are not timing all the pulses in 1 (or in my case 4) seconds - and the time elapsed would be the length of the delay (assuming timer 1 hasn't overflowed). We do, however, need a delay - otherwise the display will be constantly updating and probably unreadable.

An alternative approach is to count the interrupts over a known period (on pin rising count = count + 1) - which is the way to go if the MCU doesn't support capture (and there are several examples of this on the forum for AVR MCUs)

So - for 400Hz - you should get a 'time' corresponding to 0.0025s - and this will reflect the number of TMR1 ticks ( the length of which depends on the clock speed of the MCU and also if there is a pre-scaler) However - 4kHz - should give a count of 1/4 of that at 1kHz - so looking at your figures 1000Hz -> 49933 and 4000Hz gives 12293 (1/4 of 49933 = 12483) - which I think is pretty good and certainly with in the probably limits of accuracy.
400Hz - TMR1 will have overflowed (at 65535) - the expected timing would be 124830 which is too large for a 16bit integer to hold...

So - you could possibly try timer 1 with a pre-scaler (for example TMR1 runs at 1/4 of FOSC) then 400Hz would give ~31200 ticks and 4kHz ~3073

Martin

[mnfisher]

I modified to run with a PIC12F1840. Running at 32MHz and capturing every 16th rising edge it can measure 320kHz (or more) (giving a count of 380 at 320kHz)

1000006184.jpg (87.02 KiB) Viewed 2585 times

Here measuring an 80kHz signal - which the scope shows as have 12.5us between rising edges - so 16 count is 200us. (1/80000 * 16 - so the maths corresponds )

At 32MHz (8MHz instruction rate / FOSC as each instruction takes 4 clocks) - we have TMR1 ticks taking 1 / 8000000)

This calculates to give a count of 1600 (0.0002 / (1 / 8000000)) - so allowing for clock errors etc - I'd say the result is pretty good....

Note the code is almost identical - need to select the input pin (can be RA2 or RA5 - I use RA5 to allow use of i2c - however hardware mode doesn't work (a bug?)) - the 'connector' to the right is for PicKit connection. The scope is also attached to ground (on the display) and RA5), signal generator attached to RA5 and VSS pin

For measuring lower pulse rates we need either to set a lower clock for the MCU, or a prescaler for TMR1 (or both)

It would also be possible to count the interrupts and 'average' the pulse length (as it stands it measures the time of the last 16 rising edges before the peripheral interrupt is disabled) As is it can measure down to ~2kHz (a count of 64068)

Martin

[carworker]

Hi Martin! It looks like I managed to measure the pulse length. But I'm not sure if I did it right. Please take a look.