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 :smile:)

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. (https://github.com/iNavFlight/inav/issues/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 :smile:)" 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). https://github.com/betaflight/betaflight/pull/1189

Not only do I wrote about it: https://github.com/iNavFlight/inav/issues/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 notifications@github.com wrote:

Would this also help cleaning up the channel forwarding / servo gimbal mess aswell? As discussed here #600 https://github.com/iNavFlight/inav/issues/600

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/1145#issuecomment-275629769, 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".

[wx4cb]

@digitalentity - @cmanley is correct, the issue I have right now is working on the BetaflightF4 board with shellixyz is that this only has 4 "motor" outputs.. Cannot use this board on anything other than a bank and yank, however, my aircraft has 1 motor and 3 servos (Y/E/A) this would mean that this board, although completely suitable for inav, is useless for anything other than bank and yank with respect to fixed wing aircraft because the mixer specifies 2 motors.

Thoughts?

[tootomthumb]

I don't have a clue about the relative difficulty of adding the feature but I would be very happy with it. I'm trying to run a Crius AIO Racer F3 board which is very similar to the SP Racing F3 EVO. I have almost everything working but have determined the Resource Motor mappings are incorrect and would love to remap them.

The obvious advantage to this sort of feature is that it potentially opens up INAV to many more FCs adding to its popularity and user base...

[digitalentity]

Implementing it in a way Betaflight does it is not user friendly - it doesn't prevent resource conflicts which are potentially harmful to hardware (most notably servos).

To get resource remapping into INAV we need the solution that will satiafy all of the following:

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

Also some things to think about - many boards are poorly designed. While this may be ok for a racequad which doesn't live long enough anyway, for a long range plane that stays in the air for hours hardware flaws are critical. Allowing resource remapping will open the door to a flood of junk hardware because many manufacturers will entirely stop thinking about keeping things compatible with existing (and verified) targets.

[wx4cb]

@digitalentity but with betaflight you can't assign the same pin to multiple resources. IE, you can't have motor 6 assigned to motor 6 AND assign it to motor 5 (for a crude example). as soon as you assign an already assigned pin to something else, it takes that pin away from what it was assigned before. This satisfies your two bullet points that you made. and believe me, i've goofed up a lot with remapping.I resource map in mine all the time. that's one reason why i'm not running inav right now. the board i have only has 4 "esc" outputs so i can't use the standard airplane mix because that says. "you must have 2 motors" and "you must have 2 elevator servos". therefore right now, I can't have a rudder. betaflight mapping has fixed that for me and it works fine on betaflight controlling my 4 channel plane, although i don't get the nice things like RTH etc, I do get the OSD which is my main thing :D

[tootomthumb]

@digitalentity I thought your point about opening the door to a flood of junk hardware is interesting but not really relevant to INAV. INAV cannot police the quality of the components people choose any more than the quality and skill of their build. What's more, manufacturers will always (if they are interested in INAV) choose to build towards a standard target or they risk reducing the popularity of their board. Expanding INAV's potential user base (it isnt a big target list) increases manufacturers' interest in building to INAV spec in the first place.

INAV should keep its list of targets because that is a great indication of what boards are supported out of the box and anyone who wants to implement INAV but buys a board outside of that list is already taking risks. I'm in this situation because I built my copter with a Betaflight board and then determined it was S**T for any GPS functions. Had I known that beforehand I would have bought one of INAV's target boards.

I realise Betaflight's implementation isn't the most user-friendly but IMHO keeping it to CLI commands means the user will have to be reasonably driven and interested in the system to attempt changes in the first place. So for the first stage of implementation, it's not bad. Obviously, in an effort to build the user base it would be far better to have it implemented in the INAV configurator but all things in good time!

Regardless of where you guys go with this, it's fantastic to see that we still have one distribution which hasn't gone down the hyper-twitchy-racer-route and isn't a Pixhawk/APM, so good luck to you!

[digitalentity]

I have a suggestion for resource remapping.

For a given target we have a set of pins with possible uses (multicopter motor/servo, airplane motor/servo etc). Currently all of those pins are mapped to motors/servos depending on aircraft type.

Suggested approach:

• Keep pin list with possible uses
• Add a motor/servo mapping table to map logical motor/servo to actual pin

The difference from Betaflight is that free mapping to any given pin is not allowed. We still have the timer list with possible pin uses but we will have the power to reorder and remap within this list.

Thoughs?

[matoy]

Hi

+1 for that feature request.

Inav is great but need lots of devices to be fully used: gps, compass, bluetooth module (to plan missions on the field without a computer). If you add to that eventually sbus, smartport telemetry and led strip... That makes a lot of UARTs.

For exemple on an omnibus pro FC: Uart1 for sbus, Uart6/3 for gps/compass (scl/sda and uart3 are same pins) Soft serial ch5/6 for bluetooth module Led strip port for led strip

That would be great for example to be able to reassign unused motor5 & 6 pins to new soft serial ports to get smartport telemetry and even smartaudio for configuring vtx.

[digitalentity]

Currently we are talking about merely rearranging motor/servo outpus for more flexible wiring. More resource remapping features might be interesting to have, but we'll need to carefully think how to add those without opening a door for new bug reports.

[wx4cb]

@digitalentity yes i totally agree. being able to remap motor outputs to pins is the first thing that we should look at 😀 but in all seriousness however, both those ideas are a great starting point.

i wasn't endorsing "free remapping" remapping any pin to anything for surwe can get you downt he road of hassles. but remapping motor/servo outputs around will also help because then you could theoretically (as boards are mainly designed around quads) have an unusual board rotation to allow for the servo pins on motors 3/4 for example have to be at the back to make the wiring look tidy.

Being able to just swap them over with 1/2 would open up the possibility that now you don't have to rotate the board or have messy wiring traversing the board.

That or the other possibility of just easily making custom mixes through resource assignment (like is the issue for the BF F4) would just make a whole bunch more boards that use existing targets (SPF3 Clones for example) open to being used.

[KnuckleUpFPV]

I wish inav had resource remapping. I have had to use betaflight on two planes from not being able to change pin assignements. They both fly just fine with betaflight. However the gps support and return to home is not the best. It works, but I dont trust it as well as I trust inav. If betaflight had full on gps support like inav, it would be perfect. I hope some day we are able to change our pins to suit our needs.

[ekitru]

I wish INAV supports this feature, in my case I can't use SoftSerial on Matek405 AIO to connect smart port and telemetry on S5 (or S6) as i can do on betaflight.

it is disappointing. Right now SS just turned off from code and nothing is written in release noted about it.

[vinicentus]

I would also like this feature. A temporary solution might be to make it easy for anyone to compile a custom board configuration. Currently don't have any good ideas on how. Some kind of tool would be great

[throttlenerd]

Yes guys resource remapping would be awesome! For example, I would love to forward two S.Bus AUX channels to LED and Motor_6 pins of my Matek F405. And yes I need softserial on Matek F405, but afaik it will be implemented in 1.9, right?

[zector555]

Has there been any movement on this? I tried BF with mapping on my omnibus F4, the servos and motors worked fine, and allowed me to use other pins for s-port telemetry software inversion (downside of F4 boards). If not, can requests be made for popular inav boards for pin changes?

[blackmennewstyle]

I was so exciting for using iNAV thinking that resource remapping was implemented until i tried after flashed my board Omnibus F4 Pro with iNAV 1.9 then all my dreams just collapsed into a super nova explosion after discovering that it just does not work.

I need to remap my channel 5 & 6 to softserial_tx in order to use smartaudio and telemetry but i can't :'(

[ekitru]

I had the same issue, you can fix mapping and build your own firmware snapshot.

[blackmennewstyle]

Hi :)

How can i fix my mapping and build my own firmware snapshot?

[ekitru]

I am not a inav developer, but I think you need to visit inav slack channel and ask there

[blackmennewstyle]

OK thank you!

Enjoy the rest of your week and happy flying!

[DzikuVx]

I allowed myself to use some of my time and explain how outputs on STM32 works, how they connect to timers and why INAV has no resource mapping aka dynamic IO allocation: https://www.youtube.com/watch?v=v4R-pnO4srU

[jasc76]

wouldnt it be possible to allow just a small amount of remapping without messing with servo / motor outputs by limiting remapping to non servo/motor ports? I wanted to add a current sensot to my airbot nano v6 and need to remap pad PA1 (RX4) as ADC Input because the nano has no Current input pad by default

[diiity]

Hello,

Just like ekitru, I am interested in this mapping, can you unblock it? Thank you diiity

[tysonfromcanada]

+1

would be nice to be able to split tx and rx pins across two different serial/softserial resources as flight controllers can be limited on pins but some are re-assignable in BF.

[umeloman]

Hi all! I think I have an idea how to remap some motors. Developers, please confirm (or not) my version. I'm building a quadcopter on Matek F405-Wing, and I don't want to use S1 and S2 pads (is is far from others) and want to use pads S3, S4, S5, S6 for m1, m2, m3, m4. Taking Hexa X mix and now we have some mixer for all 6 motors: m1 m2 m3 m4 m5 m6 Throttle (1) (1) (1) (1) (1) (1) Pitch (-0.8) (0.8) (-0.8) (0.8) (0) (0) Roll (0.5) (0.5) (-0.5) (-0.5) (1) (-1) etc. yaw

Now I have edited mixer for quad inside of hexa mixer: m1 m2 m3 n4 m5 m6 Throttle (1) (1) (1) (1) (1) (1) Pitch (0) (0) (1) (-1) (1) (-1) Roll (0) (0) (1) (1) (-1) (-1) etc. yaw So I'm not using m1 m2 in mixer and I gave a functions of Quad's m1 m2 m3 m4 to m3, m4, m5, m6 outputs. How do you think?

[jettero777]

It’s really a shame that the feature is not implemented. On my FC I have only 2 spare UARTS, for GPS and Crossfire Rx, and I need also CC, SA, camera trigger, etc. In Betaflight I just remap useless LED STRIP, RSSI and other pads, here I can't do it.

Furthermore, 1 motor is not spinning currently in iNav (ESC is ok it plays in startup, and it works fine in Betaflight), probably it is misconfigured resources and timers conflicts in the target config (target FLYWOOF411, board GOKU GN413S) And without resource editing/remapping I can't debug and handle it. And very popular Flywoo Explorer LR4 uses FC with same FLYWOOF411 target, so I suppose iNav could be useless there too.

4-inch mini long rangers are trending now, almost every manufacturer start to sell such models, and FCs used there are 16x16 or 20x20 stacks with limited number of UARTs, so without remapping it will be poor user experience for those who decide to try iNav on such mini long rangers.

IMHO better to make iNav more flexible and make a possibility for using iNav on mini long range quads too.

[harryjph]

I also think this is worth revisiting. Betaflight's unified target system is so much better than the legacy target.c system that INAV is still using. Resource remapping is such a core feature nowadays in Betaflight that everyone takes it for granted until they try to use INAV and realize that unless there's an existing board definition, you have to recompile the firmware.

I also hear a lot of people complaining that creating a custom target for INAV is a pain. If INAV were to use a unified target system it would be so much easier.

[wx4cb]

Has anyone said... betaflight != inav :)

