{"id":1207,"date":"2021-11-23T19:23:31","date_gmt":"2021-11-23T19:23:31","guid":{"rendered":"https:\/\/picockpit.com\/raspberry-pi\/?p=1207"},"modified":"2023-09-19T14:37:58","modified_gmt":"2023-09-19T14:37:58","slug":"circuitpython-adafruit-feather-rp2040-and-i2c","status":"publish","type":"post","link":"https:\/\/picockpit.com\/raspberry-pi\/es\/circuitpython-adafruit-feather-rp2040-y-i2c\/","title":{"rendered":"CircuitPython, Adafruit Feather RP2040 e I2C"},"content":{"rendered":"\n

As you probably guessed by the title, this article discusses CircuitPython, the Adafruit Feather RP2040, and the I2C communication protocol.<\/p>\n\n\n\n

The RP2040 has two I2C controllers – good for example, when you want to run two I2C devices with the same I2C address. <\/p>\n\n\n\n

In my test setup, I have an Adafruit Feather RP2040 microcontroller board, and have attached two of our BME688 breakout boards<\/a> – one using the pins SCL + SDA and one using A1 (for SCL) + A0 (for SDA).<\/p>\n\n\n\n

I am using CircuitPython in version 7.0.0, which you can download from here<\/a>.<\/p>\n\n\n\n

Furthermore, I’ve installed all of Adafruit’s libraries to the lib <\/strong>folder on the Feather RP2040. (The Feather RP2040 has enough space on it’s Flash to enable this)<\/p>\n\n\n\n

You can download these libraries in the Adafruit CircuitPython Bundle here<\/a>. (I downloaded adafruit-circuitpython-bundle-7.x-mpy-20211123.zip<\/a>)<\/p>\n\n\n\n

<\/p>\n\n\n

\n
\"\"<\/figure>\n<\/div>\n\n\n

Note<\/strong>: to install these libraries simply copy them to the lib folder on the CIRCUITPY “drive” which is mounted on your computer. You will of course have to copy only the libraries, not the examples and other stuff.<\/p>\n\n\n\n

The big advantage in using Adafruit’s stuff is that you get a ton of examples which cover many popular chips, and you can very easily start with it. There are things like driving a microSD card using SPI, reading an RTC, and reading from the BME680 sensor. <\/p>\n\n\n\n

Testing I2C in CircuitPython<\/h2>\n\n\n\n

I’ve got the following setup, as I want to drive two devices independently of each other (which happen to have the same addresses in this case):<\/p>\n\n\n

\n
\"\"
Feather RP2040 and two BME688 breakout boards<\/a><\/figcaption><\/figure>\n<\/div>\n\n\n

Note that our BME688 breakout boards already include Pullups for SDA and SCL. (You need pullups on SDA and SCL).<\/p>\n\n\n\n

Note 2: Our BME688 breakout board has the option to change the address, so this scenario is meant for demonstration purposes. <\/p>\n\n\n\n

In order to drive through both pin sets sequentially (to discover the devices), I’m using the following code:<\/p>\n\n\n\n

<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
print<\/span>(<\/span>"<\/span>Scanning SCL \/ SDA<\/span>"<\/span>)<\/span><\/span>\ni2c<\/span> <\/span>=<\/span> <\/span>busio<\/span>.<\/span>I2C<\/span>(<\/span>board<\/span>.<\/span>SCL<\/span>,<\/span> <\/span>board<\/span>.<\/span>SDA<\/span>)<\/span><\/span>\n# <\/span>a<\/span> <\/span>scan<\/span><\/span>\ni2c<\/span>.<\/span>try_lock<\/span>()<\/span><\/span>\nprint<\/span>(<\/span>i2c<\/span>.<\/span>scan<\/span>())<\/span><\/span>\ni2c<\/span>.<\/span>unlock<\/span>()<\/span><\/span>\ni2c<\/span>.<\/span>deinit<\/span>()<\/span><\/span>\n<\/span>\nprint<\/span>(<\/span>"<\/span>Scanning A0 \/ A1<\/span>"<\/span>)<\/span><\/span>\nsi2c<\/span> <\/span>=<\/span> <\/span>busio<\/span>.<\/span>I2C<\/span>(<\/span>board<\/span>.<\/span>A1<\/span>,<\/span> <\/span>board<\/span>.<\/span>A0<\/span>)<\/span><\/span>\n# <\/span>a<\/span> <\/span>scan<\/span><\/span>\nsi2c<\/span>.<\/span>try_lock<\/span>()<\/span><\/span>\nprint<\/span>(<\/span>si2c<\/span>.<\/span>scan<\/span>())<\/span><\/span>\nsi2c<\/span>.<\/span>unlock<\/span>()<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
<\/p>\n\n\n\n
Note: the i2c.deinit()<\/strong> is key to this particular example working! (because SCL \/ SDA and A0 \/ A1 have both the same hardware I2C peripheral – see below).<\/p>\n\n\n\n
This should output the following:<\/p>\n\n\n\n
<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
Scanning<\/span> <\/span>SCL<\/span> <\/span>\/<\/span> <\/span>SDA<\/span><\/span>\n[<\/span>119<\/span>]<\/span><\/span>\nScanning<\/span> <\/span>A0<\/span> <\/span>\/<\/span> <\/span>A1<\/span><\/span>\n[<\/span>119<\/span>]<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
<\/p>\n\n\n\n
Both boards are seen, sequentially in the individual scans. <\/p>\n\n\n\n
The problem is that we want to use them simultaneously.<\/p>\n\n\n\n
Running two I2C buses simultaneously on the Adafruit Feather RP2040<\/h2>\n\n\n\n
CircuitPython supports both <\/strong>hardware controllers (SDA0\/SCL0 and SDA1\/SCL1). You do not need to set any configuration (which controller you want to use, or how to mux the pins) – this is taken care of by busio <\/strong>for you.<\/p>\n\n\n\n
You need to pay attention, though, which pins you use, as the pins will provide only one <\/strong>of these buses in each case, and if you happen to choose conflicting pins, you will get  ValueError: I2C peripheral in use <\/em>.<\/p>\n\n\n
\n
\"\"
Adafruit Feather RP2040 Pinout<\/a><\/figcaption><\/figure>\n<\/div>\n\n\n
If you want to use “conflicting” pins, fo rexample SCL \/ SDA (which have SCL1 and SDA1) and A0 \/ A1 (which also have SCL1 and SDA1), you will need to bitbang one of the ports: <\/p>\n\n\n\n
Here’s how to scan this pin configuration without calling deinit():<\/p>\n\n\n\n
<\/circle><\/circle><\/circle><\/g><\/svg><\/span><\/path><\/path><\/svg><\/span>
import<\/span> <\/span>board<\/span><\/span>\nimport<\/span> <\/span>busio<\/span><\/span>\nimport<\/span> <\/span>bitbangio<\/span><\/span>\n# <\/span>https<\/span>:<\/span>\/\/circuitpython.readthedocs.io\/en\/latest\/shared-bindings\/bitbangio\/index.html<\/span><\/span>\n<\/span>\nprint<\/span>(<\/span>"<\/span>Scanning SCL \/ SDA - main I2C<\/span>"<\/span>)<\/span><\/span>\ni2c<\/span> = <\/span>busio<\/span>.<\/span>I2C<\/span>(<\/span>board<\/span>.<\/span>SCL<\/span>,<\/span> <\/span>board<\/span>.<\/span>SDA<\/span>)<\/span><\/span>\n# <\/span>a<\/span> <\/span>scan<\/span><\/span>\ni2c<\/span>.<\/span>try_lock<\/span>()<\/span><\/span>\nprint<\/span>(<\/span>i2c<\/span>.<\/span>scan<\/span>())<\/span><\/span>\ni2c<\/span>.<\/span>unlock<\/span>()<\/span><\/span>\n# <\/span>no<\/span> <\/span>need<\/span> <\/span>to<\/span> <\/span>call<\/span> <\/span>deinit<\/span> <\/span>here<\/span>!<\/span><\/span>\n#<\/span>i2c<\/span>.<\/span>deinit<\/span>()<\/span><\/span>\n<\/span>\nprint<\/span>(<\/span>"<\/span>Scanning A0 \/ A1 - secondary I2C [bitbang!]<\/span>"<\/span>)<\/span><\/span>\nsi2c<\/span> = <\/span>bitbangio<\/span>.<\/span>I2C<\/span>(<\/span>board<\/span>.<\/span>A1<\/span>,<\/span> <\/span>board<\/span>.<\/span>A0<\/span>)<\/span><\/span>\n# <\/span>a<\/span> <\/span>scan<\/span><\/span>\nsi2c<\/span>.<\/span>try_lock<\/span>()<\/span><\/span>\nprint<\/span>(<\/span>si2c<\/span>.<\/span>scan<\/span>())<\/span><\/span>\nsi2c<\/span>.<\/span>unlock<\/span>()<\/span><\/span>\n<\/span>\n# <\/span>we<\/span> <\/span>also<\/span> <\/span>do<\/span> <\/span>not<\/span> <\/span>need<\/span> <\/span>to<\/span> <\/span>call<\/span> <\/span>deinit<\/span> <\/span>here<\/span><\/span>\n#<\/span>i2c<\/span>.<\/span>deinit<\/span>()<\/span><\/span><\/code><\/pre><\/div>\n\n\n\n
<\/p>\n\n\n\n
We are using bitbangio <\/strong>to drive a secondary I2C. In my case the secondary I2C is used for an internal purpose (for a port expander), and quite likely can do with a lower interface speed. <\/p>\n\n\n\n
Note: you are not able to choose the I2C peripheral which is routed to the pins in software – if you need a different peripheral, you need to use different pins. <\/p>\n\n\n\n
Troubleshooting I2C errors<\/h2>\n\n\n\n
ValueError: I2C peripheral in use<\/h3>\n\n\n\n
If you are using busio.I2C for both ports: Check if you are already using the same hardware I2C peripheral – and whether you need to reassign your pins.<\/p>\n\n\n\n
For example, both SCL and SDA , and A0 and A1 share the same hardware I2C peripheral (SCL1 \/ SDA1 – see the Adafruit Feather RP2040 pinout picture in this article). <\/p>\n\n\n\n
In case you do want to use the same pin setup, you can use bitbangio to “create” an additional software-controlled I2C port. The downside of this is lower speed for this software-I2C port, and a higher CPU load. <\/p>\n\n\n\n
RuntimeError: No pull up found on SDA or SCL; check your wiring<\/h3>\n\n\n\n
If you get the following error<\/p>\n\n\n\n
RuntimeError: No pull up found on SDA or SCL; check your wiring <\/em><\/p>\n\n\n\n
then you should put pullup resistors between 3V3 on the board (the 3.3V pin) and respectively your SDA and SCL pins. These are required for normal I2C operation (the devices pull down the I2C pins to communicate, the default \/ idle state on the bus is high) – and are not included on the Adafruit Feather RP2040. They are included on many Adafruit peripherals, and on peripherals of other companies (like, again our own BME688 breakout board<\/a>). <\/p>\n\n\n\n
If you don’t know what a pullup is: this is essentially a resistor between the pin in question (e.g. SDA) and the 3.3 V supply pin. It does not need to be terribly precise. You should start out with 10 kOhm resistors, if that doesn’t work, possibly try a 1 kOhm resistor for a “stiffer” pullup. <\/p>\n\n\n\n
TimeoutError: Clock stretch too long<\/h3>\n\n\n\n
Check if the chip you want to talk to is powered properly. <\/p>\n\n\n\n
Misc. notes<\/h2>\n\n\n\n
Here, 119 is decimal for hex 0x77<\/a> – which is the address of our BME688 breakout board in the default state. <\/p>\n\n\n\n