Joel Bodenmann

You will have to use the toggle driver of the ginput module. You can find several examples on how to use it within the /demos directory (search for *Toggle*). Currently there's just the input driver for the ChibiOS/RT PAL HAL (I assume that is what you're using). Therefore there shouldn't be a lot of trouble to get it working. You can take a look at the example file for the olimex board to see how it's done. I'll add this to my ToDo list to write proper documentation about it. ~ Tectu

Why do you want to do that? The way it's meant to be done is that the button sends an event when it gets touched. In case of you want this to set some "pressed animation", that is also a job that's handled by the button widget. ~ Tectu

Which toolchain are you using? The recommended toolchain for ChibiOS/RT is the GNU ARM GCC. You may also want to run uGFX natively on you host computer to simplify the development process and finding bugs. ~ Tectu

The GWIN documentation mentions what steps need to be done for a custom render routine. You can also find a thread with sample code here. You can find all the required information about the widget in the GHandle: typedef struct GWindowObject { #if GWIN_NEED_WINDOWMANAGER // This MUST be the first member of the struct gfxQueueASyncItem wmq; // @< The next window (for the window manager) #endif const struct gwinVMT *vmt; // @< The VMT for this GWIN coord_t x, y; // @< Screen relative position coord_t width, height; // @< Dimensions of this window color_t color, bgcolor; // @< The current drawing colors uint16_t flags; // @< Window flags (the meaning is private to the GWIN class) #if GDISP_NEED_TEXT font_t font; // @< The current font #endif } GWindowObject, * GHandle; I'm going to prepare an example showing how to use cyrillic fonts within the following days. ~ Tectu

Yes, the code runs here too. Also, I suggest you to use GIF images for animations like your "WELCOME" text, if you have the required amount of memory. Furthermore, you don't need to create a window all over screen. This is automatically done when you initialize GWIN. You're also using the old fonts. Make sure you read the blog from time to time. ~ Tectu

Hello debayan and welcome to the forum, I just grabbed my embest board and flashed a working button example. Then I rotated the display and everything is still working nicely: gdispSetOrientation(GDISP_ROTATE_90); Could you please attach your code? On what release are you? I tried it out with the current master. ~ Tectu

Hey man, sorry that this took a bit longer than expected but I finally found time to include it into the repo. It looks good to me so far. Can you please get the latest master and try to use the implemented driver? You may want to tell me your real name for the contributors table. ~ Tectu

Can you please show how to reproduce your problem? The source does clearly show how the passed handle is used: void gwinDestroy(GHandle gh) { // Remove from the window manager #if GWIN_NEED_WINDOWMANAGER _GWINwm->vmt->Delete(gh); #endif // Class destroy routine if (gh->vmt->Destroy) gh->vmt->Destroy(gh); // Clean up the structure if (gh->flags & GWIN_FLG_DYNAMIC) gfxFree((void *)gh); gh->flags = 0; // To be sure, to be sure } ~ Tectu

This clearly is a documentation typo. It's supposed to be gwinDestroy(). Thanks for finding, it has been fixed! However, if you need different sets of controls, the tab widget might be of your interest too. The /demos/modules/gwin/widgets demo shows how it can be used (along the very simple example on the tab widget documentation page). ~ Tectu

Two lined button text is currently not possible. Of course you could add the text in the image of the button, if you're using the custom rendering routine. Please open an appropriate thread for future questions. ~ Tectu

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