Proposed changes to save-image and load-image

#1

In a future release of uLisp I propose the following changes to save-image and load-image to:

  • Allow saving images to non-volatile memory even when SD card is enabled
  • Improve the autoloading and autorunning of images on reset
  • Warn about potentially invalid images
  • Make the feature less confusing.

Current behaviour

If you do not have SD card support

  • You can save to or load from non-volatile memory.

  • One image (“ulisp.img” on LittleFS) can be saved or loaded

  • Undocumented: in addition on LittleFS you can give a filename and save multiple different images to non-volatile memory.

If you have SD card support

  • You can only save to or load from SD card.

  • If you do not give a filename the default file “ulisp.img” is used.

  • You can give a filename and save/load multiple different images.

If resetautorun and SD card support are enabled

  • The default image “ulisp.img” is loaded from SD card on reset.

  • If it was saved with a function parameter, that function will be run.

If resetautorun is enabled but not SD card support

  • The image (“ulisp.img” on LittleFS) is loaded from non-volatile memory on reset.

  • If it was saved with a function parameter that function will be run.

To enable resetautorun

  • You had to change the #define resetautorun setting and upload uLisp again.

Proposed new behaviour

  • If you don’t give a filename, save-image/load-image will use non-volatile memory.

  • If you do give a filename, save-image/load-image will use SD card, or if not installed, give an error “SD card not available”.

  • The #define resetautorun will no longer be used, and you will now be able to change the behaviour without re-compiling and uploading uLisp as follows:

    • If the second parameter to save-image is t the image will be loaded from non-volatile memory on reset.

    • If the second parameter to save-image is a function, the image will be loaded from non-volatile memory and that function run on reset.

  • To improve on the currently non-ideal behaviour, loading an image saved from an older version of uLisp will display a warning:

    This image was saved from an older version of uLisp and may not be valid.

    Alternatively, rather than check the uLisp version, one idea is to do a silent pprintall on save-image, calculate a checksum over the output, and save it in the image header. Then do the same on load-image, and display a warning if they don’t agree.

Potential problems with the proposed changes

  • Users who are using the undocumented ability to save named image files on LittleFS will no longer be able to do so.

  • Users will no longer be able to autoload or autorun an image from SD card on reset.

  • Platforms without the ability to save images to non-volatile memory will not be able to use resetautorun (these platforms are BBC Micro:bit, Maxim MAX32620FTHR, Sipeed Maixduino, and Sipeed MAiX BiT).

  • To turn off autoloading on reset or autoloading and running on reset you will have to resave the image with a different parameter.

I’d welcome any comments or suggestions for improvements.

#2

Dear David, thanks for new ideas !

" The #define resetautorun will no longer be used, and you will now be able to change the behaviour without re-compiling and uploading uLisp" - i think it would be useful.

#3

I feel like this calls for 2 or 3 functions:

  1. one function that works as you proposed for saving the image
  2. one function specifically for changing which image or if an image should be loaded at startup or not
  3. maybe one function to modify what function is run on startup?

2 can also possibly be used to let you pick which SD card image to run on startup, and you don’t have to resave the image to turn off autoloading

#4

The tricky problem is where to save the state of “whether an image should be loaded at startup, if so which image, and whether a function should be run”. Not all platforms provide EEPROM, and writing settings into flash or an external DataFlash chip usually involves erasing a page of memory, typically 4K bytes.

This is why my solution proposes to store this information along with the actual image in non-volatile memory. It also implies that users will no longer be able to autoload or autorun an image directly from SD card on reset.

#5

Ok I see, then your solution makes much more sense.