@WMXZ - Now that some of the LittleFS stuff is starting to work reasonably well (with @defragster) changes to not always format sectors,
it will be interesting to see if some of the experiments I have done to for example use an idle callback to read in the next logical block of data while the previous one is being written out. My current stuff sets up 3 buffers for TX (with DMAMEM) Still lots to experiment with.
But then I was wondering about if/how I might use MTP in real programs. And for example I could see my never to be complete Well Monitor program, where I was logging data, it would be nice if I could simply plug in my portable and grab log files.
So then wondered about what a program should do to create a log file. So I started looking at your mtp-logger sketch which looks like fun and I started asking myself questions. And wondering your ideas and plans for having MTP and FS(s) know about each other.
Currently your sketch when logging does:
Code:
int16_t file_open(uint16_t store)
{ char filename[80];
if(!makeFilename(filename)) return 0;
if(!checkPath(store, filename)) return 0;
mfile = sdx[store].open(filename,FILE_WRITE);
return !(!mfile);
}
So in your case you are opening a file for write in your first SD drive... Where you may have several different logical drives associated with your MTP data...
I notice in your mSD_Base class you have public methods like:
Code:
uint32_t sd_getFSCount(void) {return fsCount;}
const char *sd_getFSName(uint32_t store) { return sd_name[store];}
File sd_open(uint32_t store, const char *filename, uint32_t mode) { return sdx[store]->open(filename,mode); }
bool sd_mkdir(uint32_t store, char *filename) { return sdx[store]->mkdir(filename); }
bool sd_rename(uint32_t store, char *oldfilename, char *newfilename) { return sdx[store]->rename(oldfilename,newfilename); }
Which as we can see maps to sdx[store]->open(filename,mode);
And your class MTPStorage_SD : public MTPStorageInterface, mSD_Base
So a couple of questions: How does one know what store value to pass in? Logically I can imagine remembering how many Storage items I added (as long as some other library did not add their own)...
So wondering if: void addFilesystem(FS &fs, const char *name) { sd_addFilesystem(fs, name);}
should maybe not be void but uint32_t which returns the store (index into an array)...
And/OR - Add method to MTPStorage_SD to something like: uint32_t mapFSToStorage(FS *pfs);
And/Or - method to lookup by name: uint32_t mapNameToStorage(const char *name);
And/Or - add logical names to FS, like: FILE *open("sdio:/foo.txt", FILE_WRITE);
Side Note: Wondering if this class name and method names should be a little less SD related? As it now can be RAM/FLASH/PROGRAM/...
Also for the fun of it, I might play around a little with the functions like sd_open, and see what happens if I wrap them into a helper class:
like:
Code:
class MTPFile : public FILE {
MTPFile(FILE &f) : _f = f {};
virtual ~LittleFSFile() {close();}
virtual size_t write(const void *buf, size_t size) {return _f.write(buf, size);}
...
virtual void close() {
_f.close();
<Notifiy MTP system about file>
}
...
Again so far I don't know enough on how much additional information the class needs to hold onto, like the name of the file? Or maybe the open actually generates the appropriate index and storage index, such that can create an event or??? But could be interesting.
Make Sense?
Kurt