ChibiOS Free Embedded RTOS

Hopefully you saw the pull request I made for restructuring.

I think we should also move the includes for specific hardware out of the library headers (e.g remove from glcd.h). I see two options: either we add a 'drivers.h' file which includes all of the driver headers, or the user manually includes just the headers they need in their glcdconf.h. I prefer the first option.

You could use the same pattern used for the HAL and have _lld.h files for the low level GLCD. The low level part would have its own low level configuration (port type, pin mappings etc).

It could be organized exactly like a normal device driver, even the file templates could be reused.
glcd.h
glcd.c
glcd_lld.h
glcd_lld.c
glcdconf.h

Giovanni

Yes, I saw the pull request of yours, Badger. It cloned your repo and tried to compile, which didn't work on the first try. I didn't have time to check for the errors, so I couldn't merge yet. I'll do it today (have some stress because of finals at monday/tuesday). After that, I'll definitly put much more work into the project.

But before I start merging now your pull request, I'd say we decide now a complete structure.
What would be the best folder hirarchy?

I guess providing a _lld.c and _lld.h file for each controller wouldn't be the worst idea, because some controllers do have extra features. For example, some TI clone of the ADS7843 does also have pressure meassurement (Z-Axis).



~ Tectu

Right now, I think our LCDs aren't using ADS7843. Look closely, they're using a ADS7843 compatible controller. It's a TI TSC2046 or XPT2046 (siliconically the same thing as TSC2046), which is a compatible implementation of the ADS7846. As described, it includes pressure measurement as well.

So I think, the LLD shouldn't be named ADS7843_LLD. It should rather be TSC2046_LLD at least.

Also, currently in the LCD LLD API, functions begin like: lld_XXX e.g. lld_lcdInit() or lld_lcdWrite(). I guess we should change it to lcd_lld_XXX, to conform more closely to the ChibiOS driver API.

The LCD driver is right now in a pretty usable stage. I have tested it with my LCD, and functions like lcdFillArea, lcdDrawString, lcdDrawLine, and lcdDrawRectString are working fine. I haven't tried out the various orientations (it is in the default portrait but I'm sure I'll face problems then.

I have submitted a pull request to Tectu for merging the text rendering API I'm currently using (and have used for my project in the user projects section). I've also added 'Transparent Text Rendering', in which the function only draws the required pixels, useful if you are displaying an Image or a pattern and want the text to blend into it, instead of appearing with its background color. More details once I receive the confirmation that it gets merged all right.

Also I'm planning to write a LCD String drawing function that can fit text with word wrap support into a set rectangle. Thus we can give a large string to it and be sure that it doesn't break between words. But I'm not sure if this should go into GUI functions section or the glcd.c file.

And a suggestion to add two primitive structures to the GLCD library: A point { uint16_t x, uint16_t y } and a rectangle {x,y,width,height}. The touch panel could work using the point structure. Instead to tpReadX() and tpReadY() we could have tpReadPoint() to read both of the simultaneously.

I do have an ADS7843 actually. Make a new driver for yours.

I have to say that I don't like the struct thing.
If you want to handle the point coordinates the touchpad returns as a struct, do it in your project yourself, but I'd really like to keep that outside the library.

I am also not sure why we should go with lcd_lld_XXX when we already have lld_lcdXXX. I tried to keep the naming convention between highleven functions and lowlevel functions the same, just with lld_ in front of each lld function.


~ Tectu

I think this is where we need the distinction between the low level hardware part of the driver, and the GUI that sits on top of it. If we design the lld part right then we can support a variety of different GUI libraries.

For the function naming, in Chibios the low level drivers have names like spi_write_lld with the high level function being SpiWrite. so by using the naming convention suggested by Abhishek we could keep within the style of Chibios (and I support that idea).

Badger wrote:For the function naming, in Chibios the low level drivers have names like spi_write_lld with the high level function being SpiWrite. so by using the naming convention suggested by Abhishek we could keep within the style of Chibios (and I support that idea).

I really have to say that I don't like that naming convention. That could be because I don't see the adventage. I tried to keep the naming convention as easy as possible. This leaded to just take the same prototypes and to lld_ in front of it.
Can someone show me the adventage of the (still weird to me) naming convention of ChibiOS?


~ Tectu

Hi guys, great effort! FYI - I've got an ebay 3.5 "TFT module with touch screen and SD card slot. The lcd controller is SSD1289 (16bit wide only), the touch chip is XPT2046. Is there a recommended schematics for connecting that to the stm32f4disco?
Thnks, p.

I don't know much about the F4, but the best thing is to try to keep the 16 lanes on the same port. I am not sure if you can do this on the discovery.

For example: I wired up the 16-bit bus from GPIOE 0 to GPIOE 15.
The other four pins don't matter.

Just ask if you have some furthur questions.


~ Tectu

On the F4disco there is none fully free 16bit port available (without desoldering some chips from the board) as I can see off the schematics .
So it needs to be investigated how to arrange it.. p.