I 'm now confused about why these parameters were designed and how can we implement them.
In my understanding, the actual controller output the predefined behavior in the form of control groups like main and aux. Then the PWM driver take over the responsibility to receive these abstract control signals which is under its power and send them to mixers to get what they finally should output per channel.
Thus, what mixers have done made all of the channels fall back to a flat level, without any abstract meanings from actual controller. They should be defined as pure CH0~CHx, but not Main0~8 or something like AUX0~8. Because this is done by mixer. PWM drivers only want to know the correct frequency and the range of pulse width.
BTW, I haven’ t found a driver in tree have full compatibility to these params.
This question exists for a long time but seems not very critical. But this new issue put forward the PWM related definitions again. I think It is not a defect of a single driver but, a big architecture problem. Because I really can not come up with a solution to produce such a driver with full params implemented. Any suggestions?
Something I think can help:
- Redefine these parameters. For example: “PWM_FREQ”, “CHANNELx_MAX/MIN/DISARMED/REV”. Trims seems a little difficult to achieve and needs further discussion.
- Force all units of parameters like “CHANNELx_MAX” to be microsecond(us) or nanosecond? this will unite the unit about how PWM is generated, but maybe drop support of some extreme high speed ESC?
- Update codes related to pwm output.
After these changes, the arch would look like:
- actual controller generates abstract control groups
- PWM driver generate correct pulses per physical channel.
- Mixer links two parts above together.
- There should be no way to directly change the PWM pulse outside of driver unless driver implements the calibration function or support test output in any way.
Multi-drivers also can be supported like that these groups of channel only for main output and those for aux output. What we need to do is to create two mixers and bind them correctly.
And in my opinion, these params to be defined in a fixed place like src/modules/sensors/pwm_params_main.c is fine… There is no need to have the driver to define what they use because all drivers lie in the flat level.
Another suggestion:
Parameters can be defined as offset+range to avoid duplicated trim calculation. So the PWM pulse which ranges from 1000us to 2000us can be described as middle_value=1500, range=1000us.
