Joel Bodenmann

The ILI9341 controller can't handle more than 20MHz when I recall correctly. However, you won't be able to archive this with your standard Arduino bread boarding & jumper wires anyway. ~ Tectu

Sounds like you have the experience that it takes to use uGFX in your project. All you really have to do is adding the files to the Keil file tree. Good luck. ~ Tectu

Hello ivan47 and welcome to the community! Sadly there are no Keil examples because they are never generic. With IDEs like Keil you will always be very hardware and application specific. However, many of our customers use Keil with uGFX without any problems. I myself have also implemented many projects with uGFX in Keil and I never faced any issues so far. Sadly they cannot be shared as those are commercial projects and therefore company property. To start I'd highly recommend to get a blinking LED example working first. Then make sure that your SPI port works before you start even downloading uGFX. I'm not sure what you're using. You should be able to find some Keil examples for the STM32F4 Discovery board with the stdperiph library without any problems as this is a very common board. Maybe ST even provides an official one. As soon as you have your basic project working you can start adding the required uGFX files. For starting you will just need the ILI9341 driver and the GDISP subsystem. Furthermore you'll need to include the corresponding GOS port (RAW32 in your case). Sadly there is no straight forward step-by-step guide for this as it again is very hardware and platform specific. We tried to write some minimal guide a few months ago. Maybe this helps: http://wiki.ugfx.org/index.php?title=IDE Should you run into any problems we're happy to help where ever we can. Just make sure that you properly report the problems that you're facing (complete compiler output, probably screenshot of your file tree etc. etc. Just whatever is needed to allow us helping you quickly.) I hope that helps for now. ~ Tectu

Glad to hear that you have everything working now and also thank you for reporting back the issue with the proper solution so other people who search the forum don't have to ask the same questions Very nice work! ~ Tectu

Thank you very much for providing the videos. This is definitely not the expected behavior. Experience says that this is exactly the hardware filling issues (assuming that the controller provides it). I have ordered on of those modules now to test it myself should you not be able to get it done yourself. Sadly it will take up to five weeks to receive it... ~ Tectu

I'm currently on my phone so I can't check the actual code but beside the interface speed (eg. using DMA as you already mentioned) the most likely reason for this is that the controller itself provides a function to fill a rectangle. You just have to send the first point, width, height and color and the display controller will draw the rectangle. Most uGFX drivers have this implemented and it can be enabled through the driver configuration file. But as I said. Right now I can not check if the ILI9341 even provides this feature and whether it has been implemented in uGFX and mbed. ~ Tectu

Do I understand you correctly that in both cases you use uGFX, just one time with mbed stuff and one time with ChibiOS/RT itself? ~ Tectu

Sounds like you are building some serious application there. Do you have some pictures that we could put in the demos section of the website? ~ Tectu

The GINPUT module does provide a working hardware keyboard interface since a few months. There is even a dedicated demo that you can run on your Windows / Linux emulator. When it comes to touch input (virtual keyboard): There is currently nothing official. However, inmarket has started working on such a keyboard widget. I am not sure what's the status on that. I'm sure he'll let us know. There is also a user called "Smd" who has successfully implemented a very neat virtual keyboard widget. However, it is for an old version and I think he never ported it to the newer version (It was for 1.8 if I remember correctly. The driver interface changed completely since then). I'd strongly recommend to wait until inmarket comes online to inform you about the current state of the official keyboard widget. What's best for your design depends on your application. If you give some more information we might be able to give some advice. Handwriting recognition is a huge topic and I don't think that it will make sense on a small microcontroller with a cheap resistive touchscreen. ~ Tectu

Can you please paste the relevant code (Small test case that shows the error, without all the bloat). Please do also paste your gfxconf.h. ~ Tectu

We are glad to hear that you got it working Could you please tell us what the actual problem was and how you fixed it? This way other people who might read this thread in the future can fix their problems too. ~ Tectu

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