run gdisp demos on freeRTOS

[Alan Chang]

Hello,

I followed the gdisp demo code which is images and run on freeRTOS.

I made a gui.c file. Here is my code.

#include "gui.h"

static gdispImage myImage;
void creat_UI (void){
		

	coord_t			swidth, sheight;
	// Get the display dimensions
	swidth = gdispGetWidth();
	sheight = gdispGetHeight();

	gdispClear(Silver);
	
	// Set up IO for our image
	gdispImageOpenFile(&myImage, "test-pal8.bmp");
	gdispImageDraw(&myImage, 0, 0, swidth, sheight, 0, 0);
	gdispImageClose(&myImage);

}
void guiEventLoop(void)
{
	gfxSleepMilliseconds(1000);
}

 

Then I made a task to run ugfx on main.c.

Here is the code on main.c

void uGFX_task(void *pvParameters)
{
	
	STM_EVAL_LEDOn(LED3);			//LED3 on
		
	gfxInit();
	creat_UI ();
	
	while (1) {
		guiEventLoop();
	}
}

 

When execute the program, all task was stopped.

I found that the function "gdispImageClose(&myImage);"  caused.

If I don not use "gdispImageClose", everything is fine.

I have no idea why.

Hope you can help.

Thanks.

[Joel Bodenmann]

Did you ensure that your thread stack is big enough?

[Alan Chang]

Hi Joel,

 

Thanks for your fast reply.

Do you mean this one in FreeRTOSConfig.h?

#define configMINIMAL_STACK_SIZE		( ( unsigned short ) 1024 )

 

Thanks.

[Joel Bodenmann]

Hello Alan,

I was referring to the stack size of the uGFX_task task. At some point in your program you have to start that task by either using the FreeRTOS API (such as xTaskCreate()) or by using the µGFX wrapper named gfxThreadCreate(). You either tell those functions how much stack you want to reserve for that task and they allocate it for you or you create the stack yourself and just point to it. In any case, make sure you're not experiencing a stack overflow caused by a stack that is too small.

A side note: Keep in mind that FreeRTOS uses numbers of words for the stack size: http://www.freertos.org/FAQMem.html#StackSize

[Alan Chang]

Hi Joel,

 

Very thanks for your information.

It is my first time to use this OS.

I think I have to check the size of stack in task very carefully in case my application uses lot of images.

 

I also tried to change the memory management file on freeRTOS to heap_4.c, and  this issue was solved.

In begging I used heap_1.c and I think it can not release the memory.

Maybe gdispImageClose called freeRTOS  API (like vPortFree) failure, so all task was block.

This is my guess.

 

 

 

Thanks.

Have  a good day.

 

 

 

 

 

[Joel Bodenmann]

Hello Alan,

First of all I'm glad to hear that you managed to resolve the issue. I completely forgot about the different heap managers that FreeRTOS has to offer. We should add that to our troubleshooting list.

Regarding the images: All µGFX image decoders are streaming decoders which means that you never need to have the entire image in memory. Caching the decoded image is optional too so the memory usage is very minimal (but depends on the image format you're using). For example, when you render a BMP that is in your microcontrollers flash (using ROMFS) then you really only need a few dozen bytes for the image header (the gdispImage structure).

[Alan Chang]

Hi Joel,

 

Thanks for your information.

It seems BMP format is a good option.

Now I will continue to develop my application.

 

Cheers.