Joel Bodenmann

A wild guess: Make sure that you disable all the filling, hardware clear and streaming features in the drivers config file. When you try to draw something the GDISP module will actually try to optimize it as far as possible using hardware fills etc. If you have these functions linked but empty nothing will happen. If that is not the problem can you please elaborate how you "manually draw pixels"? Sorry for not answering your linked question yet. Inmarket and I are currently both very busy. We'll get back to you ASAP! ~ Tectu

Looks like you know what you're doing. Getting this display working shouldn't be a problem for you then Let us know when we can help. ~ Tectu

In your case this would be TM_SPI_Send() and TM_SPI_ReadMulti(). Note that you also need to initialize the SPI peripheral yourself in the init() routine of the board file (just copy the content from the XPT2046_Init() function from your first post). The acquire_bus() and release_bus() routines can be used to handle the CS (Chip Select) signal of your touch controller. ~ Tectu

Sorry for being unclear. You are right, there are certain configs that the GDISP module uses to communicate with the driver. What I meant to say is that you don't have to implement any of these as they are usually completely optional. For starting you really just need the init() and the setPixel() routine. You can find a list of the currently implemented GDISP <--> Driver config parameters here: /src/gdisp/gdisp_driver.h This is indeed not properly documented and we should write a proper HowTo on writing a new display driver. It has just not made it up to the high priority part of the ToDo list so far. ~ Tectu

Hello crteensy and welcome to the community! Thank you for giving uGFX a try before you start rolling your own - this is exactly how uGFX started ;-) About the C++ question: From the uGFX point of view there is no problem if you want to use C++ in your board files. uGFX is 100% pure C and if you can get your toolchain to compile your C++ code then I don't see any problems there. About the gdisp_lld_config.h: Those are not documented because they are driver dependent. Some controller chips allow hardware fillings and some don't, some need buffer flushing and others don't. Hence we didn't bother to implement a standard list of available options because there will always some special one pop up that is not yet there. When you're using an existing driver simply copy the existing config file from the drivers config file. If you write your own driver then you're free to do it as you like. Of course it would make sense to stick with what's already there when it comes to naming. Probably we should create a small list anyway (somewhere in the wiki). To your frame buffer question: As inmarket already said uGFX itself does not care about that. It all comes down to the drivers implementation. When it comes to high-level user API then you might want to take a look at the Pixmap feature of the GDISP module: https://bitbucket.org/Tectu/ugfx/src/a5 ... ?at=master I hope that clears up things a bit. Please let us know should you have any further questions. ~ Tectu

Hello ivan47, Please note that we don't provide support for other libraries. If you're not using ChibiOS/RT then it would be the easiest to copy the actual board template file (which you can find under /drivers/ginput/touch/ADS7843/) and fill in the corresponding routines using the SPI API from the stdperiph library that you're using. Sadly we don't provide examples for this as it is very hardware dependent. It's the touch controllers register you want to read/write from (port is probably indeed not the best name here). Note that this interface is specific to the implementation of the uGFX ADS7843 driver. To implement the board file for your project you just have to make sure that you write this value to the bus before you read. Everything else is taken care of for you. ~ Tectu

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