New Application Note - High Resolution PWM
Tony, I realize it has been some time since you did this work, but your PWM application note ServoDemo/ServoDemo_In_Text project doesn't appear to work as is. The ServoDemo that uses the API does work.
I cannot locate the functional difference that causes the ...Text demo to fail. Can you look at it?
I cannot locate the functional difference that causes the ...Text demo to fail. Can you look at it?
Tom
Tom,
I agree, that is where there was a type. There was another too. The pc_pwm_maska and maskb should have been modea and modeb.
They are not to be used to mask out bits, rather they should be used to set bits to select the PC mode.
I have changed the source files, and I believe I have corrected all the errors pertaining to THIS problem. I am surprised that this is the only issue discovered so far!
-Tony
I agree, that is where there was a type. There was another too. The pc_pwm_maska and maskb should have been modea and modeb.
They are not to be used to mask out bits, rather they should be used to set bits to select the PC mode.
I have changed the source files, and I believe I have corrected all the errors pertaining to THIS problem. I am surprised that this is the only issue discovered so far!
-Tony
One aspect of FastPWM mode that I don't see stressed is that zero-percent PWM is not available; an OCRx count of zero yields a one-count-wide output.
Timer1's 16-bit counter yields, if the FastPWM full-range count is the ideal 65536, an "Off" PWM on time of 0.0015% That sounds small but it will be an error if you expect zero, and larger for smaller count ranges.
Timer2 is an eight-bit counter so one count time on it is 0.4% - for my app, quite significant - so I'm using PCPWM, which provides full 0-100% control.
Tony, the API is great. It is very useful as the tool you intended, but it is also very educational, and allowed me to strip the programming to the bare essentials and include Timer2 quite easily. Thanks!
Timer1's 16-bit counter yields, if the FastPWM full-range count is the ideal 65536, an "Off" PWM on time of 0.0015% That sounds small but it will be an error if you expect zero, and larger for smaller count ranges.
Timer2 is an eight-bit counter so one count time on it is 0.4% - for my app, quite significant - so I'm using PCPWM, which provides full 0-100% control.
Tony, the API is great. It is very useful as the tool you intended, but it is also very educational, and allowed me to strip the programming to the bare essentials and include Timer2 quite easily. Thanks!
Tom
You are correct, the pins DO need to be set as outputs. For some reason I had the feeling that when the PWM generator hardware took over control, it would both set the pin respective pins as outputs and would make it high or low as determined by the generator.GTBecker wrote:Well, one problem was that the pins weren't set as outputs, I see, but I still only have OCR1b working.
The ATMega documents do state this explicitly if you look in the correct place. In the PWM section, it mentions this for OC0A, but nothing else. In the pin definitions section, it does state that the pins need to be assigned as outputs for each of the PWM pins.
-Tony
P.S. Thanks for the compliment re: the appnote. Your needs and your adaptation of the information to Timer2 is precisely what I had in mind when I wrote the note. I had pondered the operation of the PWM hardware for a long time, beginning of the BX24. At that time I had a negligible understanding of the hardware, and I followed cookbook instructions to get things working. I found the ATMega documentation totally cryptic. Eventually, as I had more experience deciphering the Atmel documents, I mostly understood what it was doing. I wrote this note mostly as a primer on the subject and to jumpstart a persons entry into PWM.
-T
Yes, this is true. I probably should stress it more. It is a real issue and requires extra logic in the software to determine that the pulse width is zero (or at least less than 0.5 of a count) and then turn off that channel and set it high or low, depending on whether it is normal or inverted logic.GTBecker wrote:One aspect of FastPWM mode that I don't see stressed is that zero-percent PWM is not available; an OCRx count of zero yields a one-count-wide output.
-Tony
-
- Posts: 163
- Joined: 24 March 2008, 23:33 PM
- Location: Southern California (Blue)
Re: New Application Note - High Resolution PWM
I've been running the VNH2SP30 motor driver PWM in my gbot90 balance bot at 20kHz for quiet motor operation. That was a featured selling point for that driver. The bot has trouble stabilizing near the vertical setpoint. At low throttle (low duty cycle), the torque is just too low. At 5% throttle, no movement whatsoever. So I tried slowing the PWM frequency - down to 1Hz. To my astonishment, I get movement and significant torque! 250Hz was best in terms of smooth continuous rotation. Yes it whines, but I actually like the sound. Documentation on the physics of PWM and motor speed/torque/current would be appreciated. Thanks.GTBecker wrote:> No torque? Slow the PWM down. Try 14Hz, or whatever is slowest, and move up from there. The inductance (or is it reluctance?) of the motor is what you're fighting...
Re: New Application Note - High Resolution PWM
I wish I understood all the issues involved!liam.zbasic wrote:Documentation on the physics of PWM and motor speed/torque/current would be appreciated. Thanks.
-Tony