Joel Bodenmann

Glad to hear that everything is working now. Thank you very much for bringing this to our attention with this very detailed bug report. ~ Tectu

Thank you very much for investigating the problem. We have just fixed the issues in the repository. It was just some bit that is responsible for the orientation set to 0 that should have been set to 1. Little things break the world, eh... Can you please verify that everything works now for you with the latest master? ~ Tectu

Hello pur300 and welcome to the communit! Have you made sure that the pins of your MCU are properly configured? Also, try out one of the ChibiOS/RT demos that use FatFS on the STM32F4 first. This helps you to make sure that the actual hardware is running without any problems. Otherwise, can you try to call gfileMount() manually in order to check its return value? If it fails you can step through the code to reveal the actual problem. ~ Tectu

Okay, I just compiled and flashed the widgets demo myself and I have the same issue that you have. There is something wrong with the code in the repository!! I am sadly not able to take a closer look at what the problem is before tomorrow evening. Please stay tuned! ~ Tectu

I'm sorry for the very late response. I am in the middle of my final exams so I spend most of the time studying and sleeping. I didn't have much time but I tested your HEX on my hardware and I see the same issue that you have while I can confirm that it works when I compile the demo myself. Therefore, this is definitely an issue with your toolchain. I will provide you tomorrow with HEX files that run on my hardware. In the meantime, can you please make sure that you have all the weird optimization stuff such as LTO disabled and that your general optimization level is set to -O0? Sorry for the inconvenient delay... ~ Tectu

Hello and welcome to the uGFX community! Wow, that's a very strange issue. We have had several issues with the Embest board due to different versions and different cable lengths. Never the less we will fix this. Can you please do the following: Try out another demo (best would be /demos/modules/gwin/widgets) and see how things go If that does not work, can you please send me your hex file(s) so I can look how it looks on my hardware If you are familiar with the STM32F4 FSMC interface and ChibiOS/RT you can try to lower your FSMC speed in the board file (between line 77 and 83 in the board file (/boards/base/Embest.../board_SSD2119.h). Can you please loop through the orientations using the touchscreen button multiple times and look if it behaves the same every time and also report which of the four orientations work and which does not. If you don't mind, can you also please leave some information about the toolchain that you're using and whether you modified anything (makefile or anything else) in the provided demo. I hope that we can sort this issue out as fast as possible so you can enjoy the full ugfx experience :twisted: ~ Tectu

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