Devo7E beta15 + Switch Mod will not fit in ROM

I thought I already had one for the telemetry, but I guess not. It is certainly a reasonable request.
There isn't a lot more stuff that can be added as a module. we are limited by the size of a module (currently 4096 bytes). Making the module bigger cuts into available RAM, and we have some that are very close to max-sized already.
Since we can't unload a module (your model would fall out of the sky) you can't really modularize anything other than the protocols.

Another option would be to replace the bootloader.
It may be possible to get up to 2kb back if we used a smaller bootloader, though I'm not sure it is possible to enable USB in so little code. You would definitely lose the display during programming, and it would be pretty risky (since a program failure would result in a bricked Tx). Anyhow, the Devo7e is probably getting pretty close to the end of its development range. I'm just not sure how to squeeze much more out of it.

We could also remove the standard GUI which would save quite a bit of space, but I'm sure a lot of folks still use it. Not really my preferred solution. I don't think it helps much to remove the advanced GUI, since the standard one uses quite a bit more ROM than the advanced if I recall, so having a 'standard' build and an 'advanced' build is probably not going to help much.

HappyHarry wrote: How about pulling all in needed languages?

Language support was removed long ago.
I have looked for a way to compile a specific language into Deviation so that you could do:
make LANGUAGE=tw TARGET=devo7e

and have a couple ideas but so far none have panned out. I had thought to define the _tr and _tr_noop macros to replace the string but I never found a suitable solution. An alternative is to hack the source-code before compiling it, but making that robust would also take some time, and it is a very ugly solution. The 3rd possibility I came up with was to hack the object files before linking. I didn't investigate whether that is even possible; it depends on how the compiler treats static strings

victzh wrote: Can _tr be 'sed'ed into code, loading strings on demand from filesystem?

You can't modify the binary after linking because the length of the string is different for each language so packing would get broken.
You don't want to access strings from SPI directly because (a) it is REALLY slow, and (b) we pass around string pointers everywhere which makes this hard.
You can try to fix (b) by allocating RAM for a string and copying from the filesystem when needed, but you can't know when a string is not in use and so clearing the cache becomes tricky which starts adding code again. Alternatively you could try a memory-mapped file, but this is a bit tricky to do via SPI on an STM32, and again, it would be really slow.

By far the easiest solution is to ensure the strings are swapped in the code before the linking is done, but I never put enough work into it to make it work.

so yes, your SLT driver is now bigger than 4kb.
I think you can increase the size of the module (you need to increase the size of all of them though, and going over 4096 means they will all take up 8192bytes in Flash (due to the page size)
To do so, you need to change the devo7e.ld, devo7e_opt.ld and protocol.ld files appropriately (reduce the ram in devo7e and increase the size in protocol.ld). you also need to change the loader code to load a larger size module.
You should check how much RAM 'make' says you have on the main build. You will be taking away from that (and you need to leave some free for stack operations).

Other options are to further optimize the code to try to squeeze down the size. I do this in the dsm code by storing initialization in an array and executing it in a loop, which is cheaper than a large number of function calls, for instance.

I'm not sure what you mean by 'second tier rf modules'.

I don't recall how I figured out the size of a module...It has been a while since I last did it. I think you can use 'objdump' on the .o file and look for the last address used (note that you need room for code and static RAM allocation, but not stack)
Or you can increase the size of the module in protocol.ld until it compiles, and then check the map file (I think we make one). Again the bin file won't be sufficient because it doesn't include the RAM allocation

Again, I'm pretty rusty at this after so many months off.

yes you should be able to change the size to 5k or 6k (but the space on spi flash will still be 8k per module).

The problem with having 2 modules (besides being a pain to maintain all the pointers) is that you are trading off ROM (scarce) for RAM (even more scarce). The modules must be run from RAM so every time you move code into the filesystem, that code will need to be loaded into RAM before it can be used.