Tasklist! about adafruit_blinka HOT 11 CLOSED

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.

from adafruit_blinka.

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.

from adafruit_blinka.

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!

from adafruit_blinka.

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

from adafruit_blinka.

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

from adafruit_blinka.

awesome! :)

from adafruit_blinka.

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.

from adafruit_blinka.

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)

from adafruit_blinka.

Understood. Need to spin up into some other issues.

from adafruit_blinka.

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 #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.

from adafruit_blinka.

Closing since to my knowledge code is all working.

from adafruit_blinka.