Have you found incoherences in the APIs? Does an interface-specific [registry] (/project/design/#interface-specific-registries) needs refactoring or is hard to use? Is a device driver missing options? We are now planning v3 to polish the APIs. This is a major release which will permit small breaking changes, as defined by the compatibility guarantee.
Now is the time to report these issues and voice your opinion! Please file a bug or reach out on #periph on the Gophers slack. You can find the slack invite on the top right of this page.
It is slated for around Q1 of 2018. It is not an hard date, we will release once we feel we reached the desired polish level. You can view the currently slated changes via the [API breaking] (https://github.com/google/periph/labels/API%20breaking) label.
One of the key design goal of periph.io is to be as fast as possible while exposing a simple API. For GPIO pins, this means having reliable low latency in the happy path.
In this article, we’ll describe how we:
Are we fast yet?
Version 2.1.0 is released!
This is a polish, features and performance update. It includes a 25x (!) GPIO performance improvements, a nice slew of new features and no breaking change.
Version 2.0.0 is released! It is a major version bump because it contains breaking changes that may require user code changes.
The idea of the project came up in early 2016 as I
(Marc-Antoine) was working on a work-in-progress
(WIP) project named dlibox but only in the
summer of 2016 I saw that there was real value into making the Hardware
Abstraction Layer (HAL) a real project. The working name of the project was
pio
but everyone agreed it was a bad name. :)