Although it would be nice, ive not yet needed a reason to remap resources :)

But to say that.... oh betaflight can do it why cant inav, its a different ecosystem tbh, and if you want to fly a quad then use a supported quad FC. If you want to fly a plane then use an fc that can do what you want.

At the end of the day, if you want a n fc to be supported then well. Get one to the inav deva. Rheyre not mDe of money and do all this for free, or heck, even work on it yourself and learn :)

Just my tuppence :)

[digitalentity]

My original comment from 2017 still stands (mostly). Betaflight main platform is just one - QUAD. They don't have to care about servos, all their outputs are the same frequency and motor protocol. INAV's platforms have much more variety and thus much more prone to issues like "I switched motor/servo outputs for easier wiring and now my servo doesn't work" or "I added another servo output and now only one motor works on my twin-motor plane".

I agree that resource remapping will add a little bit of flexibility in exchange for larger code size and higher complexity. However, the main request for remapping seems to come from F722 and F411 boards. Interestingly enough, those boards are already at the flash memory limit and if we do resource remapping those targets are going to be removed reducing the value of resource remapping even further.

[KnuckleUpFPV]

Try cleanflight. The code for wings is a bit old, but still works really well. It also allows resource mapping. If you fly in manual mode most of the time and just want return to home and loiter. Go to cleanflight. I use it on a few planes that needed mapped from dead pins. If I ever get back to school and learn to code. Ill make a seperate version of inav with resource mapping. Until then. Go for cleanflight.

