SQLite Library (VFS) for Teensy 4.1

Sam Halvoe

New member
Hello everyone,

I started working on a SQLite Library for Teensy 4.1 --> see Platform IO Project on GitHub.
I took the test_demovfs.c from SQLite Website and used the Teensy SdFat library to implement the VFS.
I am using the built in SD card slot of Teensy 4.1. VFS stands for Virtual File System, it's the OS Interface,
which is used by SQLite to interact with the underlying file system and/or os. (see SQLite Website)
(I also looked at the ESP32 version from this repository, to learn some things: see on GitHub)

It's not polished and certaintly not finished. But a simple test succeded, running the main.cpp file of the project.
I am open for all questions and suggestion.
 
I would strongly recommend using the FS Interface instead. This is an existing problem with quite a few projects; they use the SdFat library directly rather than the generic filesystem interface and it prevents them from being usable with other devices/filesystem types.
 
Did not know about FS Interface. Would I have to implement FileImpl myself or exists an implementation for SdFat/SD cards?
 
You don't have to implement FileImpl. That is the interface provided by File objects, which are what you want to use instead of FsBaseFile. Generally you don't create them directly though, but rather get them by calling open on the FS object (which for SdFat/SD cards would be the "SDClass SD" global provided by the SD library).
 
Unfortunately, the current File design doesn’t return or let you access filesystem errors. This is because read() and write() functions return size_t and there is no “get last error” call.

For example, all LittleFS errors are actually converted to zero.

When I use the File interface, I make modifications so that these functions return ssize_t instead. This has helped me track down things like “file is full” errors.
 
When I use the File interface, I make modifications so that these functions return ssize_t instead. This has helped me track down things like “file is full” errors.
Isn't that more a deficiency of the individual filesystem libraries (or at least their wrappers) not making use of errno?
 
Would it be a good idea to provide a mechanism for error handling with a callback that converts error codes of the used filesystem library to error codes that are understood by my library or by SQLite?
I could provide default callbacks for some libraries that implement the FS interface. In addition users could provide their own callbacks (when there is no default callback).
 
Isn't that more a deficiency of the individual filesystem libraries (or at least their wrappers) not making use of errno?
Yes, that’s one way of looking at it.

The return value from write() is easy enough to cast, but read() and many of the bool-returning functions destroy the value. This is in LittleFS.h.

One of these days, I should submit a PR to at least set errno in there, as one possibility.

Another is some sort of “get last error” function in File or FS.
 
Last edited:
Isn't that more a deficiency of the individual filesystem libraries (or at least their wrappers) not making use of errno?

Yes, that’s one way of looking at it.

The return value from write() is easy enough to cast, but read() and many of the bool-returning functions destroy the value. This is in LittleFS.h.

One of these days, I should submit a PR to at least set errno in there, as one possibility.

Another is some sort of “get last error” function in File or FS.

I just made a PR to add setting errno to LittleFS:

Comments and suggestions welcome.
 
Back
Top