ESP8266 Community Forum

- Mon Feb 01, 2016 9:33 am #40162 Hi, in the mp3 player project I see that they suggest to install an SPI RAM from microchip, piggybacking it on the onboard flash chip and connecting the CD pin to GPIO0. The RAM is a Microchip 23LC1024.

Now, if I'd like to use that RAM in another project based on Arduino's IDE, how can I benefit of the additional memory? It would be great to have bigger amount of RAM but I don't get how to access it... can someone help me?

- Mon Feb 01, 2016 10:01 am #40163 You would only be able to access it over SPI, not using direct memory reads or writes. And you could only do it while the flash is not being use, so the code itself would need to run in iram, which is very limited in itself.

I would propose saving on ram memory usage, that would quite a bit better.

- Tue Feb 02, 2016 7:45 am #40255

You would only be able to access it over SPI, not using direct memory reads or writes. And you could only do it while the flash is not being use, so the code itself would need to run in iram, which is very limited in itself.

I would propose saving on ram memory usage, that would quite a bit better.

Yes but it's better than nothing I think.
If I parse a ~4k characters json string ESP8266 keeps rebooting with strange stack overflow errors fired over the serial port.
Adding a 32mbit flash and a 1mbit ram would extend ESP8266 capabilities a lot... I just need to figure out how to use that stuff with Arduino IDE, even if programming natively using espressif sdk may be more memory efficient... :/

- Tue Feb 02, 2016 9:00 am #40263 I don't think adding ram, which is not directly addressable, is the solution.

If you keep being bitten by the watchdog, that means you take too much time in your code before returning to the system. The watchdog is already quite tolerant, long before the watchdog bites, the WLAN subsystem will already give up.

The interesting thing is that you can do quite a bit with 4096 bytes of memory and returning to the system in time. I have just finished an OTA firmware update system where sectors of 4k are read, erased, written and read again (verify) and that be done all in time.

A Q&D workaround might be to double the CPU clock frequency to 160 MHz.

Otherwise you will have to optimise the code or slice the operation and have it called piece by piece by a background task (always the preferred way). You should never perform lengthy operations in callbacks, and certainly not in interrupts handlers.