Joel Bodenmann

That sounds good to us! We are happy to answer any of your questions to help you figuring out what causes the problem with the F7 port. It's just that we are currently drowning in work so we don't have time to get to it ourselves. ~ Tectu

Glad to hear that you got it working - does this actually solve your issue/answer your question or should we still have a look this when we get to it? ~ Tectu

The built-in graph widget only provides very basic functionalities. It doesn't have an internal list of points. Each time the graph is redrawn you must redraw your points manually using gwinGraphDrawPoints(). This means that if you want to scroll your graph you'll have to shift your points manually using the process you described. If you have needs for a graph that can shift points I would strongly recommend implementing your own graph widget! ~ Tectu

Displaying multiple graphs at the same time is not a problem at all. You can have as many windows and widgets on your display at the same time. Just think of the graph window as if it were a regular widget like a button or a slider: You can have as many of them as you want, working independently. That is also why I used the term "graph widget" instead of "graph window" in my first post - to avoid confusion. ~ Tectu

uGFX comes with an existing graph widget: http://wiki.ugfx.org/index.php/Graph Examples: https://i.ytimg.com/vi/WcNgBEWWnrc/maxresdefault.jpg http://wiki.ugfx.org/images/b/b4/Graph_demo_640x480.gif Whether you want to use the existing graph widget or not is up to you. The graph widget is one of the first widgets that we created. It isn't the most used thing in the uGFX library and therefore we didn't spend a lot of time extending and optimizing it. Don't get me wrong, the code that is there works very well and there are many people who use it. It's just not the holy grail for all your graph needs. Writing your own graph widget would be very easy as the graph itself is not a widget but a window (read the GWIN article in the wiki for more information). The basic difference is that a window doesn't take any user input while a widget does. Therefore, creating a custom graph window is just a matter of using the already available GDISP drawing functions to make it look and behave like you want. You can look at the existing graph implementation (/src/gwin/gwin_graph.c) to learn how to implement your own, it's really straight forward. Please do not hesitate to ask should you have any other questions regarding the existing graph widget or writing your own. We are happy to help wherever we can. If you decide to either write your own graph from scratch or extend the existing one, we would of course be very happy if we can add your contribution to the library so others will benefit too ~ Tectu

Hello SimonRogers and welcome to the Community! Sorry for the late reply. We are currently very busy. Sadly I can't promise you that we'll have time to take a look at this before Monday morning. The last time we checked the demo worked the way it should. There are also a lot of users that successfully use the uGFX library with cyrillic fonts so we don't expect there to be a big issue. Did you try to use a different font? This article explains how you can use any Cyrillic TrueType font that you can find on the internet: http://wiki.ugfx.org/index.php/Font_rendering ~ Tectu

Hello Sillvers, You change the buttons text like you change the text of any widget by using gwinSetText(). API Documentation: http://api.ugfx.org/group___widget.html#ga0d2b40a6ef33c7be87f77876a94b9561 Please do not hesitate to ask should you have any other questions. ~ Tectu

Hello Kent and welcome to the community! I'll fix and update the project over the weekend. Sorry for the inconvenience! ~ Tectu

Nothing in uGFX is being redrawn periodically. When using a plain gdispImage you have to redraw the image yourself when it needs to be redrawn. When you are using the ImageBox widget the image will automatically be redrawn if it needs to, eg. if something covered it and moved or when the visibility changed. In either way, there are no periodic redraws. ~ Tectu

Well, glad to hear that you got it working Let's hope we'll be faster next time ~ Tectu

We are glad to hear that you got it working! Happy to hear that you like the uGFX library ~ Tectu

Using RLE fonts is the way to go then ~ Tectu

Glad to hear that you like what you see Note that you can run uGFX on any RTOS (or bare metal without any operating system at all). The decision whether you want to use uGFX or not shouldn't be influenced by the underlying system. Please do not hesitate to ask should you have any other questions. We are happy to help where we can. ~ Tectu

1. The most proper, most reliable and most portable way of doing this is creating your own widget that allows to input a date/time. The widget would behave just like the other widgets such as the buttons and the sliders: You can create an instance, you can place them anywhere on the display and you can give them any size. The widget would sent an event through GEVENT when the date/time has changed just like the slider sends an event when the slider position has changed. You can also add different functions eg. to query the current date/time and to change from 12 to 24 hour mode. Those are of course not necessary but writing a real widget helps you to add functionalities in the future while being completely portable. Writing your own widget is not as complex as it might look at the first glance. Essentially it is just a VMT (table of function pointers) where you register your functions that handle touch inputs and so on. Everything is nicely commented and documented. As there are already quite a lot of different widgets you have many different examples that will help you to understand how to write your own widgets. We are also happy to answer any of your questions (please make a new forum thread for that). I would really encourage you for writing a real widget for this. The widget class is really just a container and it won't be more difficult than writing this manually. There is one function that renders the widget and in that function you call gdispDrawXxx() and gdispFillXxx() functions just as you would outside of a widget and there are other functions that tell you when a touch happened and at what position. It's straight forward - really. Just read some of the existing ones and let us know when you have any questions 2. Using the gwinButtonDraw_Image rendering routine is the correct way of doing what you want to do. You can replace the image at any time by just calling gwinSetCustomDraw() with a different image pointer. That function will also take care of redrawing the button widget so you don't have to take care of that yourself. Important note: Many people want to change the image during runtime because they want to draw different images for the pressed and the released state. However, that is not necessary. .The gwinButtonDraw_Image already takes care of that for you: The image you pass by gwinSetCustomDraw() can either have one time, two times or three times the height of the actual button widget itself. When the image is twice the height than the button then the top half of the image is used for the 'released' state and the bottom half is used for when the button is in the 'pressed' state. The same applies to when then image is three times the height: Top for pressed, middle for released and bottom for when the button is disabled. Here's a very basic image just to make sure that you understand what I'm trying to say:

