DutyCycle to be updated at the end current PWM period

[khoih-prog]

Original post from @ggmichael in Change Duty Cycle #1

Thanks for this! Your library has fixed a problem I was having with inconsistent calibration, which I now think arose from the changing timing of the analogWrite pwm.

One more feature that would be nice would be to be able to command a duty cycle update to occur at the end of the next full period instead of immediately (as I think happens now). If you're trying to create a continuously variable mean output voltage, resetting the channel at a frequency that approaches the PWM frequency causes a bias towards whichever part of the duty cycle comes first. This wouldn't happen if the update occurred at the end of the cycle. It may be that there are other applications (long cycles) where you would prefer the update straight away. So perhaps a flag to set either mode.

[khoih-prog]

HI @ggmichael

I'll publish a new release to add this enhancement within half an hour for you to test the new feature. Be ready.

Regards,

[khoih-prog]

Hi @ggmichael

The new ESP8266_PWM releases v1.2.2 has just been published. Your contribution is noted in Contributions and Thanks. Please test and verify the new feature is supported and working OK now.

The library is better and better everyday, thanks to contributing users like you, who spot bugs, test and request enhancements. We, the library writers, normally can't never have enough time, knowledge and experience to know all the use-cases in the world to add the new features.

Best Regards,

---

Releases v1.2.2

1. DutyCycle to be optionally updated at the end current PWM period instead of immediately. Check DutyCycle to be updated at the end current PWM period #2

[ggmichael]

I can confirm that the new code gets rid of the 'glitch' on changing duty cycle - that's great - thanks. I think you're right that analogWrite() doesn't do this, but there's no harm in having a better implementation. (However, something is now causing the ESP8266 to reboot periodically - I have to check over my integration of the library)

[khoih-prog]

HI @ggmichael

However, something is now causing the ESP8266 to reboot periodically - I have to check over my integration of the library

If you still have that problem, I suggest you try these mods to see if it's any better

1. Increase ESP8266 clock to 160MHz from 80MHz, if not yet
2. Increase the HW_TIMER_INTERVAL_US from 20uS to higher, such as 30, 50, 100uS. For example
   ISR_Modify_PWM.ino#L46

#define HW_TIMER_INTERVAL_US      50L

The reason is the ISR-based function run() now take more time to process (double accuracy, dutycycle check, etc.)

I'm thinking, in future releases, about letting users optionally select double, float or uint32_t for dutycycle / frequency / period, depending on the use-case.

[ggmichael]

Hi Khoi, I got a previous version to work by back-integrating the main parts of your new updates. I did use floats for the duty cycle instead of double (I think double is more precision than you could ever need). The period remained uint32_t (this also makes sense to me, since this is the actual count). Frequency could also be a float, since it is always converted. So maybe this is the reason. I'll try your new suggestions when I get a chance - probably only next week.

…

On Tue, 1 Feb 2022, 14:59 Khoi Hoang, ***@***.***> wrote: HI @ggmichael <https://github.com/ggmichael> However, something is now causing the ESP8266 to reboot periodically - I have to check over my integration of the library If you still have that problem, I suggest you try these mods to see if it's any better 1. Increase ESP8266 clock to 160MHz from 80MHz, if not yet 2. Increase the HW_TIMER_INTERVAL_US from 20uS to higher, such as 30, 50, 100uS. For example *ISR_Modify_PWM.ino*#L46 <https://github.com/khoih-prog/ESP8266_PWM/blob/main/examples/ISR_Modify_PWM/ISR_Modify_PWM.ino#L46> #define HW_TIMER_INTERVAL_US 50L The reason is the ISR-based function run() now *take more time to process* (double accuracy, dutycycle check, etc.) I'm thinking, in future releases, about letting users optionally select double, float or uint32_t for dutycycle / frequency / period, depending on the use-case. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR5ZQ2XLYMJDCQALK3GE77LUY7RLBANCNFSM5NEVDMVQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[khoih-prog]

I did use floats for the duty cycle instead of double (I think double is more precision than you could ever need). The period remained uint32_t (this also makes sense to me, since this is the actual count). Frequency could also be a float, since it is always converted.

I agree with you and will make float for DC and Freq, period uint32_t. Sorry for to be too unreasonably aggressive.

Will have a new release within today.