Improved FAT32 support for ESP32 and allows Files to be used with SDC… #1528
Conversation
…ard that are mounted externally. - Replaced esp_vfs_fat_spiflash_mount with esp_vfs_fat_spiflash_mount_rw_wl and esp_vfs_fat_spiflash_unmount with esp_vfs_fat_spiflash_unmount_rw_wl to enabled RW access to file system and support wear leveling of the SPI flash. - Removed hard coded SECTOR_SIZE used in Fat32 size calculations and use the sector size from the Fat structure. This allows to correctly handle various sector sizes (512, 1024, 2048 or 4096) instead of just the hardcoded 512 and 4096 and report correct capacity and amount used. - For use with SD cards, these are mounted separately from the current File code. (this could be added to modFile.c if needed.) Added MODDEF_FILE_SDCARD if this is set to a 1, then the File internal mounting/unmounting is not used). - Throws JavaScript xsUnknownError exception if there is an error when mounting the media. Before it went to modLog that didn't appear to do anything. - If SPIFFS is used, the directory create and delete functions are bypassed in case the user software calls it. It will still create files with the directory name and path seporator in the root directory.
|
?? |
|
Improved exception reporting with Path and Partition information. Tested with FAT32 and SPIFFS with internal Flash partitions, and FAT32 with SD card support. |
| - The default name for the FAT32 partition is `storage`. To use a different name, set the `partition` defined in the manifest. | ||
| - If the file system is not on the internal ESP32 Flash, it will need to be managed externally to the File's internal software. For example, this is required for SD card support, Set the `sdcard` define to 1 to bypass using the File class's software to mount, unmount and format the file system. You will need to manage the file system externally from the `File` class. | ||
|
|
||
| The storage partition used by the default Moddable SDK build for ESP32 does not reserve a partition for FAT32. Therefore, it is necessary to use a different partition file in projects that use FAT32. To do that, set the `PARTITIONS_FILE` variable in the `build` section of the project manifest to point at an ESP32 partition file: |
There was a problem hiding this comment.
We didn't imagine someone wanting to use FAT32 for internal partitions. It should be easy enough to support a FAT32 internal partition without having to manually manage a PARTITIONS_FILE. In the mcconfig implementation here it could check the defines for "fat32" set to a non-zero value and use "fat32" instead of "spiffs".
| xsUnknownError("Failed to initialize filesystem"); | ||
| } | ||
|
|
||
| gUseCount--; |
There was a problem hiding this comment.
xsUnknownError("foo") is equivalent to throw new Error("foo") in JavaScript and consequently will not return. That means that gUseCount will never be decremented in the case of an error, which will leave the file system permanently active. The decrement should happen earlier so it isn't bypassed when the exception is thrown.
| int result = mkdir(path, 0775); | ||
| if (result && (EEXIST != errno)) | ||
| xsUnknownError("failed"); | ||
| xsUnknownError("Directory create failed"); |
There was a problem hiding this comment.
I'm not sure about this. We generally have concise messages for a couple reasons. First, to minimize code size. They add up. Second, the operation ("Directory create" here) should be pretty clear from the exception thrown. For example:
try {
function myFunction() {
throw new Error("boom");
}
myFunction();
}
catch (e) {
trace(e.stack, "\n");
}Outputs:
Error: boom
at myFunction ($MODDABLE/examples/hellotest/main.js:3)
at main ($MODDABLE/examples/hellotest/main.js:5)
But maybe there's a scenario where this helps that I'm overlooking. Can you explain the motivation?
|
|
||
| xsmcVars(1); | ||
| xsmcSetInteger(xsVar(0), total); | ||
| xsmcSetInteger(xsVar(0), (uint64_t)total); |
There was a problem hiding this comment.
This won't work as you expect. An XS integer is a 32 bit signed value by definition. The file system values can be bigger than that. The correct fix is to use a number (floating point double).
xsmcSetNumber(xsVar(0), total);That said, I'm not sure that size_t on ESP32 is bigger than 32 bits. You might want to check that and explicitly use a uint64_t instead, if it isn't already 64-bits.
…ard that are mounted externally.