Some things about PWM driver

[albi]

It is because it would have to recalculate the duty cycle for all channels, the information is not stored in the driver but only into the comparator registers. It would be possible to scale the values into the comparators but there would be issues with rounding or truncation.

I understand the point, if the aim is only to re-configure the pwm after start, no problem.

The setting is effective starting next cycle so there should be the time to re-enable the channels too, depending on when the change is started.

be careful, when the timer is drived to max frequency, if the update fall near the wrap point of ARR, could happen a wrong update of one cycle.
I think that both new values, pwm frequency and duty, ​​must be prepared in advance and that the update must be done in the most possible atomic way

Uhm, about the fixed time-on, is it a good idea to assume it as default for variable frequency mode? .

Yes, in my experience, fixed "on time" is the default mode when variable frequency is used. The ARR value (pwm pweriod) span from comparator value (on time) +1 to 0xFFFF

supporting this mode would be simple

yes, when, in a few days, I will try the new driver features, i will also test a variable frequency routine

IMO, define the value of pwm cycle as frequency is generally a most commonly used term than pwm period, it might be better than the control function set the frequency and then add one or more macro to allow the input value as period (nS/uS/mS as input units)

Alberto

[Giovanni]

I just see a problem with the atomicity thing. Changing frequency and duty cycles of all channels atomically is not possible unless the timer clock is suspended/stretched somehow (and I don't know if that would be a good idea), this regardless of how close you perform the above operations, this is why i wrote "depending on when the change is started". Starting a change from the periodic callback should be safe because the available time would be guaranteed: 1 cycle time.

Anyway OK, I will remove the channels disabling from the trunk because the fixed width mode is a very good point.

About changing from period to frequency, that would introduce truncation/rounding problems, working in tick units probably is safer, conversions can always be performed outside the driver.

Giovanni

[albi]

Anyway OK, I will remove the channels disabling from the trunk because the fixed width mode is a very good point.

I suggest to not modify pwm_lld_change_period and add a dedicated function like pwm_lld_update_period

About changing from period to frequency, that would introduce truncation/rounding problems

in pwm the exact value of cycle frequency isn't a mandatory requirement, a little rounding of can be accepted
the mandatory requirement is the on/off time ratio or 'on time' duration, this should be done choosing the highest timer resolution possible

[Giovanni]

I will take a bit of time about this change, probably it is possible to remove that "enabled_channels" field at all, this would save significant code space. The period change function would become simply a macro with a bit of inlined code.

Giovanni

[albi]

I wont clarify a bit my point of view (of an user point of view):

The pulse wave modulation is pertinent to a specific field of applications, motors drive, power conversion, dimming etc.
during this work, arbitrary values are continuosly passed to update the duty-cycle or frequency with costant rounding/truncations of registers value
In this optic, for example, the catch of improper values off arr in config phase, to avoid rounding/truncation is a non sense.

The actual pwm driver is only a partial implemetation of all necessary features of a complete pwm system.
lack three-phase generation, break input management, analogs inputs managements, encoder management, dual slope pulse centering etc...
the way for the finish is is still long. this driver should implement the interface in a manner appropriate to the primary scope.

The generation of precise frequency or pulse or 'one shot' timing and also the misuration of periods by the input capture
are a completly different field of applications, mix toghether pwm and these, to an unique driver, add unnecessary difficulty
and the interface, risk of becoming weak.

That does not mean you can not have parts of code in common. A common part of driver code, as a file containing init, start, stop, could be included in to
each specialized driver.

Alberto

[Giovanni]

I understand, it remains to be defined if this more complex system can be built on top of the simple PWM driver or it has to be something different.

Interesting problem, I think we should start from requirements rather than progressive changes to the current PWM implementation. From your description it looks more like a complete application layer than a mere device driver, probably multiple device drivers would be involved and glued together by the upper layers.

Giovanni

[albi]

Sorry for delay, the time running quick.

it remains to be defined if this more complex system can be built on top of the simple PWM driver or it has to be something different.

I think they can, provided it has clear boundaries, which related solely to its specific use. IMO this is a very good job, I see no reason to abandon it for something else.

I think we should start from requirements rather than progressive changes to the current PWM implementation

could be a more correct general approach.

From your description it looks more like a complete application layer than a mere device driver

I described a borderline case, is very difficult develop and test all those things, without an adeguate harware,
but you can lay the foundation (the as possible, of timer extended features, usable in pwm applications) to allow users to develop its own application layer.

probably multiple device drivers would be involved and glued together by the upper layers.

Yes, I think that development must be done keeping in mind to converge to this type of structure, if will possible of course.

Alberto

[Dave_fr]

Hi,

Random question : "how do associate a physical processor's pin on which you want the PWM signal to happen with a PWM channel ?"

Best regards,

Dave

[Giovanni]

PWM channels cannot be associated to arbitrary pins, those are hardwired to specific TIM outputs and to specific pins, the information you need is on the STM32 Datasheet (note, not the Reference Manual).

Some timer outputs can be remapped to alternative pins using AFIO registers.

Giovanni