Milestones

[cefn]

Discussion points for milestones on the Blinka project...

Milestone 0 - Technical proof/reference approach

Reference implementations able to run canonical Adafruit library examples backed by corresponding hardware. This was the original project scope as per #2 :) So far intended...

• board.* (schemes for breakout-specific pin identities)
• microcontroller.* (schemes for chip-specific pin identities)
• digitalio.* (Pin constructors and enums for Pin config)
• busio.I2C, proven with BMP280, MMA8451, BNO055 examples
• bitbangio.I2C, proven as per bitbangio.I2C (but perhaps not able to service everything hardware can)
• busio.SPI, proven with RFM69 pair
• busio.UART, proven with MTK3339

Strictly I am over the hours now but I'll keep going to try and get these examples proven against hardware on Micropython on ESP8266 (where CircuitPython tests can run proving feasibility) and with luck Pyboard too (where CircuitPython tests can't prove feasibility, so potentially some open questions), with neighbouring packages placed onto a todo list, (analogio, pulseio etc.) as per the Tasklist. In the short term I will refocus on busio after the bitbangio cul-de-sac

Milestone 1 - Adequate Testing Coverage

• Likely Not: Unit Tests; since code is largely wrapper code, there is limited capacity or value for unit-test coverage since the objective of the code is validity for integration. For desktop-based/Travis unit tests, we may need to commit to CPython compatibility (e.g. break modules into platform-specific submodules) which has a cost and marginal value I think given there will be few elements which can be separated this way into unit-testable fragments.
• Likely: Integration Tests; I expect most meaningful tests to be integration tests
• Will commit to a list of Target Hardware; To prove compatibility/stability through integration tests, we will need to identify target hardware that we consider in scope (so far Huzzah and Pyboard). Should we freeze the target hardware to these, or do we expect to list ESP-01, NodeMCU, D1 Mini, various ESP32 boards e.g. M5Stack, (see also the list of supported hardware at Micropython.org and Loboris' fork)
• Will commit to Micropython versions; Testing so far has been against 1.9.3, maybe a marginal advantage to committing against the current stable rebased version of CircuitPython, (1.9.2 right now?). Perhaps in the future this list will extend to CPython3.x if e.g. Pi GPIO is intended to be wrapped also.
• Coverage; An intuitive run at coverage can be gained by surveying lines of code, and authoring cases for TDD that way. Q. Is a more formal definition of coverage possible? Are there test suites covering CircuitPython that can be ported?

Regardless how integration-test cases are arrived at, they are inevitably slow and complex to test and re-test as they require access to specific hardware and manual wiring-up each time. Although I should have proven Milestone 0 by minimal reference test cases, that isn't the same as aiming at test coverage.

Whether coverage is considered an objective or not, the test suite provides a useful way to communicate compatibility targets intended or achieved, even if few people will ever test or see the results.

It would be good to know what would count as a complete-enough integration test suite for Adafruit's purposes so we can define this Milestone properly.

Milestone 2 - Snapshot Documentation

Before non-specialists adopt any snapshot of the codebase, there will need to be introductory documentation detailing how to set up Blinka on Micropython.

There may be guidance to select the relevant packages which enable various CircuitPython interfaces on Micropython boards (especially if targeting hardware with limited filesystem storage, as packages will need to be selectively uploaded, rather than adopting the upload-the-whole-bundle approach).

Remaining documentation should mirror the CircuitPython tree, (merged from the sphinx doctree from the C source of CircuitPython's the API documentation)), with exceptional notes relating to the Micropython port only where necessary.

Milestone 3 - Exhaustiveness

Having exhaustiveness of the CircuitPython API (either providing or explicitly excluding support for all parts of the API) would be a useful objective meaning that those familiar with, or referencing CircuitPython resources, can establish with confidence whether they can rely on such-and-such a part of the API being available on their Micropython platform. This could be delivered by meaningful error messages at runtime. Given we will have only looked at a small part of the API within earlier tranches, exhaustiveness might involve providing an API which flags everything else as unsupported, then working back from there as support is extended. Certainly for any modules which are at least partially supported, there will need to be runtime errors thrown for unsupported elements. We might provide a directory structure of README files so that people can navigate to interface definitions and learn they are unsupported. In the long run, if the project reaches a suitable level of maturity, then the 'blinka' implementation of a given platform might be featured in something like the https://circuitpython.readthedocs.io/en/2.x/shared-bindings/index.html#module-support-matrix

[ladyada]

milestone 0: is really the only task, and getting the code working is the goal :) reply to the email thread and we'll make sure we work out the time you have left and add more if needed

for milestone 1:
doing substantial automated hardware tests is nearly impossible, so your test suite should simply be the example code that comes with each library indicated in milestone 0 (for i2c/spi/uart). those libraries were chosen to give as-complete-as-possible coverage of everything you can expect from the various if you're getting the right output, as matches the feather m0, you're good. this isn't an enterprise release, it's some free software we're giving to the community so no big deal if we miss something on v1.0.0 :D

ESP32 isn't part of the milestone, its beta anyways - your only targets should be the pyboard and an esp8266 running micropython 1.9.3 (or whatever is latest)

milestone 2 & 3: don't worry about these, they're not essential for this project.

[makermelissa]

Closing since code is working.