This class focuses on the timing sensitive parts of the protocol.
Everything else will be done by Python code.
This also establishes that its OK to back a nativeio class with a
bitbang implementation when no hardware acceleration exists. When
it does, then bitbangio should be used to explicitly bitbang a
protocol.
1) Bus error will be thrown on read/write errors with errno set. (Read didn't used to fail at all.)
2) try_lock correctly returns boolean whether lock was grabbed.
Fixes#87
The new sequence is as follows:
* Solid blue during the boot/settings script.
* Solid green during the main/code script.
* After main while waiting to enter repl or reset:
* Fading green once main is done successfully.
* On error produce a series of flashes:
* Long flash color of script.
* Long flash color of error:
* Green = IndentationError
* Cyan = SyntaxError
* White = NameError
* Orange = OSError
* Yellow = Other error
* Line number of the exception by digit. Number of flashes represents value.
* Thousands = White
* Hundreds = Blue
* Tens = Yellow
* Ones = Cyan
* Off for a period and then repeats.
At any point a write to the flash storage will flicker red.
Fixes#63
Docs are here: http://tannewt-micropython.readthedocs.io/en/microcontroller/
It differs from upstream's machine in the following ways:
* Python API is identical across ports due to code structure. (Lives in shared-bindings)
* Focuses on abstracting common functionality (AnalogIn) and not representing structure (ADC).
* Documentation lives with code making it easy to ensure they match.
* Pin is split into references (board.D13 and microcontroller.pin.PA17) and functionality (DigitalInOut).
* All nativeio classes claim underlying hardware resources when inited on construction, support Context Managers (aka with statements) and have deinit methods which release the claimed hardware.
* All constructors take pin references rather than peripheral ids. Its up to the implementation to find hardware or throw and exception.
Scott Shawcroft
Scott Shawcroft