Nano-RK Tips and Tricks

Many of these suggestions are generally good practice for any resource constained development.

Don't Allocate Large Data Structures Inside Functions
  • Allocating large data structures in functions puts them on the stack. Typically your task's stack is only 128 bytes, so putting things like a network buffer on the stack will almost certainly cause a stack overflow. Instead, make large data structures global.
Take Care When Passing Large Data Types to Functions
  • When passing large data structures, make sure to pass them by reference using pointers so that they do not get pushed on the precious stack.
Avoid Recursive Function Calls
  • Recursive function calls are also heavy when it comes to stack consumption. Try to avoid them whenever possible
Use "inline" For Speed And To Save Stack Space
  • When it seems fit, use "inline" to avoid pushing things onto the stack for small functions.
Be Very Careful With Dynamic Memory
  • Malloc does work, but if you frequently malloc and free memory you will create fragmentation. Eventually this fragmentation can lead to malloc failing. This is especially bad when you run your application for a few minutes and it seems fine, but then fails after a few hours. In general, avoid using malloc whenever possible. If you must, use it in situations where the code can safely continue if allocation fails.
Use nrk_kprintf() Whenever Possible
  • Strings used in normal printf() are stored in RAM! nrk_kprintf() stores them in FLASH memory using the PSTR macro. Only use regular printf() when the string is dynamic (i.e. you use %d to print variables etc).
Watch out for strings
  • Strings declared anywhere consume DATA and hence use RAM. They are also stealthy in that they don't show up using avr-nm. Try to avoid them at all cost. Many times it is better to pass a numerical value to a function that has a big kprintf() switch inside it.
How Much Memory Is My Code Using?
  • After you compile, you should get a printout that tells you the size of your .data, .text and .bss sections. .data is the amount of RAM that your program uses that is defined at startup to a particular value. This means that it has to be stored in both RAM and ROM. .text is the amount of code your program uses. .bss is the amound of zeroed out RAM your program uses. Since the memory is set to 0 by default, you do not need to store a copy of it in ROM like with the .data section. So your total RAM is data+bss while your FLASH usage is data+text. In Nano-RK the stacks for applications are stored in static memory, so they appear in the bss section. The kernel stack by default does not, so you should account for the RAM usage as data+bss+128bytes to be safe. In the following example the RAM usage is 220+1021+128 = 1369 and the FLASH is 17258+220 = 17478. A FireFly v2.2 node has 8192 bytes of RAM and 131072 bytes of FLASH.
    Size after:
    main.elf  :
    section     size      addr
    .data        220   8388864
    .text      17258         0
    .bss        1021   8389084
    .stab      41268         0
    .stabstr   16934         0
    Total      76701
    
What variables are using up my memory?
  • Use avr-nm to find a list of symbols and how much they consume. Below is an example that prints the size of functions and static memory sorted as decimal:
    avr-nm -S --radix=d --size-sort main.elf
    ...
    08388989 00000001 D NRK_UART1_TXD
    ...
    08389446 00000116 B tx_buf
    00012074 00000118 T nrk_event_wait
    
  • "T" refers to the text section, "B" refers to the BSS section, and "D" refers to the data section. Remember that strings don't show up in this list because they do not have compiler mapped labels.
Avoid floating point
  • There is no FPU on this processor, so all floating point is done through software emulation. It is big and very slow.
Stick with C99 variable types
  • Use C99 types like (uint8_t, int8_t, uint16_t, int32_t etc) instead of int, short, long etc.