Available Memory on Arduino

I seem to recall that there is very limited space to store data on the arduino… If I needed to store an array of ~600 floating point numbers, is that possible? Is it technically possible for GC to send an array of ~600 floating point numbers and store in local memory (not necessarily long term flash storage)?

Floats take 4 bytes to store. The EEPROM library makes 4096 bytes available for read/write storage. A fair chunk of that is presently being used to save configuration and present location.
If the values are unchanging they might be written to program memory at compile time, see PROGMEM. I think they would need to be pulled into ram for use, so beware of schemes that pull the whole lot at a go.

This is related to the calibration model I’m looking at… Was trying to figure out if the arduino could store the error array in flash and then retrieve them. They couldn’t be stored at compile time. Else, I assume the arduino has enough RAM to hold an an array of 600 floating point numbers if they get sent to them from GC when GC connects?

I hesitate to say that there would be enough ram (dynamic memory). Though the compiler indicates that the global variables use 22%, there is much else that needs that dynamic memory during a run. We’ve had problems running out caused by the serial communication routines, and the kind of intermittent errors that arise are pretty troublesome.

2 Likes

Ok, will focus on using GC for time being…

1 Like

There’s certainly more compute power and storage available on that end of the wire :grin:.

2 Likes

Am I correct in saying that all GC does at the moment is to feed the contents the gcode, line by line, to the arduino? That is, there’s no parsing/processing of a gcode line that happens inside GC.

1 Like

GC handles translating the gcode XY coordinates when the ‘Home’ location is moved, so there is processing/parsing going on. It removes comments as well, to reduce the serial chatter.

1 Like

Excellent… sounds like a perfect place to do some work. Thanks!

1 Like

almost, GC can look at the line and parse it looking for too many decimal places
and truncate the numbers.

but what it passes to the arduino is gcode

David Lang

That’s fine. i think if it does XY coordinate transformation for the home location, it would easily be able to be modified to incorporate an additional coordinate transformation for an error matrix and then send the resulting gcode to the arduino. Baby steps…

remember, the gcode only specifies the endpoints of the cut, if you need to do
calculations for errors that may change from location to location, you will have
to do it in the firmware (or break long movements and large arcs into many small
movements so that you can add compensation.

If GC is changing the numbers to move where home is, we are doing things wrong.
GC should send a message to the firmware “make this point 0,0” and then send the
exact same numbers as before

Yes… thanks… hmmm… /em scratches head…

Baby step 1. Quantify errors. At a minimum, this can be used to determine how accurate our calibration is or test one linkage kit vs. the other, etc…

Exactly. This gets quite difficult. It is theoretically possible to parse the Gcode, apply your transformation to correct the positional error of the sled, and then build Gcode off of that result. But it would be an intensive process, and it’s likely the resulting Gcode would be very different from the original code.

2 Likes

For the optical calibration, I’m using 31x15 (465) int’s to store the x error and another 31x15 to store the y error. Right now the system is based on interpolation so these values have to be sent over from GC to the controller everytime GC starts because they aren’t stored in EEPROM. At 2-bytes per int, it looks like there would be 1860 bytes needed. We may be able to switch to a curve-fit scenario, but right now, is there way to figure out how much EEPROM space is available? Can we fit 1860 bytes in?

In the 4k EEPROM of the Mega, the first 300 bytes are mentioned in this comment in Settings.cpp:

// EEPROM addresses 300 and up can be used by Maslow.  Under 300 was used
// previously by pre v1.00 Firmware.

From 300 to 340 is used to store current position data by settingsSaveStepstoEEprom() and above 340 the system settings are stored. These presently occupy 294 bytes, but will no doubt grow as more settings are added.
It looks to me like if you started at address 2000 (or 2048 :wink:) you would have room for your values and still leave room for the system settings to expand some.

3 Likes