-
Notifications
You must be signed in to change notification settings - Fork 0
PWM to drive over 16 channels #1
Comments
Hi @LaurentR59 The current 16-channel limitation is artificial and arbitrary decided to avoid overloading the board. I'll create a new version for this feature. Anyway, I'll make it configurable in users' code, and will be max 48. But I think for slow PWM (low PWM frequency), the max number of channels can be very large. Is that value 48 reasonably large enough ? You can also use many Timers, if available, by adding the Timers and similar code for 1 Timer.
With DxCore, you can move millis() to other Timers, such as TCA, TCD |
Hi
48 is really large number but will be helpfull a lot and d ne perfect for slow timings and could cover a large range of usages with many cpu pin version.(8 to 48 or 64!)
Usually it s required to avoid led flickering so. 50/60hz or 100/120hz is good and enough! ( specially for video) Should be adapted for code facility around these values or possibilities.
Probably as an extension il d helpful to have such extent capacity for all of your others pwm_slow libs (rp2040, atmega, avrmega,… ) on same kind of build if possible. (Easiest way to build code project by #if defined(xxxcpu model xxx) and including header files and some variables for modular approach with similar core code between the different lib usages
Sorry to requiring so much change!
Anyway sincerely really appreciate!
Regards
Laurent
Envoyé de mon iPhone
… Le 25 août 2022 à 17:41, Khoi Hoang ***@***.***> a écrit :
Hi @LaurentR59
The current 16-channel limitation is artificial and arbitrary decided to avoid overloading the board. I'll create a new version for this feature.
Anyway, I'll make it configurable in users' code, and will be max 48. But I think for slow PWM (low PWM frequency), the max number of channels can be very large.
Is that value 48 reasonably large enough ?
You can also use many Timers, if available, by adding the Timers and similar code for 1 Timer.
other is to get capacity or possibility to move millis() on a TIMER A type? (not sure it would be well managed by dx core or megacorex and megatinycore?)
With DxCore, you can move millis() to other Timers, such as TCA, TCD
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
OK, hear you, I'll set max number of channels to 64 and configurable in your code. Will modify those slow PWM-related libraries similar way. The next release will be out within today. Please test then, with max 64 channels, if possible. |
Hi @LaurentR59 The new Dx_Slow_PWM releases v1.0.1 has just been published. Your contribution is noted in Contributions and Thanks Looking forward to receiving more contributions from you. Best Regards, Release v1.0.1
|
Our messages cross temselves!
Configurable value up to 64 is just perfect!! ( cover all case hardware)
And can be set to requested level
Thanks
Laurent
Envoyé de mon iPhone
… Le 25 août 2022 à 20:50, Khoi Hoang ***@***.***> a écrit :
Hi @LaurentR59
The new Dx_Slow_PWM releases v1.0.1 has just been published. Your contribution is noted in Contributions and Thanks
Looking forward to receiving more contributions from you.
Best Regards,
Release v1.0.1
Make MAX_NUMBER_CHANNELS configurable to max 64 PWM channels
Remove debug codes possibly causing hang
Improve debug to use Serialx port automatically according to boards
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
You now just declare in your code (any number up to 64). Will be trimmed to 64 if bigger than 64. Dx_Slow_PWM/examples/ISR_8_PWMs_Array_Complex/ISR_8_PWMs_Array_Complex.ino Lines 39 to 40 in fd34060
|
Hi
64 channels means that 64 I/O pins existing and can be used if they’re aivalable.
48 pins CPU Like AVR Dx Ofer only 41 I/O
64 pins version propose 55 I/O
32 pins CPU match with 27 I/O
Same on atmega or megatiny.
So 64 is over physical capacity according to one pin per channel rule. ( or I might wrong !?)
64 is may be « pleasant for factor 2 » settings?
On rp2040 only 30 I/O
So may be compromised around 32 ( or 48 as max but I think 64 is too much and without target usage for existing cpu although it could cover largest 64 pins cpu)
With only curiosity nano avr128da48 board I could not make test over the limit explained earlier.
But I will for more Than 16 like 24 on my labo board.
Laurent
Envoyé de mon iPhone
… Le 25 août 2022 à 20:14, Khoi Hoang ***@***.***> a écrit :
OK, hear you, I'll set max number of channels to 64 and configurable in your code.
Will modify those slow PWM-related libraries similar way. The next release will be out within today.
Please test then, with max 64 channels, if possible.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Is your feature request related to a problem? Please describe.
if the need is over driving 16 channels, it means we must to use another object for 16 additionnal channels if I m not wrong?
juste to be sure how to process on that case.
So what happen if non other hardware TIMER still available?? (usually One is for millis(), one will be for ISR_Timer interupt generating this PWM, another one can be keep for core operations (in my case NMRA DCC signal management).... so few solution available!
Worst case on megatiny CPU with less TIMER ( A0 B0 B1 only)
Describe the solution you'd like
May it would be possible to limit frequency ( ex between 50hz-120hz range and add PWM channels on the 16 ones on the initial range as a way? (may be not at all!)
Describe alternatives you've considered
using biggest hardware on the family to have enough TCB Timer ressources is the intial possibility if available!
other is to get capacity or possibility to move millis() on a TIMER A type? (not sure it would be well managed by dx core or megacorex and megatinycore?)
May require some additionnal settings according optional links between TIMER A type and B type.
using millis on same timer as the one managing PWM? (stupid way? uncompatible?)
Additional context
optimisation of selected hardware according usages needs specially for limited TIMER numbers.
The text was updated successfully, but these errors were encountered: