Raspberry Pi用pigpio Library - その3

pigpioライブラリの概観の続き（その1、その2）。今日は実装の技術的な面の印象に関する簡単なまとめと、Cから呼ぶにあたっての前おきについて．．．

1.12  技術的な面の印象まとめ

こうやってざっくり見てみると、このpigpioライブラリの技術的なキモは高精度で高分解能で、しかも低負荷のタイマ実装にある、ということがわかる。それをベースにすることで、高精度のPWM、割り込みに依存しないコールバック、汎用のGPIOでシリアルやSPIなどのbit bangが実現されている。ハードウェアによるクロックをベースにしているらしいことはわかるけど、どうやって実現しているのか、ソースを眺めてもなかなかわからない。

一方で、どうやらこの人はbcm2835ライブラリを実装した人と違って、unixに慣れ親しんだ人らしい。呼吸するようにpthreadを使いこなして、socketやpipeを自由に扱っている。

ソースをちらちら見ていると、場合によってはライブラリ内部でさらにスレッドを起こして、ロック（pthread_mutex_lock）や、中には条件付きロック（pthread_cond_lock）なんかが大量に使われてスレッド間の排他制御をしているらしいことがわかる。こんなにたくさんロックを使うとデッドロックを起こしたりしてデバグが大変なんだけど、もちろん問題なく動くようである。

ちなみにライブラリ内部で使われているpthreadのラッパ関数はユーザにも開放されていて簡単にスレッドを使えるようになっている。しかしもちろん排他制御なんかはpthreadと同じで安易には使えない。スレッドを使いこなしている人のキー入力削減用だと考えるべきだろう。

ソースはbcm2835ライブラリの人とよく似て簡潔なもので、コメントも要所々々にしかない。スペースの空け方が独特なので見慣れない表現に見えるところもあるが、基本的にはディテールは読みやすいソースである。

ところが一方で大量のstatic変数と、たくさんの長大な（何回もスクロールしないと閉じカッコが現れない）関数定義が含まれていて、全体像を捉えるのが難しい。

歳をとるとこういうソースを追いかけながら中身を理解するのは厳しくなってしまう。

2  pigpioのCベースAPIの概要

pigpioはCで実装されているのでCから呼ぶのが一番素直である。使い方が難しくて困る、というようなところはない。さくっと眺めてみる。

2.1  コンパイル以前

pigpioは普通にインストールすると/usr/local/libや/usr/local/include、/usr/local/bin、/usr/local/manなんかに配置される。ソースへのインクルードは

#include <pigpio.h>

だけでいい。リンクの時にpthreadライブラリと、pigpioライブラリ本体、それとrtが必要になる。このlibrtはなんだかよく知らないんだけど、POSIXの"Real Time Extension"というものらしい。何がどうリアルタイムなのかよくわからない。ソースを見て関係しそうなのはクロック取得のあたりとnanosleepぐらいしかないんだけど、librtなしでもコンパイルできてしまう。OS Xにないし、僕がOS Xではないunixをいじっていた頃（もう3、40年前だわ）にもなかったので、よくわからない。

pigpioの多くの関数は成功すると0あるいは正の整数を返す。負の戻り値は失敗で、エラーコードを表す。たまにunsignd intを返す関数では0が失敗を表すこともある。

2.2  GPIOピンの命名

bcm2835ライブラリの作者も悩んでたけど、pigpioではBCM2835のSoCのGPIOピンの呼び名をSoCのピン名称のまま使うことにしたらしい。

BCM2835にはGPIOピンとして54本あるが、現状のRaspbery Piのモデルは0から最大で27までしか今のところ出ていない（例えばPi 3のピンヘッダは40ピンだけど残りの12本は電源とグランド）。さらにはRaspberry Piのモデルによって出ていたり出ていなかったり、ひどいことに物理的な位置が違っていたりする。

bcm2835ライブラリでは、機種ごとの物理的なピンの位置で呼ぶようにしてたけど、pigpioではソフトウェアからはBCMに統一して、ハードウェアを分類する関数を用意してそれに従って物理的な位置と対応づけることにしたということらしい。

今一番たくさん使われているPi 1B+、Pi 2B、Pi 3、Zeroの物理的な対応は同じなので、古いモデルを考慮する必要がないのであれば、それほど悩むことはないかもしれないけど、Raspberry財団の互換性に対する意識はどうやら低いらしいので、今後どうなるかはわからない。まあ、今以上にたくさん使われるようになって、モデルもスケールに従って増えてくると、こんなやり方ではユーザはついてこないということは、普通ならいずれはわかるはずではある。

財団の悪口はこのくらいにして、次回から具体的なC関数を眺めてみる。