eep_i2c.py: Fix cptest path handling.

Add support for I2C EEPROMs with page sizes other than 128 in eeprom_…

eeprom/i2c/I2C.md

@@ -132,15 +132,16 @@ Arguments:
  is `2**block_size` so is 512 bytes by default.
  5. `addr` override base address for first chip
  6. `max_chips_count` override max_chips_count
+ 7. `page_size=7` The binary logarithm of the page size of the EEPROMs, i.e., the page size in bytes is `2 ** page_size`. The page size may vary between chips from different manufacturers even for the same storage size. Note that specifying a too large value will most likely lead to data corruption in write operations. Look up the correct value for your setup in the chip's datasheet.
 
  With `addr` and `max_chips_count` override, it's possible to make multiple
  configuration
- 
+
  example:
- 
+
  array with custom chips count:
  ```python
- eeprom0 = EEPROM( i2c, max_chips_count=2 ) 
+ eeprom0 = EEPROM( i2c, max_chips_count=2 )
  eeprom1 = EEPROM( i2c, addr=0x52, max_chips_count=2 )
  ```
  1st array using address 0x50 and 0x51 and 2nd using array address 0x52 and 0x53.
@@ -150,7 +151,7 @@ Arguments:
  eeprom0 = EEPROM( i2c, addr=0x50, max_chips_count=1 )
  eeprom1 = EEPROM( i2c, addr=0x51, max_chips_count=1 )
  ```
- 
+
 ### 4.1.2 Methods providing byte level access
 
 It is possible to read and write individual bytes or arrays of arbitrary size.
@@ -216,6 +217,9 @@ These are provided by the base class. For the protocol definition see
 [the pyb documentation](http://docs.micropython.org/en/latest/library/uos.html#uos.AbstractBlockDev)
 also [here](http://docs.micropython.org/en/latest/reference/filesystem.html#custom-block-devices).
 
+These methods exist purely to support the block protocol. They are undocumented:
+their use in application code is not recommended.
+
 `readblocks()`  
 `writeblocks()`  
 `ioctl()`

eeprom/i2c/eep_i2c.py

@@ -67,9 +67,7 @@ def test(eep=None):
         eep[sa + v] = v
     for v in range(256):
         if eep[sa + v] != v:
-            print(
-                "Fail at address {} data {} should be {}".format(sa + v, eep[sa + v], v)
-            )
+            print("Fail at address {} data {} should be {}".format(sa + v, eep[sa + v], v))
             break
     else:
         print("Test of byte addressing passed")
@@ -132,14 +130,15 @@ def cptest(eep=None):  # Assumes pre-existing filesystem of either type
             print("Fail mounting device. Have you formatted it?")
             return
         print("Mounted device.")
-    cp("eep_i2c.py", "/eeprom/")
-    cp("eeprom_i2c.py", "/eeprom/")
+    cp(__file__, "/eeprom/")
+    # We may have the source file or a precompiled binary (*.mpy)
+    cp(__file__.replace("eep", "eeprom"), "/eeprom/")
     print('Contents of "/eeprom": {}'.format(uos.listdir("/eeprom")))
     print(uos.statvfs("/eeprom"))
 
 
 # ***** TEST OF HARDWARE *****
-def full_test(eep=None, block_size = 128):
+def full_test(eep=None, block_size=128):
     eep = eep if eep else get_eep()
     page = 0
     for sa in range(0, len(eep), block_size):

eeprom/i2c/eeprom_i2c.py

@@ -19,7 +19,7 @@ T24C32 = const(4096)  # 4KiB 32Kbits
 # Logical EEPROM device consists of 1-8 physical chips. Chips must all be the
 # same size, and must have contiguous addresses.
 class EEPROM(BlockDevice):
-    def __init__(self, i2c, chip_size=T24C512, verbose=True, block_size=9, addr=_ADDR, max_chips_count=_MAX_CHIPS_COUNT):
+    def __init__(self, i2c, chip_size=T24C512, verbose=True, block_size=9, addr=_ADDR, max_chips_count=_MAX_CHIPS_COUNT, page_size=7):
         self._i2c = i2c
         if chip_size not in (T24C32, T24C64, T24C128, T24C256, T24C512):
             print("Warning: possible unsupported chip. Size:", chip_size)
@@ -29,6 +29,8 @@ class EEPROM(BlockDevice):
         self._i2c_addr = 0  # I2C address of current chip
         self._buf1 = bytearray(1)
         self._addrbuf = bytearray(2)  # Memory offset into current chip
+        self._page_size = 2 ** page_size
+        self._page_mask = ~(self._page_size - 1)
 
     # Check for a valid hardware configuration
     def scan(self, verbose, chip_size, addr, max_chips_count):
@@ -67,7 +69,7 @@ class EEPROM(BlockDevice):
         self._addrbuf[0] = (la >> 8) & 0xFF
         self._addrbuf[1] = la & 0xFF
         self._i2c_addr = self._min_chip_address + ca
-        pe = (addr & ~0x7F) + 0x80  # byte 0 of next page
+        pe = (addr & self._page_mask) + self._page_size  # byte 0 of next page
         return min(nbytes, pe - la)
 
     # Read or write multiple bytes at an arbitrary address

eeprom/spi/SPI.md

@@ -209,6 +209,9 @@ These are provided by the base class. For the protocol definition see
 [the pyb documentation](http://docs.micropython.org/en/latest/library/uos.html#uos.AbstractBlockDev)
 also [here](http://docs.micropython.org/en/latest/reference/filesystem.html#custom-block-devices).
 
+These methods exist purely to support the block protocol. They are undocumented:
+their use in application code is not recommended.
+
 `readblocks()`  
 `writeblocks()`  
 `ioctl()`

flash/FLASH.md

@@ -12,7 +12,7 @@ chips including those with 24-bit addressing. He tested an XPX XT25F32B; I
 tested Winbond W25Q32JV 4MiB and Cypress S25FL064L 8MiB devices.
 
 It is likely that other chips with 4096 byte blocks will work but I am unlikely
-to be able to support hardware I don't possess. See 
+to be able to support hardware I don't possess. See
 [Section 6](./FLASH.md#6-unsupported-chips) for recommendations on settings.
 
 ## 1.2 The driver
@@ -36,7 +36,7 @@ capacity of flash chips.
 FAT and littlefs filesystems are supported but the latter is preferred owing to
 its resilience and wear levelling characteristics. Please note that this driver
 has been tested on LFS2 only. Users requiring a driver with minimum RAM use
-may want to consider [this driver](https://github.com/robert-hh/SPI_Flash). 
+may want to consider [this driver](https://github.com/robert-hh/SPI_Flash).
 This supports an LFS1 filesystem on a single flash chip.
 
 Arguably byte level access on such large devices has few use cases other than
@@ -161,7 +161,7 @@ Arguments. In most cases only the first two mandatory args are required:
  6. `block_size=9` The block size reported to the filesystem. The size in bytes
  is `2**block_size` so is 512 bytes by default.
  7. `cmd5=None` Flash chips can support two low level command sets, a 4 byte
- set and a 5 byte set. By default if the size read from the chip's ID is 
+ set and a 5 byte set. By default if the size read from the chip's ID is
  <= 4096KiB the 4 byte set is used oterwise the 5 byte set is adopted. This
  works for supported chips. Setting `cmd5` `True` forces 5 byte commands,
  `False` forces 4 byte. This override is necessary for certain chip types
@@ -271,6 +271,9 @@ These are provided by the base class. For the protocol definition see
 [the pyb documentation](http://docs.micropython.org/en/latest/library/uos.html#uos.AbstractBlockDev)
 also [here](http://docs.micropython.org/en/latest/reference/filesystem.html#custom-block-devices).
 
+These methods exist purely to support the block protocol. They are undocumented:
+their use in application code is not recommended.
+
 `readblocks()`  
 `writeblocks()`  
 `ioctl()`
@@ -349,7 +352,7 @@ 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 
+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

fram/FRAM.md

@@ -187,6 +187,9 @@ These are provided by the base class. For the protocol definition see
 [the pyb documentation](http://docs.micropython.org/en/latest/library/uos.html#uos.AbstractBlockDev)
 also [here](http://docs.micropython.org/en/latest/reference/filesystem.html#custom-block-devices).
 
+These methods exist purely to support the block protocol. They are undocumented:
+their use in application code is not recommended.
+
 `readblocks()`  
 `writeblocks()`  
 `ioctl()`

fram/FRAM_SPI.md

@@ -179,6 +179,9 @@ These are provided by the base class. For the protocol definition see
 [the pyb documentation](http://docs.micropython.org/en/latest/library/uos.html#uos.AbstractBlockDev)
 also [here](http://docs.micropython.org/en/latest/reference/filesystem.html#custom-block-devices).
 
+These methods exist purely to support the block protocol. They are undocumented:
+their use in application code is not recommended.
+
 `readblocks()`  
 `writeblocks()`  
 `ioctl()`

spiram/SPIRAM.md

@@ -163,6 +163,9 @@ These are provided by the base class. For the protocol definition see
 [the pyb documentation](http://docs.micropython.org/en/latest/library/uos.html#uos.AbstractBlockDev)
 also [here](http://docs.micropython.org/en/latest/reference/filesystem.html#custom-block-devices).
 
+These methods exist purely to support the block protocol. They are undocumented:
+their use in application code is not recommended.
+
 `readblocks()`  
 `writeblocks()`  
 `ioctl()`