Joel Bodenmann

Hello and welcome to the community! I'm not sure what your exact question is. What you are saying makes sense and is correct. Except that you don't have to implement the timer_handler() function. Everything else is correct. You can find additional information on how to implement the two functions for the systick (gfxSystemTicks() and gfxMillisecondsToTicks()) in the corresponding documentation. Everything else should just work out of the box if you are running a generic 32-bit (soft-)CPU. I'm not sure whether this answers your questions. Please let us know if you have any other questions.

Both drivers have been added to the repository. Thank you very much for your contributions, we appreciate it a lot! Please feel free to create a new pull request adding the missing features if you ever decide to add then

I am sorry to hear that you broke your display module If the driver works so far please feel free to pull request it. It can always be improved later on. Important is that the usual display features are working. There are many drivers in the repository that don't implement the full set of power modes and so on yet.

Are you 100% sure that this issue only appears in VisualStudio? If not, can you please open a bug report on this? --> https://community.ugfx.io/bug_tracker.html/ugfx-library/

@olegator how is it looking? Do you think that your driver is ready for a pull-request?

Furthermore: What display / display controller are you using? Are you 100% sure that you need to flush once every second? That sounds very odd. Note that µGFX has different redrawing modes and different flushing modes. If you use the flushing stuff built-in the GDISP module, µGFX will take care of when flushes are required and when not. Flushing is part of the driver interface. You still have full control over how flushing happens.

Does it just "seem" to do that? Because as @inmarket mentioned the behavior depends on the redrawing mode. Can you confirm (using a debugger, analyzer, tracer, ...) that the thread that takes care of the flushing actually blocks? Also, we need more information here: Are you using the flushing capabilities built into the GDISP module or a custom solution? If custom, why? The built-in stuff uses a GTimer and therefore doesn't create a dedicated thread for flushing. Also, the built-in stuff is supported all the way down to the display driver level. If you are using custom stuff, are you creating the threads through the µGFX API? (eg. gfxThreadCreate()). Anything else you think would help us to help you...

I'm glad to hear that you are already in the process of manufacturing. Nice work! Please keep us up to date. Oh, I have missed that, sorry! That explains how you managed to get that GUI run so smoothly. I was wondering what kind of magic you applied to run it that smoothly with the voice recognition and everything on an STM32F105

Wow! This is an amazing project! I'm really not sure what to say. This is something you don't see very day. Are you planning on selling the hardware? Can we get one already? Please keep us up to date about this project. We hope that you will make more demos & videos. We'd love to include those in the demos section of our website. This project is definitely worth spreading. Personally I was never interested in all that IoT stuff because most of the things I saw so far weren't that appealing to me. But this gets my full attention. May I ask what your considerations were to choose this microcontroller at the end? As far as I know there are Cortex-M4 based STM32F4 versions available with the same package. Just a tiny bit more expensive but with two or three times the performance (depending on the application). We are very happy to hear that. Thank you for choosing µGFX This is amazing! I didn't know that the µGFX-Studio would already be advanced enough to use it for something like this. Too bad that the current version is still somewhat limiting and doesn't offer all available widgets. We need to get the new µGFX-Studio v0.2 out as soon as possible!

Hi remon! What underlying system are you using? It sounds like your underlying system doesn't provide a preemptive scheduler. This would for example also be the case with the scheduler that comes as part of the Raw32 port.

Winner A @chrisjn52 with his spin box widget: Winner B @Sting with his table widget: Generic information We will sent the STM32F746G-Discovery boards to the winners as quickly as possible. However, it will take some time until we include the winning widgets into the official repository. We will get in touch with each widget author individually to follow up on whether additional modifications are required or recommended.

That is because it has been added to the default values of the driver Makefile: https://git.ugfx.io/uGFX/uGFX/src/master/drivers/multiple/SDL/driver.mk#L3 The template makefile uses that driver makefile, therefore there is no need to add it there as well.

Hello Guido, I'm afraid that honestly there is currently no other documentation besides the API reference and the existing board files for the toggle, dial and keyboard drivers of the GINPUT module available. The toggle and dial drivers appears to be straight forward to use so that nobody complained so far that there's no extra documentation and as far as we know nobody ever wrote a keyboard driver. As our ToDo list is rather large we just never got to it. So you might want to re-evaluate your last statement (although very much appreciated, thanks!). There's quite a lot on the schedule for this week so I can't promise that we get to writing up some documentation for those GINPUT drivers this week, but I put it on the ToDo list now. However, I am pretty confident that you should be able to get it working anyway. The API reference is there (all functions, variables & types are documented). Also, you are more than welcome to ask for help whenever you have any questions. We are happy to help wherever we can.

Actually, forget what I just posted above. I missed that you are trying to set the paths manually now. Sorry! The problem is that we have the following lines in /drivers/multiple/SDL/driver.mk: CFLAGS += `sdl2-config --cflags || /usr/local/bin/sdl2-config --cflags` LDFLAGS += `sdl2-config --libs --cflags || /usr/local/bin/sdl2-config --libs --cflags` Try removing those.

