Model data

It's a rather complicated question, because I don't understand enough your mixer, neither Walkera's approach, especially the order of the their parameters applied.

I don't see how the switches may be configured, that controls your mixer? May be I should read the er9x guide again... Have you implemented their whole concept, or just a part of it? What are the differences?

I see scaler can be the "rate" of the original, but how you define it switchable to offer dual rates? And in the original it all depended on the flight mode switch also...
In case of helis we should switch stick input to different output channel depending on the flight mode switch: in normal mode we control the throttle, while in stunt modes we control the pitch, while the throttle provided by only a mix...
Do the switches switch the whole mixer for an input or channel, or can they switch some parameters of that independently, for example just the scaler or just the curve?

The curves can be ported easily, because you have a 7 point PWL curve. Only the optional points should be calculated and always added.

I implemented the er9x system almost as-is, but did not implement the dual-rate/expo as a pre-filter. Instead the template will automatically define multiple mixers to get the desired behavior. We may need a new template or moodify the existing template to handle the flight-mode switch.

Here is the DR template. There is only 1 screen for input, but it is implemented as 2 mixers:
1) ch = If (! dr_switch) Input1 * rate1 * curve1
2) ch = If (dr_switch) Input1 * rate2 * curve1

To do flight mode, you'd need something like this:
Here is a collective definition (throttle stick controls the collective in both modes, but with different curves)
1) var1 = If (! fmode) Input1 * curve1 //This is a 2d curve
2) var1 = If (fmode) Input1 * curve2 //This is a 3d curve
3) collective = If (! dr_switch) var1 * rate1
4) collective = If (dr_switch) var1 * rate2

The throttle could be the same, using an 'idle up' curve for 3dmode, or it could be a function of a different channel (like the collective or a mix) for 3dmode.

Note that after defining a dual-rate mode (and pressing 'ok'), you can switch to 'complex' to see how the mixers were actually configured.

I've decided to try using INI format for the model data. It won't be as compact as a binary implementation, but it is easy to use, and I found a tiny parser for it here:
code.google.com/p/inih/

I implemented a simple 4-channel model using it which was 570 bytes, though that includes no curves.

The biggest issue with using INI files is that the file-size is not fixed. That may not play well with my FAT driver.

I haven't yet implemented save functionality, but that is up next.

Hi! I'm back from the holiday.
You have done amazing job in a week!

The ini format is dense enough if you keep the names short. (...and if don't waste the file size on spaces... )
You can reduce it even more if there are default values for each settings, and do not write them if they are equal to that.
What's the problem with the FAT driver? The files use 4kB blocks anyway, don't they?

Well, I compiled and run, and it saved the model config to a new file the exact way I have just wrote...

FDR wrote: Well, I compiled and run, and it saved the model config to a new file the exact way I have just wrote...

Yep, I'm already a step ahead of you.

As for the FAT filesystem. the petitfat driver I'm using doesn't allow resizing a given file. The main reason is that there really is no way to do it without using a 4kB buffer to hold the sector while you flash and rewrite it.
Since I don't want to do that, I came up with a hack:
1) store all data on the flash chip inverted. This means that 0x00 will be stored as '0xff' (which is the erase state of the Flash). It has the side-effect of not abusing the Flash rewrite as often too, since FAT is a '0' heavy filesystem.

2) clear the lowest three nibbles of a given file's size on write. You can always do this even if the bytes have been previously written because of how flash works.

So this means that as soon as you write the ini file, it will get a size of 4095 with all the unused bytes being read as '0x00'. This allows the firmware to write the ini file of any size 0-4095 bytes without needing to rewrite the directory structure.
The code will still read an ini file that was copied in so the user doesn't need to format it this way.
Currently with every single parameter different from the default for all channels using 13-point curves everywhere, the maximum size written by the firmware is ~3kB. That will likely grow as we add more capabilities and/or channels. If we ever see realistic firmwares going towards the 4K boundary, I'll probably need to use a full-featured FAT driver, but for now, I think this will do.

Yes, the fixed size fixed position Walkera approach has benefits when writing to the flash: only the changes will be written.

The file size can be further reduced by using shorter names, however it worsen the readability. But if you would use 4 char names all the place, it would ease porting it later to the DEVO 7 display...

How many channels and mixers give the 3k size?