LittleFS, Teensy 4.1 and a Fujitsu 4Mb FRAM chip

D

dgnuff

Active member
I'm looking at setting up a LittleFS filesystem on the current project, and the local LittleFS package seems like the obvious way to go.

However, I'm using an Adafruit breakout with the 4Mb Fujitsu FRAM chip on it, which isn't currently supported by LittleFS. It's a one line change (yeah, really :) ) to add an entry for this chip, mostly copying the entry for its smaller 2Mb brother that is supported, and making the necessary adjustments.

Any interest in a PR with this change?

In addition, there's one thing I can't determine from the documentation. For now, with the FRAM breakout attached, working and formatted as LittleFS, this is a bit of a non-issue for this project. But for the future, once I've done the myfs.begin(CS) call to initialize the filesystem, how can I determine safely if it's formatted or not? That way, I can call quickformat() if it isn't or leave it alone if it is.
 
If the 'one line' change is made there and working? PR is easy - even posting it here might get enough interest from @mjs513 or other to do or help.
> If there is a question about some element of the line not working ... same

When the myfs.begin() is processed the media (FRAM) layout is checked for 'formatted media' signature. If present all is well, if it is not then it is formatted for use, and .begin() returns ready for use ... IIRC.
> quick look at the code would confirm - but my day ended already ...
 
The change is to add a config entry for the Fujitsu 4Mb FRAM. This is a link to the commit on github in my fork of LittleFS.

https://github.com/dgnuff/LittleFS/commit/2e5fb4e89cd1f81e4d4d53d8627062c635976c25

BTW, I forked Paul's repo rather than mjs513's since mjs513's is itself a fork of Paul's. If it'd make better sense to fork mjs513's I can easily do that, and send the PR that way. Whatever works best for everyone else.

As for testing, it comes up, and the Teensy can read and write files on the filesystem. I have not yet stress tested it to the point when I have the filesystemover half full - that's the point where something is most likely to break, since that's stretching it beyond what the 2Mb chip is capable of. I'll take a look at that tomorrow, there's a few sketches in the examples directory that look like they could be repurposed for stress testing.
 
dgnuff said:
The change is to add a config entry for the Fujitsu 4Mb FRAM. This is a link to the commit on github in my fork of LittleFS.

https://github.com/dgnuff/LittleFS/commit/2e5fb4e89cd1f81e4d4d53d8627062c635976c25

BTW, I forked Paul's repo rather than mjs513's since mjs513's is itself a fork of Paul's. If it'd make better sense to fork mjs513's I can easily do that, and send the PR that way. Whatever works best for everyone else.

As for testing, it comes up, and the Teensy can read and write files on the filesystem. I have not yet stress tested it to the point when I have the filesystemover half full - that's the point where something is most likely to break, since that's stretching it beyond what the 2Mb chip is capable of. I'll take a look at that tomorrow, there's a few sketches in the examples directory that look like they could be repurposed for stress testing.
Click to expand...

No need to fork mine as long as Paul gets the PR for the change. So just send the PR directly to paul's repo.
 
Cool!

Looking at the code noted p#2: main/src/LittleFS.cpp#L184
> indeed if it won't mount (as pre-formatted/signed) it will do a FORMAT. For FRAM
> Are those debug Serial.println()'s really there?
Code: 
	[B]Serial.println([/B]"attempting to mount existing media");
	if (lfs_mount(&lfs, &config) < 0) {
		[B]Serial.println([/B]"couldn't mount media, attemping to format");
		if (lfs_format(&lfs, &config) < 0) {
			[B]Serial.println([/B]"format failed :(");
			port = nullptr;
			return false;
		}
		Serial.println("attempting to mount freshly formatted media");
		if (lfs_mount(&lfs, &config) < 0) {
			Serial.println("mount after format failed :(");
			port = nullptr;
			return false;
		}
	}
	mounted = true;
 
dgnuff said:
...

As for testing, it comes up, and the Teensy can read and write files on the filesystem. I have not yet stress tested it to the point when I have the filesystemover half full - that's the point where something is most likely to break, since that's stretching it beyond what the 2Mb chip is capable of. I'll take a look at that tomorrow, there's a few sketches in the examples directory that look like they could be repurposed for stress testing.
Click to expand...

This sketch: ...\teensy\hardware\avr\1.58.1\libraries\LittleFS\examples\Test_Integrity\MRAMSPI\MRAMSPI.ino
is one of the sketches used to 'Test Integrity' of LittleFS during development.

