Joel Bodenmann

Thank you for sharing. I'm sorry but I won't have time before the weekend to check on this. I'll keep you posted. ~ Tectu

Okay guys, here you go: unicode support! ~ Tectu

I sent an e-mail to you. ~ Tectu

I don't know of anybody which is currently working on this. If you want to source (sponsor) such a smartwatch, I'm open to look into this. ~ Tectu

That will work soon. µGFX gets UTF support shortly. ~ Tectu

Very nice! Thank you for contributing an advance ;-) ~ Tectu

Sure, sounds good to me. I can wait ~ Tectu

Yes, that's completely right. I will do it and add the driver with the new files. As soon as you are back, you can try the driver and tell me if everything works properly. Enjoy your vacation! ~ Tectu

Okay, I finally got the time to look at your new driver. It looks a lot better now! There's only one more thing: Could you please split the I²C and SPI interface into two separate board files named gdisp_lld_board_example_spi.h and gdisp_lld_board_example_i2c.h? If you don't want to waste your time with that, I can do it as soon as I add the driver to the repository. Keep going the good work! ~ Tectu

I am sorry that this takes so long... I will do this tomorrow, promised! I am currently very busy with real life issues. ~ Tectu

Hello goeck, Thank you very much for sharing you driver. I took a look and these are the points I have to mention: I see that you have the ChibiOS/RT logo in the framebuffer per default. Since this project is now completely separated from ChibiOS, it's a big no-go. I recommend you using an empty frame buffer. In the source file, what is this? /* Fulfill Adafruit license.*/ gfxSleepMilliseconds(1000); The driver source must be as generic as possible and really just LCD controller dependent - not LCD panel or LCD module (adafruit) dependent. In the source file, after the scroll implementation which ends at line 534, you start giving an interface to control several things such as the LCD controllers power states and start addresses. These are things that need to be declared as static and only usable inside your drivers source file. Things like backlight and contrast changes are meant to be made through the gdisp_lld_control() routine. Here's an example. I'd recommend to name the BLACK and WHITE macros in the SSD1306.h a different way, such as SSD1306_BLACK and SSD1306_WHITE so there are no confusions between the rest of the library. The board file mess has been cleaned up in the meantime. All the #ifdef stuff in line 43 of the source file became obsolet. It's now appropriate to just #include gdisp_lld_board.g there. Beside these things, your driver works seems to be very solid and consistent. Good work! ~ Tectu

Hey goeck, First of all: Thanks for sharing. Could you please do me a favor and open a new thread in the Hardware sub forum about this (driver name in the thread title)? It helps to keep things clean and I am sure that there will be some discussions going on ~ Tectu

It works - that was the goal. Everything else is learning by doing. ~ Tectu

Good to see that it finally worked out I assume it works with the correct FSMC address now? What was the issue that it didn't work in the first place today? ~ Tectu

You have to take a look at your microcontrollers datasheet to learn how to use your FSMC interface in 8-bit mode. The driver itself does not have to be modified because it does not care how you actually talk to the display controller. The driver itself calls the read and write routines from the board file (gdisp_lld_board.h). Inside your board file, you just implement all the write_xxx() calls so it works with FSMC in 8-bit mode. The current board files that can be found inside that directory show how to use FSMC in 16-bit mode. There are currently no examples available that show how to use FSMC in 8-bit mode. I'd appreciate it when you'd share your work after you got everything successfully working. ~ Tectu

If the driver has been written correctly, you just have to create a board file (gdisp_lld_board.h) which talks to the display in 8- instead of 16-bit mode. ~ Tectu

Ah, if you have those hardware buttons, then you will be fine. Most widgets such the buttons, sliders, lists and so on do support the toggle input, as you mentioned correctly. The big widget demo shows how to use that. Yes, please open a new thread with an appropriate subject for future questions (It's not meant to be rude, but a clear structure helps other users to find the answers they are searching for). ~ Tectu

What means "plenty"? - I'd be interested. GWIN is not the thing you need then. You have to do all the widget drawing yourself. GWIN can only be used together with at least one input source. ~ Tectu

Good to hear that you got it working. I hope that you can show us at some point what you're doing, we really need more stuff from users to show off with ;-) About the driver: Make sure you got the config right. For testing, set everything to false so it just uses the pixel draw routine. Then start by implementing window filling etc. Keep stuff like vertical scrolling etc. for the rest. If you have any problems, feel free to open up a new thread related to that driver. ~ Tectu

This will take quite some time. I search you not to use the ASYNC mode of GDISP and use the MULTITHREAD instead. The other issue about the undefined reference has been fixed. ~ Tectu

I am working on it. The GQueue module has been reworked but we didn't bother with testing all the possible configurations in the gfxconf.h so now the API is outdated ;-) ~ Tectu

There's definitely something broken. I am currently looking into it. To compile successfully, please set GDISP_NEED_ASYNC to FALSE. You should then also be able to successfully compile with GWIN and different widgets. ~ Tectu

The config you showed still has GFX_USE_GQUEUE and GQUEUE_NEED_ASYNC set to FALSE. Please set them to true, issue a make clean and try to compile again. ~ Tectu

So does it work now? ~ Tectu

First of all, it's correct that you have to include gfx.h everywhere. Anything else is "linked" through that file depending on your needs. About your actual problem: It looks like there are some rules missing that should automatically turn on stuff in the config file for you. Please try to enable GFX_USE_GQUEUE and GQUEUE_NEED_ASYNC in your gfxconf.h. If this works, please let me know which features you're using (paste your gfxconf.h here) so I can take a look at what went wrong. About the driver: It is ALWAYS nice to add new drivers to the project because this really increases the value of it. However, the driver needs to be in the same architecture as the current ones and it should be as clean and complete as possible. If features are not implemented, they need to be handle correctly. Often people just copy another driver and features they don't implement keep being the same as for the original driver - this can lead to a lot of trouble. If you don't think it's good enough, you can also just send it to me and I'll take a look and clean it up - then you just have to do a final test to confirm that it's still working. ~ Tectu