Joel Bodenmann

@timandr just checking: Do you have all the information you require to proceed? Please don't hesitate to ask if you have any questions. We are happy to help where we can

Thank you for sharing the video. Personally I am pretty sure that what you are getting there is way below the performance that the STM32F469i can deliver. As mentioned previously the DSI setup of the ST demos don't seem to use the optimal settings. Blitting a pixmap on a system like that should not not be a visible operation, it should happen so fast that it appears to be instant. I hope that we will have time to write the proper board files before we release µGFX 2.7 by the end of the month. We are sorry for the delay, there's currently just too much on the ToDo list.

Sadly we are having the same problem: We are engineers, not designers. Both @inmarket and I are not very good when it comes to making visually appealing designs. This is why there is no set of fancy/nicer looking default rendering routines for GWIN that could be used on more powerful systems. @chrisjn52 is currently writing a set of minimal, old-school styled 3D rendering routines. I'm not sure what the progress is on that. You can create gradients by using gdispBlendColors(). You can find an example in the default rendering routine of the pushbutton widget which uses a gradient background/fill unless GWIN_NEED_FLAT has been set to TRUE: // Fill the box blended from variants of the fill color tcol = gdispBlendColor(White, pcol->fill, BTN_TOP_FADE); bcol = gdispBlendColor(Black, pcol->fill, BTN_BOTTOM_FADE); dalpha = FIXED(255)/gw->g.height; for(alpha = 0, i = 0; i < gw->g.height; i++, alpha += dalpha) { gdispGDrawLine(gw->g.display, gw->g.x, gw->g.y+i, gw->g.x+gw->g.width-2, gw->g.y+i, gdispBlendColor(bcol, tcol, NONFIXED(alpha))); }

I guess there is not much left to say for me... Rendering a BMP from flash should definitely be a very fast operation. As mentioned in my previous post, the ST example uses a weird mode for the DSI. That may or may not result in lower performance, I haven't studied the datasheet enough yet to give a certain answer to that question. Unfortunately we are very busy the following two weeks, it might take up to three weeks until we get to finishing the implementation of the official board files for the STM32F469i-Discovery board Please don't hesitate to ask if you have any questions. The limitation(s) imposed by the single-fine-inclusion mechanisms are documented here. You can find more information about the performance & resource requirements of our PNG decoder here (mind the comments!):

We are happy to hear that you are making good progress with your table widget. You definitely seem to put a lot of effort into it. Having a full test protocol is a very professional thing to do. Please keep it up and don't get discouraged, this is definitely not an easy job if you want to get it right!

Hello Maytham and welcome to the community! @inakto sent us his project which is working. However, it is far from a state where we could just copy-paste and include it into the repository. We started working on this and we got the basic display stuff working. We didn't look into the touchscreen stuff yet but that should be rather straight forward because µGFX already has a driver for that touch controller. The main issue is that the official STM32F469i-Discovery demo(s) from ST themselves use the DSI in a the video mode. That is by far the "worst" mode to use. From what we can tell you would only use that mode if you're short on memory which isn't the case on that board. Theoretically we can just take the ST board files and wrap them around the uGFX board files, but the DSI definitely wouldn't be working at its maximum performance.

Hello and welcome to the community! It is definitely possible to run µGFX on an 8-bit AVR microcontroller. I have a friend who successfully ran it on an ATmega with an ILI9341 SPI display. Furthermore, I think that @inmarket also used it on some Arduino system based on an AVR microcontroller. However, while it is certainly possible to run µGFX on such a platform it really isn't recommended. We recommend to use at least a 16-bit platform.

As @inmarket mentioned the issue seems to be a restriction in the compiler used by Keil. Your options are: Using a different underlying system such as Keil RTX, FreeRTOS or ChibiOS which are very well tested with µGFX (or any of the other alternatives) Change your Keil project to use GCC instead of ARMCC Investigate on how to use the "Embedded Assembly" alternative (link: http://www.keil.com/support/man/docs/armcc/armcc_chr1359124253861.htm) which appears to not have these restrictions.

Hello @Sahsuvar and welcome to the community! If memory serves me right it is indeed just a syntax problem. As @inmarket mentioned we currently just lack the man power to take care of everything. If you can get it fixed, we would love to put a version of the code that works with the Keil compiler into the official µGFX library. Note that you can use the GFX_COMPILER_KEIL macro to write Keil specific stuff. One of the reasons why this currently isn't that high on our ToDo list is because most of the people that use Keil (with the µGFX library) are using Keil RTX as the underlying system (RTOS). In that case the Raw32 port is not used.

Sounds good! Can't wait to see it!

The Linux-Framebuffer board files only contain drivers & board files for passive display output. They don't contain anything that handles mouse/touch inputs. If your touchscreen/mouse is accessible through the Linux input event system, you can simply use the Linux-Framebuffer-Touch board files which will automatically include the /drivers/ginput/touch/Linux-Event driver. You can find more information about this here: https://wiki.ugfx.io/index.php/Linux#Touchscreen_.2F_Mouse And a complete tutorial here: https://wiki.ugfx.io/index.php/Raspberry_Pi Also, this new Linux-Framebuffer-Touch board file has been added just a few days ago. You might want to click the "Follow" button on the µGFX-Development blog to stay up-to-date about these kind of new things, updates & bug fixes: I hope that helps. Let us know if you have any other questions.

Hello @Sting, We worked a bit with the Linux framebuffer board ourselves yesterday and we found a bug that prevented using it on some systems. We fixed that bug now. You might want to retry using the framebuffer driver on your embedded Linux device.

Hello @timandr and welcome to the community! That is actually the expected behavior when manually adding files to a project. Judging from your screenshots you are doing the right thing. You always have to tell the compiler/linker which paths it should include. This is "normal" and is nothing special with Eclipse or your particular setup. However, note that in general you could also just use the Makefile(s) that come with the µGFX library. We are currently working on a project that uses an Altera FPGA and the NIOS-II soft CPU. It too comes with an Eclipse environment and generates Makefiles for the project. At least with our project it is possible to just include the µGFX makefiles in that generated makefile. Apparently the Altera tools are smart enough to keep manual changes made by the user. But that's just additional information. You are in no way obligated to include the µGFX library by using the built-in makefiles. You can just include it by manually adding all files an paths. It's just a very tedious job. Don't trust the highlighting of Eclipse. The µGFX build system is way too complex for this. Many of those macros get defined and undefined dynamically during the compilation process. Eclipse only knows about the state of those prior to compilation. Just ignore the Eclipse highlighting. We never worked on the Microblaze architecture itself but as mentioned above we ourselves as well as a few of our customers are running µGFX on FPGAs with soft-CPUs successfully without any problems. Getting this to work should definitely not be a big problem. Usually it's a bit of a pain until it compiles the first time because each SDK of those soft-core/FPGA vendors works a bit differently. All in all, what you are describing is correct. You are definitely approaching this the right way. The compilation error you are getting (the one about gfx.h: No such file or directory) is most likely caused by the fact that you are not adding the path to ugfx/src to your compiler include paths list. Can you please try adding the that path and making a clean build? I hope that helps. Please don't hesitate to ask if you have any other questions.

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?