Xilinx EDK - max array size

[Tobias Baumann]

Hi

I want to handle an array with some hundred elements.

Here is an example code:

#include "xmk.h"
#include "sys/init.h"
#include "platform.h"
#include "xbasic_types.h"

#include <stdio.h>

#define BUFFER_LENGTH 496

void printBuffer(Xuint8* buffer, Xuint16 length)
{

Xuint16 i = 0;

for(i=0; i<length; i++) {
printf("buffer %u: %x\r\n", i, buffer);
}

return;
}

void *hello_world(void *arg)
{

Xuint32 i = 0;
Xuint8 buffer[BUFFER_LENGTH];

for(i=0; i<BUFFER_LENGTH; i++) {
buffer = 0xAA;
}

printBuffer(buffer, BUFFER_LENGTH);

print("Hello World\r\n");

return 0;
}

int main()
{
init_platform();

/* Initialize xilkernel */
xilkernel_init();

/* add a thread to be launched once xilkernel starts */
xmk_add_static_thread(hello_world, 0);

/* start xilkernel - does not return control */
xilkernel_start();

/* Never reached */
cleanup_platform();

return 0;
}

The maximum buffer length can be 496. If I increase the heap and stack
size from 1kB to 2kB, the maximum buffer length can be 772. It's a bit
weired, because I double the stack size, but I can't double the array
size. In an other programm I have a stack and heap size of 20MB and I
only can create an array with 256 elements.

So I need some basical information about where I have to find mistakes
in my program and how I can solve them. And I need information about
where the limits are. For example when I increase the stack size so 1000
kB, the program above won't run with an 5000 elements array. I have no
idea where the problem is and where I have to search.

Thanks a lot for helping.

Greets,
Tobias

 

[Marc Jet]

Tobias Baumann wrote:

So I need some basical information about where I have to find mistakes
in my program and how I can solve them. And I need information about
where the limits are.

Your code seems to use too much autovar (stack) memory at runtime. I
don't know how you found the value of 496. Maybe your program crashes
for higher values?

Simple C runtime doesn't do stack checking and you can run out of
memory without warning. You should avoid this.

A good start would be to move the big buffer outside of the function
(possibly with a "static" keyword in front). This will make it a link
time allocation in BSS section, and the linker will complain if
there's not enough memory available instead of just crash. Also, you
can consult the linker map file to see how much bigger your buffer
could be.

When your project advances and you really need dynamic buffer
allocation, you can use a real memory allocator for the bigger stuff.
It lets you to handle more memory while the stack requirements remain
small. It will also tell you when there is not enough memory and your
code can handle that gracefully.

You may find more advice from embedded system programmers. The
constraints are not always the same as on a desktop system, where
resouces are almost infinite.

Best regards,
Marc

 

[MBodnar]

On Mar 23, 7:05 am, Marc Jet <jetm...@hotmail.com> wrote:

Tobias Baumann wrote:
So I need some basical information about where I have to find mistakes
in my program and how I can solve them. And I need information about
where the limits are.

Your code seems to use too much autovar (stack) memory at runtime.  I
don't know how you found the value of 496.  Maybe your program crashes
for higher values?

Simple C runtime doesn't do stack checking and you can run out of
memory without warning.  You should avoid this.

A good start would be to move the big buffer outside of the function
(possibly with a "static" keyword in front).  This will make it a link
time allocation in BSS section, and the linker will complain if
there's not enough memory available instead of just crash.  Also, you
can consult the linker map file to see how much bigger your buffer
could be.

When your project advances and you really need dynamic buffer
allocation, you can use a real memory allocator for the bigger stuff.
It lets you to handle more memory while the stack requirements remain
small.  It will also tell you when there is not enough memory and your
code can handle that gracefully.

You may find more advice from embedded system programmers.  The
constraints are not always the same as on a desktop system, where
resouces are almost infinite.

Best regards,
Marc

Like Marc said, definitely avoid those stack allocations. In this
embedded environment with little runtime support, it can be hard to
diagnose problems like these (especially as the program gets more
complicated).

Thankfully, as an embedded designer targeting a specific platform for
a specific application, you can pretty much have free reign over the
entire address map. It's perfectly legal to declare a pointer to a
known region of unused memory (known and unused in the sense that none
of the peripherals are mapped to that address and the code size of the
elf won't clash with it). Something like:

Xuint8 *buffer = 0x04000000; // just the starting address of the
buffer

Then you can dereference it like an array. I've used this technique,
and it's easy, but I'm not 100% sure it's the best/safest/etc.

Regards,

MB