and fix name in pypi too

I tried to import adafruit_motorkit in python3
the compiler throws back the following errors:

Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import adafruit_motorkit
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
  File "/usr/local/lib/python3.5/dist-packages/adafruit_circuitpython_motorkit-1.2.4.dev0+g6f2d8ad.d20181230-py3.5.egg/adafruit_motorkit.py", line 59, in <module>
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 664, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.1.0-py3.5.egg/board.py", line 65, in <module>
NotImplementedError: Board not supported

I have a Raspberry Pi 3 B model. As stated in the adafruit_blinka/board.py, this board is supported. This RPi worked before with the adafruit_motorkit library but for some reason it's not working now when I reinstalled the Operating system
Any help would be great

Similar to #66 , I am getting NotImplementedError: Board not supported.

I am using Raspberry Pi 3 Model B+, with 64-bit Arch linux ARM installed.
Below is the output of /proc/cpuinfo

processor       : 0
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 1
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 2
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 3
BogoMIPS        : 38.40
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

On tracing back where the error arises, I found out that in neopixel_write.py, line 14 returns None. This function call goes to Adafruit_Python_Platformdetect's _pi_rev_code here. However, detector.chip.id is BCM2XX when running detect.py and when trying the code myself in python3 console. So the control goes to get_cpuinfo_field. Here, the regex pattern does not find any matches because there are no lines starting with Revision or revision. There are a few lines with CPU revision though. I don't know if those are the ones that it should be looking for. If they are, a quick fix would be to remove ^ from the regex pattern here

https://circuitpython.readthedocs.io/en/3.x/shared-bindings/digitalio/DigitalInOut.html#digitalio.DigitalInOut.switch_to_output

Hey @atan1021,

Thank you for your contribution to this library in the efforts of supporting the TX2, however I'm having some problems getting my neopixel lights running with it on my TX2.

The error references not being able to find a GPIO library in /opt/nvidia/jetson-gpio/lib/python/Jetson/GPIO.

I looked in JetPack to see if I was missing a dependency but I couldn't find any relating to GPIO and I couldn't find any reference to it online.

Any help is greatly appreciated, and the error is down below.

Thanks,
John

Traceback (most recent call last):
  File "neopixel_simpletest.py", line 2, in <module>
    import board
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.6.dev1+g49fca60-py3.5.egg/board.py", line 68, in <module>
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.6.dev1+g49fca60-py3.5.egg/adafruit_blinka/board/jetson_tx2.py", line 3, in <module>
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.6.dev1+g49fca60-py3.5.egg/adafruit_blinka/microcontroller/tegra/t186/pin.py", line 5, in <module>
ImportError: No module named 'Jetson'

Hi, I'm just trying to test the DC-Stepper Motor HAT following the online instructions located here: https://learn.adafruit.com/simple-raspberry-pi-robot/hardware

It's a Raspberry Pi 3 with Jessie that I've apt-get updated/upgraded.

I'm running a Python3 virtual env and adafruit-blinka and adafruit-circuitpython-motorkit pip3 installs worked without error.

(car1) pi@picar:~/car1 $ uname -m
armv7l
(car1) pi@picar:~/car1 $ pip list
Package                          Version
-------------------------------- -------
Adafruit-Blinka                  1.0.2
adafruit-circuitpython-busdevice 2.2.7
adafruit-circuitpython-motor     1.3.3
adafruit-circuitpython-motorkit  1.2.3
adafruit-circuitpython-pca9685   3.2.3
adafruit-circuitpython-register  1.3.2
Adafruit-PlatformDetect          0.0.7
pip                              18.1
rpi-ws281x                       4.1.0
RPi.GPIO                         0.6.5
setuptools                       40.6.3
spidev                           3.2
wheel                            0.32.3

However, I cannot run any of the examples to test the motors and am not experienced enough to understand how to debug.

(car1) pi@picar:~/car1 $ python3
Python 3.4.2 (default, Sep 26 2018, 07:16:01)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from adafruit_motorkit import MotorKit
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/pi/car1/lib/python3.4/site-packages/adafruit_motorkit.py", line 59, in <module>
    import board
  File "/home/pi/car1/lib/python3.4/site-packages/board.py", line 59, in <module>
    raise NotImplementedError("Board not supported")
NotImplementedError: Board not supported

I've also run the tests for i2c and spi

https://learn.adafruit.com/adafruits-raspberry-pi-lesson-4-gpio-setup/configuring-i2c

(car1) pi@picar:~/car1 $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: 70 -- -- -- -- -- -- --
(car1) pi@picar:~/car1 $ ls -l /dev/spidev*
crw-rw---- 1 root spi 153, 0 Dec 24 14:42 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 Dec 24 14:42 /dev/spidev0.1

Any suggestions on how I could troubleshoot further? Appreciate your time.

Wiring PI and RPi.GPIO are supported on this board; unfortunately this package mistakenly detects the board as a BeagleBone black.

Machine Specs: Ubuntu 18.04 Desktop on an i7 based workstation.

