Joel Bodenmann

Simply light up the LED in the event loop where you check which button was pressed: switch(pe->type) { case GEVENT_GWIN_BUTTON: if (((GEventGWinButton*)pe)->gwin == ghButtonOn) { // Turn on the LED palClearPad(GPIOB, 1); } else if (((GEventGWinButton*)pe)->gwin == ghButtonOff) { // Turn of the LED palSetPad(GPIOB, 1); } break; default: break; } ~ Tectu

Hello miogui and welcome to the community! The correct way to write a buffer to the display is by using gdispBlitArea() which takes a pointer to a buffer (see gdispBlitArea() API documentation). The function is implemented so it always uses the fastest way possible. If your display supports hardware fills, it will use that. If your display driver support hardware streaming, it will use it. You can take a look at the implementation here. I hope that helps. ~ Tectu

You can google a bit, there are many issues with using SPI with SD-Cards. SPI mode is not officially supported / included in the standard and it is often just some ugly implementation and these days barely any modern card even supports it at all. SDC is definitely the way to go (as you saw now ;-)). Let us know about any results. ~ Tectu

Please make sure that one of the many examples that come with ChibiOS/RT using FatFS is working BEFORE you start using GFILE. The reason: For you it will be a lot easier to debug any issues. If you have it working using one of the ChibiOS/RT examples it will be working with GFILE within minutes ;-) A general suggestion: Always use SDIO/SDC instead of MMC/SPI mode (provided that your hardware setup allows it). The NSS (chip select) signal is controlled by the ChibiOS/RT driver in either case (whether you are using GFILE or not). That is the reason why you have to set up your peripherals correctly (palSetPadMode() etc.). ~ Tectu

Did you ever manage to have it working just with ChibiOS/RT itself? The /src/gfile/gfile_fatfs_diskio_chibios.c is just a copy of the ChibiOS/RT file so assuming that your peripherals are all set up correctly it should work. What is the return value of gfileMount() ? ~ Tectu

Hello fastlink, Similar to the GDISP and GINPUT module, the GFILE/FatFS module needs a "board file" to know how to talk to the device. This file is called "diskio.c" and we provide a standard one for ChibiOS/RT which you can find here: /src/gfile/gfile_fatfs_diskio_chibios.c. The easiest way is to modify the file so it matches your needs. I have never tested it with MMC/SPI but I can guarantee you that it works just fine and out of the box with SDC/SDIO. So assuming that your peripherals are configured the right way it should just work out of the box for MMC/SPI as well. This part does indeed need improvement in both, implementation and documentation. We will improve the diskio interface so you can either submit a custom file although you are using ChibiOS/RT or at least provide some macros to specify the used peripherals. However, it might take a while until I have time to do this as I want to roll out the beta of the uGFX-Studio first. Please let us know when you need further help to get it working. ~ Tectu

Awesome! Can't wait for it Every new display driver is exiting. ~ Tectu

I don't have any but it certainly looks interesting for that price. Did you order one? Thanks for sharing! ~ Tectu

No problem indeed. We are happy to help wherever we can. Sorry that it takes us sometimes longer to reply but especially during weekend we are often not in front of our computers during the day. ~ Tectu

I don't understand that sentence. You can you please try to rephrase this? Also, it is recommended to turn of all the modules expect of the GDISP module until you have the display runing properly. ~ Tectu

So you are 100% sure that the hardware works even now with the "old" project? Can you please make sure that you replaced the SSD1289 driver in your project with the modified one from the other project? As you updated to a more recent version you might have forgotten that. From what I can say the display was initialized but there is definitely some speed issue. ~ Tectu

Can you please describe the symptoms that you get? Do you see a white screen? Noise? Garbage? Nothing at all? Wrong colors? Please also let us know about your hardware setup (what microcontroller, what display, what interface you are using, if it is a PCB or wires on a breadboard etc.). ~ Tectu

The _aa prefix means 'Anti-Aliased'. You can read more about fonts on the wiki: http://wiki.ugfx.org/index.php?title=Font_rendering Please let us know when you need any additional help to get your project working. ~ Tectu

This was an issue ("typo") in the uGFX library itself. We pushed a fix to the master branch. Please update the corresponding file in your project and this error should be gone. Sorry for the trouble. ~ Tectu

You are using a "strange" version of uGFX. I have replace the 'ugfx' directory with the latest master and I can compile without any problems (after adding all the other missing uGFX files to the Em::Blocks project tree). Note that you have to fix the GDISP_USE_DMA macro in the configuration file. It needs to be either set to TRUE or FALSE (I recommend not to mess with DMA until you got the display working). ~ Tectu

I have downloaded the project again from the link in your first post but I don't see any board files in the src directory. It looks like you left them in the driver directory. Note that you will also have to add those new files in the Em::Blocks project file tree. ~ Tectu

Hello fastlink, I took a look at your project and it seems like you are missing the actual board files for both the display and the touch screen. You need to supply two files which tell uGFX how to talk to your display and to your touch screen controller. In your case you can copy the following two files from the uGFX library directory: /drivers/gdisp/SSD1289/board_SSD1289_template.h /drivers/ginput/touch/ADS7843/gmouse_lld_ADS7843_board_template.h Copy those two files to your project directory (the place where you also have your main.c) and drop the _template in the file names. Then fill in the routines. You can read more about board files here: http://wiki.ugfx.org/index.php?title=Board_File Let us know if you have any questions about the board file implementation. ~ Tectu

I am deeply impressed. We would love to put this on our demos page. ~ Tectu

We'd love to see a video of this - is it possible for you to make a public available one? ~ Tectu

With the method mentioned above it is only possible to rotate by 90 degrees as your display won't provide any other orientations that than. When we will implement this feature ourself it will be most likely possible to rotate by 90 degrees as well as by any degree value (the 90 degrees will just be a lot quicker). ~ Tectu

Depending on the GCC version that you are using you might encounter a linking error when building an uGFX project under Linux. This is due to a very well known bug in one of the latest versions of GCC. To bypass this problem, simply disable the LTO feature. When you're using our Makefiles you can just set the OPT_LINK_OPTIMIZE macro to no: OPT_LINK_OPTIMIZE = no This will produce a slightly larger binary but on a Linux enviornment this shouldn't be that much of a problem. ~ Tectu

No problem, I know this situation. Worst thing on earth ~ Tectu

It looks like we won't have time to get this done within the next couple of weeks as we are working on some other quite vital parts of the uGFX project. Did you proceed in any manner? ~ Tectu

Thank you very much, we just fixed this as well: https://bitbucket.org/Tectu/ugfx/commit ... e2b551775a Please keep us up to date about any other upcoming bugs. We are thankful for any bug report as this helps to drastically increase the quality of the library. We also just added you to the community table on our website. We can add your real name if you like. ~ Tectu

Thank you very much, we have just fixed this issue: https://bitbucket.org/Tectu/ugfx/commit ... 39aa742c06 We appreciate bug reports like this a lot! ~ Tectu