Technical details on the memory issues for the 7e?

With the fork discussions, the Devo 7e has been pointed as the culprit for many new developments/features.
Most of these problems seem to stem from the limited memory on its CPU/MCU. However, after having made a quick search on the forums, I didn't find clear explanations on where the problems lies.

From what I understand, one limiting factor is the "ROM" size (ie the main program that is stored on the chip and loaded at startup) which lead to the separation of the protocols into modules that are stored loaded from flash at runtime.
- Second, the RAM in itself, which limits the size of theprotocols to around 4K.

1st,is this correct ?
2nd , is there somewhere a more comprenhensive message or thread that discusses with details the 7e limitations ?


PS : as for the code, I've had a look and wonder if (for the 7e) some memory couldn't gained on the ROM file by "compressing" or replacing the many const strings (especially in the "config/model" code) with "integer codes" and hence the hardware.ini and model.ini files. It should be straightforward to write a "converter utility" that converts to/from "uncompressed" format.

Granted, that would be quite dirty, but could alleviate pressure in both ROM and RAM.

1 - you are correct.
2 - there are no many more details than this - limited both ROM and RAM - 128k and 20k correspondingly. It would cost Walkera pennies to replace this with more powerful chip. Sigh...

There are talks of Ultimate Devo 7E, with MCU replaced with beefier STM32F103RC - it would immediately allow breathing space. And I plan to do so to my Devo - I have the chips coming today!

I thought about it a bit - not everyone would dare to replace the MCU, it looks intimidating. There is a way, much more hard from the point of view of a developer, but more palatable for modder - to have an addon board to offload larger part of Deviation there, not only protocols. Something like UniversalTx board but with larger MCU. The problem is it's hard to find an interface between two MCUs - it can not be too wide - we're limited by SPI bus. So you can't move all the drawing code to the second MCU. What you can do, is to make the main MCU kind of graphical co-processor and sensor (all the gimbals and switches are already connected to it) and move all the logic to the second MCU. So the second, larger MCU would instruct the first one to draw a button, or a text somewhere on the screen and take input from the switches, buttons, and gimbals and pass it to the second MCU. It will require a lot of work on separation the code this way, but it is the only way I can see now to both preserve the platform - Devo 7E - and make it reasonably easy to implement for individual modders.

The problem with found to an external CPU is that it doesn't really "preserve the 7e." The ability to run a standard build of deviation on an unmodified 7e is the draw here.

I think the openTx solution is a better one. Companion TX let's you select a set of options to include and then build that. Since there's no "standard" distribution, there's no need to pick a set of features to take out for the 7e.

The idea of using binary config files has also been worked on. It also needs a desktop program to create the compressed config files. The existing work was for the 7e only.

The proposed form would be taking both approaches, but not specifically to support the 7e.