Devo7e work

I've started work on the the Devo7e port. It looks like it is going to be very challenging.
I've already removed support for languages and for the simplified mixer. Even so, the build is still 28kB too big to fit into the memory available.
I've looked at various options, and the most likely to succeed would be to do a lot of optimization of the Devo10 GUI. This will not be an easy project, and 28kB is a lot of space to recover.
An alternative would be to remove filesystem support, which would probably do it, but that would basically cripple the whole premise of Deviation, and is not something I really want to contemplate.

Latest experimental build: 2013-01-22
You do not need to do anything with the included debug zip file. It is only needed should you need to report bugs to me

To install, install the dfu, install the filesystem, then copy the 'protocol' directory to the Tx.
When upgrading you must always install the dfu, then copy the corresponding files from the protocol dir

Oops. I forgot to use the optimized printf routines.

With the optimized printf routines, I'm within 8kB of being able to fit in the needed memory.
If I remove support for ini handling, I can then actually get into the needed footprint with room to spare (which we'll need).

There are a couple of downsides of course:
1) you won't be able to load ini files from the forums onto the devo7e without converting them
2) model files won't be compatible between firmware upgrades (it may be possible to do something about that)
3) model files won't be human readable

If I take this path, I'll provide a utility to convert between the binary format and ini format.

Note, all I've done so far is to strip down the Devo10 firmware to be able to fit in the Devo7E available memory. I have not actually loaded firmware onto the Devo7e, and have no idea yet what the effort will be to make it actually work.

The main concern with the Devo12 is that the screen resolution is much higher, and there are a bunch of capabilities not available in other models (RTC for instance). So the effort to do the 12 properly is very high. The 7e should be easier since the GUI from the 10 can mostly be reused.

Now that I have a 12 in my possession, I'm sure it is just a matter of time till I start work on it.

But this thread is for the 7e

Well, I built a dfu image and loaded it onto my Devo7e without once boting Walkera's firmware. Since they haven't released a firmware upgrade for the 7e, there is now no way for me to go back

I can power on/off with the power switch, and read/write to the SPI Flash, CYRF chip, and UART, so things are going well. I'm currently working on the display which seems to be based on the sT7595 protocol (though I see an additional command in the initialization that I don't know: command = 0xea), so I'll likely have the display operational soon. after that, it is just a question of mapping the sticks and buttons, and I should have an initial functional firmware.

Moving USB support into the bootloader may be an option, but I don't think it will gain enough to add ini support which is very expensive. I'd rather not have to write a custom bootloader if I can help it though.

I will not sacrifice the protocol support over any other feature for the 7e. The main reason people choose Deviation is for the Protocol support so I will ensure that we keep them all. I didn't try it, but I don't foresee any issue attaching the V911 transceiver.

The 7e has 2MB of external Flash (half that of the devo8/10). The Devo10 filesystem takes up about 500kB (and that includes language support which we may need to remove). That leaves 1.5MB for model data. Each model is 4kB. So...around 375 models. We're actually limited in the firmware to < 256 at the moment, but I don't think you'll be running out of models anytime soon.

I've spent the past 3 days banging my head against the wall. I would have code that worked fine, and then make a slight change, and it would hang the Tx. i was able to narrow it down to adding a single 'nop' (no operation) command in main() would toggle whether the firmware compiled or not. this indicated some sort of alignment issue, and I've been chasing it for 3 days. These types of issues are incredibly frustrating to debug, so I wasn't making much progress.

Today, I finally figured out that the cause was a change introduced in September to support a newer libopencm3, which could cause this to happen under very specific circumstances.

Fixing it in a way that can support old and new libopencm3 is not really reliable, so instead I'll be updating to the latest libopencm3, and that will be required going forward.

But hopefully this will let me move forward with the actual Devo7e work instead of fighting random hangs.

I feel for you...

Does that mean, that everybody will have to upgrade the development environment?

To prevent this from ever happening again, I'm going to distribute libopencm3 with Deviation and configure it to use the local one instead of any pre-installed version.

So no, you won't need to update your build env.

Well, now that I found the bug in the linker script, I made good progress. I've gotten virtually all of the I/O mapped now, and the screen is working. I'm about ready to start putting everything together and actually building a working firmware. Hopefully some time this weekend.

I've uploaded the necessary hardware connection data here:
www.deviationtx.com/articles/18-devo-7e-hardware-connections