There's a few oddities when running Blinka/CircuitPython on linux. Here's a list of stuff to watch for that we know of!
This FAQ covers all the various platforms and hardware setups you can run Blinka on. Therefore, some of the information may not apply to your specific setup.
Most issues can be solved by forcing Python to upgrade to the latest
platform-detect libraries. Try running
sudo python3 -m pip install --upgrade --force-reinstall adafruit-blinka Adafruit-PlatformDetect
Somehow you have ended up with either the wrong board module or no board module at all.
DO NOT try to fix this by manually installing a library named
board. There is one out there and it has nothing to do with Blinka. You will break things if you install that library!
The easiest way to recover is to simply force a reinstall of Blinka with:
python3 -m pip install --upgrade --force-reinstall adafruit-blinka
Due to the way we share an SPI peripheral, you cannot have two SPI devices with different 'mode/polarity' on the same SPI bus - you'll get weird data
95% of SPI devices are mode 0, check the driver to see mode or polarity settings. For example:
To check what version of spidev Python is using:
Python 3.6.8 (default, Oct 7 2019, 12:59:55)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import spidev
If you see a version lower then 3.4 reported, then try a force upgrade of spidev with (back at command line):
sudo python3 -m pip install --upgrade --force-reinstall spidev
Some linux boards, for example, AllWinner-based, do not have support to set pull up or pull down on their GPIO. Use an external resistor instead!
If you are getting a stack trace that ends with something like:
File "hid.pyx", line 122, in hid.device.read
OSError: read error
Try setting an environment variable named BLINKA_MCP2221_RESET_DELAY to a value of 0.5 or higher.
This is a value in seconds to wait between resetting the MCP2221 and the attempt to reopen it. The reset is seen by the operating system as a hardware disconnect/reconnect. Different operating systems can need different amounts of time to wait after the reconnect before the attempt to reopen. Setting the above environment variable will override the default reset delay time, allowing it to be increased as needed for different setups.
Blinka uses the libusbk driver to talk to the FT232H directly. If you have other FTDI devices installed that are using the FTDI VCP drivers, you may run into issues. See here for a possible workaround:
Some CircuitPython modules like may not be supported.
- Most SBCs do not have analog inputs so there is no
- Few SBCs have
neopixelsupport so that is only available on Raspberry Pi (and any others that have low level neopixel protocol writing
- Rotary encoders (
rotaryio) is handled by interrupts on microcontrollers, and is not supported on SBCs at this time
pulseioPWM support is not supported on many SBCs, and if it is, it will not support a carrier wave (Infrared transmission)
- For display usage, we suggest using python
Pygame, we do not have
We aim to have, at a minimum,
busio (I2C/SPI). This lets you use the vast number of driver libraries
Some libraries, like Adafruit_CircuitPython_DHT will try to bit-bang if pulsein isn't available. Slow linux boards (<700MHz) may not be able to read the pins fast enough), you'll just have to try!
It looks like libgpiod may not be installed on your board.
Try running the command:
sudo apt-get install libgpiod2
Be sure you have the latest libgpiod.sh script and run it with the
All Raspberry Pi Computers Have:
Google Coral TPU Dev Boards Have:
Orange Pi PC Plus Boards Have:
Orange Pi R1 Boards Have:
Odroid C2 Boards Have:
DragonBoard 410c Boards Have:
NVIDIA Jetson Nano Boards Have:
FT232H Breakouts Have:
If you are using Blinka in FT232H mode, then keep in mind these basic limitations.
MCP2221 Breakouts Have:
If you are using Blinka in MCP2221 mode, then keep in mind these basic limitations.