Joel Bodenmann

Hello lliypuk and welcome to the community! inmarket has bought this board and I think he already got it working but it's not finished. I'm sure he'll let you know about the current state when he visits the forum the next time. ~ Tectu

First thing to check is to make sure that the backlight is actually on. It happens very often that the display is actually working but people can't see it because the backlight is off. Please make sure that the backlight is always set to 100% on in the board file. If that is not the problem, can you please tell us what you're seeing? Do you see a white screen or noise? Can you verify the signals using an oscilloscope or a logic analyzer? About the pin configuration: The pin configuration is done inside of the init_board(). This way you don't have to worry about your chibios board file. When you add the backlight, make sure that you also add this pin configuration to the board file. ~ Tectu

Sorry, I was on the road and I couldn't try to compile it myself. This one here should now at least compile correctly: /* * This file is subject to the terms of the GFX License. If a copy of * the license was not distributed with this file, you can obtain one at: * * http://ugfx.org/license.html */ #ifndef _GDISP_LLD_BOARD_H #define _GDISP_LLD_BOARD_H // For a multiple display configuration we would put all this in a structure and then // set g->board to that structure. #define SET_CS palSetPad(GPIOC, 8); #define CLR_CS palClearPad(GPIOC, 8); #define SET_RS palSetPad(GPIOC, 9); #define CLR_RS palClearPad(GPIOC, 9); #define SET_WR palSetPad(GPIOC, 10); #define CLR_WR palClearPad(GPIOC, 10); #define SET_RD palSetPad(GPIOC, 11); #define CLR_RD palClearPad(GPIOC, 11); // The ChibiOS/RT bus groups IOBus busC; IOBus busB; static inline void init_board(GDisplay *g) { // As we are not using multiple displays we set g->board to NULL as we don't use it. g->board = 0; switch(g->controllerdisplay) { case 0: // Bus setup busC.portid = GPIOC; busC.mask = (1<< 0)|(1<< 1)|(1<< 2)|(1<< 3)|(1<< 4)|(1<< 5)|(1<< 6)|(1<< 7); busC.offset = 0; busB.portid = GPIOB; busB.mask = (1<< 8)|(1<< 9)|(1<<10)|(1<<11)|(1<<12)|(1<<13)|(1<<14)|(1<<15); busB.offset = 0; // Pin configuration palSetBusMode(&busC, PAL_MODE_OUTPUT_PUSHPULL); // DB0 - DB7 palSetBusMode(&busB, PAL_MODE_OUTPUT_PUSHPULL); // DB8 - DB15 palSetPadMode(GPIOC, 8, PAL_MODE_OUTPUT_PUSHPULL); // CS palSetPadMode(GPIOC, 9, PAL_MODE_OUTPUT_PUSHPULL); // RS palSetPadMode(GPIOC, 10, PAL_MODE_OUTPUT_PUSHPULL); // WR palSetPadMode(GPIOC, 11, PAL_MODE_OUTPUT_PUSHPULL); // RD // Configure the pins to a well know state SET_RS; SET_RD; SET_WR; CLR_CS; break; } } static inline void post_init_board(GDisplay *g) { (void) g; } static inline void setpin_reset(GDisplay *g, bool_t state) { (void) g; (void) state; /* Nothing to do here - Reset pin connected to NRST */ } static inline void set_backlight(GDisplay *g, uint8_t percent) { (void) g; (void) percent; /* Implement PWM here - Always 100% for testing purposes */ palSetPad(GPIOC, 12); } static inline void acquire_bus(GDisplay *g) { (void) g; CLR_CS; } static inline void release_bus(GDisplay *g) { (void) g; SET_CS; } static inline void write_index(GDisplay *g, uint16_t index) { (void) g; palWriteBus(&busC, index & 0x00FF); palWriteBus(&busB, index & 0xFF00); CLR_RS; CLR_WR; SET_WR; SET_RS; } static inline void write_data(GDisplay *g, uint16_t data) { (void) g; palWriteBus(&busC, data & 0x00FF); palWriteBus(&busB, data & 0xFF00); CLR_WR; SET_WR; } static inline void setreadmode(GDisplay *g) { (void) g; // change pin mode to digital input palSetBusMode(&busC, PAL_MODE_INPUT); palSetBusMode(&busB, PAL_MODE_INPUT); CLR_RD; } static inline void setwritemode(GDisplay *g) { (void) g; // change pin mode back to digital output SET_RD; palSetBusMode(&busC, PAL_MODE_OUTPUT_PUSHPULL); palSetBusMode(&busB, PAL_MODE_OUTPUT_PUSHPULL); } static inline uint16_t read_data(GDisplay *g) { (void) g; uint16_t ret = 0; ret |= ((uint16_t)palReadBus(&busC) & 0x00FF); ret |= ((uint16_t)palReadBus(&busB) & 0xFF00); return ret; } #if defined(GDISP_USE_DMA) #error "GDISP - ILI9325: The GPIO interface does not support DMA" #endif #endif /* _GDISP_LLD_BOARD_H */ ~ Tectu

We wrote a board file which should be working. However, we had no hardware to actually test it: /* * This file is subject to the terms of the GFX License. If a copy of * the license was not distributed with this file, you can obtain one at: * * http://ugfx.org/license.html */ #ifndef _GDISP_LLD_BOARD_H #define _GDISP_LLD_BOARD_H // For a multiple display configuration we would put all this in a structure and then // set g->board to that structure. #define SET_CS palSetPad(GPIOC, 8); #define CLR_CS palClearPad(GPIOC, 8); #define SET_RS palSetPad(GPIOC, 9); #define CLR_RS palClearPad(GPIOC, 9); #define SET_WR palSetPad(GPIOC, 10); #define CLR_WR palClearPad(GPIOC, 10); #define SET_RD palSetPad(GPIOC, 11); #define CLR_RD palClearPad(GPIOC, 11); static inline void init_board(GDisplay *g) { // As we are not using multiple displays we set g->board to NULL as we don't use it. g->board = 0; switch(g->controllerdisplay) { case 0: // Bus setup IOBus busC = {GPIOC, (1<< 0)|(1<< 1)|(1<< 2)|(1<< 3)|(1<< 4)|(1<< 5)|(1<< 6)|(1<< 7), 0}; IOBus busB = {GPIOB, (1<< 8)|(1<< 9)|(1<<10)|(1<<11)|(1<<12)|(1<<13)|(1<<14)|(1<<15), 0}; // Pin configuration palSetBusMode(&busC, PAL_MODE_OUTPUT_PUSHPULL); // DB0 - DB7 palSetBusMode(&busB, PAL_MODE_OUTPUT_PUSHPULL); // DB8 - DB15 palSetPadMode(GPIOC, 8, PAL_MODE_OUTPUT_PUSHPULL); // CS palSetPadMode(GPIOC, 9, PAL_MODE_OUTPUT_PUSHPULL); // RS palSetPadMode(GPIOC, 10, PAL_MODE_OUTPUT_PUSHPULL); // WR palSetPadMode(GPIOC, 11, PAL_MODE_OUTPUT_PUSHPULL); // RD // Configure the pins to a well know state SET_RS; SET_RD; SET_WR; CLR_CS; break; } } static inline void post_init_board(GDisplay *g) { (void) g; } static inline void setpin_reset(GDisplay *g, bool_t state) { (void) g; (void) state; /* Nothing to do here - Reset pin connected to NRST */ } static inline void set_backlight(GDisplay *g, uint8_t percent) { (void) g; (void) percent; /* Implement PWM here - Always 100% for testing purposes */ palSetPad(GPIOC, 12); } static inline void acquire_bus(GDisplay *g) { (void) g; CLR_CS; } static inline void release_bus(GDisplay *g) { (void) g; SET_CS; } static inline void write_index(GDisplay *g, uint16_t index) { (void) g; palWriteBus(&busC, index & 0x00FF) palWriteBus(&busB, index & 0xFF00); CLR_RS; CLR_WR; SET_WR; SET_RS; } static inline void write_data(GDisplay *g, uint16_t data) { (void) g; palWriteBus(&busC, index & 0x00FF) palWriteBus(&busB, index & 0xFF00); CLR_WR; SET_WR; } static inline void setreadmode(GDisplay *g) { (void) g; // change pin mode to digital input palSetBusMode(&busC, PAL_MODE_INPUT); palSetBusMode(&busB, PAL_MODE_INPUT); CLR_RD; } static inline void setwritemode(GDisplay *g) { (void) g; // change pin mode back to digital output SET_RD; palSetBusMode(&busC, PAL_MODE_OUTPUT_PUSHPULL); palSetBusMode(&busB, PAL_MODE_OUTPUT_PUSHPULL); } static inline uint16_t read_data(GDisplay *g) { (void) g; uint16_t ret; ret |= ((uint16_t)palReadBus(&busC) & 0x00FF); ret |= ((uint16_t)palReadBus(&busD) & 0xFF00); return ret; } #if defined(GDISP_USE_DMA) #error "GDISP - ILI9325: The GPIO interface does not support DMA" #endif #endif /* _GDISP_LLD_BOARD_H */ Can you please test the board file and let us know when you have any problems? ~ Tectu

@inmarket: Those jumper wires that you can see in the photo are from the programmer / JTAG. The display itself is wired on the PCB to the microcontroller that you can see on the back side of the PCB. @david: I checked and your display is definitely not connected via FSMC. It is simply bit-banged using GPIO. This is quite typical for those chinese boards. We will try to write up a board file for you this evening. ~ Tectu

That's correct but I assume he would get a proper compiler error. But probably we should mention that anyway: Make sure that you don't compile a different board_ILI9325.h accidentally. ~ Tectu

Hello david! Can you please give us some information about your actual hardware setup? Do you use a well known development board with an e-bay display attached? Is it a custom board? You mention that you're using GPIOC 0 to 7 and GPIOB 8 to 15. I don't know the pin out of the STM32F1 that you're using but most likely this won't be the FSMC interface of the chip. This would mean that you have to implement your own board file so the data is being put on the right pins. There should be a template file in the drivers directory that you can copy to start. The board file that you show in your forum post is using the FSMC peripheral. ~ Tectu

Thank you very much for the good words Let us know whenever you have any other problems or questions! ~ Tectu

Glad to hear that you got it working now! With the current implementation you have to do this manually in your own application code as this is hardware/peripheral specific. For a display or touchscreen you would simply do it in the init() routine of the board file. The GFILE module does however not have a board file. This is probably something we should consider to redesign. Just call them manually for now. You can actually specify the behavior of the gfxInit() call. There is a setting in the configuration file called GFX_NO_OS_INIT. If this is set to FALSE gfxInit() will automatically call halInit() and chSysInit(). If it is set to TRUE you will have to call them manually. ~ Tectu

You have to enable the following things in your configuration file: GFX_USE_GFILE GFILE_NEED_FATFS Then it should be working ~ Tectu

This looks like a ChibiOS/RT issue then. I'm sadly not able to verify the pin asignment of your project until the weekend. Probably taking this to the ChibiOS/RT forum would speed up the process of finding the issue. If you have your SD card working under ChibiOS/RT it should just work without any problems with the GFILE module. ~ Tectu

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