For the 512KB available on that chip some adjustment to the allocation factors may be needed to sensibly fill the media.
Code: 
// Adjust these for amount of disk space used in iterations
#define MAXNUM 5	// Number of files : ALPHA A-Z is MAX of 26, less for fewer files
#define NUMDIRS 0  // Number of Directories to use 0 is Rootonly
#define BIGADD 256	// bytes added each pass - bigger will quickly consume more space
#define SUBADD 128	// bytes added each pass (*times file number)
#define MAXFILL 2048 // 66000	// ZERO to disable :: Prevent iterations from over filling - require this much free

The ###ADD names are confusing as they evolved across diff media and test goal of filling it with files of diff sizes - but MAXNUM is how many files as noted and this small media assumes no subdirs with zero for NUMDIRS.

Running the sketch and entering a # of loops to make will add, test, remove files in some pattern. Content Errors will be noted - only goes wrong when media is overfilled logging write fail errors. If media doesn't go over half full perhaps increase MAXNUM and watch used size value.

Making NUMDIRS non-Zero will quickly increase space used and number of files - maybe with a small MAXNUM it will be a good test?
 
mjs513 said:
No need to fork mine as long as Paul gets the PR for the change. So just send the PR directly to paul's repo.
Click to expand...

It's worth noting that the vast overwhelming majority of my git experience was working in a corporate environment, so I'm not as familiar as all that with working on open source projects. So it's best to view my caution as just being polite, and thinking I need to check with the repo owner before submitting a PR. But if you think it's fine, then I can go ahead and submit, subject to the comments at the bottom of this note.

defragster said:
Cool!

Looking at the code noted p#2: main/src/LittleFS.cpp#L184
> indeed if it won't mount (as pre-formatted/signed) it will do a FORMAT. For FRAM
> Are those debug Serial.println()'s really there?
Click to expand...

Great. I looked in my local copy of the library, and that code is present, so that's one less thing I have to worry about. Also in the version I have, all those Serial.println calls are commented out.

defragster said:
This sketch: ...\teensy\hardware\avr\1.58.1\libraries\LittleFS\examples\Test_Integrity\MRAMSPI\MRAMSPI.ino
is one of the sketches used to 'Test Integrity' of LittleFS during development.
Click to expand...

Thanks for the heads up on this. I'll modify that sketch as best I can and leave it run for an hour or so. Once it's done with that, as long as everything checks out, I'll go ahead and submit.
 
dgnuff said:
...
Thanks for the heads up on this. I'll modify that sketch as best I can and leave it run for an hour or so. Once it's done with that, as long as everything checks out, I'll go ahead and submit.
Click to expand...

Sketch has a set of commands - listed at start - do a 'h'undred loops and see how long it takes - and works well and monitor the size used. Then if that is reasonable do 'k' for thousand perhaps or just hit 'c'ontinuous and let it run - then enter 0 to stop it and view the scrolled spew and 'd' and 'D' for dirs size and with Verify.

Any format or reclaim on that media won't help - unless the disk overfills then 'q'uick format to restore and if using subdirectories do an 'm'ake dirs before more loops or it will fail for not having the dirs premade.

Other things noted in some fashion in the startup text and '?' command listing.

Good luck
 
@defragster - @dgnuff

Will make the changes, i.e, adding the FRAM chip as well as commenting out the serial.print's - yes they were for debugging purposes :)
 
mjs513 said:
See PR https://github.com/PaulStoffregen/LittleFS/pull/56
Click to expand...

Good Work @mjs513!

Note: with a PSRAM or EEPROM the 512KB size could also be tested for 'Integrity' parameter values to use for usable filling since there is no 4Mb FRAM here - but that wouldn't test the FRAM range/function ... and have coded/posted enough today ... for now.

@mjs513 - was there media that didn't support sub directories (due to space overhead) - or is that just imagination/forgetfulness?
 
defragster said:
Good Work @mjs513!

Note: with a PSRAM or EEPROM the 512KB size could also be tested for 'Integrity' parameter values to use for usable filling since there is no 4Mb FRAM here - but that wouldn't test the FRAM range/function ... and have coded/posted enough today ... for now.

@mjs513 - was there media that didn't support sub directories (due to space overhead) - or is that just imagination/forgetfulness?
Click to expand...

@defragster - to be honest I can't remember either - its been a while.
 
You must log in or register to reply here.
Back
Top