Prior to refactor branch.

README.md

@@ -69,11 +69,8 @@ In the table below the Interface column includes page size in bytes.
 | Microchip    | 24xx64    | I2C 128   |   8KiB |   EEPROM   | [I2C.md](./eeprom/i2c/I2C.md) |
 | Adafruit     | 1895      | I2C n/a   |  32KiB |   FRAM     | [FRAM.md](./fram/FRAM.md)     |
 
-Documentation:  
+Note that the flash driver is **under development** and has a possible issue
-[SPI.md](./eeprom/spi/SPI.md)  
+discussed in [FLASH.md](./flash/FLASH.md).
-[I2C.md](./eeprom/i2c/I2C.md)  
-[FRAM.md](./fram/FRAM.md)  
-[FLASH.md](./flash/FLASH.md)  
 
 ## 1.5 Performance
 
@@ -109,7 +106,7 @@ electrical limits may also apply).
 
 The larger capacity chips generally use SPI.
 
-# 3. Design details, littlefs support
+# 3. Design details
 
 A key aim of these drivers is support for littlefs. This requires the extended
 block device protocol as described
@@ -137,6 +134,13 @@ default in MicroPython's littlefs implementation is 512 bytes and all testing
 was done with this value. FAT requires 512 bytes minimum: FAT testing was done
 with the same block size.
 
+## 3.1 Developer Documentation
+
+This [doc](./BASE_CLASSES.md) has information on the base classes for those
+wishing to write drivers for other memory devices.
+
+# 4. littlefs support
+
 The test programs use littlefs and therefore require MicroPython V1.12 or
 later. On platforms that don't support littlefs the options are either to adapt
 the test programs for FAT (code is commented out) or to build firmware with

flash/FLASH.md

@@ -25,6 +25,21 @@ its resilience and wear levelling characteristics.
 Byte level access on such large devices probably has few use cases other than
 for facilitating effective hardware tests and diagnostics.
 
+## 1.1 Test Status
+
+The driver has been tested with both chip types. Single chip setups work fine.
+With pairs of devices I have seen sporadic single bit errors, especially at
+high baudrates. I strongly suspect hardware issues with my breadboard lash-up
+and am awaiting PCB's in manufacture. The reasons I suspect hardware are:
+
+ 1. Errors are usually single bit: it's hard to see how the driver could do
+ this.
+ 2. Errors are not consistent.
+ 3. They are baudrate dependent.
+ 4. The breadboard is truly revoltming.
+
+However until I can test with a PCB the possibility of a bug remains.
+
 ##### [Main readme](../README.md)
 
 # 2. Connections
@@ -61,8 +76,7 @@ Other platforms may vary but the Cypress chips require a 3.3V supply.
 The devices support baudrates up to 50MHz. In practice MicroPython targets do
 not support such high rates. In testing I found it necessary to specify 5MHz
 otherwise erratic results occurred. This was probably because of my breadboard
-test setup. I have a PCB in manufacture and hope to run at 20MHz. For now code
+test setup as described above. SPI bus wiring should be short and direct.
-samples specify 5MHz. SPI bus wiring should be short and direct.
 
 # 3. Files
 
@@ -70,10 +84,18 @@ samples specify 5MHz. SPI bus wiring should be short and direct.
  2. `bdevice.py` (In root directory) Base class for the device driver.
  3. `flash_test.py` Test programs for above.
  4. `littlefs_test.py` Torture test for the littlefs filesystem on the flash
- array.
+ array. Requires `flash_test.py` which it uses for hardware configuration.
 
 Installation: copy files 1 and 2 (3 & 4 are optional) to the target filesystem.
-Test scripts assume two chips with CS/ pins wired to Pyboard pins Y4 and Y5.
+The `flash_test` script assumes two S25FL256L chips connected to SPI(2) with
+CS/ pins wired to Pyboard pins Y4 and Y5. The `get_device` function may be
+adapted for other setups and is shared with `littlefs_test`.
+
+For a quick check of hardware issue:
+```python
+import flash_test
+flash_test.test()
+```
 
 # 4. The device driver
 
@@ -227,7 +249,8 @@ following.
 
 This performs a basic test of single and multi-byte access to chip 0. The test
 reports how many chips can be accessed. Existing array data will be lost. This
-primarily tests the driver: as a hardware test it is not exhaustive.
+primarily tests the driver: as a hardware test it is not exhaustive. It does
+provide a quick verification that all chips can be accessed.
 
 ## 5.2 full_test(count=10)
 

flash/flash_test.py

@@ -6,17 +6,22 @@
 import uos
 from machine import SPI, Pin
 from flash_spi import FLASH
-# Add extra pins if using multiple chips
-cspins = (Pin(Pin.board.Y5, Pin.OUT, value=1), Pin(Pin.board.Y4, Pin.OUT, value=1))
 
-# Return an EEPROM array. Adapt for platforms other than Pyboard.
+# **** ADAPT THIS FUNCTION ****
+
+# Return an EEPROM array. Adapt for platforms other than Pyboard, chip size and
+# baudrate.
 def get_device():
     if uos.uname().machine.split(' ')[0][:4] == 'PYBD':
         Pin.board.EN_3V3.value(1)
-    flash = FLASH(SPI(2, baudrate=5_000_000), cspins)
+    # Adjust to suit number of chips and their wiring.
+    cspins = (Pin(Pin.board.Y5, Pin.OUT, value=1), Pin(Pin.board.Y4, Pin.OUT, value=1))
+    flash = FLASH(SPI(2, baudrate=5_000_000), cspins, size=32768)
     print('Instantiated Flash')
     return flash
 
+# **** END OF USER-ADAPTED CODE ****
+
 # Dumb file copy utility to help with managing EEPROM contents at the REPL.
 def cp(source, dest):
     if dest.endswith('/'):  # minimal way to allow

flash/littlefs_test.py

@@ -6,16 +6,7 @@
 import uos
 from machine import SPI, Pin
 from flash_spi import FLASH
-
+from flash_test import get_device
-cspins = (Pin(Pin.board.Y5, Pin.OUT, value=1), Pin(Pin.board.Y4, Pin.OUT, value=1))
-
-# Return flash array. Adapt for platforms other than Pyboard.
-def get_device():
-    if uos.uname().machine.split(' ')[0][:4] == 'PYBD':
-        Pin.board.EN_3V3.value(1)
-    flash = FLASH(SPI(2, baudrate=5_000_000), cspins)
-    print('Instantiated Flash')
-    return flash
 
 directory = '/fl_ext'
 a = bytearray(range(256))