Joel Bodenmann

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.

@inmarket: I do not think that that is what is going on here. After all, his screenshot is showing that an instance of arm-none-eabi-gdb is being launched. @jbsull: Could you please show us a screenshot of your OpenOCD configuration? @cpu20 might be of help here too

Did you start (and configure) OpenOCD? Our ChibiStudio guide explains this step-by-step with screenshots: https://wiki.ugfx.io/index.php/Using_ChibiStudio#Configuring_OpenOCD There's a ready-to-run project for the STM32F429i-Discovery using ChibiStudio on our downloads site. Maybe you might want to have a look at that one to see how the debugger was configured:

Hah, glad to hear that you figured it out. I was about to blame file encoding. Don't hesitate to ask if you have any further questions. We're happy to help wherever we can

Hello Alan, For things like this, you can use a software timer. The GTIMER module provides those. They are extremely simple to use: Write your function, create a GTIMER object and specify the interval --> https://wiki.ugfx.io/index.php/GTIMER Software timers are less flexible and less precise than threads. However, for things like updating the UI they are usually more than sufficient. If you feel like that's not the case, then go straight for a dedicated thread. There are demos on how to create threads with the µGFX API (gfxThreadCreate()). µGFX will directly use the underlying threads provided by FreeRTOS in your case.

Hey there! This sounds like a simple encoding/file_format issue. What system are you working on? On unix this might be a simple repository format issue that can be fixed with something like dos2unix. Any additional information that you can provide might help here.

Hi, I can't really help with this right now but the reason why @inmarket told you to have a look at those functions is because functions such as geventEventWait() and others use things like gfxSleepMilliseconds() and similar internally.

Hi, I'm not sure whether I understand you correctly. Fonts are always handled in that manner. Fonts are never loaded into RAM by gdispOpenFont(). The requirement for using fonts is that the font is available in a byte addressable memory. Microcontroller FLASH usually fulfills this requirement. gdispOpenFont() will just prepare the font but the font data is not actually loaded into RAM. You can also store your font in a non-byte-addressable memory and use gdispAddFont() to add it to the font engine during runtime once you loaded it into an addressable memory.

Hello Alan, I'm not sure whether you want a custom widget to receive & handle the toggle or whether you just want a generic toggle event in your applications event processing loop. Can you please clarify this? Did you properly use gwinAttachToggle() to attach the toggle to your custom widget? Did you check for the return value of that function? It returns FALSE if attaching failed. Note that pressing the toggle will not generate an event that you receive through the regular geventEventWait() setup. Your widget's toggle handling functions will be called. You can process the toggle event there and if you like you can create an event there. Did you make sure that your toggle board file is correct? I'd recommend you to properly debug this by setting breakpoints in the corresponding functions.

You need to attach the toggle to the widget by using gwinAttachToggle(). Have a look at the API reference and /demos/modules/gwin/widgets.

The argument you pass to gfxAlloc() is the number of bytes you want to have available for your own use. If you request 40 bytes then you'll be presented with a zone where you can use all 40 bytes to your pleasing. However, the memory manager still needs to store some information (let's call this meta information) about the allocated memory. Most importantly it's the size of the block: If you call gfxFree() then the memory manager needs to be able to know how many bytes are going to be freed. It does that by putting a header in front of the memory that you get a pointer to. That's why you need a few bytes more than just what gfxAlloc() gets as a parameter.

You're welcome - happy to help!