Joel Bodenmann

Can you please provide a ZIP containing your entire ChibiOS project so we can have a go on it ourselves? We haven't had any problems at all with using µGFX with ChibiOS and neither did anybody else - this has to be something very small in the build setup

Hello @Stewels and welcome to the µGFX community! I took a look at your makefile and this is wrong: # GFX files. include $(GFXLIB)/tools/gmake_scripts/library_ugfx.mk include $(GFXLIB)/tools/gmake_scripts/os_chibios_git.mk Please follow this guide to add µGFX to your existing ChibiOS project: https://wiki.ugfx.io/index.php/Using_ChibiOS/RT

Thank you for your feedback, we appreciate it a lot! I'm not really sure what you'd expect. Usually you need to debug your application, not the library you're using. So simply using fprintf() as suggested by @inmarket should get the job done.

@inmarket I already have his project with the corresponding changes in uGFX.

Glad to hear that you got it working! I was somehow under the impression that you don't get anything on the display - this definitely makes sense. I assume the errors you're getting are due to the fact that there's not enough RAM to fit the uGFX heap during linking time.

Did you properly set GFX_CPU, GFX_OS_HEAP_SIZE and GFX_COMPILER? The latter is very important when using Keil. When using the Raw32 (baremetal) port with Keil you want to make sure taht GFX_OS_HEAP_SIZE is a non-zero value. It's the heap size that µGFX will use in bytes. Give it something like 20k or 40k to get started.

Whether that is okay or not is something you need to decide yourself. You have to implement the widget the way you like it The GTimer should definitely only run while you're editing the numbers. I'd add API for that, something like: mywidgetHoursSet(GHandle gh, uint8_t value); mywidgetMinutesSet(GHandle gh, uint8_t value); mywidgetHoursFlash(GHandle gh, bool_t enabled); mywidgetMinutesFlash(GHandle gh, bool_t enabled); So when you want to start changing the hours, you'd do this: // Start flashing the hours digits mywidgetHoursFlash(ghWidget, TRUE); // Some code that allows the user to modify the hours while (...) { // ... mywidgetHoursSet(ghWidget, <newValue>); // ... } // Done changing the hours - stop flashing mywidgetHoursFlash(ghWidget, FALSE);

Hello Fabien, There are no built-in mechanisms for this. However, it's extremely easy to implement this yourself as all of the things you need for that are exposed as high-level API. The most challenging thing will be the handling of overlapping containers but as @Steffan showed that is no biggie either:

Hello Alan, Using a GTimer inside the custom widget to make the digits flash is definitely the (only) right approach. You can either separate the gdispFillStringBox() into multiple ones or (and this should be fast), simply use gdispFillArea() to render a rectangle over the portion of the string you want to hide momentarily (to make it look like it flashes). You can use gdispGetStringWidth() to find the correct width of the rectangle.

Hi @Oshel, There's not really much going on in _gosInit() for RAW32. I'm afraid there's not much that comes to mind. Unfortunately you have to get out the debugger and dive into it One thing though: Did you try this with disabling all modules so that gfxInit() really just invokes the GOS module? Please don't hesitate to ask if you have any specific questions - happy to help wherever we can!

Great! Thanks a lot for sharing this with the community

I'm not really sure whether I understand what you want to achieve, but in general: Use a GTimer inside your custom widget to implement things like animations, flashing and stuff like that. But keep in mind that you are only allowed to draw in the one drawing/rendering function. So use the GTimer only to change an internal flag and draw based on the state of the flag.

Hello nathan, Are you sure that you downloaded the latest version of the µGFX library? I just checked the changelog.txt file and it clearly lists the changes under the Release 2.8 line. If in doubt, the changelog is also listed at the bottom of the download page file description:

Glad to hear that everything is working now. We released v2.8 of the µGFX library which comes with a vastly reworked STM32LTDC driver. A couple of issues have been fixed. Additionally, it's now possible to use the second layer of the LTDC.

Can you please show us the implementation of auto_Demo() and updateModeItem()? Also, what's the value of UPDATE_ITEM_INTERVAL?