[harryjph]

@wx4cb Saying that INAV shouldn't have a feature because Betaflight has it is pretty bad reasoning too. INAV should differentiate itself by doing stuff that Betaflight can't do (which it does), not by refusing to do stuff it can.

@digitalentity OK, thanks for your response. I really understand the concern with flash space and I expect you're right about putting 512K flash targets over the limit. The project that I'm working on that led me down this path is a micro hovercraft, powered by an AIO FC/ESC/RX/VTX board. I was just setting about creating a custom target.c when I realized INAV unfortunately doesn't support the FrSky SPI RX protocol either, which I assume is also due to flash space limitations. It would be nice to have resource remapping, primarily because it would make supporting new boards much easier, but I understand why it's impractical here. If only STMicro would give us a chip with yuge flash...

@KnuckleUpFPV thanks for the suggestion, however the reason I wanted to use INAV is for its Rover/Boat configuration as I'm building a hovercraft. Because of the other issues I've encountered I think I'm just gonna hack Betaflight to drive RC inputs directly to motor outputs as that's all I need in this situation.

[KnuckleUpFPV]

If all you are after is rover functions. Flash ardupilot to your fc. Bit of a pain to setup, but offers far more features than inav.

[wx4cb]

@wx4cb Saying that INAV shouldn't have a feature because Betaflight has it is pretty bad reasoning too. INAV should differentiate itself by doing stuff that Betaflight can't do (which it does), not by refusing to do stuff it can.

