Joel Bodenmann

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

Hello TCL987 and welcome to the community! It is indeed to possible to run RAW32 without dynamic memory. You can specify the size of your "static heap" in the configuration file. See here: http://wiki.ugfx.org/index.php?title=Ba ... Management Let us know should you have any other questions. ~ Tectu

First of all, please note that you only want to use the STM32F429iDiscovery driver if you actually are using the STM32F429i-Discovery board. Otherwise please use the generic STM32LTDC driver (make sure you check out the Alternate_Raw32_Scheduler branch of the repository). The STM32F429iDiscovery driver currently doesn't support screen rotations with DMA2D. However, it is easy to add and we already started doing this for the generic STM32LTDC driver. You can see the switch statement in both the gdisp_lld_fill_area() and gdisp_lld_blit_area() functions: https://bitbucket.org/Tectu/ugfx/src/83 ... LTDC.c-401 It is just a matter of changing the values for the OMAR, OOR and NLR registers of the DMA2D peripheral. If you add this for the STM32F429iDiscovery driver we would be thankful if you could contribute the code back so we can add it to the repository. ~ Tectu

Have a look at the GDISP Pixmaps: http://wiki.ugfx.org/index.php?title=Pixmaps I assume that this is what you want. Let us know should you have any questions. ~ Tectu

Hello fastlink, Can you please show us the full compiler output that you are getting? What example are you using? We are successfully using the STM32F4 Makefile template with ChibiOS/RT 2.x but we have not tested it that much with 3.x. It is very possible that there might be something wrong in there. ~ Tectu

No problem. Thank you for testing! I hope that you understand that we will not add support for ChibiOS/RT 3.x for new features as ChibiOS/RT 3.x has officially been released and 2.x will no longer be developed actively. ~ Tectu

I just checked: In case of you are using ChibiOS/RT 2.x this might be an issue. However, we only checked for ChibiOS/RT 3.x. See here: http://forum.chibios.org/phpbb/viewtopi ... =16&t=2730 What underlying system are you using? ~ Tectu

What libraries are you using? I downloaded the latest STM32CubeF4 and the file stm32f4xx.h from CMSIS has that define in there. It is the same for the F7 and there it works great for me. Are you using the old StdPeriph libraries? Line 67 in: stm32f4xx.h /** * @brief STM32 Family */ #if !defined (STM32F4) #define STM32F4 #endif /* STM32F4 */ ~ Tectu

Thank you for reporting this issue. We have pushed a fix to the repository: https://bitbucket.org/Tectu/ugfx/commit ... 4ba6d57909 Can you please give it a try and let us know whether it is now working properly? ~ Tectu

A primary version of the touchscreen driver has been added. The first version keeps everything simple: No multitouch support and no support for changing orientations. ~ Tectu

Whoops. I just realize that the KS0108 requires 5V logic and everything I have here is 3.3V based. Will you get a new display soon to make sure that the driver performs as expected or should I just add the driver to the repository straight away? ~ Tectu

Whoops... I am happy to test it with my GLCD when I find some time. I hope that mine will work. I bought it like 5 years ago and never tested it. I looked at the zip that you attached to your previous post and everything looks good on first glance. However, what happened in KS0108.h? ~ Tectu