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[i]);
	}

	return;
}

void *hello_world(void *arg)
{

	Xuint32 i = 0;
	Xuint8 buffer[BUFFER_LENGTH];

	for(i=0; i<BUFFER_LENGTH; i++) {
		buffer[i] = 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

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

On Mar 23, 7:05=A0am, 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. =A0I
> don't know how you found the value of 496. =A0Maybe your program crashes
> for higher values?
>
> Simple C runtime doesn't do stack checking and you can run out of
> memory without warning. =A0You should avoid this.
>
> A good start would be to move the big buffer outside of the function
> (possibly with a "static" keyword in front). =A0This 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. =A0Also, 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. =A0It 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. =A0The
> 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 =3D 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