GUI

You probably need to do a pull then.
You should have:
target/emu_devo8/stubs.c

I just committed the fix though. I also added timer support. If you want to know the time, you can use CLOCK_getms().

If you need to do something on a regular cadence, we can implement a callback system that does stuff on a regular interval, which would be more efficient than polling

May be we should collect the goals for the GUI too, just like you did for the model data?
I think it would be a good starting point to define what's wrong with the original.

While I think it is not too bad, let me set out my complaints:
- It is not visible enough. That was the cause we started tinkering with the library;
- the voices and alarms are bad: the turn on/off voices are annoying and unnecessary, but the alarms (like the timer and telemetry warnings) are too quiet. Both shoul be configurable, like the buzzer setting is.
- values are slow to set by only small steps allowed. There should be larger steps too, or clicking inside the box it should be entered on a virtual keyboard, like they did with the fixed id and the name;
- model settings are dispersed into the model and function menu. You often have to go out entirely, go into the other menu, change something, go out again, beck to the previous menu, so you can change a thing which was disabled depending of the other setting.

There a a lot more in the "would-be-great" category, for example: shortcuts on the main window should be configurable, but the above ones are really annoying sometime...

I just committed new code that changes the organization of main() so you probably want to pull. I also added the ability to support proportional fonts to the gui. You probably want to look it over. Lastly, I added a debug window to the GUI which will be used to display channel output as we start work on the real GUI and want to be able to see how curves and mixers are working.

also, it is possible to completely remove tearing in the emulator by switching to an event loop. there is a define in makefile.inc to enable this. I decided to leave it off, as any tearing you see with the current implementation will show up on the actual hardware, only worse, so hiding it in the emulator masks the problem.

yeah, that is pretty lame I'll fix it.

If you remember, you can press 'x' to exit cleanly though.

Edit: It is fixed now.

The bmp offset code is fixed. I keep forgetting that the bmp is drawn from bottom to top which changes the math. I can see the button label is only partially redrawn, but it ooks like your ordering is off, since it overwrites the dialog box.

yep. That is how it is (all other sticks work as you'd expect though). Actually the real analog range is much smaller (only ~11 bits) but you can assume we'll provide 16-bit normalized data (0 is smallest, 65535 is largest) to the routine. any reversing or scaling will be done ahead of time.

I just committed an xy graphing function. It should be mostly flexible enough to display curves.

Would you mind if I converted all of the guiDialog/guiButton/guiLabel structs into a single union? Overall I think it would use less space (though individually the struct will be a little bigger). but it should make the code a lot easier to read since most of the case statements in gui.c would go away. Alternatively, we could define all the structs to have common variables in a common location, then we could cast each to a base struct and still save most of the code complexity (though not the variable space)

I've changed how partial redraw is done in the GUI. I assume the following rules:
* Only a dialog object can overlap another object
* When a dialog is open, anything underneath will not be redrawn
* If a dialog image has transparency, the transparency will not be properly honored

With those rules in place, it is much easier to do a partial redraw as there is no need to intersect objects to see if they overlap, and ordering of objects is irrelevant.

There are further efficiencies that can be implemented still, especially with regards to removing objects, but it seems to work pretty well now.

I introduced a new 'dirty' bit which can be set for each object, and then a redraw will only redraw the dirty objects.

I also introduced a new 'transparent' bit which defines whether a GUI object has transparency. If it doesn't, there is no need to redraw the background, and so there is less flicker.

I'm not sure what you mean by 'menu' but it will likely be easier to not draw on top of a frame, and instead to just replace the background image as appropriate. For instance, I can completely eliminate flashing redraw if I know that the bar-graph widget is not drawn on top of any other widget. This is because I can only draw the transparent portions, and not overwrite the static portions. The result is much nicer than drawing the background under the bar and then redrawing the bar. I think the ability for widgets to intelligently redraw is probably worth the limitations of a widget only being allowed to draw on the background or a dialog (or maybe a non-transparent frame)

The performance is now sufficient for me to start work on the Mixer page, though if you can get similar performance without the overlap restriction, that would certainly be better.

I've been thinking about it a bit, and I think the best solution will be to define all widgets in ROM (via const variables). All of the GUI_Create* functions then become macros which fill in the structure. The Object list still needs to be in RAM. There are 2 downsides to ths approach that I see:
1) It limits the ability to modify the layout of the screens via a theme. We'll basically be hardcoding all of the elements. At most you could reorganize them in a theme, but not change their size
2) You can't store any dynamic data in the widget. That either needs to be stored in the object, in a linked pointer or fetched via a callback.

Still, I think this is the way to go. It should save a lot of RAM.

I've just added a spinner widget. I think I now have enough widgets to design the Mixer page.
I'm trying to decide if this is a good time to try switching to a ROM based implementation, or if I should build the mixer interface 1st.

I added code to significantly improve BMP performance, but we're currently limited by the FAT filessystem implementation as far as redraw speed. I'm not sure what we should do here. I could probably write some routines to short-circuit the FAT system when reading data, which may help, but I'm not sure I really want to go there.