Top level package now defines only uart and spi ports. pin submodule handles pins

[hackapet/Adafruit_Blinka.git] / notes / index.md

diff --git a/notes/index.md b/notes/index.md
index 51d786e2854a3d41f69519758430fb2c2869c867..2004644b0cc88fb71e8594fa2034434e1dd5c789 100644 (file)
--- a/notes/index.md
+++ b/notes/index.md
@@ -15,30 +15,16 @@ MCP layer are in fact already served from the CP layer.
 # Example
 
 To take a minimal example, the following asserts the default behaviour of the DigitalInOut 
-constructor, to configure a pin as an input with no pull. The gc.collect() calls help to 
-minimise heap fragmentation, and ensure there is enough memory to run the particular test. 
+constructor, checks the behaviour of switch_to_input/output(), configures a pin as a pull-up button, a pull-down button and an LED.
 
 ```python
-import gc
 import testing
-gc.collect()
-import testing.platform.all.digitalio as suite
-gc.collect()
-case = suite.TestDigitalInOut()
-gc.collect()
-if hasattr(case, 'setUp'):
-    case.setUp()
-gc.collect()
-
-gc.mem_free()
-case.test_default()
+testing.main()
 ```
 
 ## Comments
 
-There is a routine in the top level of the repo called `upload_feather_m0_watch.py` which monitors the repo folder (on a regular 
-filesystem) and selectively synchronizes it with the CIRCUITPY folder 
-when any changes are saved, which assists with development.
+There are routines in the top level of the repo like `upload_feather_m0_watch.py` which selectively synchronize files it with the CIRCUITPY or PYBFLASH folder for stm32 and samd21 (with a file-watching behaviour for edits), or which execute a selective ampy upload for CircuitPython/Micropython on esp8266.
 
 Given the limited memory available, on the Feather M0 Express, running the test case requires that 
 the [micropython-lib unittest library](https://github.com/micropython/micropython-lib/blob/master/unittest/unittest.py) 
@@ -48,23 +34,24 @@ simply loading the unittest module already busts the available memory.
 
 # Test Suite Structure
 
-The structure of the testing modules is as follows...
+The structure of the testing modules is as follows, to permit test suites to be imported selectively
+on different implementations, platforms and boards (see agnostic.py for definitions of these terms)...
 
 * _testing_ - common function definitions for suite-execution
 * _testing.mcp_ - test suite for hardware-agnostic elements of MCP layer (e.g. Enum)
-* _testing.platform_ - calculates platform-specific parameters for test fixtures
-* _testing.platform.all_ - suites expected to run on all platforms
-* _testing.platform.mcp_ - suites testing MCP-specific classes and behaviours (under the hood of the hardware compatibility layer) and only 
+* _testing.implementation_ - calculates implementation-specific parameters for test fixtures
+* _testing.implementation.all_ - suites expected to run on all platforms
+* _testing.implementation.micropython_ - suites testing MCP-specific classes and behaviours (under the hood of the hardware compatibility layer) and only 
 expected to run on Micropython
-* _testing.platform.circuitpython - suites testing CircuitPython-specific 
+* _testing.implementation.circuitpython - suites testing CircuitPython-specific 
 classes and behaviours, and only expected to run in CircuitPython_
 
 e.g.
-* testing.platform.all.digitalio - tests against the 
+* testing.implementation.all.digitalio - tests against the 
 digitalio module regardless of platform
-* testing.platform.circuitpython.digitalio - tests of digitalio against a 
+* testing.implementation.circuitpython.digitalio - tests of digitalio against a 
 native circuitpython host
-* testing.platform.mcp.digitalio - tests of digitalio against the mcp 
+* testing.implementation.micropython.digitalio - tests of digitalio against the MCP
 compatibility layer