To test if external memory board works we are going to write a simple routine that tests if microcontroller can allocate memory heaps, write to and read from then. First of all we have to set up AVRStudio project. If your are going to use automated make file generation, you need to add external RAM options, so compiler would know what address range to allocate for RAM. To do so open AVRStudio Configuration options and in custom options add line to Linker Options:
-Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x8030ff
This shows linker start and end address of external memory. This also indicates that memory is used for variables (.data/.bss) and heap (malloc()).
This way we end up with having internal SRAM address range 0×800000 – 0x8010FF and external 0×801100 – 0x8030FF as we are using 8Kbytes of external memory chip so we add 0×2000 to end of internal address range. Totally we have 12Kbytes of SRAM where internal now is used only for STACK and external for ,data (static data), ,bss (global or static variables) sections and heap.
There are many ways to test RAM. We are going to use malloc() function which simply allocates some amount of memory and returns its start address to pointer. Once we have configured compiler options we can start writing code. Before we can use external memory we must enable it by setting SRE bit in MCUCR register. This action turns XMEM dedicated microcontroller pins in to XMEM interface. Also we can release PC5, PC6 and PC7 unused address pins – they may be useful for other tasks.
void XMEM_init(void)
{
// External memory interface enable
MCUCR |= (1<
SRE);
XMCRA = 0;
//PC7..PC5 released pins
XMCRB |= (1<XMM1)|(1<XMM0);
}
After initialization we can start writing program. We are going to allocate 255 bits in heap memory allocated in external ram by writing simple code:
#define BUFFER_SIZE 255
uint8_t *mem;
mem = malloc(BUFFER_SIZE);
After allocated heap memory we can fill it with some data and read back to see if everything goes right;
uint8_t index;
// Fill memory incrementing values
for(index = 0; index < BUFFER_SIZE; index++)
{
mem[index] = data++;
}
// Display memory block
for(index = 0; index < BUFFER_SIZE; index++)
{
PRINTF("%02X ",mem[index]);
if((index&0x0F) == 0x0F)
{
PRINTF("/n");
}
}
in the terminal screen we get:
In this case heap memory is start is at 0×1221 location. Meaning that .data and .bss sections are between address space 0×1100 to 0x121E. You can check these locations in .map files. In my case .data section starts at 0×1100 and.bss section-starts at 0×1114. And also I find that memory for heaps is allocated at 0x111e. So our *mem pointer points to heap memory starting with 0x121E.
Lets test another situation when external memory is used only for heaps. For this wee need to change linker options like this:
-Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x8030ff
Then we expect out memories to be allocated this way:
After compilation we can see the results in terminal:
We can see that out heap is placed at the start of external memory. First two bytes are used to hold size of allocated area. Lets look at .map file.
.data 0x00800100
.bss 0x00800114
__heap_start = 0x801100
__heap_end = 0x8030ff
We can see that .data sector is allocated at beginning of internal RAM (0×0100), then goes .bss sector, while heap for heap is dedicated whole external RAM.
Which memory allocation model use – it depends on your application. If you are going to use big data buffers like for holding graphical information ready to send to displays – definitely allocate external RAM for heaps only. In other case if you are going to use RTOS with lots of tasks, then probably it is best to leave more internal RAM for STACK and move static data to external RAM.
This is only a surface of what we’ve “scratched”. There are lots of more things you can do with memory allocations and sectors.