Hello Tobi, Thank you for your feedback - we appreciate it a lot! There's nothing wrong in your code. This must be an issue in the SDL driver itself (the one in /drivers/multiple/SDL). I haven't written the SDL driver myself so this is primarily wild guessing but I assume the in the SDL initialization there is some configuration flag that lets you choose whether touchscreen events are being processed as mouse events (in case of SDL can distinguish the two). There's definitely no other magic involved in other parts of µGFX. I don't have time to dive into this right now - could you take a look?

Hello Alan, Yes, you can have as many running GTimers as you want (it's fine to have two gtimerStart()). However, don't forget to call gtimerInit() on each GTimer object. It should look like this: GTimer gtimer_Demo; GTimer gtimer_UpdateItem; gtimerInit(&gtimer_Demo); gtimerInit(&gtimer_UpdateItem); gtimerStart(&gtimer_Demo, auto_Demo, 0, TRUE, AUTO_DEMO_INTERVAL); gtimerStart(&gtimer_UpdateItem, updateModeItem, 0, TRUE, UPDATE_ITEM_INTERVAL); Did you do that? If this was not the problem: How did you check that the second one didn't work? Keep in mind that unlike threads, all GTimers are executed in one thread (the thread internally created & maintained by the GTIMER module). Each GTimer instance will run on the same stack and the same priority. So make sure that GTIMER_THREAD_WORKAREA_SIZE is set accordingly.

That's great! We're preparing a few new icons for the new version now. Anything else that comes to your mind?

Qt is extremely overkill for that platform - you won't have any luck getting that running, and even if, it will run extremely poorly. Whatever you want to do with Qt on that platform: Use µGFX instead. µGFX has been built exactly for this.

Hello Jim, I just fixed that in the software. Will be part of v0.20.6 that should be released in a few hours. Simply delete the font_t declarations in gui.h. They are not needed. Use gstudioGetFont() if you need access to a font in your code. Example: font_t f = gstudioGetFont(DejaVuSans12);

Hello Jim, It's correct that you copy all the files of the generated output directory (generated by the µGFX-Studio) to your project. Once you added the necessary files you just have to add the call to guiInit() to your main.c. Here's the most minimalistic main.c that we use for testing purposes: int main(void) { gfxInit(); guiInit(); guiShowPage(DISPLAY_PAGE); while(1) { gfxYield(); } } of course your main() can contain other things as well. You really just add the functions you can find in gui.h to interact with the GUI. I hope that helps. Don't hesitate to ask if you have any further questions.

Hello Ambroise and welcome to the µGFX library! The Qt drivers that come with µGFX are there so you can use µGFX inside a Qt application. The only reason they exist is because we use that in the µGFX-Studio. You cannot use µGFX to run Qt. I started developing µGFX because I wanted something like Qt but targeting embedded systems. So if you like Qt then you'll like µGFX - the philosophy is the same. Running Qt on Embedded Linux is usually not a problem but running Qt on a microcontroller is pretty much pointless as Qt was not build with that in mind. What exactly are your needs? & requirements? Grüsse aus dem Wallis, ~ Joel

@nathanwiebe: Time to upgrade to stock v2.8

ChibiStudio is just a custom distribution of Eclipse. All it really is is the default Eclipse with the default CDT tools (C development tools) and a few ChibiOS specific plugins. Those plugins are really ChibiOS specific. They provide stuff like analytics of ChibiOS threads and so on - you can't use them with anything other than ChibiOS. If you want to use ChibiStudio but you're not using ChibiOS then you can just go ahead and use Eclipse. There are other (plenty!) of other Eclipse distributions specific for a certain target. For example, there's STM32SW4 for STM32 baremetal targets. There are also Eclips eversions specific to other ARM versions. As far as I know Atmel provides their own IDE named AtmelStudio which is based on VisualStudio (But I might be wrong there - long time...).

Glad to hear that you managed to get it working! Well done! I'd like to improve our documentation where necessary, but I feel like those steps have been explained there. Where do you see possible improvement? By the way: 4444 is the telnet port while 3333 is the GDB port.