Do you actually have sdl2-config available/installed? You should be able to just type this command in your terminal (outside of any makefile) and get the corresponding paths back: joel@ubuntu:~$ sdl2-config --libs --cflags -L/usr/lib/i386-linux-gnu -lSDL2 -I/usr/include/SDL2 -D_REENTRANT If that doesn't work you most likely don't have that program/script installed or the package manager of the distribution you are using didn't put it in the standard path. In case of you missed that: You have to install the libsdl2-dev package on your host system (the system where you are compiling your µGFX program on). The sdl2-config program/script is part of that package.

There's a lot of stuff that can go wrong with initializing the Linux framebuffer. The obvious stuff (that is also mentioned in the documentation) is that you lack permission to access the framebuffer device if running from user space or that the framebuffer devices is accessible through a different path than then two default ones in the Linux-Framebuffer board files. For the former, fix the permissions - for the latter, modify the framebuffer device path(s) in the board file as described in the wiki. After that there's a lot more that can go wrong. The easiest and most efficient way of figuring out what's happening is to open the board file (the file /boards/base/Linux-Framebuffer/board_framebuffer.h) and simply looking (CTRL+F) for the error message you are getting. For example, the one you are describing appears in line 102 and is related to changing the video properties. It's likely that your system doesn't allow doing that. As you can see there's a #define around that that allows to turn that off. The corresponding documentation/comment at the top of the file where the macro gets defined helps to understand what is going on. I hope that helps you to get it working. I'd like to explicitly note again that you cannot use the framebuffer driver if you are running a desktop environment on the same system. As far as I know (and I might be wrong) it is not possible to use the framebuffer while running an X server.

Hello Ivan, Thank you for your good words, we appreciate it a lot! We've never had contact with NuttX so far. However, we would love to change that! We are not only very open to, but rather actively interested in working together with other projects and companies. Are you in contact with those people or do you happen to have the requires connections to make it happen? Best regards, ~ Joel

Six hours left for final polishing

Six hours left for final polishing

Your problem is that you are both including a premade board file by using the GFXBOARD variable while also manually including the X driver further down below. That won't work. You have to either use the framebuffer driver or either use the X driver (unless you setup multiple displays support but that is most likely not what you are after). If you want to use the X driver you have to set the GFXBOARD variable to Linux if you are running µGFX 2.6. HOWEVER, please read the rest of the message before you do so. The X driver has been deprecated a few minutes ago If you want to use the framebuffer driver you have to set the GFXBOARD variable to Linux-Framebuffer. You are not supposed to manually include any driver if you are using pre-made board files. Note that you would use the X driver if you want to run a µGFX driver inside X (eg. inside a desktop environment). You would use the framebuffer driver if your Linux system doesn't have X or a desktop environment system but rather just a kernel provided framebuffer. Right now at this moment we are extending the Linux documentation. Our community member @olegator contributed an SDL driver which VASTLY improves the performance of rendering a µGFX application on a Linux system that is capable of running SDL (eg. when you're having a desktop environment). If you are running a Linux distribution on your BeagleBone that can run SDL we strongly recommend using the new SDL driver. You can find more information in the documentation (that we are currently updating as we speak): https://wiki.ugfx.io/index.php/Linux Note that we also cleaned up the Linux board files section. You might want to have a look at the repository to grab the latest example Makefiles and drivers: https://git.ugfx.io/ugfx/ugfx Update: The new SDL driver has been officially added:

Hello and welcome to the community! The GINPUT module is able to directly handle digital inputs (eg. buttons attached to GPIOs) through the toggle driver. Most widgets define one or more toggle roles. You can use gwinAttachToggle() to assign any of your buttons to any of the widgets toggle roles. This allows having physical buttons to press virtual buttons, scrolling through lists and so on. Our recommendation is to use this solution if that's possible for your system. It would allow bypassing (and therefore deprecating) the additional Linux driver that makes your buttons look like a keyboard and you would be able to dynamically change the roles of the buttons inside of your µGFX application. However, as per your description it sounds like the keyboard driver of the GINPUT module might be more suited for you. Just as with the toggles roles, most widgets implement keyboard handles. For example, you can use the space or enter keys to push a virtual button, check/uncheck a checkbox or use the arrow keys to scroll through a list. To use this feature you have to implement a GINPUT keyboard driver to interface your current gpio-keys-keyboard solution. You can find the GINPUT driver interface under /src/ginput/ginput_keyboard_driver.h. You can have a look at the keyboard driver implemented in the SDL driver to learn how to interface a keyboard on a Linux system. On a side note: Right at this moment we are writing the documentation for the new SDL driver that vastly increases the rendering speed of a µGFX application running on a Linux system when not using the framebuffer driver. We strongly recommend you changing from the X driver to the new SDL driver. Documentation: https://wiki.ugfx.io/index.php/Linux I hope that helps. Update: The new SDL driver has officially been added:

I haven't looked at your widget yet, I will give it a look tonight or tomorrow morning. If it is working with µGFX 2.5 then it will work with µGFX 2.6 for 100% sure. There are only bug fixes and new features from 2.5 to 2.6. Nothing has changed. Unless we added new bugs that is

Yes, there's always a lot of optimization that can be done by tweaking some of the display controller values. Please keep us up to date about this!

Hello @olegator ! That's quite a coincidence, I just received the ST7735 based display module that I ordered as mentioned above. I guess there's not much fun left for me to do then Thank you very much for contributing this driver. We will have a look at it and include it in the repository eventually (you might want to pull request as soon as you think that it's ready).