Joel Bodenmann

Thank you very much for bringing this to our attention. We just fixed that Note that in general we recommend having a look at the demos that can be found in the /demos/ directory of the uGFX library. The ones on the wiki are easy to get outdated and usually just show the most basic usage possible. ~ Tectu

Great! As inmarket mentioned the default window manager that comes with the uGFX library doesn't handle overlapping widgets unless they are in a parent/child relation ship (containers). This is one of the limitations the window manager has but in return it is a very small and fast window manager that only uses very little resources. However, if you have more complex needs that's no problem: The GWIN API allows to use a different window manager. You can write your own window manager that properly supports overlapping widgets and use that one instead of the default built-in one by calling gwinSetWindowManager(). Writing your own window manager is not as difficult and complex as it might sound at first. So if you would like to have a go on that feel free to use the current one as an example/reference. We are also happy to help wherever we can. ~ Tectu

Calling gwinSetText() invokes a redraw of the corresponding widget and therefore invokes calls from the GDISP module that access the display. The GDISP API is only multi-thread safe is GDISP_NEED_MULTITHREAD has been set to TRUE in your configuration file. ~ Tectu

More information about this can be found here: http://wiki.ugfx.org/index.php/GFILE#STDIO_emulation ~ Tectu

More information on this can be found here: http://wiki.ugfx.org/index.php/GOS#Emulating_Malloc ~ Tectu

To actually answer your question: The way you added interrupt support is fine. Given that uGFX currently doesn't provide a proper interrupt driven mouse driver (as per the reasons listed by inmarket) there's no official / better way of doing this. Adding this to the driver is the most proper way as it keeps the libraries core code unchanged. Compared to having interrupt support directly built into the GINPUT module you don't loose much as the overhead of calling read_xyz() is very little compared to doing the actual I2C read. This is also the reason why we didn't bother adding an interface for this so far: Most touchscreen controllers provide a proper penDown signal that can be hooked up to a pin. Checking a GPIO pin is a lot faster than doing the actual I2C/SPI reading so the performance lost by polling is not that big. Anyway, things like this are on our ultra-low priority ToDo list and are something we will definitely tackle in the future. Most likely stuff like this will be completely reworked for the 3.x release. ~ Tectu

Yes, the background color of the built-in WhiteWidgetStyle is supposed to be straight white. You can see that the generated code uses HTML2COLOR(0xFFFFFF) for that. It doesn't get more white than that Eventually, yes. We will release v0.13 on the 15th of February. Right now we are working on adding the possibility to add custom fonts. If we have enough time we will also add support to provide a temporary cure solution to use custom widgets in the studio (just dummy place-holders). We'll see what we can do. I can imagine that adding graph support should be very easy and that we can get some preliminary version going for 0.13. Frame support can be done quite easily too as it's the same code as the container widget - just with a different rendering. However, the question about the frame widget is how to treat that in the studio. This will usually be used as a pop-up dialog menu. Therefore, the user must be able to define that outside of the actual display page. Adding indirect items is currently not supported at all (but obviously will be) and therefore requires some major changes. I am pretty confident that the frame will be there at least as soon as v0.14 rolls out. If you have any questions, feedback, bug reports or feature requests please do not hesitate to let us know in the corresponding uGFX-Studio section on this forum. We are happy to hear all about them! ~ Tectu

