Joel Bodenmann

Hi, I created a new topic out of your post because it was unrelated to the Kinetis Design Studio. The GDISP_DRIVER_VMT macro is only used internally. That's why there is no documentation of it. It's a macro that gets defined by the driver itself. Unless you are writing your own driver you don't have to worry about it. Just include the driver(s) that you want to use and everything else should be taken care of.

We fixed the issue with the color formats. You should be able to run an unmodified version of the latest µGFX library (master branch of the repository) on your system. Thank you for bringing this to our attention.

Thank you for bringing this to our attention. We will take a look into it and take the necessary measures to fix this problem. In the meantime: We have cleaned-up and added the Linux event system touch/mouse input driver to the repository. Can you please pull the latest master and give it a try? You should be able to just use the new Linux-Framebuffer-Touch board file. It pulls the original Linux-Framebuffer files internally.

May I ask what hack you had to apply?

Thank you very much for testing it. We are happy to hear that you were able to get it running without any problems at all. We will include this in the official repository within the following days. Keep an eye on the blog to stay up to date about this.

Hello and welcome to the community! Currently there is no official GINPUT driver for for the Linux (event) system in the repository. However, as you mentioned there is a working solution: We never got to try it ourselves but we know of several people which claim that it works well just out of the box. If you could try that driver and leave us some feedback we can look into integrating it into the official repository fort he upcoming release of µGFX 2.7.

It will take quite some time to get it to a usable state. But we are working on it as we speak Wow, that sounds like quite a project! Please keep us up too date about your progress. We are very interested to hear more about it!

Thank you very much for sending the project. Also big thanks from us towards you friend! We will try to get it done this week. I'm afraid that demo wasn't created with the µGFX-Studio. This might be interesting to you:

Yes, if you can post your work that would definitely help us speeding up the process!

Good to hear back from you! There's currently really no deadline for that. If required, we can ensure that it will be there for the µGFX 2.7 release that should take place in mid-September. However, it sounds like you have working board files. Is everything working including the touchscreen using the STM32 Cube HAL?

Hello Alamart, I'm afraid I'm not sure what you're asking. Can you be a bit more specific?

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.