RAM left in Sparki

Sparki
#1

The RAM size of the Sparki is 2.5 Kbytes meaning it’s not a lot to work on. It seems that the Sparki driver itself consumes 2 Kbytes of that so you are left with 512 bytes or so for your sketch. In my experience if you get below 100 bytes or so weird things will start happening, I guess it’s because the stack may be corrupted at this point. So in reality you have close to 400 bytes, which I think is to little. I would like to see an optimized driver that consumes less RAM and where you could easily remove resources in the driver when you compile by utilizing pre-compiler definitions, like #define SPARKI_USE_DISPLAY if you would like the to use the display and the memory resources it utilized, if not these memory resources would be available for the sketch instead.

Edit: Seems like pre-compiler definitions might be tricky given Arduinos structure, maybe a better solution would be to have a standalone include for the RAM heavy parts of the driver like the display (which seems to consume the majority of the 2 Kbytes of RAM) so it can be included exclusively by #include instead? What do you think Joe?

Call the following function to find out how much RAM you have left (taken from playground.arduino.cc/Code/AvailableMemory):

int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}
#2

Is the sparki LCD logo taking up space? Seem like this would be an easy way to free up a bit.

#3

I think the logo is just how the pixels are initiated in the display buffer. The display buffer consumes 1 Kbytes of RAM (128x64 pixels = 8192 bits =1 Kbyte).

#4

I think the logo is just how the pixels are initiated in the display buffer. The display buffer consumes 1 Kbytes of RAM (128x64 pixels = 8192 bits =1 Kbyte).[/quote]

Correct. The screen buffer (which is needed in the ram to operate the display) is 1024 bytes. All other screen variables are stored i the flash, so that they don’t take RAM.

As for define, we plan on introducing the opposite:
#define SPARKI_NO_DISPLAY

We’ll see what else we can do for the rest of the drivers, but its already fairly efficient. What we would really have to do is start playing more with more stuff in terms of partial inclusion of startup drivers based on what code is used. Maybe something like having the functions that use the parts start them up on their first run.

#5

in Sparki.cpp, the font table is taking up a lot of room…
It maps all 256 characters it seems. 5 bytes each character. If you’re just going to print text, you could easily reclaim half of that for RAM (it’s 256*5). The upper ones are all probably unused by most (I may be wrong since it’s got some accented letters for other languages).

I tried it just now and got an extra 640 bytes. My simple sketch went from 15,916 to 15,276 bytes used.

For those that want to try and need the space now, what I did was to truncate the font table half way through. It starts at about line 861 of sparki.cpp (keep a backup!). Go down halfway (+127 from the line you start on) and comment out the rest with /* and */.

If you were concerned about this, you could modify the drawChar routine to ignore anything over 127 I suppose.

Also, you could also get rid of anything less than 32 to reclaim 32*5 bytes if you add a little math… Who needs to ‘print’ an ESC or CR?

#6

roboalchemist: That 's great news, thanks!

jle: Actually the font table does not use the RAM (run-time memory for variables and strings), instead it is stored in the Flash memory (program memory) since it’s declared with PROGMEM, see arduino.cc/en/Reference/PROGMEM . This is why the Sketch size (program memory) is reduced when you reduce the table. It’s better to use the Flash memory, which is much larger @28 Kbytes, for constants and strings.

Another way of reducing RAM size within your sketch is to store strings that are declared within the code in Flash instead of RAM by using the F() macro.
This (which uses at least 10 bytes of RAM):
Serial.println(“Hello World”);
Will instead with this use the Flash (no RAM used only 10 bytes of added Sketch size):
Serial.println(F(“Hello World”));

#7

Oops… I should leave this to the experts.
Thanks for explaining that Ingemar.

#8

I was a bit worried when I read the first posts in this thread, but the later ones fixed that. I thought the lack of memory would make it impossible to do anything that required the Sparki to remember things, like mapping. But there seems to be several options to get around this. One is the one proposed by roboalchemist, others include using the Flash for large amount of data, use your own modified include files to reduce ram usage or simply hijack the memory used by the screen (funky screen paterns can be considered a bonus). Plenty of options open and those who wants to do more advanced projects should be able to handle at least some of them.

#9

Great ideas being shared here…but let us not forget that majority of us, myself included, are novices and may not have the expertise and experience with Arduino structure and programming. We will need instructional tutorials or curriculum that we do not have but have been advertized. And those that ArcBotics have published are still unstable and still trying to get their kinks out. To find workarounds on issues like RAM deficiency or misprogrammed EEPROM are beyond a novice’s comprehension. We do not even know what’s causing the problem sometimes let alone diagnose it and find the correct solutions. It would take us some time to learn them but learn we would.
Is Sparki’s architecture (registers, RAMs, EEPROM, etc) similar to the an Arduino Leonardo or other Arduino? There are no published schematics, memory maps, register list, list of reference to low level functions, etc to really get into that level of programming. The only documentation we have right now is what’s publish in their websites. That’s why we do not have much to share in terms of “new” innovative codes other than modifications of existing published codes.

Sorry for the rant…

#10

As a novice so is it unlikely that you will need more Ram then generally availible as it’s more advanced pojects that is likely to run into issues. As a Kickstarter funder you are actually getting this before the general public, so some slack needs to be given for documentation and tutorials not being perfect yet. And if you are a novice, then you can’t expect to turn into an expect over night, just due to some tutorial.

As for the workarounds I mentioned, so are they not really that advanced. The way to use the flash as memory is described in a link above to the general Arduino page about PROGMEM. And, yes the Sparki has an Arduino board. A lot can be figured out by checking the include library Sparki.cpp and there you can find the pointer to the LCD buffer (st7565_buffer) wich you can then use yourself if you like as an array pointer. This will corrupt the image on the display of course. But if they fix an option to turn off the display with an option, then that will obviously be easier for you to use.

#11

I actually agree with ortsac, its currently at times still too advanced for people. They shouldn’t have to worry about things like RAM/ROM, EEPROM, etc for most things. That said, this is still young, and we’re rapidly working on addressing everything as soon as it comes to us, so we’re looking forward to getting to that point soon.

#12

Sparki is still a great system to learn from. It’s greatest asset is that the components are integrated into a single board. I do understand that it is still at its infancy and as we all together peel the layers of the system we will all benefit.

Is there by chance you have a block digram of the system that you can share with us? Just curious, what part of the Atmega chips control the various components of the system? When someone talks about EEPROMs not programmed or have been re-programmed by another application software or the servo/wheels not turning to the desired set angle, or that the range_finder not measuring the distance of the object in front of it, we can all visualize what part of the system is involved. And perhaps, one of this day we can actually look at sparki.cpp/.h and actually understand what the settings are for or what the sketches are manipulating in the system. For me, that would be beneficial and great learning tool.

#13

No worries, we’re open source through-and-through.

We have every used to design Sparki here:
github.com/arcbotics/sparki

Specifically, the electronics schematics are here:
raw.github.com/ArcBotics/Sparki … _Rev15.pdf

#14

Thanks for sharing the schematics, this will greatly help visualize different components on the system.