Background: I'm using an Adafruit HTU21D-F Humidity/Temp sensor connected to a USB pluggable FT232H breakout board (C232HM-DDHSL‌-0 USB2.0/I2C cable). Adafruit GPIO has support for FT232H (https://github.com/adafruit/Adafruit_Python_GPIO/blob/master/Adafruit_GPIO/FT232H.py)

Question: I want to use circuitpython, in particular, the HTU21D-F code (https://github.com/adafruit/Adafruit_CircuitPython_HTU21D/blob/master/adafruit_htu21d.py) but I don't have a supported board as I'm using a linux desktop computer. What are my options? Can I use circuitpython? Is there any documentation regarding this type of use?

I realize this may be the wrong place to post this, if so where should I post it? Who should I consult? (Thanks!)

I can be bitbanged in a separate thread or process. Bitbanging code is here:

adafruit/Adafruit_CircuitPython_DHT#18

i think a pi zero is an armv6 or something? lets make it auto install on a pi zero too

Someone on discord was following this guide using a Pi Zero W:
https://learn.adafruit.com/neopixels-on-raspberry-pi
It didn't work because rpi_ws281x didn't get installed along with blinka. Probably because of this:
https://github.com/adafruit/Adafruit_Blinka/blob/master/requirements.txt#L2
They did a manual pip3 install of rpi_ws281x and their NeoPixels started working.

This is probably a similar issue:
https://forums.adafruit.com/viewtopic.php?f=50&t=143702
although Pi model is unknown at this point.

Line 21 in busio.py should have an "elif" statement instead of an "if" statement. Currently, if the board is not a beaglebone_black, the code attempts to execute the last else statement. This creates an error for Raspberry pi boards which do not use the Micropython machine module.

Discovered this issue when trying to install CircuitPython from this tutorial: https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/installing-circuitpython-on-raspberry-pi

def init(self, scl, sda, frequency):
self.deinit()
if board_id == "raspi_3" or board_id == "raspi_2":
from adafruit_blinka.microcontroller.raspi_23.i2c import I2C as _I2C
if board_id == "beaglebone_black":
from adafruit_blinka.microcontroller.raspi_23.i2c import I2C as _I2C
else:
from machine import I2C as _I2C

->>>
def init(self, scl, sda, frequency):
self.deinit()
if board_id == "raspi_3" or board_id == "raspi_2":
from adafruit_blinka.microcontroller.raspi_23.i2c import I2C as _I2C
elif board_id == "beaglebone_black":
from adafruit_blinka.microcontroller.raspi_23.i2c import I2C as _I2C
else:
from machine import I2C as _I2C

Hi,

I followed this tutorial :
(https://learn.adafruit.com/adafruit-neopixel-uberguide/python-circuitpython)

The set up was successful also with adafruit-blinka and everything we can find here :
https://learn.adafruit.com/circuitpython-on-raspberrypi-linux/installing-circuitpython-on-raspberry-pi

`debian@beaglebone:~$ sudo python3
[sudo] password for debian: 
Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> 
>>> 
>>> 
>>> import board
>>> import neopixel
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/neopixel.py", line 34, in <module>
    from neopixel_write import neopixel_write
  File "/usr/local/lib/python3.5/dist-packages/neopixel_write.py", line 19, in <module>
    raise NotImplementedError("Board not supported")
NotImplementedError: Board not supported
>>> `

Debian version (Debian 9.5 2018-10-07 4GB SD IoT from beagleboard website):

`.   debian@beaglebone:~$ cat /etc/*-release
     PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
     NAME="Debian GNU/Linux"
     VERSION_ID="9"
     VERSION="9 (stretch)"
     ID=debian
     HOME_URL="https://www.debian.org/"
     SUPPORT_URL="https://www.debian.org/support"
     BUG_REPORT_URL="https://bugs.debian.org/"`

All the best

Hi everyone,
I am working on a project which consists in putting some colors on my LED. They are quite similar to WS2812 devices but I was thinking about using the neopixel module given. However, it looks like I also need the neopixel_write function imported from the esp module (which I cannot import as well, so I've been looking for the esp.py file which is missing). Thus the neopixel_write function definition is missing and I cannot use it. Does anyone know where I can find it ? I found this : https://github.com/adafruit/Adafruit_Blinka/blob/master/src/neopixel_write.py (I ignore everything above the function definition) but I run my main file, it is not working because the _neopixel is not defined and I have no idea what it stands for.
I am using Atom as IDE and working with a Pycom/Sipy device. Thanks for your help, I can provide you with further information if needed.

Which blinka libraries and functions are working with jetson nano and tx1 ?

I need to use gpio, i2c, and UART. Jetson UART supported with blinka?

How can use this pin definations? https://github.com/adafruit/Adafruit_Blinka/blob/master/src/adafruit_blinka/microcontroller/tegra/t210/pin.py

I coudn't figure about pin definations with 40 pin gpio locations

i would like to test a project written in / for CircuitPython on my (new) PocketBeagle :-)

the Beagle Board Black is already in the system. but the PocketBeagle is not there yet.

Are there any official roadmaps what boards are consider to be added by Adafruit?
or is the concept more 'the community adds what they need' ? (iam totally fine with this concept ;-))

and if the second way is the way to go -
is there any documentation how to do this?
what is needed to add a new Board?
i think

• as the BBB is already supported
• and Adafruit_BBIO also seems to run nicely on PocketBeagle

this 'should be' an easy thing?
only add some good pin-mappings?!

if this is the case iam happy to try to add it ;-)

