Joel Bodenmann

Hello ekondratiev and welcome to the community! uGFX itself allows to connect two (or more) displays to the same controller. The displays can be the same or different types. You can then control each display independently from each other. If you want to display the same information on both screens you would either simply draw the same thing to both displays or you would, provided that you have enough memory, create a pixmap framebuffer of the size of the screens in memory and perform each drawing option inside of the frame buffer. Then you can simply dump the entire framebuffer to both displays and you'll have an exact copy on both screens without any additional drawing overhead. Note that pixmaps are a feature of uGFX that we haven't properly documented yet. Essentially a pixmap is a virtual display of a given size in memory. You can draw to the pixmap like you would to any other display and then simply dump the pixmap to the actual display. You can have a look at the pixmap demo which you can find under /demos/modules/gdisp/pixmap. You can find some more information about multiple displays here: http://wiki.ugfx.org/index.php?title=Multiple_displays Please let us know should you have any additional questions. ~ Tectu

Hello rexnanet and welcome to the community! There are three things you need in order to run uGFX: A display driver A board file The OS abstraction The display driver The display driver is the piece of software between the uGFX logic and the microcontroller peripherals (the hardware interface). You're using an ILI9341 display controller and uGFX already comes with a driver for this controller. Hence you don't have to do anything here. The board file The board file is a simple file through which uGFX communicates with your hardware. For each display driver there is a board file template located under the display driver directory (eg. /drivers/gdisp/ILI9341/board_ILI9341_template.h). You have to copy that file to your project and fill in the empty routines. As you will see it's just a matter of an init routine to initialize your peripherals and different other very simple routines to control the reset pin and actually send data to your display controller. As you already have a working project you can simply take your current code and fill it into the board file. The OS abstraction uGFX internally uses some memory management algorithms and other things. Some people are using an operating system (eg. an RTOS susch as FreeRTOS) on which they want to run uGFX. The GOS module is the module which implements all these things. Assuming that you're not using any special OS you can simply use the existing RAW32 port. This port of uGFX implements everything to run uGFX on a bare metal system without any underlying OS. The only thing you have to do is to implement two functions which convert ticks to delays as described by the documentation. This is usually straight forward as it is just a matter of dividing your system tick by a number to retrieve a value in milliseconds. As you can see all the heavy lifting is already done in your case and it's just a matter of gluing things together. Please let us know should you have any questions or should you run into any problems. We're happy to help wherever we can. ~ Tectu

Glad to hear that you got it working! We would appreciate it A LOT if you would write a guide that becomes part of the wiki. uGFX lacks a lot of "How to use" documentation which makes it difficult for beginners. Please check your mail to learn about your wiki credentials. That issue is most likely caused by missing linking to the math library. Just link to the math library (add -lm to the linker/compiler flags and you should be ready to go). If that's not it, please show us the compiler output log. ~ Tectu

Hello and welcome to the community! It looks like you're missing a couple of things: The board file is not named correctly. It needs to be named board_ILI9341.h You don't seem to have a configuration file. Copy the gfxconf.example.h from the librarys root directory and name it gfxconf.h About ch.h: The board file that you're using is a board file for the use with ChibiOS/RT. When you're not using ChibiOS/RT then you need to implement your own board file. The easiest way is to copy the board file template ugfx/drivers/gdisp/ILI9341/board_ILI9341_template.h and start implementing it using your HAL. In case of you're using ChibiOS/RT (because you call the ChibiOS/RT initiailization functions in your main.c and you're using the ChibiOS/HAL in your board file) then please get a ChibiOS/RT project working first without uGFX. Once you have it running on your board it will be easy to add uGFX to the project. ~ Tectu

Hello Stas285 and welcome to the community! Inmarket has already covered pretty much everything. I'd just like to leave a few more comments: 1. uGFX is meant to be easy and powerful at the same time. I know that this sounds very controversial and that most libraries fail miserably at this point. We pay a lot (and I mean a really lot) of time and attention to have an API that is totally consistent and easy to use. Along with the very simple and straight forward API we provide interfaces for more advanced programmers to customize their uGFX experience to fit into their application seamlessly without any unnecessary pay-offs. Summary: uGFX is very easy to use compared to other embedded GUI libraries if you don't want to dig deep and as soon as you want to dig deep you will discovery that it provides everything you need to customize it to build a powerful and optimized application. Just click a few minutes through the API and the examples which you can find in the /demos/modules directory and judge by yourself whether the API is easy enough: http://api.ugfx.org But as inmarket already said: We're of course biased. This can however always be turned to a positive point: We looked for a good embedded GUI library ourselfs back then and there way nothing around that suited our demands (which were very close to yours) so we decided to do it ourself ;-) 2. I'm sadly not allowed to list any specific names due to NDA contracts but many big industrial companies are already using uGFX very successfully and they are rather satisfied with it. In fact, about half of our commercial customers switched from an existing embedded GUI library to UGFX. 3. ChibiOS/RT is a great RTOS. It's basically uGFX but on the OS side: It is very easy to use at the beginning (very straight forward API, plenty examples, active forum community and open development) and when you become more advanced there are enough interfaces that you can use to optimize your application. One of the greatest things about ChibiOS/RT is that it provides an (optional) built-in HAL. You can get anything from I2C, SPI, SD-Cards and so on working within minutes. uGFX actually started as an official add-on module to ChibiOS/RT called ChibiOS/GFX. As soon as we realized that there's a high demand for a library like uGFX in the embedded world we decided to abstract the OS interface so it can now be used with anything. 4. uGFX-Studio: The beta is very close as inmarket said. I just published a new . It is already a usable program but it lacks the actual widgets as we focused on the ground work first. We will add the remaining widgets within the following weeks and then we'll release the public beta.We have already provided preview versions to selected commercial customers. If it helps you to decided whether you want to use uGFX please contact us through the listed e-mail address and we'll see what we can do for you If you have any further question do not hesitate to ask. We're happy to help wherever we can. ~ Tectu

