why was my code footprint not be reduced?

--- Quote Start ---

originally posted by nios_ii@Apr 8 2006, 06:29 AM

herein, i have a another problem.

in the code i wrote for my customed niosii system,the printf function was called to write some character to the stdout,but once the program run,i don't get the character i want,i just get the info:terminate the program in niosii ide or ctrl-c.

could you tell me why and how i get i want in the console?

thanks! http://forum.niosforum.com/work2/style_emoticons/<#emo_dir#>/blink.gif

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=14146)

--- quote end ---

--- Quote End ---

It is likely that you are still running out of memory, but at runtime rather than during software build. There is a key difference here because during software build, the linker has no idea how much memory your program might use in operation, only the memory used by the program itself and any global data that you statically delcare.

Once your program is running, though, any declared vairables or arrays at subroutine entry get placed on the stack, and any memory requested through malloc() is placed on the heap. In the case of printf(), I know that at least a couple of kilobytes of memory can be used via malloc calls (in reality printf asks for little memory from malloc, but malloc itself is optimized to allocate more memory than is needed to make future malloc calls more quick/efficient). The result is stack/heap collission and erratic/unpredictable program operation.

There is a Nios II feature that helps with this - runtime stack checking - that works if your stack and heap are in the same memory device (or onchip ram). It can be enabled via the system library properties dialog. Be aware, though, that to perform these checks extra code is required, and that will bump up memory usage just a bit in itself.

The best bet for deeply embedded systems with just a few kilobytes of ram is ususally to be very careful of memory use and to know exactly how much is used at any point... calling C library routines without knowing their effect on memory use is, sadly, a common point of failure.