GUI

hmm.

Can you pull the latest code (hg pull -u) and give it a shot?
I changed to a double-buffering scheme. It seems to mess with the mouse, but behaves better on my machines.

FYI, your binary works fine on my machine. I wonder if it has something to do with Gnome vs XFCE

I have no idea what is going on with your swap (or python which is probably unrelated to my code).

Edit: I have a feeling my fltk code is crap. I played some tricks to prevent having a separate drawing thread, and maybe it isn't very robust. If the current code also doesn't work, I'll rewrite the GUI in its own thread (or maybe just do it in gtk...I dunno)

Phew.
Note that the current code will use 100% CPU. That is expected because it is in an infinite loop at the moment. Something we'll likely need to fix in the GUI design.

MatCat wrote: I agree, now that it is working I am going to start experimenting with it... I noticed the analogs go from F005 to FFFF in 10 steps... Is that the real analog range? (I saw in code it is 10% steps)

no. that is just because I inverted the value, which is wrong. The actual range is 12bits, but practically 0x1d0 - 0xdf0. The throttle has a 'low' value at max value, all others are as you expect (larger to the right/top).

We need to think about what we want in a GUI...

Is the fl library only good for the emu? Are we going to have to make GUI components from scratch for the firmware or are there libraries we can use?

We need to do everything from scratch. Fltk is just being used as the backend for the PC. The available routines are all in scren/qvga/ and at the moment they are only primitives. I've seen one GPLed GUI framework suitable for embedded applications, but honestly it was really ugly, and I'm pretty sure we don't need a windowing system.

FYI, I just checked in support for BMP images. When using the emulator, you can load 16bit BMP files There is also support for loading 'window' out of a bmp file. This allows you to store multiple images in a single file which reduces overhead of the filesystem and BMP header

The example just loads a BMP as the background image

I haven't yet got filesystem support working on the STM32, so for now, this is Emulator only, but hopefully I'll have the filesystem working on the Devo8 soon so the same code should work there as well.

I fixed the issue with the BMP code. I wasn't reading enough bytes, and just got lucky that they were all zeroed out when I examined them. It should be fine now.

As for the color code, it is rgb565.

so to convert to 24bit color:
if you save BMP to 16bit, you will get rgb565, so you only care about this if you are using the primitive gfx functions.

I've added additional checking to ensure that the BMP is in rgb565
I also think I've fixed the wrapping issue.

I don't have any issues with printf. They work fine for me when I put them in.

Note that the font drawing currently has a hard-coded background color. The LCD doesn't have a convenient way to skip a pixel when drawing. I added support for transparent backgrounds on the fonts, but you need to repaint the background before changing any text if you use it, so it is disabled for now. Look in lcd_string.c for more info.

As for commit access, I'd rather start with you using your own repository and issuing pull requests. Mercurial, like Git is a distributed VCS, so there is no 'master' repository, just a bunch of peers. You can create an hg repository on bitbucket or wherever you like and publish your changes there, and I can pull them into my repository. Once I'm convinced we're on the same page, I'll provide commit access

1) You need to make your repository public. It is an option under admin (un-select 'private'). Alternatively you need to invite me to see it, but better to just keep everything open

2) You can look at the instructions here to have a different 'pull' and 'push' path:
wiki.alliedmods.net/Mercurial_Tutorial

3) The LCD module produces either 8 or 12bit ADC data. I currently have it configured in 8-bit mode. We should definitely change the struct to be 16bits for coordinates (regardless of whether the values are 8 bit or not), but be aware that the values will not correspond to pixel location. We need to write a calibration and mapping routine to convert the raw data into pixels. This is something that will need to go into scren/qvga/lcd_calibration.c or something. It is on my to-do list, as I already found an open-source calibration routine (though it shouldn't be too hard to write one from scratch)