Re: newlib port problem (stdio and malloc)

[Nick Clifton <nickc at redhat dot com>]

Hi Zhang,

> 1. I need use stdio to display debug information. The debug information is output by the UART.
>     Now I modify the function "int _swiwrite ( int    file,    char * ptr,    int    len)" in "\newlib-1.10.0\newlib\libc\sys\arm\syscalls.c".
>     This function is modified something like this:
>     for (i=0; i<len; i++)
>     {
>         while(1)
>         {
>             if (UART can send data)
>             {
>                 break;
>             }    
>         }
>         send one byte
>     }
>
>     Is it OK?

Possibly. You are essentially polling the UART in a very tight loop, 
which is likely to eat up CPU resources.  If you can arrange for the 
UART to deliver an interrupt when it is ready for more data then you 
could write a much more performance-friendly interrupt handler routine.

Alternatively you could put the process to sleep in between polls of the 
UART, or arrange to copy to the buffer to a separate area and then have 
say the clock interrupt handler read bytes out of this buffer and send 
them on to the UART.

>     When I use stdio function, I find it's not a good way to modify like this.
>     Any suggestion?
>
> 2. I need use malloc/free to manage memory. When I check the function "caddr_t _sbrk (int incr)" in "\newlib-1.10.0\newlib\libc\sys\arm\syscalls.c", I find _sbrk() tries to manage the memory between [end, sp). 
>     Although it's ok to manage like this, I want to know why  _sbrk() on the ARM system doesn't try to manage a fixed range of memory? For example, manage the memory between [end, end + MEMORY_SIZE). 

Because the code assumes that there is a continuous block of memory 
between the end of the .data section (the "end" label) and the bottom of 
the stack.  The stack grows down into this memory region and the 
malloc/free heap grows upwards into this region.

It would be perfectly possible to change to the memory map (for a 
particular target environment) so that the stack and heap live in 
different, separate, areas, and in this case the _sbrk() code would need 
to restrict itself to [end, MAX_HEAP_MEMORY).

Cheers
  Nick