Actually i said the opposite... just because betqaflight has a feature, doesn't mean that inav should to

and with regards to what you want, what is it that it doesn't do that you need for a rover config? I have built 2 rovers and 1 airboat all with inav and they work great

[harryjph]

@wx4cb I think you misinterpreted my comment, I said I wanted to use INAV because it does have rover functions. Unfortunately it doesn't have other features that I also need, such as SPI RX support.

@KnuckleUpFPV I could do, but AFAIK that doesn't support SPI RX either :( and I'd still have to create a target config for my board which I'd like to avoid. I've worked around this by just hacking betaflight code to send RC data to motors, that's all I need for now as I'm not adding any autonomous functionality (yet).

Also we're getting off topic here so probably best to end this discussion!

[KnuckleUpFPV]

@harry1453 ardu does support spi. Just to give you a heads up. Agree. Off topic. Not that it matters much as the massive community request will never be met.

[stewi1014]

I'd like to throw a possible alternative into the ring. Disclaimer; I'm a software developer with limited INAV and STM experience. I'm sorry if I'm just polluting the issue.

What about supporting two or more static mappings - not dynamic - that are committed into the repository in the same way they are today.

I don't think it's a stretch to say that a decent chunk of use-cases for dynamic IO mapping are exactly identical, and beyond the identical use cases, many use cases would revolve around a single pin, be it damaged or otherwise. AFAICT, Simply having more than one static mapping to choose from would cover a majority of the use cases of dynamic mapping.

I.e https://github.com/iNavFlight/inav/issues/8582 likely applies to all users of the Matek H743 mini who wish to use it for fixed wing, and my use case which moves motor outputs physically next to eachother and opens two servo outputs for Quadcopters and Octocopters using the Matek H743-WING

I also feel like there's a number of people like me around, who aren't scared to get their feet wet and are willing to do some legwork to create valid, static IO mappings for our boards.

I really liked @digitalentity's list of requirements, so:

fit into flash on F1 targets

Complex validation of user-inputted mappings and the implementation of some generic IO mapping system is avoided. Preprocessor directives can be used to only include the feature for boards that have more than one IO mapping.

will be fool-proof - this implies that code must be able to prevent hardware resource conflicts

The only UI element needed in the configurator would be a drop down menu (maybe below Platform type). I think it's safe to say users would expect this to wipe existing mixer configuration, so I don't see any possibility of this introducing new avenues for invalid configurations or being non-intuitive.

will support motor/servo and multi/airplane mixers

Remains the same as current.

The lingering question I can't easily answer is; When the configuration is actually applied at startup, how feasible is it to select one of two or more IO mappings; as is currently set during Preprocessing.

Again; sorry if I'm not fully understanding what's going on. The main point I'm trying to make is I think there's room in the middle ground here where we can have our cake and eat it too.

I'd be more than willing to help develop this, but I would definitely need some help to fully understand how it would be best implemented and a mentor on the codebase.