We just released circuits_gpio v0.4.1 which has important updates for Raspbian. All Circuits projects should work well on Raspbian now.

While many of us primarily work with Nerves, we want Circuits to have a great out-of-box experience with Raspbian and other Linux distros running on Raspberry Pis, Beaglebones, etc. If you’re using one of these, please let us know (via GitHub issue) if anything doesn’t work or is confusing.

Circuits.GPIO 2.1.3 is now available that fixes a serious issue that caused interrupt messages to stop being sent. Please update when you can. I went ahead and marked the hex packages for versions prior to 2.1.3 as invalid since this issue can be quite hard to track down. Thanks to @akoutmos for providing me a Nerves Livebook that reproduced it and @gus who also was able to reproduce and confirm the fix in a different context.

The bug affects anyone using two or more GPIOs in interrupt mode. If you’re not using interrupts or use only one, then upgrading is less important. In practice, the issue occurred when a GenServer using one GPIO in interrupt mode crashes and restarts. Another open GPIO in interrupt mode could stop getting interrupt messages. Internally, the ordering of events matters, so it was possible to get inconsistent outcomes.

circuits_gpio v0.4.2 is available now. It has an important update that makes GPIO pullup and pulldown settings work with the Raspberry Pi 4. This feature is frequently used by Raspberry Pi hats that have buttons on them.

circuits_gpio v0.4.3 and circuits_i2c v0.3.5 are available now.

circuits_gpio has a fix for handling fast GPIO transitions. One example of these are the spurious transitions from button presses. The normal route is to add debounce handling code to remove them. circuits_gpio does some debouncing due to it being slow. In some cases you don’t want to miss the GPIO transition. This release fixes a bug when turning it off. See the :suppress_glitches option.

circuits_gpio also supports forcing GPIO emulation on for testing libraries that use it. See CIRCUITS_MIX_ENV.

circuits_i2c fixes an issue when scanning the I2C bus for devices. There’s no spec for enumerating an I2C bus, so it’s done heuristically. There’s still an outstanding issue for an improvement in this area.

A final note: Several people have contacted me about cdev support for circuits_gpio. This would be a significant and important update. I am not working on this, but others have expressed interest. Since this is a sizable unfunded effort, I’m not sure when this work will be available - no changes have been pushed to any public repo yet. If you are interested in contributing to this effort, I will gladly put you in contact with others.

Thanks for the heads up on the Elixir Circuits website. It’s back up now.

Elixir Circuits handles the communication to each of those devices. I’m not sure if anyone has published libraries for those sensors. I feel like the ADC and color sensor have code out there some where.

There are three main approaches to adding support for a chip if no one has made an Elixir library already:

1. Download the part’s datasheet and implement it yourself by making calls to Circuits.I2C. The SHTC3 part is probably a good one to start since it has a short datasheet and you could experiment with it at the iex prompt.
2. Port a Python library. This works with the datasheet is hard to understand.
3. Don’t use Elixir Circuits at all and go through a Linux device driver

I’d start with the SHTC3 or TCS34725 since those seem more straightforward than the others. I think that it depends on what you want to do with the IMU (ICM20948) and ADC. If you just want to get values out of it, Elixir is fine. If you’re using those to control a drone or something where dropping a sample would be really bad, then I’d look at Linux’s IIO drivers. This isn’t meant to be a critique of Elixir, but more that writing timing critical device drivers in Linux userland can be hard.

One last thing: if you want to experiment with the devices at the IEx prompt, the Circuits Quickstart can help. That project has pre-built images for many Nerves boards. You can copy/paste short Elixir modules into the prompt if you’d like. Of course, you’ll eventually want to make your own firmware image and get away from copy/paste programming at the iex prompt, but for little things and experimentation, I find it pretty convenient.