Does anyone have any specifics on how much RAM and Program Space is available for the user on the Particle mesh devices? Wanting to compare against the photon
@alex.bussiere, I’m still not quite sure what the user-available RAM is on the Mesh devices. If the Console is to be believed, it ranges from 60KB to 80KB (out of 153KB) depending on the device (Xenon, Argon, Boron) though the nRF52840 has 256KB in total. I would wait for more official data from Particle, especially since the firmware is still in development.
As for flash space, the nRF52840 has 1MB of onboard flash but the mesh boards also have 4MB of external QSPI flash that can be used for program execution or storage. Here is how Particle has Partitioned it:
OTA (1500KB, @0x00289000)
Reserved (420KB, @0x00220000)
FAC (128KB, @0x00200000)
LittleFS (2M, @0x00000000)
I’m not sure what the reserved area and FAC are but the LittleFS area of 2MB may be for the user.
Perhaps @rickkas7 can add more insight here.
RAM available is 72248 bytes, a little more than the Photon and Electron. Tested on the Argon with 0.8.0-rc.25 but it should be similar on all devices. I got that from running this code:
#include "Particle.h"
void setup() {
Serial.begin();
delay(5000);
Serial.printlnf("memory=%lu", System.freeMemory());
}
void loop() {
}
The user firmware binary space is 128 Kbytes, same as the Photon and Electron.
The FAC slot is the factory user firmware backup slot. Unfortunately it’s actually empty from the factory, but you could put an extra copy of your firmware or tinker in it.
The LittleFS is a file system block. It’s not currently user accessible. Various data files and configuration files are stored there. For example, the Boron 3rd-party SIM settings are stored in a file there. The EEPROM emulation is just a file in the LittleFS file system (and is 4096 bytes).
In theory more space could be opened up in the future. The external QSPI flash can be configured for XIP (execute in place) so code can be placed there, though it’s not configured to do that at this time.
2 Likes
I upvote the XIP functionality!
We’ve been at the 128k limit for sometime and we aren’t able to add new features to our product.
3 Likes
I second the XIP functionality. we are flirting with the 128k limit (we have a lot of text we need to store in the program for a display) on the photon and was hoping the Mesh devices would have more
Can all of that (or nearly all) be used to store data from a sensor? I'm trying to collect vibration data from a 3-axis accelerometer at 100 samples/second. I'd like to be able to collect for 2 minutes which would be 72kB (2 bytes/sample x 3 axes x 100 samples/sec x 120 seconds). Could I use the Flash memory for this, or is it too slow?
@rickkas7, I would say not since your app will have other variables necessary for operation. Given that firmware development is ongoing, available RAM values can’t be trusted just yet IMO.
I would love to see the balance QSPI flash available as a LittleFS partition available to the user or for XIP firmware expansion space. Again, early days and much is to be done.
2 Likes
I would use a FRAM for sensor data. It’s fast, non-volatile, does not wear out, and SPI connected. This driver
mentions the 32Kbyte (256 Kbit) version, but it works with bigger ones, too. You can get the Fujitsu version up to 2 Mbit (256 Kbyte).
1 Like
I though about that, but, what I’m doing will only be done a few times in this way. Would the flash, either internal or external be fast enough for this? I’ll probably only collect this data several times, then offload the data to my desktop machine for analysis. What I 'm trying to do is determine when my well pump is pumping my well dry which cause the water in the pipe to surge for a while (it’s not good for the pump to keep pumping this way). I’m assuming that the vibrations in the pipe will be distinguishable from normal operation, but I need to analyze the data to see how best to do that. Once, I’ve determined how to analyze the data, the normal operation of the device wouldn’t need to collect the data for so long, and would probably use something like a circular buffer in RAM to hold the data. It might also turn out that I don’t need to collect the data at that fast a rate).
@Ric, if this is a just a data collection exercise then why not use a Photon and microSD card to collect all the data you want. Then use mesh device when you go to your next stage of implementation.
Yeah, I could do that. Originally, I though about using RAM and the Argon just because it had a little more RAM than the Photon, but maybe the usable amount is not higher? Since this will be a short term exercise, I was hoping to avoid the use of any external hardware (besides the accelerometer) if I could. The Photon has plenty of flash memory to do what I want, so I’ll ask again. Is flash fast enough? I’m not worried about wear, because of the small number of times I’ll need to erase.
Instead of collecting all that data, just run an FFT and pump the data out to your PC across Tcp or Udp. An 800 line spectrum at 10khz should clearly show the surging action.
@rickkas7. Can you give us an update where these numbers stand with the latest firmware? Also, is there a plan for the roadmap to have more than 128k user space on the new devices?
1 Like