A background is nothing else but a container that spans the whole display area. The background designer just generates a custom rendering routine for that container. Let's have a look at some generated code. The following is the custom rendering code that will be applied to the page container. The background is called MyBackground: static void containerDraw_MyBackground(GWidgetObject* gw, void* param) { (void)param; // Clear container area gdispGFillArea(gw->g.display, gw->g.x, gw->g.y, gw->g.width, gw->g.height, gw->pstyle->background); // Draw the elements gdispImageDraw(&companyLogo, 500, 10, 121, 60, 0, 0); } As you can see the first thing that happens is that the entire container area gets cleared with the background color specified in the widget style. That is always the first thing that happens. When you make your own background by adding a huge rectangle in the background designer it will add another gdispFillArea() call to the rendering function. This means that the container area gets cleared twice which doesn't only waste a lot of performance, but will also lead to render artifacts when the two colors are not exactly the same. In the background we added an image (companyLogo). As you can see that is a bare GDISP image that gets rendered directly. Not an imagebox widget (as you couldn't use them in a rendering routine anyway). The difference between putting an image in the background instead of an imagebox is, that the imagebox adds overhead. It it's a widget, this means that it has to maintain position, styles, fonts, text and so on. The image added to the background is a simple gdispImage object without any overhead at all. Another advantage of putting an image into the background is that you can use the same background on multiple display pages. If you want to show your company logo on all display pages using imagebox widgets you'd have to place individual imageboxes on each display page. This multiplies the overhead mentioned above by the number of display pages. Having the image in the background means that all display pages that use that background use the same rendering function and therefore the same image object. Not only no overhead but also no additional overhead for additional pages. Regarding your question about using a container to apply a style to an entire page: No, the proper way is to use the 'GWIN default style' property in the settings or to assign a style to each widget individually. As per the reason(s) above, never put a container that covers the entire display area. This means that you are doing something wrong (as in not following the intended usage). I hope that helps. ~ Tectu

Thank you for providing this detailed information! Hopefully this will help BenjyC to get his project up and running. But I have to ask again, just to be sure: Did you use the project from the bitbucket repository or the one I attached to a forum post on the previous page? If you used the latter, can you please let us know what modifications were required to get it working (because currently it seems like it hardfaults) and/or provide a ZIP with the modified, working project? ~ Tectu

Interesting, underscores shouldn't have an effect as long as the name starts with a letter (specified by the C standard). I pulled your project before you edited your post so I will have a look anyway to figure out what needs to be fixed. The upcoming 0.13 release already contains a lot of fixes to prevent generating invalid variable and function names. A general comment: Use the Background property of the WidgetStyle to change the background color. Drawing a huge rectangle in the background designer is the wrong approach and will not only have worse performance but will also lead to unexpected problems as some parts of de GWIN module need to know the background color. ~ Tectu

This seems to be a very odd problem. Those color macros are very well tested and no issues are known to exist. I expect the issue to be somewhere in the code generated by the uGFX-Studio. Most likely you have some invalid characters in your color name (eg. spaces or special characters) that don't get filtered properly. Can you please attach your uGFX-Studio project directory as a ZIP archive to your forum post so we can have a look? Can you also give information about the version of the studio, your operating system and which compiler throws this error? ~ Tectu

If he's using the project I attached in a post above then he's not using our makefiles. The baremetal project for the STM32F746-Discovery currently uses one of my own makefiles (to keep stuff easy to understand for people who want to use this as a starting point) and doesn't use the ones that come with the uGFX repository. I guess we have to wait until CShark provides us with his fixed version of the project that actually works. ~ Tectu

I'm afraid we can't really help with that. Try the EmBitz forum Technically you don't. However, the LTDC needs sufficient memory to put the framebuffer somewhere. For small displays the internal SRAM might be enough, but you won't have much RAM left. But for anything bigger than 320x240 this will most likely not work out. That is the reason why all LTDC designs use external SDRAM: It's a cheap way of adding a lot memory to your design. So technically no, you don't need external memory but practically you are forced to because you don't have enough internal one. Yeah, LTDC and DMA2D give a huge performance boost! ~ Tectu

The demo uses the Makefile build system. Therefore, it doesn't use the single-file inclusion system. I'd recommend you to try building and running that demo outside of EmBitz first. Then you will have a base project that will help you to understand which files you need. You can then work on creating an EmBitz project from that. ~ Tectu

Nope, the hardware acceleration is part of the driver and therfore controlled in the drivers configuration file (/drivers/gdisp/STM32LTDC/gdisp_lld_config.h in your case). You can see that DMA2D is already enabled by default. The gfxconf.h configuration file only controls application stuff. ~ Tectu

Once again: The demo that comes with the uGFX library is supposed to run with the plain, standard ChibiOS/RT that you can download. No special versions, no community stuff, just the plain ChibiOS/RT. I just took the time to verify whether everything still works and indeed the supplied demo worked out of the box without any problems. I uploaded a ZIP to the uGFX homepage that you can download. The demo contains everything you need (including uGFX and ChibiOS). Just download, unzip and execute 'make' and everything should work out of the box. Note that ChibiOS 16 is just a bundle that contains ChibiOS/RT, ChibiOS/NIL and ChibiOS/HAL. Therefore, you should be able to run the exact same demo without any modifications by just swapping the ChibiOS directory (and modifying the path in the Makefile if the directory hierarchy changed). Please give the project that you can download here a try and let us know if it worked. ~ Tectu

I just realize that this board file can be found in the uGFX directory. I have no idea who put it there. But that board file is definitely NOT a good example. We'll either clean it up get rid of it. Sorry for the inconvenience! As an example on how to talk to a display controller via SPI using ChibiOS/HAL you might want to look at this: /boards/addon/gdisp/board_SSD1306_spi.h ~ Tectu

Hello Dolence and welcome to the community! There are many things that can go wrong here so let's go through a short list: Make sure that your SPI pins are initialized properly. It's a good manner to initialize ALL pins in the board_init() function. So do the same as you did for the Reset, CS and DS pins for the MOSI, MISO and SCK pins. Use the ChibiOS/HAL API for handling the SPI. Currently you are manually accessing some of the SPI registers which is NOT recommended when working with ChibiOS. You can find plenty of examples on how to use the ChibiOS/HAL API to interface an SPI client in the various ChibiOS examples, demos and testhal as well as for some other displays and touchscreens in the uGFX boards directory. Make sure that you use spiSelect() as well as spiUnselect() inside the acquire_bus() and release_bus() functions. Use the synchronous API (spiSend() if I remember correctly) to send the actual data. Check your SPI modes. Make sure that the clock polarity etc. is set properly. Your ChibiOS/HAL SPI config struct seems a bit odd. Usually the ILI9341 should work with all default settings. Just limit the clock speed but don't touch the SSE, SSI and so on (I might be wrong here). Check the SPI signals with an oscilloscope or a logic analyzer. Lastly: We have had multiple issues with the ILI93xx drivers where a supplier claimed that it's one display but in fact it was another one. While commonly this usually happens with the ILI9325 vs. ILI9320 we have seen the same with the ILI9341. If none of the above fixed your issue I'd recommend trying all the other ILI93xx drivers. This should be very straight forward as the board files for all those drivers are exactly the same. I hope that helps to resolve your issue. ~ Tectu

That's nice! Can you upload your project so everybody can benefit? At the end we want heavily extend the 'ready-to-use' projects that can be downloaded from the uGFX homepage. Just to clarify: Did you get this working based on the project I posted a couple of posts earlier? ~ Tectu

Very interesting. I guess we have some reading ahead of us I guess that this will depend a lot on the used memory (speed) and the used resolution. Anyway, my statement "Adding su pport for the second layer is fairly easy" was from the actual implementation point of view. uGFX already implements everything required to handle a second layer. The required changes only have to happen in the STM32LTDC driver. But let's not get too off-topic in MobileWill's thread. We can always open a new discussion thread in the Development section ~ Tectu

This is a bit a problem with the STM32F429i-Discovery board: The people who designed this board decided to use a display that has an internal controller (ILI9341). The entire purpose of having the LTDC (and DMA2D) peripherals is that you can directly hook up the bare display panel without any dedicated controller in between. The ILI9341 can do this but it needs to be put into this mode first. This is a configuration step that happens through the SPI interface. So when uGFX is initializing the driver, it will first tell the ILI9341 display driver via SPI that it should stop bothering and just directly route the RGB interface through. This is why the board file of the STM32F429i-Discovery is so cluttered and full of stuff. You can compare it to other board files. Usually its just a matter of a couple of lines of code. I have no idea what the issue with SPI5 would be. Maybe ChibiOS/HAL changed something. As mentioned I currently can't give it a try as I am on the road and most likely I won't find time for this before next week. All I can tell you is that the Makefile based example projects that can be found in the STM32F429i-Discovery board directory were known to work very well. Very happy to hear that We are indeed very keen to make uGFX become the best embedded GUI library available while keeping the sources open and maintaining an active community. Actually those where some of the main reasons why I started uGFX. DMA2D is supported by uGFX. If you have a look at the STM32LTDC driver you can see that the driver config has a corresponding define for that to enable or disable DMA2D. The performance gains are HUGE! As of now you can't use the second LTDC layer, that is correct, but the DMA2D hardware acceleration works on one layer. Adding support for the second layer is fairly easy and it's on our ToDo list, just currently not that high important. What basically needs to be done is initializing the second layer. Then, use a gdispControl() command to return a GDisplay* pointer of the second layer and you're done. Now you have two separate displays you can talk to. Once can then proceed by adding more API to switch the currently active layer and so on. ~ Tectu

Hello MobileWill and welcome to the community! king2 has already answered most of your questions so I'm just being a bit more specific here: 1. The /boards directory doesn't contain any drivers. It only contains what we call board files. The board files contain functions which uGFX uses to communicate with your hardware. For example, there can be a function to write a byte, another to read a byte and another function to change the intensity of the backlight. These are things that we can't do for you because it heavily depends on the user hardware. The board files are a very flexible way of providing the user with the possibility to run the same software on any platform. So in you case, if you have a look at /boards/base/STM32F429i-Discovery you will see that it doesn't contain a single line of actual uGFX code. The code in there is mostly 3rd party code to work with the RAM and so on. The board.mk Makefile includes the actual drivers which are located in /drivers. 2. The last time we checked the examples for ChibiOS/RT 2.6 and ChibiOS/RT 3.x that are located in the board directory of the STM32F429i-Discovery board worked out of the box. ChibiOS 16 just seems to be a new way to give the entire bundle (HAL, OS, ...) a version number so you are still using ChibiOS/RT 3.x and therefore the examples should work. Sadly we can't test that right now. 3. Regarding your question about the window stuff: uGFX comes with a full window manager. We also provide widgets to create dialog boxes and so on. Furthermore, it's possible to completely modify how a widget looks from the actual user space application code. This means that you can change the default look of our slider widget without modifying the actual uGFX library code. Most widgets also come with a built-in rendering function that can handle images in case of you have some more advanced needs. It is also possible (and comparably quite easy) to write your own widgets. You can read more about this stuff in the following locations: http://wiki.ugfx.org/index.php/GWIN http://wiki.ugfx.org/index.php/Widgets http://wiki.ugfx.org/index.php/Creating ... ng_routine You might also want to talk to king2 about that as he recently worked a lot with modifying how widgets look 4. Any display panel will work with the hardware acceleration provided by the STM32F429 microcontroller as long as you can hook it up to the LTDC interface. This means that in general any panel with an RGB interface will work. I hope that helps a bit. Please do not hesitate to ask any further questions. And let us know when you had any issues getting the examples for ChibiOS that are located in the board directory for the STM32F429i-Discovery working. ~ Tectu

Hello CShark and welcome to the community! When I understand you correctly you managed to make the LED blinking with the project I attached in my last post? The errors you get is because uGFX isn't available/linked properly. I just took a look and it seems like I have removed the uGFX part from the Makefile. What you need to do in the Makefile is the following: Set the GFXLIB variable to the path pointing to the µGFX library root directory Include the main µGFX Makefile (/ugfx/gfx.mk) Add GFXSRC to the sources variable/list Add GFXINC to the include paths variable/list Include additional Makefiles of the µGFX library to include board files, drivers, ... That would look something like that (I haven't tested it! I'm currently on the road): ################################################################################ # Generic Makefile for STM32 based applications using StdPeriph/STM32Cube. # # # # Copyright (C) 2015 by Joel Bodenmann # # # # Feel free to use this makefile without any warranty on your own risk. # ################################################################################ # This is the name of the binaries that will be generated TARGET = project # Some paths CMSIS = CMSIS HAL = STM32F7xx_HAL_Driver # Include uGFX stuff, don't forget about $(GFXSRC) and $(GFXINC) further below GFXLIB = /path/to/your/ugfx/directory include $(GFXLIB)/gfx.mk include $(GFXLIB)/boards/base/STM32F746-Discovery/board.mk # Here we add all *.c files that we want to compile CSRCS = \ $(GFXSRC) \ $(HAL)/Src/stm32f7xx_hal.c \ $(HAL)/Src/stm32f7xx_hal_cortex.c \ $(HAL)/Src/stm32f7xx_hal_flash.c \ $(HAL)/Src/stm32f7xx_hal_flash_ex.c \ $(HAL)/Src/stm32f7xx_hal_rcc.c \ $(HAL)/Src/stm32f7xx_hal_rcc_ex.h \ $(HAL)/Src/stm32f7xx_hal_gpio.c \ $(HAL)/Src/stm32f7xx_hal_dma.c \ $(HAL)/Src/stm32f7xx_hal_i2c.c \ $(HAL)/Src/stm32f7xx_hal_ltdc.c \ $(HAL)/Src/stm32f7xx_hal_pwr.c \ $(HAL)/Src/stm32f7xx_hal_pwr_ex.h \ system_stm32f7xx.c \ main.c # Here we add all *.cpp files that we want to compile CPPSRCS = # Here we add all *.s files that we want to compile (Don't include startup file) ASSRCS = # Here we add the paths to all include directories INCS = \ $(GFXINC) \ $(CMSIS)/Device/ST/STM32F7xx/Include \ $(CMSIS)/Include \ $(HAL)/Inc \ . # here we add the paths to all custom libraries LIBDIRS = # here we add libraries LIBS = # StartUp file STARTUP = startup_stm32f746xx.s # Linker script LDSCRIPT = stm32f746nghx_flash.ld # The controller type CONTROLLER = STM32F746xx # MCU flags MCUFLAGS = -mthumb -mcpu=cortex-m7 # Should a map file be generated? (yes / no) GENERATE_MAP = no # The following variables hold binaries and settings ARCH = arm-none-eabi AS = $(ARCH)-gcc LD = $(ARCH)-gcc CC = $(ARCH)-gcc CPPC = $(ARCH)-g++ SIZE = $(ARCH)-size OBJCOPY = $(ARCH)-objcopy ASFLAGS = -ggdb -Wall CFLAGS = -ggdb -Wall -std=c99 CPPFLAGS = -ggdb -Wall LDFLAGS = -lnosys -fno-exceptions -fdata-sections ################################################################################ # Don't change anything below this line # ################################################################################ # Some directory and file magic BUILDDIR = build OBJDIR = $(BUILDDIR)/obj MAPFILE = $(BUILDDIR)/$(TARGET).map # Add the startup file ASSRCS += $(STARTUP) # Generate the object names OBJS = $(addprefix $(OBJDIR)/,$(addsuffix .o,$(basename $(CSRCS:%.c=%.o)))) OBJS += $(addprefix $(OBJDIR)/,$(addsuffix .o,$(basename $(ASSRCS:%.s=%.o)))) OBJS += $(addprefix $(OBJDIR)/,$(addsuffix .o,$(basename $(CPPSRCS:%.cpp=%.o)))) # Automate the inclusion paths CFLAGS += $(INCS:%=-I%) $(MCUFLAGS) -D$(CONTROLLER) -DUSE_STDPERIPH_DRIVER CPPFLAGS += $(INCS:%=-I%) LDFLAGS += $(LIBDIRS:%=-L%) $(INCS:%=-I%) $(LIBS) $(MCUFLAGS) -T$(LDSCRIPT) # Some user settings magic ifeq ($(GENERATE_MAP), yes) LDFLAGS += -Wl,-Map=$(MAPFILE),--cref endif # This is the default target if the user does just calls 'make' all: build size # Build all the files build: builddirs $(BUILDDIR)/$(TARGET).elf $(BUILDDIR)/$(TARGET).bin $(BUILDDIR)/$(TARGET).hex # Create the required directories (if not already existing) builddirs: @mkdir -p $(BUILDDIR) @mkdir -p $(OBJDIR) # Create the *.bin $(BUILDDIR)/%.bin: $(BUILDDIR)/$(TARGET).elf @$(OBJCOPY) -O binary $< $@ # Create the *.hex $(BUILDDIR)/%.hex: $(BUILDDIR)/$(TARGET).elf @$(OBJCOPY) -O ihex $< $@ # Link everything together to a *.elf file $(BUILDDIR)/$(TARGET).elf: $(OBJS) @echo Linking $@ @$(LD) $(LDFLAGS) -o $(BUILDDIR)/$(TARGET).elf $(OBJS) # Compile assembly files $(OBJDIR)/%.o: %.s @mkdir -p $(dir $@) @echo Compiling $^ @$(AS) $(ASFLAGS) -c -o $@ $^ # Compile c files $(OBJDIR)/%.o: %.c @mkdir -p $(dir $@) @echo Compiling $^ @$(CC) $(CFLAGS) -c -o $@ $^ # Compile cpp files $(OBJDIR)/%.o: %.cpp @mkdir -p $(dir $@) @echo Compiling $^ @$(CPPC) $(CPPFLAGS) -c -o $@ $^ # Print size information size: $(BUILDDIR)/$(TARGET).elf @echo @echo $(SIZE) $^ @echo $(FOO) # Clean up clean: @rm -rf *.o $(BUILDDIR) $(OBJS) $($MAPFILE) $(TARGET).* @echo Done # Clean must be a phony target so make knows this never exists as a file .PHONY: clean ~ Tectu

Oh dear, I completely forgot about this one! Sorry! I got disturbed while working on the new STM32F746-Discovery baremetal project and then forgot about it. Sadly I won't have time to finish this in the next 10 days. However, I already have a project that compiles correctly, it just currently doesn't show anything on the screen. If anybody wants to have an early look I attached the project to this post. The new project uses a new dedicated Makefile and the latest STM32F7Cube HAL. Edit: I just had a look. There must be an issue in the initialization code as the LED doesn't start flashing. Compiling with uGFX works just fine, tho. If nobody will have fixed this I'll finish this next week. ~ Tectu

Hello Sillvers, pleased to meet you again too That sounds like you're assigning the new image the wrong way. What you need to do is calling gwinSetCustomDraw() with the new image as the custom parameter. Like this: gwinSetCustomDraw(ghProgressbar1, gwinProgressbarDraw_Image, (void*)&newGdispImage); That will automatically update everything that needs to be updated and issue a redraw. Note that you might want to close the previous image to free some resources (depending on your needs). As inmarket mentioned you NEVER EVER have to manually call a rendering routine. The GWIN module takes care of redrawing when something needs to be redrawn. If you need to issue a redraw manually, use gwinRedraw() instead. That will use the currently assigned rendering routine to redraw the widget. ~ Tectu