GUI

Looks good so far.
FYI, you can use LCD_DrawImageFromFile instead of LCD_DrawWindowedImageFromFile if you just want to draw a bitmap at the provided coordinates. The Windowed mode works as well, but is more cumbersome if you don't need the extra functionality.

You should use gdb. It is the easiest way to find issues like this. Likely your bmp isn't in the right format or in the right location.

As I mentioned above, we need a mapping function to convert the raw ata to screen coords. I purposefully convert screen coords to 0-255 in the emulator since we can't rely on the raw values returned by the actual touch sensor. We need a calibration routine and then a mapping routine.

I just committed the relevant changes to make coords 16bit, and for the emulator to return actual screen coords. It is just temporary until the calibration routines work, but should let you make progress.

did you do a:
make clean TARGET=emu_devo8
When I built your code, the x coord did go from 0 - 320
My Makefile does not notice changes to .h files, which would likely cause the behavior you saw.

I also committed a fix for the screen offset issue. the image will now appear properly, and you should not need to subtract one from the image width/height either.

They use kind of spin button for numeric values. It would be better to provide two different step: small and large. (...and input from a virtual keyboard. They use one too for the model name and the fixed id. )
Scrollbar and scrolling capability come to my mind too...

Cool!
I think it is caused by the subdomain...
I'm out for three days now. After that we can port the whole thing.

Note that we can't actually buffer the screen. We don't have enough RAM for a page buffer, so we'll need to be smarter about that.

One possibility is to keep track of what is on each layer and to use windowed mode to re-render each layer on change
Another is just to re-render the entire screen whenever anything changes

About transparency:
it can be done, but it is very expensive. Especially for bitmaps. It is fine if what you are rendering is small, but to use transparency on a large bitmap would likely cause unacceptable performance. I'd strongly recommend designing a system that doesn't need it.

Transparent text background is already supported, but it requires implementing a redraw method, which is why it isn't enabled. You can however change the background for the text. I'm not sure how useful that is though

I've now implemented the touch calibration routine. Press '1' in the emulator to activate it.
So you can now use the x/y coordinates from SPITouch_GetCoords as actual screen coordinates

Actually, that is difficult to do.
The reason is because of how the LCD screen driver works.
The way we use it now is to define a viewport (x0,y0) - (x1, y1) and then to just send one pixel at a time which increments the current location pointer automatically. There is no 'skip' function, so you need to write to every single pixel in the window. I had tried reading the pixel and writing the value I read, to tryto increment the internal poiter value, but it didn't work for me.

The only way around this that I know of is to use the DrawPixelXY function. This is much slower as it basically sets a 1-pixel wide viewport, and then writes to it for each pixel. That is fine if the image is small, but you wouldn't want to use it for the full screen.