kopia lustrzana https://github.com/peterhinch/micropython_eeprom
FLASH.md: Add design notes.
rodzic
6b42d58b8c
commit
5037f0999a
|
@ -28,9 +28,10 @@ The driver has the following attributes:
|
||||||
4. It supports filesystem mounting.
|
4. It supports filesystem mounting.
|
||||||
5. Alternatively it can support byte-level access using Python slice syntax.
|
5. Alternatively it can support byte-level access using Python slice syntax.
|
||||||
|
|
||||||
Flash technology requires a sector buffer. Consequently this driver uses 4KiB
|
Supporting byte level access on Flash technology requires a sector buffer.
|
||||||
of RAM (compared to minuscule amounts for the FRAM and EEPROM drivers). This is
|
Consequently this driver uses 4KiB of RAM (compared to minuscule amounts for
|
||||||
an inevitable price for the large capacity of flash chips.
|
the FRAM and EEPROM drivers). This is an inevitable price for the large
|
||||||
|
capacity of flash chips.
|
||||||
|
|
||||||
FAT and littlefs filesystems are supported but the latter is preferred owing to
|
FAT and littlefs filesystems are supported but the latter is preferred owing to
|
||||||
its resilience and wear levelling characteristics. Please note that this driver
|
its resilience and wear levelling characteristics. Please note that this driver
|
||||||
|
@ -341,3 +342,31 @@ Instantiate with `cmd5` set `True` or `False` appropriately.
|
||||||
|
|
||||||
If you have success with a new chip please raise an issue with the part no. and
|
If you have success with a new chip please raise an issue with the part no. and
|
||||||
the `cmd5` setting and I will update the docs.
|
the `cmd5` setting and I will update the docs.
|
||||||
|
|
||||||
|
# 7. Design notes
|
||||||
|
|
||||||
|
This driver buffers one sector (4KiB) in RAM. This is necessary to support
|
||||||
|
access as a byte array. I believed the buffer would confer an advantage when
|
||||||
|
running a filesystem, but testing suggests that performance is essentially
|
||||||
|
the same as an unbuffered driver. This appears to be true for littlefs 2 and
|
||||||
|
FAT. Testing was done by comparison with
|
||||||
|
[this unbuffered driver](https://github.com/robert-hh/SPI_Flash).
|
||||||
|
|
||||||
|
Both filesystem drivers seem to be designed on the assumption that they are
|
||||||
|
communicating with a Flash chip; they always write one sector at a time. In the
|
||||||
|
case of littlefs, whenever a byte in a sector is changed, it erases and writes
|
||||||
|
a new sector. It does this without buffering, reading the contents of the old
|
||||||
|
sector and modifying it on the fly.
|
||||||
|
|
||||||
|
The FAT driver seems to do something similar, but according to its docs it can
|
||||||
|
briefly create a buffer for two sectors.
|
||||||
|
|
||||||
|
A possible future project would be an unbuffered Flash driver based on the one
|
||||||
|
referenced above, with the following characteristics:
|
||||||
|
1. No byte array access. Filesystem use only.
|
||||||
|
2. A stand-alone driver not based on `bdevice.py`.
|
||||||
|
3. Support for littlefs2 and FAT. Littlefs2 is preferred over littlefs1 unless
|
||||||
|
RAM minimisation is paramount.
|
||||||
|
4. Support for multi-chip arrays.
|
||||||
|
|
||||||
|
The advantage would be a saving of somewhere around 6KiB of RAM.
|
||||||
|
|
Ładowanie…
Reference in New Issue