Inspired by the issue, I also decided to take up the challenge.I also seem to have managed to get it to work for a 'Run from RAM' program while accessing the file system in flash. That should open the door to easier and better recovery of MicroPython systems which have become 'bricked' through 'main.py' problems. My previous effort only works for the Pico, not the Pico W or other boards.
FatFs images are very large and the minimum storage size supported by FatFs is 64KB, making it difficult to allocate space for RAM disks and working programs. To address this issue, an option has been added to reduce the footprint by reducing some of the FatFs features:
https://github.com/oyama/pico-vfs/commi ... 3db61480b4
If a small USB MSC programme using littlefs + FAT file system is built with only the compile option -Os, the firmware size is about 200 KB:
Code:
Memory region Used Size Region Size %age Used RAM: 200644 B 256 KB 76.54%Code:
target_compile_options(${TARGET} PRIVATE -Os -DPICO_VFS_NO_RTC=1)Code:
Memory region Used Size Region Size %age Used RAM: 160772 B 256 KB 61.33%I were working on porting SQLite3 to Pico, but struggled because there was no easy way to know the status of files on littlefs. Therefore, I'm added a generic firmware project that copies the contents of littlefs on the Pico's onboard flash to a FAT RAM disk and shares it with the host PC via the USB mass storage class:
https://github.com/oyama/pico-drive-sync
The firmware is designed to run on RAM, so the total file size it can handle is limited to 64KB, but it can also write to littlefs from the host PC. As it runs only in RAM, independently of the firmware written to the flash, it simplifies the handling of USB MSC file access conflict issues.
It would be seamless if the starting position of the littlefs on the target flash could be known, but currently this needs to be notified at build time.
Statistics: Posted by 0yama — Sun Jun 02, 2024 4:29 am