New Application Note - High Resolution PWM

Discussion about the ZBasic language including the System Library. If you're not sure where to post your message, do it here. However, do not make test posts here; that's the purpose of the Sandbox.
GTBecker
Posts: 616
Joined: 17 January 2006, 19:59 PM
Location: Cape Coral

Post by GTBecker »

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?
Tom
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Post by spamiam »

GTBecker wrote:I cannot locate the functional difference that causes the ...Text demo to fail. Can you look at it?
I will take a look at it. It HAS been a while since I used it, so it might take some deep thought. I will get on it asap.

-Tony
GTBecker
Posts: 616
Joined: 17 January 2006, 19:59 PM
Location: Cape Coral

Post by GTBecker »

Well, one problem was that the pins weren't set as outputs, I see, but I still only have OCR1b working.
Tom
GTBecker
Posts: 616
Joined: 17 January 2006, 19:59 PM
Location: Cape Coral

Post by GTBecker »

Got it. Should be:

Const f_pwm_modea as Byte = &B0000_0010
Tom
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Post by spamiam »

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
GTBecker
Posts: 616
Joined: 17 January 2006, 19:59 PM
Location: Cape Coral

Post by GTBecker »

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!
Tom
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Post by spamiam »

GTBecker wrote:Well, one problem was that the pins weren't set as outputs, I see, but I still only have OCR1b working.
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.

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
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Post by spamiam »

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.
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.

-Tony
liam.zbasic
Posts: 163
Joined: 24 March 2008, 23:33 PM
Location: Southern California (Blue)

Re: New Application Note - High Resolution PWM

Post by liam.zbasic »

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...
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.
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Re: New Application Note - High Resolution PWM

Post by spamiam »

liam.zbasic wrote:Documentation on the physics of PWM and motor speed/torque/current would be appreciated. Thanks.
I wish I understood all the issues involved!

-Tony
Post Reply