| Age | Commit message (Collapse) | Author |
|---|
|
This only needs to be enabled if a board uses FAT FS on external SPI flash.
When disabled (and using external SPI flash) 4k of RAM can be saved.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This is run with uncrustify 0.70.1, and black 19.10b0.
|
|
The pyb.Flash() class can now be used to construct objects which reference
sections of the flash storage, starting at a certain offset and going for a
certain length. Such objects also support the extended block protocol.
The signature for the constructor is: pyb.Flash(start=-1, len=-1).
|
|
The flash-IRQ handler is used to flush the storage cache, ie write
outstanding block data from RAM to flash. This is triggered by a timeout,
or by a direct call to flush all storage caches.
Prior to this commit, a timeout could trigger the cache flushing to occur
during the execution of a read/write to external SPI flash storage. In
such a case the storage subsystem would break down.
SPI storage transfers are already protected against USB IRQs, so by
changing the priority of the flash IRQ to that of the USB IRQ (what is
done in this commit) the SPI transfers can be protected against any
timeouts triggering a cache flush (the cache flush would be postponed until
after the transfer finished, but note that in the case of SPI writes the
timeout is rescheduled after the transfer finishes).
The handling of internal flash sync'ing needs to be changed to directly
call flash_bdev_irq_handler() sync may be called with the IRQ priority
already raised (eg when called from a USB MSC IRQ handler).
|
|
This patch renames the existing SPI flash API functions to reflect the fact
that the go through the cache:
mp_spiflash_flush -> mp_spiflash_cache_flush
mp_spiflash_read -> mp_spiflash_cached_read
mp_spiflash_write -> mp_spiflash_cached_write
|
|
If no block devices are defined by a board then storage support will be
disabled. This means there is no filesystem provided by either the
internal flash or external SPI flash. But the VFS system can still be
enabled and filesystems provided on external devices like an SD card.
|
|
Explicitly writing out the implementation of sys_tick_has_passed makes
these bdev files independent of systick.c and more reusable as a general
component. It also reduces the code size slightly.
The irq.h header is added to spibdev.c because it uses declarations in that
file (irq.h is usually included implicitly via mphalport.h but not always).
|
|
If a board wants to use SPI flash for storage then it must now provide the
configuration itself, using the MICROPY_HW_BDEV_xxx macros.
|
|
This allows a board to have multiple instances of the SPI block device.
|
|
It makes it cleaner, and simpler to support multiple different block
devices. It also allows to easily extend a given block device with new
ioctl operations.
|
|
This patch alters the SPI-flash memory driver so that it uses the new
low-level C SPI protocol (from drivers/bus/spi.h) instead of the uPy SPI
protocol (from extmod/machine_spi.h). This allows the SPI-flash driver to
be used independently from the uPy runtime.
|
|
This patch takes the software SPI implementation from extmod/machine_spi.c
and moves it to a dedicated file in drivers/bus/softspi.c. This allows the
SPI driver to be used independently of the uPy runtime, making it a more
general component.
|
|
The spiflash driver now supports read/write of multiple blocks at a time.
|
|
To use QSPI (in software QSPI mode) the configuration needed is:
#define MICROPY_HW_SPIFLASH_SIZE_BITS (n * 1024 * 1024)
#define MICROPY_HW_SPIFLASH_CS (pin_x1)
#define MICROPY_HW_SPIFLASH_SCK (pin_x2)
#define MICROPY_HW_SPIFLASH_IO0 (pin_x3)
#define MICROPY_HW_SPIFLASH_IO1 (pin_x4)
#define MICROPY_HW_SPIFLASH_IO2 (pin_x5)
#define MICROPY_HW_SPIFLASH_IO3 (pin_x6)
|
|
|
|
Prior to this patch, storage.c was a combination of code that handled
either internal flash or external SPI flash and exposed one of them as a
block device for the local storage. It was also exposed to the USB MSC.
This patch splits out the flash and SPI code to separate files, which each
provide a general block-device interface (at the C level). Then storage.c
just picks one of them to use as the local storage medium. The aim of this
factoring is to allow to add new block devices in the future and allow for
easier configurability.
|