Yep, sorry for the long response time. Inmarket and I maintain this forum during our spare time and we're currently both very busy (but still happy to help when we can - just give it a bit of time). There's definitely something very fishy going on. Please do as inmarket told you so we can verify it on our own. And in general: It's not a very good thing that you post the response to a forum post on your blog as other people who use search engines to find answers to their problems will find this thread and they won't find all the related information in one place. So for the future please keep everything related in here. Long posts are no problem at all. The more details we get the better we can help. Don't give up! You only get better when things don't work ;-) ~ Tectu

There is some validation happening inside the calibration code: The very last cross that you click (the one in the middle) is to verify that the calibration was somewhat accurate. It basically checks the coordinates and when they are within a certain limit then you pass the calibration - otherwise it fails and you have to repeat the calibration process. The first thing to do is not using your finger but something like an old plastic PDA pen or something that will vastly increase accuracy. If you can pass the calibration with a pen then your problem is definitely that you're not accurate enough with your finger. You can increase the value GMOUSE_STMPE811_FINGER_CALIBRATE_ERROR which is located inside of the touch board file. This value specifies the tolerance of the verification in pixels. ~ Tectu

I took out a board of my own that uses and SSD1289 and the ADS7843 to make sure that the uGFX drivers and overall code are still working. Result: Everything works fine out of the box (latest master branch). As we can rule out issues on the uGFX side and hardware issues (you mentioned that your old binary still works) there's definitely something wrong with the board file or the underlying system initialization (eg. peripheral setup). Now you mentioned that it sometimes senses but not correctly. Does this imply that it sometimes doesn't do anything? Can you please explain exactly and as accurate as possible what you see on the screen, what you're doing, what the reaction is etc. Can you just never pass the calibration screen because it tells you that calibration failed? Does the first cross show up but never vanish when you press the touchscreen? You said that you checked the getpin_pressed() with an oscilloscope. Important to know is whether the board file function actually properly returns TRUE/FALSE. Please light up some LED when it returns TRUE and turn the LED off when it returns FALSE. Before the getpin_pressed() magic is not working 100% reliably there's no sense to digg any further. I took a look at your board files again and I still can't find anything wrong. The only thing that's missing is initializing the IRQ pin properly. As you updated your Chibios it can be that the internal chibios board file changed and the default configuration is no longer working for your setup. For example the pin could now be a floating input rather than a pulled up one etc. This is why you should always initialize all of your required peripherals completely manually inside of the board_init()functions. ~ Tectu

Can you list the changes that you applied? So when I understand you correctly we're 100% certain that the hardware itself works? Can you please hook up your debugger to see whether it get stuck somewhere in the actual touch code? Can it be a stack overflow (GTIMER_THREAD_WORKAREA_SIZE should at least be 2048 for now). Can you also verify that getpin_pressed() is working by either looking at your debugger or flashing an LED in said code? We need to figure out whether the system crashes or keeps running and uGFX does just not get proper touch information. Also, did you change the underlying system that you're using? (Eg. did you update ChibiOS/RT as well?) I took a look at your code and I couldn't find anything that's obviously wrong. ~ Tectu

You definitely forgot to include some files. Looking at the names of the undefined references will give you a pretty good idea which files you missed as we structured everything neatly. What you're definitely missing: The actual GWIN files (gwinSetVisible is part of /src/gwin/gwin.[ch]), the mcufont code (which is located under /src/gdisp/mcufont/), the GINPUT keyboard code (include all the interface codes, even though you don't use them (keep them disabled in your configuration file)). I hope that helps you to figure out what you're missing. It would take a very very very long time to list every single file here. If you hit any other problems please let us know. Happy to help where we can. ~ Tectu

