PhilHornby
Senior Member
I have an old project, that I have recently been doing some work on: it's a 14M2-based 'Battery Capacity' tester. Basically, it uses various PWM settings to drive a MOSFET (via a resistor and capacitor) to achieve controlled discharge currents, with the attached cell run-time measured and displayed on a 20x4 LCD.
The program uses two tasks on the 14M2, one does the voltage monitoring and controlling, the other updates the LCD and logs via HSerout (with a software interlock between the two). A while back, the program expanded into the 2nd 14M2 slot - and although the code that runs in Slot #0 doesn't actually need it, two tasks are employed in both slots (Slot #0's 2nd task just suspends itself when it runs).
When the battery measuring run completes, the PWM is switched off and current flow from the cell ceases. Pressing a button triggers a "RESET" and it's ready for the next test. The strange behaviour with PWMOUT, is noticeable because of my latest modification...
I have added a facility to abort the test early ... and trigger that 'RESET'. It took me slightly by surprise to find that this didn't turn off the PWM - but I know that not everything gets reset ... so not the end of the world...
To counter this, I added a PWMOUT PWMPin,Off statement as the first line of Slot #0, Task #0 and ... it had no effect at all
(Issuing this statement before the RESET statement works, so I have a fix.)
If I allowed the restarted program to proceed, it was eventually getting back into line, of its own accord (it issues a PWMOUT 'on', a PWMDUTY and another PWMOUT 'OFF'), so ...
Is this a timing issue ... does the PWM circuitry not respond immediately after a RESET?. Or is not possible to turn it OFF, until it's specifically been turned ON?
(or is my project possessed by a winged daemon of the night ... which occasionally happens)
If necessary, I can try and distill out the essence of the problem into a much simpler program - but I wondered if anyone can spot what's going on, before I do that.
The program uses two tasks on the 14M2, one does the voltage monitoring and controlling, the other updates the LCD and logs via HSerout (with a software interlock between the two). A while back, the program expanded into the 2nd 14M2 slot - and although the code that runs in Slot #0 doesn't actually need it, two tasks are employed in both slots (Slot #0's 2nd task just suspends itself when it runs).
When the battery measuring run completes, the PWM is switched off and current flow from the cell ceases. Pressing a button triggers a "RESET" and it's ready for the next test. The strange behaviour with PWMOUT, is noticeable because of my latest modification...
I have added a facility to abort the test early ... and trigger that 'RESET'. It took me slightly by surprise to find that this didn't turn off the PWM - but I know that not everything gets reset ... so not the end of the world...
To counter this, I added a PWMOUT PWMPin,Off statement as the first line of Slot #0, Task #0 and ... it had no effect at all
(Issuing this statement before the RESET statement works, so I have a fix.)
If I allowed the restarted program to proceed, it was eventually getting back into line, of its own accord (it issues a PWMOUT 'on', a PWMDUTY and another PWMOUT 'OFF'), so ...
Is this a timing issue ... does the PWM circuitry not respond immediately after a RESET?. Or is not possible to turn it OFF, until it's specifically been turned ON?
(or is my project possessed by a winged daemon of the night ... which occasionally happens)
If necessary, I can try and distill out the essence of the problem into a much simpler program - but I wondered if anyone can spot what's going on, before I do that.