Joel Bodenmann

You're welcome. We're happy to help where we can. Please let us know should you face any other issues. ~ Tectu

I'm not sure if I understand your question properly. If you want to use both, Cyrillic and Latin fonts you need two fonts anyway. Therefore it is no problem setting a different range for the two as you generate them. Then use the method to use multiple user fonts as by the method that inmarket showed. ~ Tectu

If you want to filter a custom range of glyphs, please select "Custom Range" in the dropdown menu on the right side. Two new fields will show up in which you can type in the actual glyphs. ~ Tectu

You are not providing the ginput_lld_toggle_config.h file to the compiler. You need to not only provide the toggle board file (ginput_lld_toggle_board.h) but also the corresponding configuration file. You can find a short readme and a board file template under \drivers\ginput\toggle\Pal. ~ Tectu

Hello GunterO and welcome to the community! Thank you very much for bringing this to our attention. This typo was already fixed in the repository some time ago: https://bitbucket.org/Tectu/ugfx/diff/d ... 2119.cT288 This fix was sadly not hotfixed in the 2.2 branch hence the most recent zip download of the uGFX version 2.2 does not include this bugfix. As the wiki page as well as the actual download page mentions we strongly recommend to use the latest master. The "stable releases" are just to provide at least some kind of history on what is going on. If you are not comfortable with using GIT then please note that you can always download a ZIP archive from the latest master branch from the bitbucket side without knowing anything about the version control system. ~ Tectu

Hello david1982, In your board file you set your SPI pins to PAL_MODE_OUTPUT_PUSHPULL mode. This way the pins really just act as normal I/Os. To use your SPI peripheral you need to set the pins to the corresponding alternating function. Furthermore the board file looks somewhat strange. You should use the high level API provided by ChibiOS/HAL to write and read from the SPI bus. A few more things to check if it does still not work (common issues): Make sure that the backlight is on Start with a low SPI frequency (especially when you're using long cables I hope that helps. ~ Tectu

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