[Feature] File system access
Despite being frequently requested, we've not enabled file system access until now for a few reasons:
- Compatibility with MINDSTORMS Robot Inventor / SPIKE V2 (
littlefs v1) / SPIKE V3 (littlefs v2) - Differences in file management compared to MicroPython
- Technical difficulties, primarily blocking file system hooks.
- City/Technic/Move Hub could not support it anyway.
I think this is gradually changing, and there might be a path to making this work.
1): There seems to be little use in maintaining compatibility (or in avoiding conflicts) with littlefs v1 anymore. At this stage I think we could format storage as needed. This is essentially what the SPIKE V3 firmware does, and this does not appear to create issues when going back to SPIKE V2, which was holding us back so far. In other words, similarly, if we enabled littlefs v2, users can still go back to the MINDSTORMS Inventor firmware without issues.
2/3): The way our firmware has been redesigned over time, we now have a main loop (sys/main.c) as follows:
while not shutting down:
a) drive event loop until start requested (which includes receiving incoming programs to RAM)
b) if start requested, run MicroPython (which keeps driving the event loop)
This means we could implement littlefs hooks like user_provided_block_device_read that drive the event loop while waiting for spi operations to complete. This means that (b) can continue to work normally, with file access using MicroPython standards. But crucially, we can also make it work in (a) by implementing this part as dedicated UI loop. On selecting a user slot, this can write the current program to disk, load the requested program to RAM. Then we can proceed to run it.
We could still not use littlefs from within pbio processes this way. But the main things can work without having to re-implement littlefs to make everything async compatible, which has been our obstacle to doing this so far.
The only limitation is that user file access will block async user functions. But this is not a major limitation and it is something we can document. This is no different than upstream MicroPython.
4): This is still the case, but we may eventually support EV3 also. It would make sense to support file systems there, so file system access is becoming more relevant. It's littlefs hooks would just read and write from RAM since we have so much of it. We can save it to SPI flash on poweroff. If we follow MicroPython standards, we may also be able to support the microSD card as a mountable disk for additional storage, data logging, and so on. This would provide a way to play sounds and show graphics without any front end components to begin with.