Joel Bodenmann

Sorry for the late reply. What uGFX revision are you on? We changed the LTDC code a few weeks/months ago as we introduced support for the F7 and back then the DMA2D seemed to work just fine. Is this only related to your other changes or is the DMA2D driver not working for you in general? ~ Tectu

Thank you for your feature request. We put it onto the ToDo list and we might give it a shot once we completed the TextEdit widget (separate branch) and implemented the default keyboard handlers for all widgets. If you need this more or less quickly I can only recommend you giving it a shot yourself. Implementing a widget yourself is not as difficult as it might look on first glance because the GWIN subsystem handles all the difficult tasks. Furthermore, there are already plenty of different widgets which can serve as examples. And if you have any questions we are happy to help where we can ~ Tectu

We cannot help you unless you post the compiler output logs. In case of you used 'very old' uGFX version before you updated to the latest master I would recommend you copying the latest board file templates and compare them to your current ones. There were some changes regarding the board files a few versions ago. Also, note that you don't have to create a board file directory for your custom board inside of the uGFX library directory. Just place the board files somewhere in your application/project directory and add them to your Makefile as any other source files. You should never ever modify the content of the uGFX library directory. Otherwise upgrading to a newer version can be very very cumbersome. There is no STM32F407 Discovery board file in the uGFX repository because this board does not have a display. There is however a board file for the Embest board which is an STM32F407 with an add-on. Furthermore, there are board files for dev-boards without a display but where a display can easily be added such as: ugfx\boards\addons\gdisp\board_SSD1289_stm32f4discovery.h. I assume that this is the board file from the 'previous version of ugfx' that you are referring to. ~ Tectu

The file gfx.h is not supposed to be in your project directory. What gave you the impression that you should copy it? Remove it and the error is gone. ~ Tectu

Can you please upload the ZIP archive as an attachment to your post? We will have a look at this during the weekend. Sorry for the delay. ~ Tectu

A simple forum search would have fixed your issue some time ago Another community member encountered this issue and we fixed it: viewtopic.php?f=28&t=263 Please let us know in the uGFX-Studio section of the forum whenever you encounter a problem with the studio. ~ Tectu

You should never ever modify the uGFX library sources to archive something in the application level of things. You can submit a custom rendering routine either through the widget initialization struct (the customStyle field) or the function gwinSetCustomDraw(). It doesn't matter where you implement your custom rendering routine. Usually they are located in a separate file. You can find more information here: http://wiki.ugfx.org/index.php?title=Cr ... ng_routine The uGFX-Studio currently only uses this feature to create custom rendering routines for the container backgrounds which you can create in the Backgrounds Manager tool. Maybe you can have a look at some of the generated code to see how it is used. ~ Tectu

Did you replace the Makefile of your project with the new one from the repository? Did you make sure that you set the paths to GFXLIB and CHIBIOS correctly? When you verified this and it is still not working please upload a .zip of your project. ~ Tectu

I made some changes to the build system for ChibiOS . Internally ChibiOS 2.x and ChibiOS 3.x are treated differently. There are now working examples for both ChibiOS 2.x and 3.x in the STM32F429i-Discovery board directory. As inmarket did not review the changes yet it might be that there will be some more changes as he is the one who originally implemented our build system. However, this way you can at least continue with your project. Sorry that this took so long. Let me know whether you got it working. ~ Tectu

Glad to hear that you got it working! Happy hacking ~ Tectu

That is correct. You can use GFXBOARD and GFXDRIVERS for easy inclusing of board files and drivers in your Makefile so you don't have to specify the path yourself. GFXDRIVERS can take a list of parameters, not just one value. Eg. you might want to do GFXDRIVERS = SSD2119, STMPE811 to include both a display and a touchscreen driver. The line you are referring to creates one valid Makefile inclusion statement for each driver entry in the list. You can just include a display driver, no need to use board files. Board files are really just a Makefile which will automatically include the necessary driver files to use all the features of the board. When you take a look at some of the board files you will find out that it really doesn't do much beside manually including the display and the corresponding touchscreen driver for that board. eg: GFXINC += $(GFXLIB)/boards/base/Embest-STM32-DMSTF4BB GFXSRC += GFXDEFS += -DGFX_USE_CHIBIOS=TRUE include $(GFXLIB)/boards/base/Embest-STM32-DMSTF4BB/chibios_board/board.mk include $(GFXLIB)/drivers/gdisp/SSD2119/driver.mk include $(GFXLIB)/drivers/ginput/touch/STMPE811/driver.mk Board files are just for the convenience for the user. No need to use them or create them. Just include the driver(s) manually in your Makefile and you will be fine. The board file included in the Makefile from that article will include the display and the touchscreen driver for that board. The board itself does not have an audio codec chip and therefore the board file does not include a corresponding driver but a user might add an audio codec add-on himself. Then he has to include the appropriate driver in the Makefile. The example shows how to include the board file and an additional driver (for the VS1053 in this case). Hence the commend "additional driver" (as it is not part of the board file). I hope that answers your questions. ~ Tectu

