PWM + Сapture + Сomparison
-
- Posts: 18
- http://meble-kuchenne.info.pl
- Joined: Sun Jan 01, 2023 11:01 am
- Location: UA
- Contact:
PWM + Сapture + Сomparison
Why haven't they added capture and comparison to the PWM function yet? I'm asking for this starting with version 5. I just saw in the neighboring topic that with a weak knowledge of the C language on version 10 this is practically impossible.
-
- Valued Contributor
- Posts: 182
- Joined: Wed Dec 02, 2020 7:28 pm
- Has thanked: 74 times
- Been thanked: 63 times
Re: PWM + Сapture + Сomparison
Because it is a lot of work to add for all the different chips involved and there were other requests as well. Time for the team is not infinite so choices have to be made…
Re: PWM + Сapture + Сomparison
Huge respect to the team. This is really a huge job. But how to get out of this situation? I have several examples in C applicable to the FC5 version. They worked there. I want to switch to a fresh platform because my Windows 7 + FC 5 laptop died. For starters, I am ready to buy the PIC8 package. But the trial version is sad. Compilation with errors. I do not know C and I have no task to learn it. Perhaps Matrix will give me recommendations and ready-made examples of C for implementing the capture function for PIC 8 bits
-
- Matrix Staff
- Posts: 1416
- Joined: Sat Dec 05, 2020 10:32 am
- Has thanked: 193 times
- Been thanked: 331 times
Re: PWM + Сapture + Сomparison
The compiler used by Flowcode 5 is different to the one used in modern versions of Flowcode. One of the significant changes is the naming of the registry locations. But it should be relatively simple to change them to the new equivalents.
You are very likely to get compilation errors when you run a v5 project in v10 because things have changed significantly between these 2 versions. But you should be able to get help on this forum to create workable versions of your old projects in v10.
You are very likely to get compilation errors when you run a v5 project in v10 because things have changed significantly between these 2 versions. But you should be able to get help on this forum to create workable versions of your old projects in v10.
Re: PWM + Сapture + Сomparison
Few of those who know will want to waste their time on me. I'll try. Thank you
-
- Valued Contributor
- Posts: 1280
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 124 times
- Been thanked: 645 times
Re: PWM + Сapture + Сomparison
I had a little experiment at a capture interrupt.
Using a PIC18F1220
I connected a signal generator, and a SSD1306 OLED (i2c) display (using my own 'tiny' display component)
The displayed values are 'okayish' but seem to fluctuate a fair bit. Using a 50Hz square wave - and counting every rising edge gives a count of 190 - 203 but occasionally giving spurious values.
Clearing and resetting timer1 helped a bit... I display the 'time value' every 1s - but occasionally the interrupts mess with the i2c
Might need some work to use a different PIC - and then devise a way to get 'data' out....
Martin
Using a PIC18F1220
I connected a signal generator, and a SSD1306 OLED (i2c) display (using my own 'tiny' display component)
The displayed values are 'okayish' but seem to fluctuate a fair bit. Using a 50Hz square wave - and counting every rising edge gives a count of 190 - 203 but occasionally giving spurious values.
Clearing and resetting timer1 helped a bit... I display the 'time value' every 1s - but occasionally the interrupts mess with the i2c
Might need some work to use a different PIC - and then devise a way to get 'data' out....
Martin
-
- Valued Contributor
- Posts: 1280
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 124 times
- Been thanked: 645 times
Re: PWM + Сapture + Сomparison
I'm not sure it's quite right - the value changes (so the interrupt is called) and do bear 'some' relationship to the signal I put in...
I'll try with a different PIC (with hardware i2c). Microchip have some good docs on use of capture and compare (see https://ww1.microchip.com/downloads/en/ ... an%20event. )
I've maybe missed something - but was expecting better accuracy?
I'll try with a different PIC (with hardware i2c). Microchip have some good docs on use of capture and compare (see https://ww1.microchip.com/downloads/en/ ... an%20event. )
I've maybe missed something - but was expecting better accuracy?
Re: PWM + Сapture + Сomparison
Hi !
FCL_T = ((unsigned int)CCPR1H << 8) | CCPR1L; // Combine high and low bytes
What's happened FCL_T If T is a variable then FСV_T but I don’t see T as a variable, and it’s not clear at all .t pulse = .t
My Previous experience FС5 is a PWM pulse length meter. The frequency is somewhere around 5 kHz. The output data and the oscilloscope screen matched very accurately. When capturing events, they occur almost instantly. Faster than the INT port. It is important that the signal frequency does not exceed the clock frequency of TMR1
Thank you
FCL_T = ((unsigned int)CCPR1H << 8) | CCPR1L; // Combine high and low bytes
What's happened FCL_T If T is a variable then FСV_T but I don’t see T as a variable, and it’s not clear at all .t pulse = .t
My Previous experience FС5 is a PWM pulse length meter. The frequency is somewhere around 5 kHz. The output data and the oscilloscope screen matched very accurately. When capturing events, they occur almost instantly. Faster than the INT port. It is important that the signal frequency does not exceed the clock frequency of TMR1
Thank you
-
- Valued Contributor
- Posts: 1280
- Joined: Wed Dec 09, 2020 9:37 pm
- Has thanked: 124 times
- Been thanked: 645 times
Re: PWM + Сapture + Сomparison
FCL_ (and the '.' in .t) - correspond to a local variable in the macro. Pulse is a global (FCV_ in C code). Note that I could have assigned directly to pulse - but I actually intended to change to a union and eliminate the shift / addition for extra speed. Time ran short - I need my beauty sleep.
I'll experiment some more - in theory the PIC I used should be capable of running at 32MHz - but I'll need to run a 'blinkie'. 8Mhz was working AOK though. Not having a hardware i2c - I should probably disable interrupts from the capture before attempting to write to the display - as there were definitely problems at higher frequencies.
I also experimented with using every 4th and 16th rising edge - but the results were similar
Martim
I'll experiment some more - in theory the PIC I used should be capable of running at 32MHz - but I'll need to run a 'blinkie'. 8Mhz was working AOK though. Not having a hardware i2c - I should probably disable interrupts from the capture before attempting to write to the display - as there were definitely problems at higher frequencies.
I also experimented with using every 4th and 16th rising edge - but the results were similar
Martim