its that time, where things must be Decided!

uarts in modern OS are kinda special, because they always get attached to a /dev/ttyUSB type device. raspi does have RX/TX pins, they're not often used because they're the console pins too...

im tempted to just make busio.uart be initialized with a path string rather than two pin names. why? because then the example code will be universally usable on mac/linux/windows (!) which means that some devices like fingerprint, gps, bno055, and others with serial i/o will be available on all OSes

BBB does have multiple uarts on pins, so we could also support passing in the RX/TX pin-names but i think that since we have to use paths, we could just stick to only path.

@dhalbert @tannewt & others - thoughts?

Raising this as an issue to provide a place for discussion, although I have a stable workaround for now, it won't be the first time I'm sure.

When attempting to test the adafruit_blinka compatibility layer against the adafruit_gps circuitpython module I found that the gps module relied on circuitpython's differently conformant subset of CPython functions in the time module, not available in the micropython time module.

Given the library imported time directly, it was necessary to monkey-patch a compatible version of time into sys.modules['time'] before running the adafruit_gps import, to try and preserve code-for-code functionality without having to modify the adafruit_gps module itself.

The approach is illustrated by the WIP patch_system() function

Using it requires that the author runs...

import adafruit_blinka
adafruit_blinka.patch_system()

...before attempting to import any library which might depend on the modules patched.

However, it may be preferable to selectively patch named modules (rather than the RAM overhead of attempt to patch everything which modules might later need), or something else entirely. Welcome people's thoughts.

Some devices are output-only or input-only.
Example: https://github.com/adafruit/Adafruit_CircuitPython_TLC59711/blob/master/examples/tlc59711_simpletest.py#L12

Forum user noticed this on RPi: https://forums.adafruit.com/viewtopic.php?f=8&t=139455

