Devo7e work

Thanks

It wouldn't help anyway. We can't use the flash for code-space.

What would help would be to swap out the MCU for the STM32F103RCT6, but the number of folks with the equipment to swap a 64pin LQFP package is probably pretty small.

If I could figure out how to use flash for code space, it would make things much better, sinc 2MB of flash is a lot more than we need for resources and model data.

I am currently battling RAM usage. We use too much RAM in stack and heap today.

The Devo7e identifies as being '10mW' but that doesn't mean anything. Until I can take the shield off, i won't know what it can actually do.

I got slowed down by unrelated stuff, but did manage to get Deviation to boot on the Devo7e. Currently there are no menus, and no way to save changes, so it isn't useful for anything other than testing that the hardware works. I'm struggling to figure out how to handle INI files. My original idea of translating them into binary on the PC before uploading is still very appealing, but I'm having difficulty actually doing it without a large amount of maintenance code which I don't want.

We had a discussion about this back when i decided on the ini file. to make an extensible file-format, you need to have index tables and other stuff that allows you to flexibly define parameters. While that code would probably be smaller than the code we have, it wouldn't help much. It would also mean i need to maintain 2 different slutions (since the ini syntax is far superior for tx that can support it)
using a memory-dump of the relevant structures requires virtually no code, so is ideal, but requires some mechanism to generate those files on the host-PC (ideally without needing to write/support a lot of additional code). I have an idea that I'll give a try, and see how well it works.

Lost message:

suvsuv wrote:

PhracturedBlue wrote: It wouldn't help anyway. We can't use the flash for code-space.

What would help would be to swap out the MCU for the STM32F103RCT6, but the number of folks with the equipment to swap a 64pin LQFP package is probably pretty small.

If I could figure out how to use flash for code space, it would make things much better, sinc 2MB of flash is a lot more than we need for resources and model data.

I am currently battling RAM usage. We use too much RAM in stack and heap today.

Here is a sample project showing how to run a program from external NOR Flash, I don't try it as I don't have Keil and JLink, but one of my friends told me it works. The original post is in Chinese, if you are interested, I can have the post translated in English.

Even it is possible to run codes from the NOR flash, it could be very slow and might not be usable for deviation as the TX program is timing-critical. You might consider only put some large size constants into the NOR Flash

FYI, while I haven't been around here for the last week, it doesn't mean I haven't been busy.
I've been doing major surgery to the GUI to drastically reduce memory usage.
I have a branch I'm working on here:
bitbucket.org/PhracturedBlue/deviation7e

The code as it is doesn't fit on the 7e, but I'm primarily working on reducing RAM usage. I'm targetting 6kB of RAM reduction (down to ~10kB on the 7e). My hope is that I can then fit a full page of ROM into ram, and can then run programs on the 7e. I'm then hoping I can load the protocol code into RAM. If it works out, I'll have enough room to support model ini files. As I've looked at it, I am really not happy with a solution without this feature.

The amount of work is really large, so it is taking a lot longer than I'd hoped.

So things are looking good.
It has taken a lot of effort, but I've reduced the Devo10 build by 24kB of ROM and almost 7kb of RAM without significantly changing functionality.
Part of that was done by using improved stdlib functions, but the hard partwas reworking the GUI to only allocate exactly the number of widgets needed, and removing the virtual-page support (which while easy to use was memory intensive)

The devo7e build now fits in the available ROM and RAM. I removed A7105 support (no Flysky/Hubsan) to achieve that though, so I am not done yet.

The good:
* Devo7e build has INI support (full compatibility with all model files)
* There is more than 4kB of RAM available. This should be enough to run 'programs' from Flash ROM (specifically the protocol code)
The not so good:
* Devo7e does not have language support. There really isn't much to be done here. Just not enough RAM. One possibility would be to build different dfus with the languages compiled in.
* Devo7e does not support the 'standard' mixer. It takes up ~10kB of ROM which just isn't available. Even getting rid of the 'Advanced' mixer doesn't make it even close
* Devo7e does not support the A7105 module. This is next on my list to remedy
* The changes have completely trashed the Devo8 build. merging the code is going to take a large amount of work.

Well, as I mentioned in a previous post, I've now implemented the protocols as loadable modules. This saves about 14kB of ROM (10kB if you don't count the A7105 stuff) at a cost of 4kB of RAM.
So I now have 10kB of ROM free and can support as many protocols as needed. I can use that 10kB of ROM for the 'Standard' mixer (though it doesn't leave any room for future expansion).

Now I just need to get eveything cleaned up and we should be ready for an Alpha release