Joel Bodenmann

We added the possibility to flip the display horizontally and/or vertically for the SSD1963 driver: https://bitbucket.org/Tectu/ugfx/commit ... 32c2114113 ~ Tectu

We have created a new article about touchscreen calibration and how to store calibration data: http://wiki.ugfx.org/index.php?title=To ... alibration Any feedback is welcomed. ~ Tectu

We're sorry, inmarket and I are currently both very busy. I put your issue on my ToDo list and I will get back to you before Monday. ~ Tectu

Chatting with inmarket it just turned out that we actually have an official demo showing how to rotate, scale and transform a polygon. You can find the demo under /demos/modules/gdisp/polygons/. ~ Tectu

Polygon functions do indeed provide parameters for translation. However, scaling is not implemented. The GMSIC module provides some magic like gmiscMatrixFixed2DApplyScale() which you might (should) be able to apply on the array of points which is being passed to the polygon drawing functions. You can find the API reference of the GMISC module here: http://api.ugfx.org/master/group___g_m_i_s_c.html Note: The GMISC module is not really heavily tested. However, we don't know of any issues so far. ~ Tectu

The pixmap is created using the exact same color format as your display controller. Otherwise you would have to translate each pixel and the main idea behind a frame buffer is that it uses the same parameters as the actual display so you can quickly transfer the frame buffer information to the display using burst writes. ~ Tectu

Perfect! Thank you Sir ~ Tectu

Sorry for the off-topic but can you from now on please use the "Post Reply" button at the bottom of each thread page to reply? Using the "Quote" button will add the previous message to your post and in well structured threads like this one it becomes messy. I removed the quotes from your previous posts. Thank you for your understanding. ~ Tectu

Let us know should you face any problems. Good luck! ~ Tectu

May I ask you why you would not want to directly run a proper X setup on your Pi? Anyway: People have already successfully run uGFX on the Pi. We provide a linux framebuffer driver so you don't need any X. That part should definitely work and set-up quite quickly for you As you have the required memory here is what I would do: I'd create one large pixmap frame buffer that is the size of all your displays. Then when rendering you can write the frame buffer to each display using the gdispGBlitArea() function. The parameters of said function allow you to easily draw just that part of the frame buffer that should go on each individual display. To simplify things you could create your own rendering routine called something like renderPixmap() and it would automatically to through all your displays and split up the frame buffer correctly. ~ Tectu

I'm sorry but I have to clear things up a bit first: Do you need to display one big image across smaller screens or will each screen display a different image? Is each display an exact mirror copy of the other displays or will each display need to be able to display different things? Also, can you tell us about your hardware resources? What system are you using? Do you have sufficient RAM to create a frame buffer for each individual display? ~ Tectu

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