newbie question: gdispImageOpenFile

[spectre]

Dear friends,

I have a bmp picture in the flash of the microcontroller,
when I call gdispImageOpenFile(&myImage, "myImage.bmp");
and I receive the error 0x0004 (GDISP_IMAGE_ERR_UNRECOVERABLE  + GDISP_IMAGE_ERR_NOMEMORY)

it means that: 
-the function tries to load the picture inside of the stack area then decode it and the ram to allocate the picture is not enough?
or 
-it means that the function tried to decode the picture allocating the decoder code in ram and the ram is not enough for the decoder only

I have available an "external ram" on my testhardware, actually not used,but before to use it I have to understand what's goin on  

thanks
Spectre

 

 

Edited December 11, 2016 by spectre

[Joel Bodenmann]

As the image doesn't get chached (unless you explicitly ask for that by using gdispImageChage()) it means that there wasn't enough memory to allocate the gdispImage object. The decoder itself is part of the program memory.
The GDISP_IMAGE_ERR_UNRECOVERABLE that you get along with that just indicates that it's an error that can't be "fixed" automatically.

If you are using the built-in memory manager (eg. when using the RAW32 port to run bare-metal without an underlying operating system) it's usually just a matter of increasing the heap size that you specify in the configuration file with: GFX_OS_HEAP_SIZE.

[spectre]

Dear Sir,

thanks for your fast reply.Really appreciated.

I am using an stm32 with 64kb of ram, and I've tried the gdisp/image example with a simple main.c file and the bmp issued with the demo and it works.
now I am trying to do the same inside of a freertos task and I get this error.

the suggestion above applies also with a freertos implementation?

Thanks again and sorry for such newbie questions
Spectre

[Joel Bodenmann]

When you're using the FreeRTOS port the GFX_OS_HEAP_SIZE macro has no effect. Instead, gfxAlloc() is simply a wrapper macro around pvPortMalloc(). In that case you have to properly configure your memory settings on the FreeRTOS side of things. 
Don't forget to make sure that your FreeRTOS task has a sufficient stack size as well.

Most likely your problem right now will be that you are have too large stack sizes that the heap managed by FreeRTOS is simply too small and with all the stuff you're doing you run out of memory and can't allocate the gdispImage object for your image anymore.

[spectre]

Yes Sir,

Solved. heap size of freertos increased

Thanks a lot!
have a nice weekend

Spectre

[Joel Bodenmann]

10 minutes ago, spectre said:

#define TASK_GUI_STACKSIZE 256" (256x4 I suppose, so 1024 bytes of stack)

Are you sure on that x4? I am pretty confident that it's really just 256 bytes which is not a whole lot if you run GUI stuff in it. But then again, it depends on whether FreeRTOS adds the space required for task-switching information to that or whether that will be part of those 256 bytes.

Note that there are two different things at play here: Stack and heap. Stack is the place where you actually execute code. Each time you call a function, there is stuff that gets put on the stack. That stuff includes backing-up CPU registers, local variables and so on. The heap is the piece of memory that you use to dynamically allocate memory. Using gfxAlloc() will use heap, not stack.
When I remember correctly the heap size in FreeRTOS is configured by something called configTOTAL_HEAP_SIZE or similar. You might have to increase that. However, keep in mind that by increasing the heap size you sacrifice stack size.

 

10 minutes ago, spectre said:

thanks again, I have to offer you a beer someday ahah

Don't worry, we are happy to help wherever we can
But of course we never say "No" to a beer  

[Joel Bodenmann]

Ah, looks like I was a few seconds too late. Glad to hear that you got it working!

[spectre]

Thanks again Sir for your detailed reply.
I have to investigate on the stack size declaration on the freertos.. I've read somewhere that the "#define configMINIMAL_STACK_SIZE 128"
inside of the freertos configuration must be declared as words and not bytes. (so value x4 = stack bytes). May be I'm wrong.

I have an external SRAM attached to this custom demoboard and I want to try it.
I think I have to understand the way to load the image from the external sram instead of the internal sram.

thanks sir,now I am abusing of you
Regards,
Spectre

Edited December 11, 2016 by spectre

[Joel Bodenmann]

4 minutes ago, spectre said:

I have to investigate on the stack size declaration on the freertos.. I've read somewhere that the "#define configMINIMAL_STACK_SIZE 128"
inside of the freertos configuration is in words and not bytes. (so value x4 = stack bytes). May be I'm wrong.

I just checked the corresponding documentation and you are right. The supplied parameter is interpreted as words, not bytes.

 

5 minutes ago, spectre said:

I think I have to understand the way to load the image from the external sram instead of the internal sram.

µGFX currently doesn't provide a high-level API for memory pool management. Therefore, you'd have to do some of the work yourself.
Please don't hesitate to create a new forum topic regarding that if you have questions.