Hi Ringo,
Ok...here is the situation. There is in fact around 500 bytes of RAM left for the user to play with. The deal with the error you are receiving is due to how the colorMap is setup in the software. The colorMap (which is a lookup table/array of 48 bytes, 16 for red, 16 for green, and 16 for blue)is specifically and purposefully placed at a memory location in RAM where the low byte of the start of the array is 0x00. In practice, the best location for this array was at 0x300. The reason this is important is because when, say, a red pixel is actually sampled in (see CamInterfaceAsm.S, in the acquirePixelBlock routine), the value of the red pixel is dumped directly into an index register (the Z register in this case). The upper byte of the Z index register is already pre-setup to point to the beginning of the colorMap. Thus, the lookup is as fast as possible because all that needs to be done is to load a value from the address pointed to by Z, and voila, the lookup table for the red pixel is returned.
The colorMap is forced to start at location 0x300 in RAM by defining a new memory section in the makefile to hold the color map (see line 101 of the makefile). But this only defines the section. In CamInterface.c, you'll see that the declaration of the colorMap is a little different:
- Code: Select all
unsigned char colorMap[NUM_ELEMENTS_IN_COLOR_MAP] __attribute__ ((section (".noinit")));
This forces the colorMap to be located in the noinit section, which was forced to start at address 0x300 by the makefile (the RAM actually "starts" at 0x800000, and thus the lookup table starts at 0x800300...confusing I know).
Running "avr-nm -n AVRcam.elf" at a command line (DOS or linux) will show the actual locations of all objects in memory. You'll see that the bss section (normal RAM) ends around 0x8002e4, and that the colorMap is then located at 0x800300. When you add in your new arrays, they are added into the bss section, which is where all normal RAM items are allocated. However, as soon as you cross over into the noinit section (with an object greater than 28 bytes or whatever), there is already an object allocated there, and whamo, compiler error.
So you're probably wondering what can be done to fix this. There are actually a couple of solutions. The easiest one is to declare your new arrays to be fit into the noinit section as well, and place them after the color map. Thus, your code should look like this:
- Code: Select all
unsigned char colorMap[NUM_ELEMENTS_IN_COLOR_MAP] __attribute__ ((section (".noinit")));
unsigned char Brightest_Row_Location[NUM_ELEMENTS_IN_COLOR_MAP] __attribute__ ((section (".noinit")));
unsigned char Brightest_Row_Value[NUM_ELEMENTS_IN_COLOR_MAP] __attribute__ ((section (".noinit")));
This will force the new arrays to start after the color map, where a nice chunk of RAM is waiting to be used. Please note that you will need to initialize this memory location (the whole noinit thing means that the section is not cleared out after power up).
There are a few other ways to deal with the situation, but this is probably the cleanest/easiest for now. Again, if you are going to be using less than ~28 bytes of additional RAM in the system, you don't have to mess with this. Its only when you want to use a whole bunch more.
Hope this long-winded answer makes sense. Please don't hesitate to throw back a follow up question if needed.