Please stop worrying about the internal code of uGFX. I assure you that everything is right with it (talking about the overall structure, not bugs). You never ever have to change anything inside of the uGFX sources, that's what the board- and configuration files are there for. You shouldn't worry about storing and restoring your calibration data before you can successfully use the device. If you can't pass the calibration screen then there's definitely something wrong in either your board file, your general peripheral code or the hardware itself. The first thing to make sure is that the getpin_pressed() function works correctly. This can easily be verified by either using your debugger or flashing an LED on and off accordingly. Otherwise, if you ruled out all the common errors: Can you please paste both board files so we can compare them? (The one that worked with the previous version of uGFX and the one that you're using now). You can use this site to paste your code: http://paste.ugfx.org ~ Tectu

You don't have to rewrite a lot of things. The hard part (talking to your microcontroller peripherals etc.) stays the same. The only thing that changes is the board file. It's just a matter of how your existing data is presented to the rest of the uGFX code. ~ Tectu

It wasn't easier, it's exactly the same! Nothing changed besides a few variable names and struct values. What inmarket tells you is that you have enabled the touchscreen in your gfxconf.h by setting GINPUT_NEED_MOUSE to TRUE but without properly linking to a driver. This is most likely due to the same reason as with your display issue: The driver interface changed and you need to update your touchscreen board file to match the new interface. So the way to your solution is: Do the same as you did for your display driver: Update the board file to match the new interface. We're sorry for the inconvenience. The old interface which you used was the same since the very first day that code existed and therefore not very optimized to fit the new code structure. We don't intend to change these things often (or ever). We're happy to help where ever we can. ~ Tectu

I'm not sure right now. Can you please make sure that compiler optimization is disabled? Make especially sure that LTO is disabled. If that didn't work, can you please tell us which compiler/toolchain you're using? ~ Tectu

Regarding your new GEVENT related problem: The structs werencleaned up and all the field holding widget pointers are named gwin now. if (((GEventGWinButton*)pe)->button == ghConsole) becomes if (((GEventGWinButton*)pe)->gwin == ghConsole) and so on. ~ Tectu

It looks like you switched to a newer version of ugfx. We changed the board file interface of the GINPUT module a few months ago. You're board file is no longer compatible. However, the changes are minimal and you should be able to update your board file by looking at the new template in the drivers directory and the examples. Let us now should you hit any problems. ~ Tectu

Just to clarify: You don't have to implement your own drivers, the drivers are already part of the uGFX library. What you have to do is implementing the board file which is just the interface through which uGFX talks to your hardware. Let us know should you face any other problems. ~ Tectu

Hello aymen and welcome to the community! The errors about the PWM that you're getting are because your'se using the ChibiOS/RT board files without actually using ChibiOS/RT. The board file that we provide for the STM32F4 Embest board are only for use together with ChibiOS/RT. If you don't want to use ChibiOS and go bare metal you have to implement your own board files. For this, please copy the empty template board files from /drivers/gdisp/SSD2119 (for the display) and /drivers/ginput/touch/STMPE811 (for the touchscreen) and implement them according to your setup. Note: You can copy the empty files without implementing them and the project will still compile. This is handy as you can make sure that your build environment is working properly before you start implementing the board files. In case of you're implementing board files for this board using the STDperiph library we would be happy to include them into the repository. ~ Tectu

I sadly don't have a working Arduino myself. However, if you two figure out how to build the required library without too much hassle I'd be happy if we could write a guide about that for the wiki. ~ Tectu

That's correct. The Non-threaded branch is ongoing development towards an uGFX which is (optionally) able to run without any threads. inmarket is doing all the development there as I am currently focusing 100% of my time on the uGFX-Studio. I'm sure he'll let you know in case of he can use some help Thanks for your interest and curiosity! ~ Tectu

That is indeed the better solution! This is the wiki article containing some information regarding custom rendering interfaces: http://wiki.ugfx.org/index.php?title=Wi ... _interface ~ Tectu

The current implementation of the label widget does not provide the possibility to render a with a transparent background. The only widget that provides transparent background is the container. However, you can easily implement this yourself. What you need to change: Locate the function gwinLabelDefaultDraw() in the file /src/gwin/gwin_label.c, copy it, name it something like gwinLabelTransparentDraw() and replace all gdispGFillStringBox() function calls with the appropriate gdispGDrawStringBox() function calls. The only thing left to do is replacing the gwinLabelDefaultDraw entry in the VMT (line 53) with gwinLabelTransparentDraw. You should now have a transparent background. You can find the API of gdispGDrawStringBox() here: http://api.ugfx.org/master/group___g_d_ ... ddd6d6da52 We will eventually add a transparent background rendering option of the label widget ourselves (I put it on the ToDo list) but this won't happen before the weekend for sure. ~ Tectu

Can you please tell us the problems that you're facing? We can't help you when you don't tell us what's not working ;-) You can run uGFX on a RPi by either using the Linux port, running FreeRTOS on the RPi with uGFX on it or you could even use uGFX bare metal on the RPi (nobody tried that yet, I think). The simplest way is the first one as Linux is already running on the board and uGFX comes with a working Linux FrameBuffer driver. ~ Tectu

Can you please ask more specific questions and provide us with more information about the problem that you're facing? If you require commercial support please contact us through info@ugfx.org to request a quotation. ~ Tectu

This sounds like it will be very difficult to debug. Can you please add some kind of heart-beat thread that flashes and LED and prints out some text through the serial port every 500ms and see if it keeps running w/o any problems as soon as the display "freezes"? it might also be a good idea to check the signals on the physical interface of the display. ~ Tectu