Tasklist!

[ladyada]

This project is to 'port' the hardware API we use in CircuitPython as a python layer to MicroPython running on Pyboard or ESP8266. Since CircuitPython uses the same Python3 runtime, its just a matter of matching up the 'pyb' and 'esp' hardware commands for pins, i2c, spi, neopixels, etc.

Once complete, you should be able to run just-about-any CircuitPython library or project on a MicroPython board.
Here are the modules in circuitpython:
http://circuitpython.readthedocs.io/en/latest/shared-bindings/index.html#modules

Your tasks:

• Start with 'board' (pin definitions/names) and 'digitalio' (basic gpio support) http://circuitpython.readthedocs.io/en/latest/shared-bindings/board/__init__.html and http://circuitpython.readthedocs.io/en/latest/shared-bindings/digitalio/__init__.html

  • Test blinking an LED on both ESP and Pyboard using various pins with DigitalInOut, Direction and value property setting
  • Test button input on both ESP and Pyb using pull up & pull down on various pins, using DigitalInOut, Direction, Pull and value property getting

• Completed 'bitbangio.I2C' http://circuitpython.readthedocs.io/en/latest/shared-bindings/bitbangio/I2C.html as per original tasklist

  • Test CircuitPython BME280 library (basic I2C) on ESP

• Hop over to 'busio.I2C' http://circuitpython.readthedocs.io/en/latest/shared-bindings/busio/I2C.html

  • Test CircuitPython BME280 library (basic I2C) on ESP
  • Test CircuitPython BME280 library (basic I2C) on Pyb
  • Test MMA8451 CircuitPy lib (repeat-start I2C)
  • Test BNO055 (clock stretch I2C)

• 'busio.SPI' ! http://circuitpython.readthedocs.io/en/latest/shared-bindings/busio/SPI.html

  • Oscilloscope is good for basic testing, check that you can send and receive data! Note there's also a read_writeinto for reading/writing at the same time
  • Test with RFM69 radio

• 'busio.UART'

  • Test with GPS library, sending and receiving data
  • check with oscilloscope various baudrates: 1200, 2400, 4800, 9600, 19200, ... 115200

You will likely need to revision 'board' at this time and do some updates as you work on busio

• Digital stuff done, you'll do a run on 'analogio' (analog in and output)

We'll evaluate our standing at this time and see if it makes sense to attack 'pulseio'

You'll need hardware that runs both MicroPython and CircuitPython:

• PyBoard (your target micropython board) https://www.adafruit.com/product/2390
• ESP8266 (target micropython and also circuitpy) https://www.adafruit.com/product/2821
• Feather M0 (circuitpy example board) https://www.adafruit.com/product/3403

[cefn]

Probably about time to get a steer if the direction is correct.

See https://github.com/cefn/Adafruit_Micropython_Blinka for the work-in-progress repository. I have put together package and test suite structure allowing test suites to be run against...

• Feather M0 Express running CircuitPython
• Feather Huzzah running CircuitPython
• Feather Huzzah running Micropython with CircuitPython compatibility layer
• Pyboard running Micropython with CircuitPython compatibility layer

A shallow description of the testing regime is at https://github.com/cefn/Adafruit_Micropython_Blinka/blob/master/notes/index.md although it has been very much in flux until recently, so documentation of the testing framework probably shouldn't be overdone right now.

This is not intended to be a test suite with extensive coverage, but it provides a useful structure for contributors to propose targets and demonstrate results as well as for project leaders to articulate differences and set directions for the work through test-driven development.

I have put some time into routines which selectively synchronize the relevant compatibility layers to the different platforms to accelerate testing, and I have some more days still in hand to work on this (roughly 5 days were set aside in total) so I am moving to have a go at I2C as proposed.

Note the issues at https://github.com/cefn/Adafruit_Micropython_Blinka/issues about completing PEP8 compliance and RST docstrings throughout but only if time remains after technical successes are achieved with the codebase so that it's seen to be worth doing this work. I will be led by your feedback.

So far the fundamentals of board, microcontroller and digitalio are operational in the compatibility layer, as indicated by the session documented at cefn#2 (comment) .

These have been recently tested on Huzzah and Pyboard, and I will return occasionally to M0 Express for conformance but the available memory was tight requiring tests to be run manually and individually on that platform, so I am waiting for the testing framework to be more settled before building frozen images and revisiting the M0 Express to verify conformance.

Before putting together a PR, I am aware you might want a different structure in the long run (only the compatibility layer - no testing or upload scripts, perhaps not a python directory). I don't want to pollute your working copy with the wrong structure but it's sure easier to operate with everything in one place right now. If you let me know what preferred structure I should PR I'm happy to do so.

Finally it's great to be working with you and I am very keen to ensure I deliver the right stuff, and welcome your thoughts and insights on what I could do better.

[ladyada]

hey! looks good so far. yeah the m0 express is tight on memory, mpy helps but there's limited - im ok with occasional 'end of the task' tests to verify rather than trying to do constant checks.
we'll verify your work today so far with a pyb. but from what i can see this looks really good!

[ladyada]

ok tested with a pyb and left some notes. really great so far! keep going :)

[tannewt]

I added one comment on the microcontroller.pin stuff but looks good otherwise! Good work!

[cefn]

Soldered together all the bits, got familiar with relevant CircuitPython libs and I2C is now minimally functional on ESP8266 (BME280 attributes correctly populated) as of cefn@b73cdee Testing with Pyb tomorrow.

[ladyada]

awesome! :)

[cefn]

Yesterday was Paragliding weather :).

For now I have put aside I2C test coverage for Pyboard etc. as a task to go back to as I think there will be a lot more needed to get substantial coverage anyway.

Right now want to make sure there are technical results across the piece to help us assess next steps, so was visiting SPI and UART.

Unfortunately I followed the link in the Tasklist which was (incorrectly?) linked to bitbangio so put some time into wrapping the bitbang implementation continuing from I2C. However, looking back at the task list, perhaps the title of the task bullet test should be respected, which said busio and would map to the hardware SPI instead.

Which one should I be looking at? The example file at https://github.com/adafruit/Adafruit_CircuitPython_RFM69/blob/master/examples/simpletest.py uses busio not bitbangio but I don't know if that's fundamental to RFM69.

[ladyada]

woops typo on my part, i meant busio for all these (altho bitbangio has the same api, fyi, it just does the pin toggles by hand rather than depending on a built in hardware support peripheral)

[cefn]

Understood. Need to spin up into some other issues.

[cefn]

So there is now a PR fulfilling this Tasklist except...

• BNO055 test authored but not successful (serving only zeroes - possibly hardware issue, can investigate further or hold off)
• busio.SPI and bitbangio.SPI authored but not tested (libraries to service RFM69 reliant on descriptors unavailable in Micropython; investigating via No seamless workaround for missing descriptor support #6). Alternative scenario?
• Not pursued oscilloscope-based tests. I'm hoping the BNC probe-cables for the oscilloscope in the new workshop should arrive imminently. I haven't much experience with an oscilloscope, honestly, but good to be nudged to start using the thing :) However, my early experimentation with the instrument could be unreliable, given my inexperience.

Can the oscilloscope trace indicate anything about the implementation choices made in the adafruit_blinka compatibility layer, or would I be investigating the timing-performance of Micropython's software/board hardware implementations. That might be beyond my expertise.

[makermelissa]

Closing since to my knowledge code is all working.