avr-gcc笔记1-data structure in ram

DATA STRUCTURE IN RAM

  Many of the devices that are possible targets of avr-libc have a minimal amount of RAM. The smallest parts supported by the C environment come with 128 bytes of RAM. This needs to be shared between initialized and uninitialized variables (sections .data and .bss), the dynamic memory allocator, and the stack that is used for calling subroutines and storing local (automatic) variables.

  Also, unlike larger architectures, there is no hardware-supported memory management which could help in separating the mentioned RAM regions from being overwritten by each other.

  The standard RAM layout is to place .data variables first, from the beginning of the internal RAM, followed by .bss. The stack is started from the top of internal RAM, growing downwards. The so-called "heap" available for the dynamic memory allocator will be placed beyond the end of .bss. Thus, there's no risk that dynamic memory will ever collide with the RAM variables (unless there were bugs in the implementation of the allocator). There is still a risk that the heap and stack could collide if there are large requirements for either dynamic memory or stack space. The former can even happen if the allocations aren't all that large but dynamic memory allocations get fragmented over time such that new requests don't quite fit into the "holes" of previously freed regions. Large stack space requirements can arise in a C function containing large and/or numerous local variables or when recursively calling function.

   avr-gcc的栈由内部RAM的顶部向下生长，这样就潜在两个危险性：一是动态分配的堆和栈有可能互相覆盖；二是.data &.bss的数据过多和栈数据覆盖。实际上以上两个问题都发生了，图像数据10Kbytes左右，处理时所需空间大概30多Kbytes（动态+静态）。小插曲1：当时由于LED彩屏的中间位置图像发生奇变才注意到这个问题-_-!

Note:

The pictures shown in this document represent typical situations where the RAM locations refer to an ATmega128. The memory addresses used are not displayed in a linear scale.

RAM map of a device with internal RAM

  On a simple device like a microcontroller it is a challenge to implement a dynamic memory allocator that is simple enough so the code size requirements will remain low, yet powerful enough to avoid unnecessary memory fragmentation and to get it all done with reasonably few CPU cycles. Microcontrollers are often low on space and also run at much lower speeds than the typical PC these days.

  The memory allocator implemented in avr-libc tries to cope with all of these constraints, and offers some tuning options that can be used if there are more resources available than in the default configuration.

  Obviously, the constraints are much harder to satisfy in the default configuration where only internal RAM is available. Extreme care must be taken to avoid a stack-heap collision, both by making sure functions aren't nesting too deeply, and don't require too much stack space for local variables, as well as by being cautious with allocating too much dynamic memory.

  If external RAM is available, it is strongly recommended to move the heap into the external RAM, regardless of whether or not the variables from the .data and .bss sections are also going to be located there. The stack should always be kept in internal RAM. Some devices even require this, and in general, internal RAM can be accessed faster since no extra wait states are required. When using dynamic memory allocation and stack and heap are separated in distinct memory areas, this is the safest way to avoid a stack-heap collision.

  There are a number of variables that can be tuned to adapt the behavior of malloc() to the expected requirements and constraints of the application. Any changes to these tunables should be made before the very first call to malloc(). Note that some library functions might also use dynamic memory (notably those from the : Standard IO facilities), so make sure the changes will be done early enough in the startup sequence.

  The variables __malloc_heap_start and __malloc_heap_end can be used to restrict the malloc() function to a certain memory region. These variables are statically initialized to point to __heap_start and __heap_end, respectively, where __heap_start is filled in by the linker to point just beyond .bss, and __heap_end is set to 0 which makes malloc() assume the heap is below the stack.

  If the heap is going to be moved to external RAM, __malloc_heap_end must be adjusted accordingly. This can either be done at run-time, by writing directly to this variable, or it can be done automatically at link-time, by adjusting the value of the symbol __heap_end.

  The following example shows a linker command to relocate the entire .data and .bss segments, and the heap to location 0x1100 in external RAM. The heap will extend up to address 0xffff.

avr-gcc ... -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff ...

  实际上如果你使用avrstudio内嵌gcc的话只要在Project->Configuration Options->Memmory中通过Add，选择Sram，在Name输入.data，Address输入0x801100即可，你也通过这个功能可方便移动自定义的数据或是默认的数据区。小插曲2：不知道是不是版本的原因，根据上面的方法在低版本（具体那个版本忘了，建议下载最新版）设置，完全没有效果，结果可以在编译信息或者看map文件，map文件很清晰的给出编译后数据的存放位置。如果你使用外部makefile或者是在PN下编译的话，你可以通过修改makefile中的Linker Options下的内容，如下所示：

#---------------- Linker Options ----------------

#  -Wl,...:     tell GCC to pass this to linker.

#    -Map:      create map file

#    --cref:    add cross reference to  map file

LDFLAGS = -Wl,-Map=$(TARGET).map,--cref

LDFLAGS += $(EXTMEMOPTS)

LDFLAGS += $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)

LDFLAGS += -Wl,--section-start=.data=0x801100

#加上上面这个语句即可以，当然上面的其他设置的关键参数也需要修改

小插曲3：把PN编译后的文件都删除时，再次编译时发现没有生成文件，有bug？关闭再打开又可以编译生成文件，但再次删除编译生成的文件时->再编译->仍旧没文件生成->bug,PN version v.2.0.7.667。

Note:

See explanation for offset 0x800000. See the chapter about using gcc for the -Wl options.

Internal RAM: stack only, external RAM: variables and heap

   If dynamic memory should be placed in external RAM, while keeping the variables in internal RAM, something like the following could be used. Note that for demonstration purposes, the assignment of the various regions has not been made adjacent in this example, so there are "holes" below and above the heap in external RAM that remain completely unaccessible by regular variables or dynamic memory allocations (shown in light bisque color in the picture below).

avr-gcc ... -Wl,--defsym=__heap_start=0x802000,--defsym=__heap_end=0x803fff ...

 

Internal RAM: variables and stack, external RAM: heap

    If __malloc_heap_end is 0, the allocator attempts to detect the bottom of stack in order to prevent a stack-heap collision when extending the actual size of the heap to gain more space for dynamic memory. It will not try to go beyond the current stack limit, decreased by __malloc_margin bytes. Thus, all possible stack frames of interrupt routines that could interrupt the current function, plus all further nested function calls must not require more stack space, or they will risk colliding with the data segment.

The default value of __malloc_margin is set to 32.

contd……