Multiple things need to be kept in mind when considering image caching. Whether it make sense to cache an image depends a lot on the user hardware/architecture as well as the application itself (how big the image is, what format/encoding the image is using, how often it needs to be drawn etc). As inmarket already said, caching an image means that a chunk of RAM will be allocated to store the entire decoded image. A decoded image is essentially a table of pixel values in the display controllers native color format. Working with an RGB565 format would mean that two bytes per pixel need to be allocated. A plain BMP file is already pretty much that. After a small header it's essentially a table of pixel values. This means that in terms of performance (as in saving CPU cycles for decoding) you won't gain anything when caching a plain BMP file. The next thing to consider is memory speed. This depends on the architecture of your device and the actual components used. In your case you're having both the ROM that stores the image as well as the RAM where you'd store the cached image on the same bus/peripheral (the FMC). Assuming that reading from your SDRAM is as fast as reading from the NOR would mean that the main gain would be that you don't need to spent time changing the peripheral configuration to switch between the two memories. Another important thing to keep in mind is hardware acceleration: In your case the DMA2D peripheral would allow to directly blit the entire image 1:1 without any CPU time involved at all. This is obviously a huge benefit and would save a lot of CPU time. In my opinion in your case it boils down to how often you need to draw the image, how big your RAM is and how fast you can access the NOR. I hope that helps... somehow. ~ Tectu

Hi! Thank you very much for your feedback. We appreciate it a lot! We see what you mean and we will definitely do that. It sounds like a great idea! However, this might take some time as you said yourself that's quite a bit of work. We'll let you know once we're done! ~ Tectu

Hello Sillvers and welcome to the community! The file/folder structure and the Makefiles provided with the library are very well tested and known to work without any issues. As inmarket already mentioned you're most likely pointing the GFXLIB variable to the wrong place. This variable should point to the top-level directory of the unmodified uGFX library directory. You can find some additional information about this here: http://wiki.ugfx.org/index.php/Getting_ ... grate_uGFX Let us know when you have any other questions. ~ Tectu

Glad to hear that you got it working! We would love to include the corresponding drivers and board files into the repository Is that Linux driver now working nicely as a generic driver or what's the current state of that? ~ Tectu

Sadly he's not able to help as he's currently on a trip (vacation). However, he sent me the files attached (GINPUT driver, board file, test project). He used this on a 3.2 Linux. The uGFX version he used this with was something between 2.3 and 2.4. I hope that helps you somehow... Please let us know how this turns out. ~ Tectu linux_ginput_event.zip

Somebody I know has already written a generic event based touchscreen input driver for using touchscreens with uGFX on a linux system. I will ask him whether it would be possible to share that driver. That would save you some pain. ~ Tectu

Hello sordfish and welcome to the community! It looks like we forgot to apply these changes. I put it on the ToDo list! Thank you for reminding us ~ Tectu

You might want to store your calibration values once you performed the calibration. This way you can 'boot up' (starting uGFX by calling gfxInit()) without the need to calibrate again. Information on how to use the calibration interface can be found here: http://wiki.ugfx.org/index.php?title=To ... alibration ~ Tectu

Just that we understand us correctly - you should be able to get this setup working without using pixmaps. For optimization that's definitely a good way to go but it should definitely also work without it. If you are having trouble getting the basic setup working without the pixmaps please do not hesitate to ask. We are happy to help where we can. You should be able to even use different bus speeds for the two by changing the SPI configuration in the acquire_bus() function so the board files. GDISPVMT_pixmap is line 33 of /src/gdisp/gdisp_pixmap.c. LLDSPEC is line 413 and 415 of /src/gdisp/gdisp_driver.h. All that does is either adding nothing or 'static' depending on whether you use just one or multiple displays. Judging from the compiler output you are lacking the inclusion of some files. Can you give some information about the build environment and the toolchain that you are using? Eg. are you using a makefile or the single-file inclusion etc. As this seems to be a bitbucket repository - is it possible that we get access to it so we can give the configuration a quick look? Please make sure that you use the latest master of the uGFX repository and that you integrated the uGFX library into your existing RPi project using either of these two methods: http://wiki.ugfx.org/index.php?title=Ge ... grate_uGFX ~ Tectu

Hello and welcome to the community! Is it possible that you just forgot to enable pixmaps in your configuration file by setting GDISP_NEED_PIXMAP to TRUE? Otherwise, can you please show us the complete compiler output log? You definitely shouldn't get any error about LLDSPEC in any case. Just to be sure: Did you manage to draw to your display without using the pixmaps so far? Can you please also provide information about the IDE and the compiler that you are using along with the compiler output log? ~ Tectu

Thanks, we will look into this. Might take a few days, tho. A few little side notes: The gradients on the F7 Discovery board look somewhat odd. You can set GWIN_FLAT_STYLING to TRUE in your configuration file to get rid of them. You can disable the µGFX start-up logo by setting GDISP_NEED_STARTUP_LOGO to FALSE you enabled an anti-aliased font but you haven't actually enabled font anti-aliasing. Set GDISP_NEED_ANTIALIAS to TRUE ~ Tectu