Joel Bodenmann

The fontconverter is up and running again: http://ugfx.org/fontconvert.php We will integrate the font converter into the new website to make it look a bit nicer in the following days. Please excuse the inconvenience. ~ Tectu

GDISP needs to be thread safe because it accesses hardware. GWIN itself on the other hand is a thread itself and does not access any hardware directly but through the GDISP module. Therefore only the GDISP module needs to be thread safe. The GFILE module (and the FatFS implementation) is not thread safe from our side. That sounds very strange. I put that on my ToDo list to investigate. Can you please post a test-case that demonstrates how the problem occurs and how it can be work-arounded? ~ Tectu

It looks like the font converter got missing during updating the website. We will add it back tonight (within a few hours). We are sorry for the inconvenience. ~ Tectu

If you really want to create a mouseDown and mosueUp event then the code you posted is the right way to go. In fact, you can see how the button widget handles this. However, the real question to ask here is why you would want to do that. A label is a non-interactive element by design. What do you want to archive? Usually the right way to do anything like this is to implement a custom render for a button or a checkbox using the standard API. ~ Tectu

Can you please tell me how I can reproduce the problem? This would save a lot of time and help to track down and fix the problem more quickly. What exactly needs to be done before that commit to show that self calibration works and what needs to be done after that commit to show that it doesn't work? I will test as soon as I am at home. ~ Tectu

Hi Dvor_nik, Inmarket does not have this board himself. I can try it tonight if you tell me what I should do. I have never tested the self calibration before. ~ Tectu

Maybe you guys could ask the MikroE people if they know anything about this issue? If they have no technically well supported forum I am sure you might find some e-mail address. ~ Tectu

If you have everything working properly it would be awesome if you could attach all the required files to this forum (upload a .zip) so inmarket can have a look whenever he has the time. We're happy for every contribution - especially as this might save him a lot of time. ~ Tectu

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