Hi Ken,
You fell for my 100% unintentional trap…thread title didn’t match content! I’d
started one message, saved it as a draft, then changed my mind on what to ask
but didn’t change the title. Doh!
I did try SmartFS and really like the sound of it, but it didn’t work “out of
the box”. I think it is because it can’t cope with 256Mbit devices; I got a
number of errors to do with sector sizes (from memory) and a quick debug
suggestion that perhaps some variables are defined as 16 bit: not sure, and
might return to it.
To answer your question – which was the original intent of this help request,
the aim is fundamentally data logging. Users will log data (at 20Hz, say;
multiple parameters) then occasionally pull them off for external analysis,
delete, and start again. So I don’t think wear levelling is actually an issue;
just speed and ease of pulling data off to spit out over USB or Bluetooth LE,
on an occasional basis.
One file open for write is fine with what I currently envision, but who knows.
SmartFS has much appeal as a “just in case”. I have more DRAM than I know what
to do with :)
Tim.
From: Ken Pettit <petti...@gmail.com>
Reply to: <dev@nuttx.apache.org>
Date: Wednesday, 25 August 2021 at 18:12
To: <dev@nuttx.apache.org>
Subject: Re: which filesystem?
Hey Tim,
Selection of filesystem is kind of a personal choice. Each filesystem
has different features / benefits. I have never used NXFFS but I know
it absolutely works with the caveat that you can only have one file open
for writing at a time. Because of this, I wrote SmartFS, which doesn't
have this limitation, but also adds extra RAM usage for each open file.
So as you see, there are tradeoffs. There is also LittleFS and SPIFFS
to choose from to make it even more complicated.
So I guess you first should ask, what features do I need from the FS?
Directory support? Wear leveling? Multiple open files for write?
Maybe a list of the features needed from the FS will help.
Ken
On 8/25/21 10:04 AM, Tim wrote:
I seem to have got over most of my SPI flash and EEPROM issues now and my
256Mb SPI flash is properly recognised.
I think I am at the last hurdle. Here is the console output, along with my
question of the day :)
Successfully initialized M25P SPI
m25p_initialize: dev: 0x2005b970
m25p_readid: priv: 0x2005b990
m25p_readid: manufacturer: 20 memory: ba capacity: 19
m25p_initialize: Return 0x2005b990
Successfully bound SPI0 CS1 to the SPI FLASH driver
m25p_ioctl: cmd: 1537
m25p_ioctl: blocksize: 256 erasesize: 4096 neraseblocks: 8192
m25p_ioctl: return 0
m25p_bread: startblock: 00000000 nblocks: 1
m25p_read: offset: 00000000 nbytes: 256
m25p_waitwritecomplete: Complete
m25p_read: return nbytes: 256
nxffs_nextentry: No entry found
nxffs_limits: No inodes found
nxffs_limits: Free FLASH region begins at offset: 5
nxffs_limits: First inode at offset 5
Succesfully initialised NXFSS
nx_mount: ERROR: Failed to find block driver (null)
Failed to mount the NXFSS volume -15
I believe the block driver would be "/dev/M25P" (M25P, for example) but
there is no code I have found that specifies the block driver location. I
have:
ret = nxfss_initialize(mtd);
then
ret = nx_mount("NULL, "/mnt/M25P", 0, NUL);
and that seems to be in common with other "bringup" code; using NULL rather
than "/dev/something".
Just need the last piece of this jigsaw if anyone could be so kind :)
