Joel Bodenmann

Looks like the actual link is missing. ~ Tectu

With the RA8875 it is a bit border line... I think we should indeed provide split drivers (GDISP only and GINPUT only) that work independent from each other as with every other touchscreen module. However, we can still provide an easier-to-use driver that is part of the /drivers/multiple directory. This way a user using the RA8875 can simply include one driver and everything else will work out of the box. It would basically be the same as for the Windows and Linux drivers. ~ Tectu

Hello kalevik and welcome to the uGFX community! All the GWIN API is thread safe. Most libraries have really big problems when it comes to multi-thread drawing. However, uGFX is one of the few that has no issues at all with that. You can draw from as many threads as you want. The only thing where uGFX is not multi-thread safe is the GFILE module. ~ Tectu

Well inmarket pretty much mentioned every point. Just one more thing: Yes the wiki page is currently out of date on the GINPUT board file and I will put this on my higher priority list. However, please note that the wiki is just giving you information on how to implementing a board file and not the actual driver. The driver is part of the uGFX library and as inmarket already said it needs some advanced coding skills and hence we have not put up documentation on that yet. The board file on the other hand just describes how the interface between your microcontroller and the touch controller works. To use an existing driver you just have to implement the board file. The uGFX driver will use the functions in the board file to communicate with the touch controller chip. ~ Tectu

If the GTIMER module is not enabled then the module does not require any stack. The amount of stack required depends from application to application. We put the default to 2k because this way it works with every even so complex application that we tested so far. However, it is possible to work with 1k or even less but that needs rigorous testing to be sure that it works reliably. But that's something that you have to do. As a general rule: All the module specific settings in your configuration file do not have any affect as long as the corresponding module is disabled. ~ Tectu

Can you please give us some information about your hardware setup, the toolchain that you are using and most importantly: Please include the full (stack) back trace from your debugger when hitting the hardfault. ~ Tectu

Can you please give a detailed description of what is not working? We need all the information that we can have in order to help you. What do you see on your screen? Is the backlight on? Did you see the startup logo? Are you using a dev-board or is it breadboard with long wires? etc... If you see artifacts or garbage on the screen a photo is always helpful as well. ~ Tectu

With these kinds of things the supplier usually gives you some arduino library to download. It often helps to take a look at the initialization code there. ~ Tectu

To answer your other question: The reason why you have to tell uGFX which OS you are using is so that you can easily use the same application with different underlying systems without any modifications. And as you see this is exactly what you want and one of the main advantages of using uGFX: It is totally portable. ~ Tectu

It looks like you're not including the c standard libraries hence you are missing NULL. About M_PI: This is sadly not properly defined in the C standard and every compiler / library does it differently. These days you usually just have to #include (which is already done for you) and tell the linker to use the math library (you need to pass the -lm flag to the linker). I don't know how you would do this in Keil, sorry. I'm sure Google will help. If you want to bypass the problem for now just make sure that GDISP_NEED_ARC is disabled in your configuration file. getpin_pressed() is a function that the GINPUT driver polls to see whether the touchscreen is pressed or not. This function need to return TRUE when the touchscreen is pressed and FALSE otherwise. Note that in case of the ADS7843 controller this is actually a dedicated pin (PENIRQ when I remember correctly). You can simply hook it up to a GPIO and return it's state. These two functions are called by the GINPUT driver at the beginning and at the end of a communication with the touch controller. These functions are very helpful when you happen to have more than one device talking on that bus etc. In your case, you can simply pull the CS line low in aquire_bus() and high in release_bus(). I hope that helps. ~ Tectu

I like where this is going. It would be neat if we could provide official Teensy (3.1) support at the end of this ~ Tectu

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