When [sticilface] started using the Arduino IDE to program an ESP8266, he found he was running out of RAM quickly. The culprit? Strings. That’s not surprising. Strings can be long and many strings like prompts and the like don’t ever change. There is a way to tell the compiler you’d like to store data that won’t change in program storage instead of RAM. They still eat up memory, of course, but you have a lot more program storage than you do RAM on a typical device. He posted his results on a Gist.

On the face of it, it is simple enough to define a memory allocation with the PROGMEM keyword. There’s also macros that make things easier and a host of functions for dealing with strings in program space (basically, the standard C library calls with a _P suffix).

However, there’s also a helper class that lets you use a string object that resides in program memory. That makes it even easier to use these strings, especially if you are passing them to functions. As an example [sticilface] writes a string concatenation function that handles PROGMEM strings.

You can use the same techniques for other data, as well, and at the end of the post, there are some very clear examples of different use cases. Under the hood, the ESP8266 doesn’t store data in bytes in program memory. The library routines hide this from you, but it can be important if you are trying to calculate space or do certain kinds of manipulation.

You can also check out the official documentation. If you want to see the technique in action, maybe you’ll be interested in your coworker’s mood. Or, try putting a Jolly Wrencher on your oscilloscope. Both projects use PROGMEM.

[Editor’s note: PROGMEM is in the ESP8266 Arduino codebase from AVR-GCC, and originally wrote (counterinutitively) into RAM.  Some clever hacking fixed that early last year, so now you can use the same AVR-style abstraction with the ESP. It still doesn’t work on the ARM Arduinos.]

Image by [connorgoodwolf] (CC BY-SA 4.0)

In this post on the Arduino.cc forums and this blog post, [Majek] announced that he had fooled the AVR microcontroller inside and Arduino into writing user data into its own flash memory during runtime. Wow!

[Majek] has pulled off a very neat hack here. Normally, an AVR microcontroller can’t write to its own flash memory except when it’s in bootloader mode, and you’re stuck using EEPROM when you want to save non-volatile data. But EEPROM is scarce, relative to flash.

Now, under normal circumstances, writing into the flash program memory can get you into trouble. Indeed, the AVR has protections to prevent code that’s not hosted in the bootloader memory block from writing to flash. But of course, the bootloader has to be able to program the chip, so there’s got to be a way in.

The trick is that [Majek] has carefully modified the Arduino’s Optiboot bootloader so that it exposes a flash-write (SPM) command at a known location, so that he can then use this function from outside the bootloader. The AVR doesn’t prevent the SPM from proceeding, because it’s being called from within the bootloader memory, and all is well.

The modified version of the Optiboot bootloader is available on [Majek]’s Github.  If you want to see how he did it, here are the diffs. A particularly nice touch is that this is all wrapped up in easy-to-write code with a working demo. So next time you’ve filled up the EEPROM, you can reach for this hack and log your data into flash program memory.

Thanks [Koepel] for the tip!