STM32 + FreeRTOS + ugfx -> No images

[Nicolas Dammin]

Hello,

I use the ugfx library for a ST7735 color display on my STM32F103. It has 64 kb of FLASH and 20 kb of RAM. 

I want to display some labels and small images on the display. The images are gif-files that are converted to header files using file2c. They are all static const. That was the only way to get the images on the internal flash of the STM.

When I use RAW32, everything works fine. But when I wanna use FreeRTOS, I won't get the images.

I am using the CubeMX software to generate the initial code, including the FreeRTOS provided there. So I preconfigure FreeRTOS in CubeMX with a gfx-Thread and let it generate the code. Then I include the ugfx library using the SW4STM32 IDE.

 

gfx-Task:

/* StartGFXTask function */
void StartGFXTask(void const * argument)
{
  /* USER CODE BEGIN StartGFXTask */
	(void)argument;

	gfxInit();

	guiInit();

	guiShowPage(DISPLAY_PAGE);
  /* Infinite loop */
  for(;;)
  {
    osDelay(500);
  }
  /* USER CODE END StartGFXTask */
}

The functions to register the Thread:

  /* definition and creation of gfxTask */
  osThreadDef(gfxTask, StartGFXTask, osPriorityAboveNormal, 0, 1024);
  gfxTaskHandle = osThreadCreate(osThread(gfxTask), NULL);

The heap memory of FreeRTOS is set to 16384k which is the maximum my STM32 can handle.

 

In the gui.c I have this for showing the image:

    // light icon
    wi.g.show = TRUE;
    wi.g.x = 5;
    wi.g.y = 5;
    wi.g.width = 20;
    wi.g.height = 20;
    wi.g.parent = ghContainer;
    wi.text = "";
    wi.customDraw = 0;
    wi.customParam = 0;
    wi.customStyle = 0;
    lightImage = gwinImageCreate(0, &wi.g);
    gwinImageOpenMemory(lightImage, light);

 

As I said, the same code worked without FreeRTOS. When FreeRTOS is used, I get the labels and the background color correct, but there is no image. 

 

Is that a memory or timing issue? 
Should I better use the FreeRTOs-functions from ugfx?
Can I get any example code for a image read from the internal flash with FreeRTOS?

 

Thanks in advance

Nico

 

[cpu20]

You are loading the image inside the StartGFXTask. This means that the stack allocated for this task will be used to load the image.

In your code you assign 1k for the task, but it is possible that if you are opening a large image it consumes the whole stack of the task.
So to begin make the stack of your StartGFXTask bigger.

[Nicolas Dammin]

Thanks cpu20. But even with 3k (more isn't possible because of the huge overhead from FreeRTOS) it doesn't work. Is there a way to transfer the image data from Flash directly to the LCD without pushing the whole image to the RAM? Like using another function? I'm totally new to ugfx.

[inmarket]

uGFX doesn't decode the whole image into RAM (unlike most image libraries) except for the JPG decoder. Instead it decided on the fly straight from the encoded image in flash.

Each of the image calls returns detailed error information if it fails. Use your debugger to determine what the error code is.

I suspect that your problem is not enough heap memory. GIF images take a minimum of 12k RAM while they are decoding (it is due to the memory requirements of the compression algorithm) so when you only have 16k total heap that makes things VERY tight which is why you can get it to work raw32 but not with the overhead of freertos. That 12k is only used while decoding an image so you can use that same 12k to decode one image after another with no problems.

I would suggest that you use BMP images, perhaps rle encoded and with the minimum number of bits possible for your image in order to save space.

GIF, PNG, JPG images will all require too much decoding ram for your situation.

[Joel Bodenmann]

Just as a side note: Keep in mind that the FreeRTOS heap managers use words instead of bytes for the heap sizes.

[Nicolas Dammin]

Thank you all for the reply. 

Now this makes sense to me. It is the decoding algorithm rather than the image itself. The internal RAM of the STM32F103 is just too small for that. I was just curious what I can do without having to add an external RAM chip, and displaying an image (in RAW32 mode) is quite impressive! 

I think I'd better use a more powerful µC and a SRAM chip for further experiments (I have them already lying around), because I think I can't get my User Interface working with those specs.

 

Thanks and Regards

Nico

[Joel Bodenmann]

You could also just not use a GIF. BMPs come with extremely little overhead to decode.

Of course, more RAM is always better if that is an option