Joel Bodenmann

Glad to hear that you got it working Keep it up! ~ Tectu

Please have a look at the /demos/modules/gwin/imagebox/ demo. It does exactly what you want: wi.g.x = 10; wi.g.y = 10; wi.g.width = 200; wi.g.height = 100; ghImage1 = gwinImageCreate(0, &wi.g); gwinImageOpenFile(ghImage1, "myImage.bmp"); ~ Tectu

Before we start digging deep you mentioned that you try to get it workingagain. What did you change since the last time where it worked? Do you use a different uGFX version or revision? Different underlying OS? Different cables, different dev-board? ~ Tectu

You can use uGFX with or without ChibiOS/RT. If you don't want to use an OS you can use the RAW32 port for uGFX. But our examples for the STM32F429i-Discovery board only work with ChibiOS/RT. Therefore you have to download ChibiOS/RT. We recommend getting the ChibiOS/RT demo for the STM32F429i-Discovery board working (blinking LED) before you add uGFX. This way you can be sure that your setup is working properly. ~ Tectu

I have not heard of that chip before myself and I have never heard that somebody of the uGFX community was using this LCD driver. However, at a first glance this one looks very similar to the ILI93xx chip series. I think that you should be able to implement a new GDISP driver yourself with not much trouble at all! ~ Tectu

Hello, There is a ready-to-run demo for the STM32F429i-Discovery board using either ChibiOS/RT 2.x or ChibiOS/RT 3.x. Those examples can be found in the /boards directory. However, they use the Make build system and are not Keil examples. Sadly Keil cannot import projects using external Makefiles. To use the examples in Keil you'd have to create a new project yourself from scratch and add all the necessary files to the project file tree. We strongly recommend using an IDE that can handle projects using external Makefiles. However, many users are using uGFX with KEIL without any problems at all. So if you want to go through the trouble it will definitely work out. ~ Tectu

Sounds good to me. Let us know when you have any questions. Let us know when you're finished with the board files so we can review and eventually add them to the repository. ~ Tectu

You're doing a great job! Thank you very much! I think we should add your board files to the /boards directory so people with a similar setup have an easy start. What do you think? ~ Tectu

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