What would be the best GCBasic software scheme for measuring 2 PWM input signals and concurrently controlling a PWM out. Since there are only 3 I/O, and small size is desired, a 10F--- is the target. The PWM inputs are 180 degrees out of phase and do not overlap (<50% duty cycle each) and have no common edges. For maxmum response no skipping of cycles allowed. All signals are <100 Hz. with 100 micro second resolution max. preferred. All suggestions appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds like a Do While loop would work for decoding the two PWM input signals. Using a software PWM out would largely depend on how much dead time is between the signals, sounds kind of iffy at best. If it's an RC pulse train, the software PWM would work, "if" you could wait to send the PWM out during the (relatively long) synchronizing wait time.
Best to use a hardware PWM out, as it would not tie up the processor like a software PWM. The hardware PWM should allow you a cycle by cycle performance. Don't think the 10fXXX line has a hardware PWM, but the 8 pin 12f683 does.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your response. This is not a RC application, the output duty cycle needs so go near 0% and 100% at ~30 Hz.. Not sure hardware pwm would operate this slow, without a real slow clock.
Been trying to define a scheme with one consistant loop where the loop time is the time base for input and output duty cycles. Each loop would increment variables for input high and lows, perform duty cycle calculations, clear variables, etc. All while keeping track of loops needed for the output duty cycle.
For 1% input resolution the loop would have to be completed in < 50 microseconds. Not sure this will work, may have to settle for 2 or 3% input resolution to stay within 255 loops per output duty cycle, and allow adequate code execution time per loop. Also not sure how to reset the incremented values at the end of each input and output duty cycle.
Interupt on change appears to be something to use for the input PWM measurement, but not sure how to impliment such a scheme.
As before, all comments and suggestions appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even with a 20 Mhz Osc, don't see how a software PWM scheme will keep up.
If the data sheet is correct, then a 500khz internal osc, and max PR2 of 255 and timer 2 prescale of 16 would give a PWM frequency of 30.5 Hz . With a Do While Loop measuring the input PWM's, a resolution in say the 30-40 us range should still be possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have to admit I have a program for this running the input PWM's signals into 2 pole filters then into ADC inputs, with a PicAxe no less. This works with undesirable concessions. The filters are a trade off between response and jitter. The output PWM minimum is 20% due to code time, i.e. pulse out = 0 + code time. Also the input is read once per output cycle. The code for this and similar small projects is the extent of my programming.
Since the I/O is all digital, the program should be all digital also. The analog stuff is a concession to the interpreter. Sure would nice if pulse in and pulse out could run concurrently.
One other issue is the input PWM rate or period varies by +- 11%. To determine the period would require measuring the hi and low of the both input PWM's.
An example of the signals in one input period are, start with the #1 input pulse of 40% of the period, then a 10% pause with no pulses, then the #2 input pulse of 40%, followed by second pause of 10% ending at start of another #1 pulse. Note, the minimum pulse on either input is 0% and the maximum 40% pulse is 5.7 ms. Not quite sure how all this would fit into do while loop(s). Seems like interrupt on change would be something to look into.
Your comments appreciated. Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can't knock the PicAxe, if it does the job you want it to do. The interpreter chips work well until execution speed becomes an issue.
Well it sounds like right now read PWM1, PWM2, then output PWMout is all inline. If that works, then an all software solution and a 10f would work.
Interrupt on pin change would probably work. You could keep track of which pin goes high, start a timer, stop timer when low, read timer registers, start timer again, stop when high again, blah blah. There should be a couple of examples in the forum someplace.
Here is an example of Do While Loops on decoding a RC receiver PPM signal. Maybe you can get ideas on how you can incorporate this into your code. The trick is to calibrate the loop to some known standard of time. This could be done with MPLAB Simulator, O-scope or ?
For NumChannel = 1 to 3 ;four servo plus two digital
TimerHigh = 0
TimerLow = 0
Do While PPM On ;= 1
wait 5 us ;weird time but works, int osc?
TimerHigh = TimerHigh + 1
Loop
If NumChannel = 2 Then RMotorHigh = TimerHigh ;First channel
If NumChannel = 3 Then LMotorHigh = TimerHigh ;Second channel
Do While PPM Off ;= 0
wait 5 us ;weird time but works, int osc?
TimerLow = TimerLow + 1
Loop
If NumChannel = 2 Then RMotorLow = TimerLow ;First channel
If NumChannel = 3 Then LMotorLow = TimerLow ;Second channel
Next
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well Kent, It looks like the thing to do at this point is convert the analog input PicAxe program to GCbasic. That should reduce the minimum output pulse length, but won't help the response time. I'll have to work on making it all digital from there. All digital will be quite a different animal.
Thanks for the input, Please post should you have any further thoughts.
Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Bob, how are you manipulating the input PWM? Are you adding them together, multiplying, or?
If you are sampling PWM1, and PWM2 inputs and want to put that out as it happens, then just turn the output PWM on and off (or HiZ if needed) inside and outside the loops. Something tells me it must be more complicated than that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The analog program is not too complicated since the analog inputs are read at the beginning of each output cycle.
The inputs are subtracted from constants, added, then scaled for the pulse out by multiplying. Something similair would be required for digital inputs, like replacing the ADC values with % duty cycle.
To obtain the proper output frequency, the pulse out is subtracted from an empirically determined constant for a dummy pulse out that also compensates for code time. The result is code time, plus a dummy pulse out, plus pulse out = ~33 mS output period.
The output duty cycle runs in parallel with measuring the input duty cycles. Since the input and output run at different frequencies there are about 3 input duty cycle pairs for every output cycle.
The only good thing about the analog input is the input signals are always there when an A/D conversion is needed. The bad thing is the overall response is slowed by both the input filters and only measuring the inputs only once every output cycle.
Input pulses with desired output pulse.
__-___-___-___- |
| Input pulses 0-40% duty cycle each,
-___-___-___-___ | ~80 Hz. =-10 Hz.
------______-- Output pulse ~0-~100% duty cycle ~30 Hz.
The duty cycle measurement of the input signals may not be needed to compensate for changing frequency. Pulse width only may have to work. It would be acceptable for the output period to be sycronized at 3 x an input period. One input can be 0% duty cycle while the other is 40% duty cycle, or vice versa.
Reading the input duty cycle or pulse width digitally is an issue when all the pulse cycles overlap with each other. Ideally for best response the output duty cycle should be adjusted for every change in the input duty cycle. An input duty cycle can go from 40% to 0% in one cycle.
Basically the code would;
Measure #1 pulse width
Measure #2 pulse width
Do math to calculate output duty cycle
Start output duty cycle
Measure #1 pulse width
Measure #2 pulse width
Update output duty cycle. (current duty cycle may change depending on point in cycle)
Repeat Continuously
Just need to read pulses in down to 0%, with some scheme to generate PWM out.
Hope this helps define the task. Its been a long evening.
Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Much clearer picture now, thanks. Still don't know if output PWM frequency must be a certain frequency, or is arbitrary.
Well it seems the possibilities and solutions are just too numerous to settle on one scheme. As with so many things you will have to decide on what takes priority; execution time, resolution, package size, price etc. As I see it, it can go from the low end 10f six pin sot, up to an 18f 64 tqfp. Checking the Microchip parametric tables will let you search for the needed criteria.
The 10f would be an all software solution, least resolution, Do While loops.
A 12f with one CCP (capture, compare, pwm) would allow a hardware PWM out, and pin interrupts for inputs. Not sure if the interrupts do anything though because of the overlapping input cycles.
A 16f with 2 CCPx would allow 2 shared 16bit capture timer1 for inputs. The 16f737-777 devices have 3 CCPx but the input compare registers would share the same 16 bit timer1 resources.
A 18f with 2-3 CCPx would allow up to 2-3 independent 16 bit timers. With 3 CCPx (i.e. 64 tqfp), you have an all hardware PWM solution. Double check the GCBasic chipdata files for support of 18f large pin devices.
To have independent and at ready digital input channels, a 28 pin device like the 18f2525 or18f4620 (or?) would do, hardly a 10f.
Maybe this is a situation where analog is king? Or, pick your poison and get coding :-).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Started this as an analog project with a SG3525 set for 20 Hz. PWM out. Didn't like the required analog filters, even simulated a self clocking (from the input signal) sample and hold circuit for faster input response and less ripple.
In casting about, ran across PicAxe. Had a course in Basic 30 years ago, so it was fun to pick it up again. Couldn't find a way to go all digital so resorted to analog filters. Also made a program to simulate the input PWM signals, using a pot to vary the duty cycles.
Now there is an opportunity to work with a compiler to speed things up a bit and try some new things. Kind of like starting over, having to try different approaches to see which set of compromises does a suitable job.
Have a penchant for making things small, so likely would start with a 10F and see how a free running polling loop would work. Will start coding this with PicAxc to sort it out, and see if it will sort of work, slowly. Then will go to a compiler if it looks viable. Could be an exercise in banging my head against a wall.
After going through this, it looks like the 30 Hz. output PWM frequency can vary +- 10%. This would allow it to be synchronized with the inputs.
Thanks Kent for the summery, it has been good going over this with you. It may take a while to get going with GCBasic, certainly there will be more questions,
Regards,
Bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What would be the best GCBasic software scheme for measuring 2 PWM input signals and concurrently controlling a PWM out. Since there are only 3 I/O, and small size is desired, a 10F--- is the target. The PWM inputs are 180 degrees out of phase and do not overlap (<50% duty cycle each) and have no common edges. For maxmum response no skipping of cycles allowed. All signals are <100 Hz. with 100 micro second resolution max. preferred. All suggestions appreciated.
Sounds like a Do While loop would work for decoding the two PWM input signals. Using a software PWM out would largely depend on how much dead time is between the signals, sounds kind of iffy at best. If it's an RC pulse train, the software PWM would work, "if" you could wait to send the PWM out during the (relatively long) synchronizing wait time.
Best to use a hardware PWM out, as it would not tie up the processor like a software PWM. The hardware PWM should allow you a cycle by cycle performance. Don't think the 10fXXX line has a hardware PWM, but the 8 pin 12f683 does.
Thanks for your response. This is not a RC application, the output duty cycle needs so go near 0% and 100% at ~30 Hz.. Not sure hardware pwm would operate this slow, without a real slow clock.
Been trying to define a scheme with one consistant loop where the loop time is the time base for input and output duty cycles. Each loop would increment variables for input high and lows, perform duty cycle calculations, clear variables, etc. All while keeping track of loops needed for the output duty cycle.
For 1% input resolution the loop would have to be completed in < 50 microseconds. Not sure this will work, may have to settle for 2 or 3% input resolution to stay within 255 loops per output duty cycle, and allow adequate code execution time per loop. Also not sure how to reset the incremented values at the end of each input and output duty cycle.
Interupt on change appears to be something to use for the input PWM measurement, but not sure how to impliment such a scheme.
As before, all comments and suggestions appreciated.
Even with a 20 Mhz Osc, don't see how a software PWM scheme will keep up.
If the data sheet is correct, then a 500khz internal osc, and max PR2 of 255 and timer 2 prescale of 16 would give a PWM frequency of 30.5 Hz . With a Do While Loop measuring the input PWM's, a resolution in say the 30-40 us range should still be possible.
Thanks Kent,
Have to admit I have a program for this running the input PWM's signals into 2 pole filters then into ADC inputs, with a PicAxe no less. This works with undesirable concessions. The filters are a trade off between response and jitter. The output PWM minimum is 20% due to code time, i.e. pulse out = 0 + code time. Also the input is read once per output cycle. The code for this and similar small projects is the extent of my programming.
Since the I/O is all digital, the program should be all digital also. The analog stuff is a concession to the interpreter. Sure would nice if pulse in and pulse out could run concurrently.
One other issue is the input PWM rate or period varies by +- 11%. To determine the period would require measuring the hi and low of the both input PWM's.
An example of the signals in one input period are, start with the #1 input pulse of 40% of the period, then a 10% pause with no pulses, then the #2 input pulse of 40%, followed by second pause of 10% ending at start of another #1 pulse. Note, the minimum pulse on either input is 0% and the maximum 40% pulse is 5.7 ms. Not quite sure how all this would fit into do while loop(s). Seems like interrupt on change would be something to look into.
Your comments appreciated. Bob
Can't knock the PicAxe, if it does the job you want it to do. The interpreter chips work well until execution speed becomes an issue.
Well it sounds like right now read PWM1, PWM2, then output PWMout is all inline. If that works, then an all software solution and a 10f would work.
Interrupt on pin change would probably work. You could keep track of which pin goes high, start a timer, stop timer when low, read timer registers, start timer again, stop when high again, blah blah. There should be a couple of examples in the forum someplace.
Here is an example of Do While Loops on decoding a RC receiver PPM signal. Maybe you can get ideas on how you can incorporate this into your code. The trick is to calibrate the loop to some known standard of time. This could be done with MPLAB Simulator, O-scope or ?
For NumChannel = 1 to 3 ;four servo plus two digital
TimerHigh = 0
TimerLow = 0
Do While PPM On ;= 1
wait 5 us ;weird time but works, int osc?
TimerHigh = TimerHigh + 1
Loop
If NumChannel = 2 Then RMotorHigh = TimerHigh ;First channel
If NumChannel = 3 Then LMotorHigh = TimerHigh ;Second channel
Do While PPM Off ;= 0
wait 5 us ;weird time but works, int osc?
TimerLow = TimerLow + 1
Loop
If NumChannel = 2 Then RMotorLow = TimerLow ;First channel
If NumChannel = 3 Then LMotorLow = TimerLow ;Second channel
Next
Well Kent, It looks like the thing to do at this point is convert the analog input PicAxe program to GCbasic. That should reduce the minimum output pulse length, but won't help the response time. I'll have to work on making it all digital from there. All digital will be quite a different animal.
Thanks for the input, Please post should you have any further thoughts.
Bob
Hey Bob, how are you manipulating the input PWM? Are you adding them together, multiplying, or?
If you are sampling PWM1, and PWM2 inputs and want to put that out as it happens, then just turn the output PWM on and off (or HiZ if needed) inside and outside the loops. Something tells me it must be more complicated than that.
Hi Kent,
The analog program is not too complicated since the analog inputs are read at the beginning of each output cycle.
The inputs are subtracted from constants, added, then scaled for the pulse out by multiplying. Something similair would be required for digital inputs, like replacing the ADC values with % duty cycle.
To obtain the proper output frequency, the pulse out is subtracted from an empirically determined constant for a dummy pulse out that also compensates for code time. The result is code time, plus a dummy pulse out, plus pulse out = ~33 mS output period.
The output duty cycle runs in parallel with measuring the input duty cycles. Since the input and output run at different frequencies there are about 3 input duty cycle pairs for every output cycle.
The only good thing about the analog input is the input signals are always there when an A/D conversion is needed. The bad thing is the overall response is slowed by both the input filters and only measuring the inputs only once every output cycle.
Input pulses with desired output pulse.
__-___-___-___- |
| Input pulses 0-40% duty cycle each,
-___-___-___-___ | ~80 Hz. =-10 Hz.
------______-- Output pulse ~0-~100% duty cycle ~30 Hz.
The duty cycle measurement of the input signals may not be needed to compensate for changing frequency. Pulse width only may have to work. It would be acceptable for the output period to be sycronized at 3 x an input period. One input can be 0% duty cycle while the other is 40% duty cycle, or vice versa.
Reading the input duty cycle or pulse width digitally is an issue when all the pulse cycles overlap with each other. Ideally for best response the output duty cycle should be adjusted for every change in the input duty cycle. An input duty cycle can go from 40% to 0% in one cycle.
Basically the code would;
Measure #1 pulse width
Measure #2 pulse width
Do math to calculate output duty cycle
Start output duty cycle
Measure #1 pulse width
Measure #2 pulse width
Update output duty cycle. (current duty cycle may change depending on point in cycle)
Repeat Continuously
Just need to read pulses in down to 0%, with some scheme to generate PWM out.
Hope this helps define the task. Its been a long evening.
Bob
Hi Bob,
Much clearer picture now, thanks. Still don't know if output PWM frequency must be a certain frequency, or is arbitrary.
Well it seems the possibilities and solutions are just too numerous to settle on one scheme. As with so many things you will have to decide on what takes priority; execution time, resolution, package size, price etc. As I see it, it can go from the low end 10f six pin sot, up to an 18f 64 tqfp. Checking the Microchip parametric tables will let you search for the needed criteria.
The 10f would be an all software solution, least resolution, Do While loops.
A 12f with one CCP (capture, compare, pwm) would allow a hardware PWM out, and pin interrupts for inputs. Not sure if the interrupts do anything though because of the overlapping input cycles.
A 16f with 2 CCPx would allow 2 shared 16bit capture timer1 for inputs. The 16f737-777 devices have 3 CCPx but the input compare registers would share the same 16 bit timer1 resources.
A 18f with 2-3 CCPx would allow up to 2-3 independent 16 bit timers. With 3 CCPx (i.e. 64 tqfp), you have an all hardware PWM solution. Double check the GCBasic chipdata files for support of 18f large pin devices.
To have independent and at ready digital input channels, a 28 pin device like the 18f2525 or18f4620 (or?) would do, hardly a 10f.
Maybe this is a situation where analog is king? Or, pick your poison and get coding :-).
Hi Kent,
Like your last sentence, very appropriate.
Started this as an analog project with a SG3525 set for 20 Hz. PWM out. Didn't like the required analog filters, even simulated a self clocking (from the input signal) sample and hold circuit for faster input response and less ripple.
In casting about, ran across PicAxe. Had a course in Basic 30 years ago, so it was fun to pick it up again. Couldn't find a way to go all digital so resorted to analog filters. Also made a program to simulate the input PWM signals, using a pot to vary the duty cycles.
Now there is an opportunity to work with a compiler to speed things up a bit and try some new things. Kind of like starting over, having to try different approaches to see which set of compromises does a suitable job.
Have a penchant for making things small, so likely would start with a 10F and see how a free running polling loop would work. Will start coding this with PicAxc to sort it out, and see if it will sort of work, slowly. Then will go to a compiler if it looks viable. Could be an exercise in banging my head against a wall.
After going through this, it looks like the 30 Hz. output PWM frequency can vary +- 10%. This would allow it to be synchronized with the inputs.
Thanks Kent for the summery, it has been good going over this with you. It may take a while to get going with GCBasic, certainly there will be more questions,
Regards,
Bob