Dynamic I/O Allocation

[raul-ortega]

It seems that in betaflight has been implemented a dynamic allocation of resources (pin functions) which could solve some problem for some users in some boards:

https://www.rcgroups.com/forums/showpost.php?p=36069013&postcount=686

An example: In the case of current sensor, I don't use it, and could use that pin for RSSI throuht ADC without the need of commenting/uncommenting define lines and compiling the source code.

Could be possible to implement it in iNav?

[digitalentity]

While Dynamic IO allocation adds flexibility of pin assignment, it also will add hard to track issues.

Betaflight gets away with this because they only use one platform - QUAD, don't use servos and things like that.

With INAV it will create unnecessary complexity and reduce user-friendliness to an average user (geeks excluded, no offence ment 😄)

I am, however, not entirely against this feature, but its very immature and without proper UI it's going to be useless or even harmless to 90% of users.

[DzikuVx]

Possible? Yes. Easy port from BF? Rather not. BF ignores servos, INAV can not ignore servos and that creates a bunch of problems: not every motor/servo combination is possible. They can not share timers and so on

[hali9]

I think it is a great idea.
Solved by a lot of problems.
For example, I do not use RSSI, current and voltage.
I would like for it to have an extra servo. (#794)

I do not agree with that:
"With INAV it will create unnecessary complexity and reduce user-friendliness to an average user (geeks excluded, no offence ment 😄)"
There is thing as a default value
It may be set by default as it is in target.h.

"and without proper UI" - just use CLI (like mmix, smix).
betaflight/betaflight#1189

Not only do I wrote about it: #271
I understand the problem with timers, but I think that this functionality could to solve it.
For example: SPRACINGF3 target.c
TIM16, IO_TAG(PA6), TIM_Channel_1 PWM1
TIM17, IO_TAG(PA7), TIM_Channel_1 PWM2
TIM4, IO_TAG(PA11), TIM_Channel_1, PWM3
TIM4, IO_TAG(PA12), TIM_Channel_2, PWM4
TIM4, IO_TAG(PB8), TIM_Channel_3, PWM5
TIM4, IO_TAG(PB9), TIM_Channel_4, PWM6
TIM15, IO_TAG(PA2), TIM_Channel_1 PWM7
TIM15, IO_TAG(PA3), TIM_Channel_2 PWM8
Pwm_Mapping.c
#if defined(SPRACINGF3)
// remap PWM15+16 as servos
if ((timerIndex == PWM15 || timerIndex == PWM16) && timerHardwarePtr->tim == TIM15)
type = MAP_TO_SERVO_OUTPUT;
#endif
If I have 4 serwo? Why remap PWM1 and PWM2 to serwo, and use TIM4 for motor?
In airplane may be use PWM1 for motor and oter for serwo or PWM1 and PWM2 for motor and other for serwo and ... itd.

You do not need to look in the code, change and compile.
Not doing so would require a procedure pwmiinit and a lot of terms for each target.

[oleost]

Would this also help cleaning up the channel forwarding / servo gimbal mess aswell? As discussed here #600

[digitalentity]

The thing is that different mixers will require different defaults for mappings - we'll end up having a ton of different mappings (exactly as we have now) plus an extra system (IO remapping) that will cause bugs (both in the code and in the configuration). This feature will also consume flash (which will force us to limit F1 targets even further). In general motor+servo can work together on a shared timer only on same pwm update frequency. BTW that's the reason we don't have servo support for multicopters on some boards. I'm not against the feature in general, but we need a clear implementation that will a) fit into flash on F1 targets b) will be fool-proof - this implies that code must be able to prevent hardware resource conflicts c) will support motor/servo and multi/airplane mixers - apparently current code in Betaflight doesn't

…

On Fri, Jan 27, 2017 at 8:02 PM, oleost ***@***.***> wrote: Would this also help cleaning up the channel forwarding / servo gimbal mess aswell? As discussed here #600 <#600> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1145 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKi_m9i63WWeVS8ay6arwQuab-d5c8isks5rWcCmgaJpZM4LpPVe> .

[vinicentus]

I believe betaflight has servo support in the resource remapping

[stronnag]

Perhaps you could explain how it works, digital servo and multishot ESC. Countless hours of following obsolete wiki leaks results in reflashing iNav so I can get decent performance out of my tricopter as I can't find workable betaflight solution.

[digitalentity]

Try putting Betaflight on airplane and get servos to work.

There are great many possible scenarios of output assignments and only a handful of them will be
functional when servos are involved. The majority of possible remap configurations will lead to either non-functional setup or burned servos. To limit amount of bug reports like "servos not working" INAV is not implementing resource remapping.

Once again - to get resource remapping into INAV we need the solution that will satiafy all of the following:

• fit into flash on F1 targets
• will be fool-proof - this implies that code must be able to prevent hardware resource conflicts
• will support motor/servo and multi/airplane mixers

[isilcala]

Personally, I think it doesn't have to be specifically 'Dynamic I/O Allocation'. I believe mostly the original goal is enabling software serial on some boards for telemetry, especially Omnibus class. If implementing 'Dynamic I/O Allocation' is challenging in iNav, perhaps some other smart way can archive it as well? Or the worst case, a special build like the 'CC3D PPM1'? I understand a custom build is an option but if this is one of the most common needs and not everyone can do it in the right way, a special build can at least solve some real problems.

[cmanley]

If this will allow one to use boards with only 4 output channels (such as nano omnibus boards) for 4ch planes then this will be a great improvement. The current limitation of reserving the first 2 outputs for motors when only 1 motor output is used means that those boards fall short of 1 output channel.

[digitalentity]

There is a reason why we reserve two pins for motors and don't allow them for servos. Hardware timers on STM CPUs generally can't be shared between ESC and servo outputs (unless they run same PWM frequency). Same is true for softserial, ppm/pwm input, ledstrip etc. Because most boards are designed without airplanes in mind - we have to figure out timer configuration that works for as many setups as possible.

Giving users ability to freely remap timers will cause a flood of "bug" reports with either "burned servo" or "non working ESC" or simply "nothing works".