Hello Enrico and welcome to the community! I gave your code a quick look but I couldn't spot something that is obviously wrong. The only thing I can say is that you don't have to include the uGFX board file AND the actual drivers in your Makefile. Including the board file is enough as this file will automatically include the corresponding driver files for you. First thing you want to do when something is not working is disabling compiler optimization (-O0 instead of -O2) and disabling LTO (USE_LTO = no). LTO is a very well known issue causer. Next, try commenting out the USB stuff and everything else. Take the bare blinker code with nothing else in it and just add gfxInit(). If that does not help, can you please upload your complete project as a ZIP archive so we can have a look? ~ Tectu

We gave it a try and it seems like we definitely have to modify our Makefiles to be compatible with the latest ChibiOS/RT 3.x. We will get this done in the following days. ~ Tectu

I will try compiling a ChibiOS/RT 3.x application using the Makefile from our repository this Sunday. Please stay tuned. ~ Tectu

I took a quick look at UC1701v2.zip from one of your earlier posts. gdisp_lld_draw_pixel() is definitely something you want to be using. The reason why you don't see write_cmd() and write_data() being called from the application code is because your display driver code is accessing a framebuffer in the drawing routines (through the RAM() macro) and not directly talking to the display each time it is performing a drawing operation. Did you check whether the framebuffer content is ever being flushed? It looks like you implemented the function but turned it of in the configuration. I don't have time to look at the UC1701 datasheet this week but the comment "This controller doesn't require flushing" next to the flushing setting in the configuration file seems a bit strange when looking at the rest of the driver code which always just accesses the framebuffer in the drivers private area (GDisplay->priv). ~ Tectu

Can you try accessing the file on the SD card while modifying some registers in the audio codec chip? When I remember correctly you have to call spiStop() before calling spiStart() with the other configuration struct when using the ChibiOS/HAL. ~ Tectu

When running the application code that you pasted earlier (the one that just calls the init functions and then gdispClear(Black/White)), can you please verify that the write_cmd() and the write_data() are being called/executed? ~ Tectu

This might be very relevant to you: viewtopic.php?f=9&t=261 ~ Tectu

In order to keep a consistent naming we renamed the following option from the configuration file: GFX_NO_OS_INIT becomes GFX_OS_NO_INIT Please make sure to update your configuration files! ~ Tectu

We have released a new implementation of the RAW32 port which is used to run µGFX on a barebone system without any underlying operating system. The new scheduler code is an improvement over the old one and contains many new settings which allow optimizing for specific compilers and CPUs if necessary. The new settings have been documented in the wiki: Config File Options: http://wiki.ugfx.org/index.php?title=Configuration#GOS Documentation: http://wiki.ugfx.org/index.php?title=GOS#Configuration Note that the following configuration option(s) changed their name: Config file option GOS_RAW_HEAP_SIZE becomes GFX_OS_HEAP_SIZE Also see: viewtopic.php?f=9&t=262 ~ Tectu

Hello jithurbide, I am sorry but I am currently very busy so I can't have an in-depth look at your application right now. Are you able to play the MP3 from the SD-Card as well or does the MP3 code just work with the ROMFS as well? If you cannot play the MP3 from the SD-Card either I would recommend you verifying that you can access your SD-Card through GFILE without any issues. For this, try to read from and write to a file on the SD-Card. ~ Tectu

Hello hekthe and welcome to the community! Currently there is no driver for the EADOGS102 in the µGFX repository. Therefore you don't only have to implement the board files but you need to write the entire driver. All GDISP drivers are located under /src/drivers/gdisp/. There are many drivers so you have lots of examples available. However, we strongly recommend reading this article before you start writing your driver: http://wiki.ugfx.org/index.php?title=Di ... iver_Model Please make sure that you strictly separate the hardware specific interface from the generic driver. The driver which goes to /src/drivers/gdisp/ must only contain driver specific things. All the hardware related functions to write to and read from the display need to go to the board file: http://wiki.ugfx.org/index.php?title=Board_File Your display seems to be similar to the KS0108 that one of our community members implemented. Maybe you can take a look at that one as well: viewtopic.php?f=23&t=249 To test your driver we strongly recommend using the /demos/modules/gdisp/basics demo before you start using the fonts demo. Please let us know should you have any other questions. ~ Tectu

Glad to hear that you got it working! Can you please contribute your changes back so we can add it to the official repository? Just attach the modified file(s) and/or provide a diff/patch. ~ Tectu

In that case I would suggest you trying to implement the platform dependent scheduler code as described in my previous post. We are happy to help where we can. ~ Tectu

uGFX can run on a bare metal system because we provide basic implementations for required things such as the memory manager and threading. Our very minimal scheduler is implemented using setjmp() and longjmp() which are stdlib functions. If you cannot provide the implementation for these functions you will not be able to use our scheduler at all. Are you sure that the libraries that you are using are not providing these implementations? You might want to take a look at the Alternate_RAW32_Scheduler branch where we are currently in the process of implementing a new scheduler as we had some platform dependent issues with the current/previous one. However, the default scheduler still uses the setjmp() and longjmp() functions. But along that, it is possible to implement a custom scheduler for a specific platform. When you have no luck with getting setjmp() and longjmp() up and running you might want consider providing such an implementation. There are already implementations for all Cortex-M series so you have a few examples. Note that I will not be of much help in that task. inmarket is the guy who is working on the scheduler. ~ Tectu