Joel Bodenmann

@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!

This must be incredibly slow! As @inmarket mentioned, filled arcs are extremely complex and slow. Wrapping it in for() loops is no good here Images will be vastly faster than this. It of course depends on your system and the available resource but it's pretty safe to say that almost any system will be vastly faster with images than this. Of course, you don't want to re-decode a PNG every time you have to render your button. So either cache the image or use an image format that is extremely fast to decode (such as BMP or even better: NATIVE).

Hi, There's currently no existing rendering function for that. Depending on your needs (and your platform / available resources) you might want to consider using images.

Hello Alan, The gwidgetVMT allows you to register functions for the following toggle events (copied from the documentation): uint16_t toggleroles; /**< The roles supported for toggles (0->toggleroles-1) */ void (*ToggleAssign) (GWidgetObject *gw, uint16_t role, uint16_t instance); /**< Assign a toggle to a role (optional) */ uint16_t (*ToggleGet) (GWidgetObject *gw, uint16_t role); /**< Return the instance for a particular role (optional) */ void (*ToggleOff) (GWidgetObject *gw, uint16_t role); /**< Process toggle off events (optional) */ void (*ToggleOn) (GWidgetObject *gw, uint16_t role); /**< Process toggle on events (optional) */ The toggle status is not saved in gw->g.flags. A toggle can have two states: on and off (true or false, 1 or 0, ...). You get a call to ToggleOn() and ToggleOff() accordingly. It's up to you as a developer to decide what to do with that information afterwards. In case of the existing pushbutton widget we just change the internal flag of the pushbutton that keeps track of the pressed/unpressed state. But in your widget you do whatever you think is best. ToggleOn() and ToggleOff() just inform you that the state of the toggle (the hardware button) changed. The rest is up to you.

Hello and welcome to the µGFX community! From the µGFX perspective you have done everything right so far. It appears that the only compilation errors you're getting are from ChibiOS. The errors you're getting indicate that you didn't enable some of the peripheral drivers and peripherals themselves. Make sure that you enable everything you need in the ChibiOS's configuration file halconf.h and mcuconf.h. There should be examples for these files in the corresponding board file directory /boards/base/Embest-STM32-DMSTF4BB/example_chibios_3.x/. I hope that helps. Don't hesitate to ask if you have any other questions. We're happy to help wherever we can!

Hello Alan, Yes, that is exactly correct! You use gwinAttachToggle() to attach your hardware button to the widget and inside your custom widget you can add the functions to handle the toggle input in the VMT as described in the wiki.

Great work at getting it working! Thank you for sharing your findings with us! The reason your memory requirement is so high is because the SSD1306 driver has to maintain an internal framebuffer. That's simply due to the fact that the SSD1306 driver requires you to write entire chunks of pixels each time - so that's a limitation given by the display controller you're using µGFX is capable of using external memory. That's no problem at all. You can locate your framebuffer anywhere you want. In fact, some driver, such as the STM32LTDC almost always use external memory for that.

Hello @marcwolf and welcome to the µGFX-community! As you have most likely realized there is currently no driver for the ST7789V display controller that comes with µGFX. However, writing a new driver is very easy and there's an entire guide on this in the wiki: https://wiki.ugfx.io/index.php/Display_Driver_Model There are already plenty of existing display drivers that can be used as examples & references as well. Alternatively, we can implement the driver for. Please don't hesitate to contact us via e-mail for a quotation. No matter what kind of interface the ST7789 provides, µGFX will definitely be able to use it - including pixel streaming.

Hello Deon and welcome to the µGFX-Community! Thank you for bringing this to our attention. We'll look into this!

I hope you found the documentation: https://wiki.ugfx.io/index.php/Creating_a_widget

Using the console widget is definitely a bad choice in any case. The console widget is not really meant for text that changes, labels are more suited for that. The console widget doesn't generate any events (in developer terms it's a window, not a widget). For this kind of thing you usually want to implement a custom widget (unless a label is enough, which it seems to be the case here so far).

Glad to hear that it works! The applications/notepad demo is really old. Do you need it for a certain thing? We should definitely update it but that is really extremely low priority for us.

Hello Fabien, The Notepad demo is quite old - I'd have to check to figure out whether it still works properly. In the meantime, can you please try one of the GWIN demos such as /demos/modules/gwin/sliders?

Hello Ian and welcome to the µGFX community! There is indeed an offline version of the font encoder available in /tools/mcufontencoder. You can either use the pre-build binaries or compile it yourself.

Hi @thexeno, I'm currently reading this with my phone on the train so I can't dive into any details. But to answer your earlier question: Yes, the SSD1306 driver is a well tested driver that is used by a lot of commercial customers and community members. I used it myself both in customer projects as well as hobby projects. I used it successfully with different compilers as well. I know that that information doesn't help you to resolve your problem right now but just to give you some confidence on this.