@s-light is adding support for PocketBeagle (#100) but could not get SPI to work. The issue is not specific to the PocketBeagle. SPI support is also broken on BeagleBone Black. Both boards have the TI AM3358 processor.

PR #46 added SPI support for the BeagleBone Black (which has a TI AM3358 processor). At that time, I was able to successfully test the BME280 in SPI mode.

However, it now encounters error OSError: [Errno 22] Invalid argument in microcontroller/generic_linux/spi.py:

From Adafruit_Python_BME280, I am testing with bme280_simpletest.py :

import time

import board
import busio
import adafruit_bme280
import digitalio
from adafruit_bus_device import i2c_device, spi_device

# create library object using our Bus SPI port
spi = busio.SPI(board.SCK, board.MOSI, board.MISO)
bme_cs = digitalio.DigitalInOut(board.P9_17)
bme280 = adafruit_bme280.Adafruit_BME280_SPI(spi, bme_cs)

# change this to match the location's pressure (hPa) at sea level
bme280.sea_level_pressure = 1013.25

while True:
    print("\nTemperature: %0.1f C" % bme280.temperature)
    print("Humidity: %0.1f %%" % bme280.humidity)
    print("Pressure: %0.1f hPa" % bme280.pressure)
    print("Altitude = %0.2f meters" % bme280.altitude)
    time.sleep(2)

which results in:

debian@beaglebone:~/Adafruit_CircuitPython_BME280$ sudo python3 examples/bme280_simpletest.py 
Traceback (most recent call last):
  File "examples/bme280_simpletest.py", line 17, in <module>
    bme280 = adafruit_bme280.Adafruit_BME280_SPI(spi, bme_cs)
  File "/usr/local/lib/python3.5/dist-packages/adafruit_bme280.py", line 469, in __init__
    super().__init__()
  File "/usr/local/lib/python3.5/dist-packages/adafruit_bme280.py", line 120, in __init__
    chip_id = self._read_byte(_BME280_REGISTER_CHIPID)
  File "/usr/local/lib/python3.5/dist-packages/adafruit_bme280.py", line 428, in _read_byte
    return self._read_register(register, 1)[0]
  File "/usr/local/lib/python3.5/dist-packages/adafruit_bme280.py", line 474, in _read_register
    spi.write(bytearray([register]))  #pylint: disable=no-member
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.9.dev23+g1d32b1f.d20190410-py3.5.egg/busio.py", line 129, in write
    return self._spi.write(buf, start, end)
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.9.dev23+g1d32b1f.d20190410-py3.5.egg/adafruit_blinka/microcontroller/generic_linux/spi.py", line 44, in write
    self._spi.no_cs = True  # this doesn't work but try anyways
OSError: [Errno 22] Invalid argument

I am trying to use the blinka on an RPI1B.
It identifies it as a 3. Accordingly, the i2c bus is identified as 1, not 0.

platform: 1
version: 3
board_id: raspi_3
Hello blinka!
Digital IO ok!
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", line 20, in __init__
    self._i2c_bus = smbus.SMBus(bus_num)
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_PureIO/smbus.py", line 105, in __init__
    self.open(bus)
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_PureIO/smbus.py", line 130, in open
    self._device = open('/dev/i2c-{0}'.format(bus), 'r+b', buffering=0)
FileNotFoundError: [Errno 2] No such file or directory: '/dev/i2c-1'

+------------------| |--| |------+
| ooooooooooooo P1 |C|  |A|      |
| 1oooooooooooo    +-+  +-+      |
|                                |
|                +---+          +====
|                |SoC|          | USB
|   |D| Pi Model +---+          +====
|   |S| B  V1.0                  |
|   |I|                  |C|+======
|                        |S||   Net
|                        |I|+======
=pwr             |HDMI|          |
+----------------|    |----------+

Revision           : 0002
SoC                : BCM2835
RAM                : 256Mb
Storage            : SD
USB ports          : 2 (excluding power)
Ethernet ports     : 1
Wi-fi              : False
Bluetooth          : False
Camera ports (CSI) : 1
Display ports (DSI): 1

P1:
   3V3  (1) (2)  5V    
 GPIO0  (3) (4)  5V    
 GPIO1  (5) (6)  GND   
 GPIO4  (7) (8)  GPIO14
   GND  (9) (10) GPIO15
GPIO17 (11) (12) GPIO18
GPIO21 (13) (14) GND   
GPIO22 (15) (16) GPIO23
   3V3 (17) (18) GPIO24
GPIO10 (19) (20) GND   
 GPIO9 (21) (22) GPIO25
GPIO11 (23) (24) GPIO8 
   GND (25) (26) GPIO7 

For Python control of TFTs and OLEDs via CircuitPython libraries.

there's limited SPI ports on the Pi, and some chips dont need high speed, lets add code for (fast) bitbang support!

This is an invitation for @tannewt and others to comment on any compatibility issues they observe from examining the https://github.com/adafruit/Adafruit_Micropython_Blinka repo, or indeed assertions they feel should be documented permanently in the form of tests.

So far, the testing framework has been minimally populated with integration tests checking that whole 'applications' can be made to run.

The aim of this issue thread is to be able to comment briefly on lower-granularity issues between the real and Blinka-simulated CircuitPython API, so that (passing or failing) test cases can be authored to improve conformance or prevent regression.

These will typically show up as a method in a new or existing unittest.TestCase class e.g. under https://github.com/adafruit/Adafruit_Micropython_Blinka/tree/master/test/src/testing/universal

This issue effects boards with the AM3358 chip such as BeagleBone and PocketBeagle. It was discovered while testing #100.

The index in the spidev path can be inconsistent between kernel builds. This means that sometimes SPI0 is /dev/spidev0.x and sometimes SPI0 is /dev/spidev1.x

For example, SPI0 is /dev/spidev1.0 when using the 4.14.108-ti-r103 kernel:

debian@beaglebone:~$ ls -ltar /dev/spidev*
crw-rw---- 1 root spi 153, 0 Apr 12 17:42 /dev/spidev1.0
crw-rw---- 1 root spi 153, 1 Apr 12 17:42 /dev/spidev2.0
crw-rw---- 1 root spi 153, 2 Apr 12 17:42 /dev/spidev2.1

However, SPI0 is /dev/spidev0.0 when using the 4.14.106-bone20 kernel:

debian@beaglebone:~$ ls -la /dev/spidev*
crw-rw---- 1 root spi 153, 0 Apr 13 13:35 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 Apr 13 13:35 /dev/spidev1.0
crw-rw---- 1 root spi 153, 2 Apr 13 13:35 /dev/spidev1.1

adafruit_blinka.microcontroller.bcm283x.pulseio is missing from the package on PyPI.

__init__.py is missing from adafruit_blinka/microcontroller/bcm283x/pulseio so setuptools.find_packages("src") does not find the package.

Additionally, special handling is needed for the libgpiod_pulsein program since it is not python code.

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

Hello,

I just wanted to try to get the Adafruit DC Motor Hat working on my raspberry pi B+. After installing everything I got a "Board not supported" exception though. The output from motor-test.py, blinkatest.py as well as detect.py are:

pi@raspberrypi:~ $ python3 motor-test.py 
Traceback (most recent call last):
  File "motor-test.py", line 3, in <module>
    from adafruit_motorkit import MotorKit
  File "/usr/local/lib/python3.5/dist-packages/adafruit_motorkit.py", line 59, in <module>
    import board
  File "/home/pi/.local/lib/python3.5/site-packages/board.py", line 68, in <module>
    raise NotImplementedError("Board not supported")
NotImplementedError: Board not supported

pi@raspberrypi:~ $ python3 blinkatest.py 
Traceback (most recent call last):
  File "blinkatest.py", line 1, in <module>
    import board
  File "/home/pi/.local/lib/python3.5/site-packages/board.py", line 68, in <module>
    raise NotImplementedError("Board not supported")
NotImplementedError: Board not supported

pi@raspberrypi:~ $ python3 detect.py 
Chip id:  BCM2XXX
Board id:  None
Is this a Pi 3B+? False
Is this a 40-pin Raspberry Pi? False
Is this a BBB? False
Is this an Orange Pi PC? False
Is this a Giant Board? False
Is this an embedded Linux system? True
Is this a generic Linux PC? False
Raspberry Pi detected.

I found these two issues which basically had the same issue:
#53
#66

The last post from issue #66 says that it should be fixed with 1.10. Therefore I looked what version I have. And i do have those:

Adafruit-Blinka==1.2.4
Adafruit-PlatformDetect==0.0.10

Anything I could try to get it working? Any help would be appreciated. Thanks.

In this issue, I would like to propose how bitbangio and busio should map into underlying hardware and software interfaces on Micropython-flashed mcus.

I propose that busio only proceeds without error when there is hardware accelerated backing to the pin choices made in the constructor, while bitbangio only proceeds when there is a capability for software implementations to be run. In either case if the platform or pin choices don't allow the corresponding implementation to be spun up, then an error should be raised.

This implies some fairly detailed mapping of pin choices to underlying hardware capabilities through platform introspection, but seems one of the few consistent ways of managing the wrapping.

There is an option for bitbangio to seamlessly ignore when it is opportunistically using hardware-backed io, rather than raising an Error, but to do this, it will end up just replicating the behaviour already in busio, largely undermining the separation, so I don't think this is ideal.

Substituting a software-bitbang I2C or SPI for a requested hardware-accelerated implementation definitely seems wrong otherwise what is the point of the package separation?

UART or other unclocked high-throughput interface, is going to be busio-only on e.g. an ESP8266 platform because of interrupts making a software implementation infeasible.

When trying to control two WS2812 strips with AdaFruit_NeoPixel on two separate PWM GPIOs (Board.D13 and Board.D18) I get the following RuntimeError:

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "na.py", line 1287, in exit_handler
led_strip.shutdown()
File "na.py", line 891, in shutdown
self.color_wipe(LED.color(0, 0, 0))
File "na.py", line 934, in color_wipe
self.pixels2.show()
File "/usr/local/lib/python3.5/dist-packages/neopixel.py", line 230, in show
neopixel_write(self.pin, self.buf)
File "/usr/local/lib/python3.5/dist-packages/neopixel_write.py", line 24, in neopixel_write
return _neopixel.neopixel_write(gpio, buf)
File "/usr/local/lib/python3.5/dist-packages/adafruit_blinka/microcontroller/bcm283x/neopixel.py", line 70, in neopixel_write
raise RuntimeError("Raspberry Pi neopixel support is for one strip only!")
RuntimeError: Raspberry Pi neopixel support is for one strip only!
swig/python detected a memory leak of type 'ws2811_t *', no destructor found.

Here is how I initialize:

pixels1 = neopixel.NeoPixel(
    board.D18, LED.LED_COUNT, brightness=1, auto_write=False, pixel_order=neopixel.GRB)
pixels2 = neopixel.NeoPixel(
    board.D13, LED.LED_COUNT, brightness=1, auto_write=False, pixel_order=neopixel.GRB)

RuntimeErrors are thrown whenever I call this:

pixels1.fill(color)
pixels1.show()
pixels2.fill(color)
pixels2.show()

Is there a reason only one strip is supported?

https://github.com/adafruit/Adafruit_Python_PureIO/blob/master/README.md

Also it is not marked as a dependency for pip3.

Hi, I'm testing Blinka on a BBB, and I have this problem when trying to use User Leds

debian@beaglebone:/var/lib/cloud9/python$ sudo python3 blinka_blink.py
hello blinky!
Traceback (most recent call last):
  File "blinka_blink.py", line 9, in <module>
    led = digitalio.DigitalInOut(board.LED_USR1)
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.7.dev3+g5d33134-py3.5.egg/digitalio.py", line 67, in __init__
    self.direction = Direction.INPUT
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.7.dev3+g5d33134-py3.5.egg/digitalio.py", line 93, in direction
    self._pin.init(mode=Pin.IN)
  File "/usr/local/lib/python3.5/dist-packages/Adafruit_Blinka-1.2.7.dev3+g5d33134-py3.5.egg/adafruit_blinka/microcontroller/am335x/pin.py", line 30, in init
    GPIO.setup(self.id, GPIO.IN)
ValueError: Set gpio mode failed, missing file or invalid permissions.

Thank you for your attention

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

It would be useful to know what the name of a project to wrap Micropython in CircuitPython-style API calls should be called.

Currently I have an mcp package (Micropython+CircuitPython) largely thanks to Tron (see e.g. https://www.youtube.com/watch?v=SmXt6Q6jU_Y + https://youtu.be/AvayPCoHGFE?t=26s ) which can be a place to hide wrapper/port specific stuff.

However, it would be useful to know what the Long and Short project name should be, as it will creep into repositories and package names which are inevitably visible and needing to be managed when people put packages onto Micropython boards.

When using the i2c-gpio overlay with default settings, it will be given bus number 3 and the SDA/SCL pins will be on 23 and 24:

pi@raspberrypi:~ $ dmesg | grep i2c
[    3.907573] i2c /dev entries driver
[    8.113216] i2c-gpio i2c@0: using pins 23 (SDA) and 24 (SCL)
pi@raspberrypi:~ $ ls /dev/i2c*
/dev/i2c-1  /dev/i2c-3

(i2c-1 is the hardware i2c port)

To allow use of this feature, need to add an entry to i2cPorts so the i2c bus can be created using those pins:

i2c = busio.I2C(board.D24, board.D23)

The overlay allows for assigning the bus number and pins when enabling it in /boot/config.txt. But I'm not sure how non-default settings could be handled. The blinka constructor has no concept of bus number, so it all keys off the pins.

For the experimental support of H3 (and so H2+ and H5) devices, the bus peripherals and UARTS can be anything from the SoC, and there are numerous non-pi form factor boards. It makes more sense to me to set the UART/SPI/I2C in the specific board files, leaving the pin definition to define only the pin names.

It would be nice to see some example code of raspberry pi interfacing with circuit playground express.

I really like what you guys do at adafruit. I am building a full AI robot using the raspberry pi for all the heavy stuff like speech and image recognition, files ect and I plan on using several circuit playground express for lots of sensor input and specific control. I am using an arduino for motor control, and general movement decisions. Circuitpython looks like the way to make it all work together.

I have not done it yet but it looks like with circuitpython on the pi I should be able to communicate and control the arduino and circuit playground express via ic2 instead of my original usb approach.

I'm using BCM.GPIO mode in my application because it is easier to map to the real pins on the Raspberry Pi. Since I upgraded to CircuitPython and use busio.I2C, it seems I'm forced to use BCM mode.

I would expect that the library do not call setmode() but rather adapt to the user preference based on the result of getmode().

I haven't seen any documentation related to BCM vs GPIO modes when using this library. What should be the strategy? Do you expect people to always use BCM? Or am I missing something? I would expect most people use GPIO since it is way easier to transfer to the real hardware than with BCM (where you always need to look back at the schematics).

I was working through https://learn.adafruit.com/neopixels-on-raspberry-pi/python-usage, adding https://learn.adafruit.com/circuitpython-essentials/circuitpython-neopix to understand how to add the W component (using bpp=4), with a Raspberry Pi Zero W and the RGBW Neopixel strip.

It didn't seem to work correctly. The result of this script:

import board
import neopixel
pixels = neopixel.NeoPixel(board.D18, 20, bpp=4, auto_write=False)
pixels.fill((255, 0, 0, 0))
pixels.write()

was a repeating pattern of red, blue, unlit, green down the strip. I expected them to all be red (or at least all the same color.)

I took a look at the code and eventually got to 1f9263a, which implies RGBW is supported, but it didn't appear the W bits were being shifted in for the call to ws.ws2811_led_set, which would explain the behavior I saw.

RPi.GPIO and Adafruit_BBIO both use the legacy /sys interface for the Linux kernel GPIO subsystem.

libgpiod is a userspace library by @brgl that use the new character device based interface for Linux kernel GPIO subsystem.

The sysfs interface for GPIO is marked as deprecated in the Linux kernel, so I believe this Blinka library should migrate to the libgpiod Python bindings.

View Adafruit_BBIO issue #157 for more information on the character device interface in the Linux kernel.

cc @brennen

Just a heads up - I had no problems installing on a RPI 3B+ running latest version of "stretch"
When I tried to install on an updated RPi Zerow running "Jessie" it failed with

pi@gjnpi0-1:~ $ pip3 install adafruit-blinka
Downloading/unpacking adafruit-blinka
  Downloading Adafruit-Blinka-0.1.7.tar.gz
  Running setup.py (path:/tmp/pip-build-epf581_d/adafruit-blinka/setup.py) egg_info for package adafruit-blinka
    /usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'long_description_content_type'
      warnings.warn(msg)
    /usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'python_requires'
      warnings.warn(msg)
    Traceback (most recent call last):
      File "<string>", line 17, in <module>
      File "/tmp/pip-build-epf581_d/adafruit-blinka/setup.py", line 44, in <module>
        'Programming Language :: Python :: Implementation :: MicroPython',
      File "/usr/lib/python3.4/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 266, in __init__
        _Distribution.__init__(self,attrs)
      File "/usr/lib/python3.4/distutils/dist.py", line 280, in __init__
        self.finalize_options()
      File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 301, in finalize_options
        ep.load()(self, ep.name, value)
      File "/tmp/pip-build-epf581_d/adafruit-blinka/setuptools_scm-2.1.0-py3.4.egg/setuptools_scm/integration.py", line 10, in version_keyword
      File "/tmp/pip-build-epf581_d/adafruit-blinka/setuptools_scm-2.1.0-py3.4.egg/setuptools_scm/version.py", line 44, in _warn_if_setuptools_outdated
    setuptools_scm.version.SetuptoolsOutdatedWarning: your setuptools is too old (<12)
    Complete output from command python setup.py egg_info:
    /usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'long_description_content_type'

  warnings.warn(msg)

/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'python_requires'

  warnings.warn(msg)

Traceback (most recent call last):

  File "<string>", line 17, in <module>

  File "/tmp/pip-build-epf581_d/adafruit-blinka/setup.py", line 44, in <module>

    'Programming Language :: Python :: Implementation :: MicroPython',

  File "/usr/lib/python3.4/distutils/core.py", line 108, in setup

    _setup_distribution = dist = klass(attrs)

  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 266, in __init__

    _Distribution.__init__(self,attrs)

  File "/usr/lib/python3.4/distutils/dist.py", line 280, in __init__

    self.finalize_options()

  File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 301, in finalize_options

    ep.load()(self, ep.name, value)

  File "/tmp/pip-build-epf581_d/adafruit-blinka/setuptools_scm-2.1.0-py3.4.egg/setuptools_scm/integration.py", line 10, in version_keyword

  File "/tmp/pip-build-epf581_d/adafruit-blinka/setuptools_scm-2.1.0-py3.4.egg/setuptools_scm/version.py", line 44, in _warn_if_setuptools_outdated

setuptools_scm.version.SetuptoolsOutdatedWarning: your setuptools is too old (<12)

----------------------------------------
Cleaning up...
Command python setup.py egg_info failed with error code 1 in /tmp/pip-build-epf581_d/adafruit-blinka
Storing debug log for failure in /home/pi/.pip/pip.log

Not sure i I'm just missing something or if it is a problem with "Jessie"
I tried

pip3 install --upgrade adafruit-blinka

and it failed the same way.

I upgraded to adafruit-blinks 0.2.4 and tried to access some neopixels, but it is not finding neopixel_write. Am I missing something?

pi@gjnpi3p-1:~/projects/blinka $ python3.6
Python 3.6.5 (default, Jul 14 2018, 16:24:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import neopixel
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/site-packages/neopixel.py", line 34, in <module>
    from neopixel_write import neopixel_write
ModuleNotFoundError: No module named 'neopixel_write'
>>> 

Here is what is installed

pi@gjnpi3p-1:~/projects/blinka $ pip3 list
Package                          Version  
-------------------------------- ---------
Adafruit-Blinka                  0.2.4    
Adafruit-BME280                  1.0.1    
adafruit-circuitpython-bme280    2.1.0    
adafruit-circuitpython-busdevice 2.2.5    
adafruit-circuitpython-neopixel  3.3.1    
adafruit-circuitpython-rfm9x     1.1.1    
Adafruit-GPIO                    1.0.3    
adafruit-io                      2.0.15   
Adafruit-PureIO                  0.2.3    
certifi                          2018.4.16
chardet                          3.0.4    
idna                             2.7      
paho-mqtt                        1.3.1    
pip                              18.0     
requests                         2.19.1   
RPi.GPIO                         0.6.3    
setuptools                       39.0.1   
spidev                           3.2      
urllib3                          1.23     
pi@gjnpi3p-1:~/projects/blinka $ 

Not 100% sure this is a blinka issue, but starting here. Something about blinka's I2C w/ Seesaw? No issue on a Metro w/ CP.

Re this thread:
https://forums.adafruit.com/viewtopic.php?f=19&t=146478

SETUP A
Raspberry Pi Zero W + STEMMA Soil Sensor
Sensor stuck in a pot of wet dirt
Python3 + blinka + CP libs
Readings are an average of 10 samples taken 1 second apart

Occasional spurious readings (~4000+) for moisture (time, moisture, temperature):

02-07-19 17:35:21 732.1 20.221553236590005
02-07-19 17:35:41 737.5 20.414848409874004
02-07-19 17:36:01 4038.4 20.307240441558
02-07-19 17:36:21 748.1 20.446733156562004
02-07-19 17:36:42 764.7 20.133870183198006
02-07-19 17:37:02 750.4 20.371672165986002
02-07-19 17:37:22 756.5 20.339123662368003
02-07-19 17:37:42 787.6 20.307240441558
02-07-19 17:38:02 761.6 20.403558438552
02-07-19 17:38:22 780.7 20.285319678210005
02-07-19 17:38:42 769.8 20.339125188245998
02-07-19 17:39:03 759.5 20.285984961018
02-07-19 17:39:23 4038.7 20.177046427086005
02-07-19 17:39:43 778.2 20.327830639290006
02-07-19 17:40:03 738.0 20.220222670974
02-07-19 17:40:23 761.5 20.381634623448

SETUP B
Metro M4 Express + STEMMA Soil Sensor
Sensor stuck in a pot of wet dirt
CP 3.1.2 + CP libs
Readings are an average of 10 samples taken 1 second apart

No spurious readings (time, moisture, temperature):

3676.87 614.3 25.3833
3696.92 614.0 25.1091
3716.97 613.4 24.9887
3737.02 614.0 24.8256
3757.07 614.4 24.8051
3777.12 614.2 24.6203
3797.17 614.5 24.6612
3817.22 614.4 24.5998
3837.27 613.7 24.5298
3857.32 614.1 24.4789
3877.37 613.8 24.5899
3897.42 614.0 24.4987
3917.47 613.7 24.3778
3937.52 613.8 24.4386
3957.57 614.1 24.3784
3977.62 614.6 24.4479
3997.67 614.4 24.4485
4017.72 614.8 24.3976
4037.77 614.7 24.4082

Using the RPi.GPIO library (https://github.com/adafruit/Adafruit_Blinka/blob/master/src/adafruit_blinka/microcontroller/raspi_23/pin.py#L1), we could add PWM functionality similar to PWMOut (https://circuitpython.readthedocs.io/en/2.x/shared-bindings/pulseio/PWMOut.html) for the Raspberry Pi.

Initialization:

pwm = GPIO.PWM(pin, frequency)
pwm.start(duty_cycle) 

variable_frequency -> ChangeFrequency
ChangeDutyCycle -> duty_cycle

• example of the RPi.GPIO PWM https://sourceforge.net/p/raspberry-gpio-python/wiki/PWM/

We ran into an interesting issue when using an lsm9ds1 and an rfm9x on a RaspBerry Pi
Both boards worked fine individually but when run together, the first sesor reading from the lsm9ds1 AFTER any communication with the rfm9x was corrupted.

There is a lengthy forum discussion
https://forums.adafruit.com/viewtopic.php?f=50&t=143689&start=30#p71264

I also ran the same test on a feather_m4 express and did not see the same behavior

I wonder if it is related to the difference in SPI mode (polarity and phase) being used on the rfm9x vs lsm9ds1.
Is there some problem with the transition between the modes. It only appears to impact the lsm9ds1, the rfm9x appears to be operating normally, but there is a lot more traffic to the rfm9x and it is possible that a bad command may not be immediately apparent.

The issue is not present if the I2C interface to the lsm9ds1 is used.

I'll try to get some cleaner examples of the issue but wanted to post this so you are aware of it.

Running the following code

`Simple test for a standard servo on channel 0 and a continuous rotation servo on channel 1.
import time
from adafruit_servokit import ServoKit

kit = ServoKit(channels=8)

kit.servo[0].angle = 180
kit.continuous_servo[1].throttle = 1
time.sleep(1)
kit.continuous_servo[1].throttle = -1
time.sleep(1)
kit.servo[0].angle = 0
kit.continuous_servo[1].throttle = 0`

Getting the error
"AttributeError: module 'board has no attribute 'I2C'

I followed the instructions from here: https://learn.adafruit.com/adafruit-16-channel-pwm-servo-hat-for-raspberry-pi/overview

Running the file on Raspberry Pi 3B
It seems like it may be an issue in the 40 pin file?

Currently, busio.UART just tries to import from machine in __init__ regardless of host:

from machine import UART as _UART

which will throw an exception on RPi and other linuxes. But the exception is not very user friendly.

ImportError: No module named 'machine'

How about adding a conditional similar to SPI and I2C to check for any_embedded_linux and throw a different exception with more useful information. Something like:

if detector.board.any_embedded_linux:
    raise NotImplementedError("not supported, use pyserial")
else:
    from machine import SPI as _SPI

@ladyada - a few Blinka notes, first of all - it is great! - I found that I can try CP modules without waiting for them to be released in PyPi just by putting the driver under test in the local folder with the test code. I did this with the mcp9808, apds996 and the rfm9x (with changes as noted below).
I have been trying out the rfm9x driver under blinka and had to make a few changes, but it is now working - the main change was I had to revise several of the spi readinto/write calls because they used "end=" and that is not supported via blinka. The changes were pretty simple and it all seems to be woking. I can send/receive from my RPi to a feather M0 express with CP 3.0.
Is the "end=" keyword "non-standard" and not going to be available on the RPi. Would you like me to submit a PR to remove it from the existing rfm9x driver for CP to keep them compatible?

Have you run into this with other drivers? I'm not sure how widespread the use of end= is in the CP drivers.

There's a fundamental contrast in the build flags between CircuitPython and Micropython seen here...

At https://github.com/micropython/micropython/blob/6e675c1baaf0de0d56a2345376d6b5600bfab3aa/py/mpconfig.h the default is set, which applies to official pyboard and esp8266 builds.

// Whether to support descriptors (__get__ and __set__)
// This costs some code size and makes all load attrs and store attrs slow
#ifndef MICROPY_PY_DESCRIPTORS
#define MICROPY_PY_DESCRIPTORS (0)
#endif

Versus the build flags for esp8266 and atmel-samd in CircuitPython

cefn@cefn-artful-thinkpad:~/Documents/shrimping/clients/adafruit/git/circuitpython-latest$ grep -rin MICROPY_PY_DESCRIPTORS .
./ports/atmel-samd/mpconfigport.h:56:#define MICROPY_PY_DESCRIPTORS      (1)
./ports/esp8266/mpconfigport.h:43:#define MICROPY_PY_DESCRIPTORS      (1)

While perhaps an average user wouldn't be reliant on descriptors, some libraries use them or encourage their use, for example adafruit_register fundamentally depends on descriptors, meaning that e.g. the BNO055 library and RFM69 libraries intended to be used in #2 cannot be made to work seamlessly on Micropython simply by making compatible I2C or SPI objects available.

The list of libraries affected in this way includes at least...

• adafruit_register
• adafruit_bno055
• adafruit_tlc59711
• adafruit_rfm69.py
• adafruit_thermal_printer

This list is based on searching for libraries using __get__() or __set__() within the Adafruit CircuitPython Bundle.

Since it doesn't trigger a load-time error, it may be feasible to monkey-patch classes such as BNO055 with property accessors to hide the descriptor logic, a step performed before using any of the constructors. However, this step would have to be explicit in any Micropython-hosted use of said CircuitPython libraries, or a separate bundle could be distributed in which descriptor logic has been substituted.

people have requested another linux device to support!