When the onboard flash memory is used as a FatFS filesystem, the FatFSUSB can be used to allow exporting it to a PC as a standard memory stick. The PC can then access, add, and remove files as if the Pico was a USB memory stick, and upon ejection the Pico can access any new files just as if it made them itself.
(Note, if you are using LittleFS then you need to use SingleFileDrive to export a single file, not this class, because the PC does not understand the LittleFS disk format.)
The FatFSUSB library allows your application to get a callback when a PC attempts to mount or unmount the Pico as a FAT drive.
When the drive is being used by the Pico (i.e. any File is open for read or write, the FatFS is not end() -ed and still mounted, etc.) the host may not access it. Conversely, while the host PC is connected to the drive no FatFS access by the Pico is allowed.
Your driveReady callback will be called when the PC attempts to mount the drive. If you have any files open, then this callback can report back that the drive is not yet ready. When you complete file processing, the PC can re-attempt to mount the drive and your callback can return true .
The onPlug callback will generally FatFS.end() and set a global flag letting your application know not to touch the filesystem until the flag is cleared by the onUnplug callback (which will also do a FatFS.begin() call).
Failing to close all files and FatFS.end() before granting the PC access to flash memory will result in corruption. FAT does not allow multiple writers to access the same drive. Even mounting and only reading files from the PC may cause hidden writes (things like access time, etc.) which would also cause corruption.
See the included Listfiles-USB sketch for an example of working with these limitations.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4