mrubyc_arduinoにGPIOとADCを組込むことに成功したので、次はPWMだろうということでやってみたが、思ったよりも苦労した。 mruby/cのPWMでは、ONの割合と周波数を変えられるようになっている。 しかし、ArduinoのanalogWriteでは割合のみで、toneでは周波数のみしか変えられ無い。 仕方が無いので、これらを独立に変えるのは諦めて、割合のみか周波数のみを、それぞれanalogWriteとtoneで指定することにした。 次に問題だったのが、toneは本来は音をならすためのもので、音の継続時間を無しでも指定しても動くようにするために、C++でtone関数がオーバーロードされている。 そのため、C言語から呼び出すのが難しく、cppとした。 まず、pwm.hは、externをどこに入れるべきか試行錯誤したが、次のようにした。 #ifndef _PWM_H #define _PWM_H #include <Arduino.h> #ifdef __cplusplus extern "C" { #endif #include "mrubyc.h" typedef struct PWM_HANDLE { uint8_t pin_num; uint16_t period; uint8_t duty; } PWM_HANDLE; void mrbc_init_class_pwm(void); #ifdef __cplusplus } #endif #endif 問題のpwm.cppだが、これらの関数はc言語から呼ばれるので、全体をexternで囲って、次のようにした。 #include "pwm.h" extern "C" { void c_pwm_new(mrb_vm *vm, mrb_value *v, int argc){ v[0] = mrbc_instance_new(vm, v[0].cls, sizeof(PWM_HANDLE)); PWM_HANDLE *handle = (PWM_HANDLE *)v[0].instance->data; handle->pin_num = GET_INT_ARG(1); MRBC_KW_ARG(frequency, freq, duty); if( MRBC_ISNUMERIC(duty) ) analogWrite( handle->pin_num, MRBC_TO_INT(duty)*255/100.

Arduinoを利用してESP32でmruby/cからGPIOとADCを使うことができるようにはなった。 私がよく使うマイコンは、ESP32よりもflashやメモリの小さなものなので、そのようなマイコンでmruby/cを動かせないかと思っている。 Arduino ZeroやXiao SAMD21に使われているATSAMD21G18Aとか、 WCHマイコンの中では高性能なch32v305などが、次のターゲットであろう。 これらは、今のやり方で動きそうに思うが、残念ながらこれらは手元には無いので、確かめられない。 さらにその次には、 ch32v203とか、 Arduino Nano Everyで使われているatmega4809などかな。 これらは、メモリも少ないが、flashも足りていない。 そこで、Arduino Nano Everyを例にして、mrubyc_arduinoのflashの削減ができないかを検討していたら、mruby/cの小さなバグを見付けたので、そのことについて書くことにする。

Arduino Nano Everyのflashは、48kである。 ADCを使った簡単なプログラムをmrubyc_arduinoでコンパイルすると、82k程となる。 flashの使用量をかなり減らさないといけない。 vm_config.hを見ると、以下のような指定がされている。

MRBC_USE_FLOAT 1
MRBC_USE_MATH 0
MRBC_USE_STRING 1

機能を制限して、flashやメモリの使用量を減らすオプションのようだ。 Floatをoffにするために、0にしてみたが、コンパイルでエラーが出てしまう。 試行錯誤の末、以下のような修正をすると、これを0にしても動くようにできた。 boxing_no.h, value.cの中には、".d"や"->d"などが使われているが、これらはfloatを使わない場合には使えなくなっているので、それらの使われている場所を以下で囲って無効にする。

#if MRBC_USE_FLOAT
#endif

そして、_autogen_builtin_class.hの中の以下の行も、同様に囲む。

extern struct RBuiltinClass mrbc_class_Float;

最後に、class.cの中のclassの定義を以下のようにする。

#if MRBC_USE_FLOAT
  MRBC_CLASS(Float),            // MRBC_TT_FLOAT     = 5,
#else
  0,
#endif

これで、floatをoffにしてもコンパイルが通るようになる。 Arduino Nano Everyの場合には、flashの使用量が5.5kぐらい減った。 同じくらい効果のある削減を、あと5個ぐらい組合せれば、動くようになるかも知れない。 mruby/cでFloatをoffにすることはあまり無いのかも知れないが、0にしたときにエラーが出るのは、一応のバグと言えるのでは無いだろうか。 Stringをoffにしようとしても、エラーが出るが、こちらはややこしそうなので、あまり手を付けていない。

さらにflashを減らす試みとして、あまり使わないclassを取り除けないかも試してみた。 具体的には、Range,Proc,Hash,Arrayなどがあまり使わないclassかなと思う。 十分には検証していないが、rangeではflashは1.5kしか小さくならなかった。 Proc,Hash,Arrayは、取り除いてみたが、vmのcoreの部分で使っている感じなので、うまく動かない可能性が高いと思う。 たとえ、これらを全て取り除いても、10kぐらいしか減らないことが分った。 今後、Rangeは殆ど消して、Proc,Hash,Arrayでは不要なmethodを取り除いたときに、どうなるかを確かめてみたいと思う。 また、rrt0.cの中には、複数のタスクを動かすためのプログラムが書かれているが、一つのタスクが動けば良いと考えれば、工夫するとflashの節約が出来る可能性もあるのでは無いだろうか。

2026/4/16追記 value.hにもマクロで".d"を使っている部分があったので、これも修正した。

先日、 mruby/cとArduinoを組み合せることによって、rubyからESP32マイコンを制御することに成功した。 その際には、 mrubyc_arduino を利用した。 そのままでは動かなかったので、若干の修正をしなければならず、 mruby mruby/c共通I/O APIガイドライン に完全には準拠しておらず、 少し無駄な部分もあったので、 STM32マイコンへの実装を参考にして、 GPIOとADCについて新たに書いてみた。 GPIO用のdigital.hは、定数などを含めて、以下のようにした。 #ifndef _DIGITAL_H #define _DIGITAL_H #include <Arduino.h> #ifdef __cplusplus extern "C" { #endif #include "mrubyc.h" typedef struct GPIO_HANDLE { uint8_t pin_num; } GPIO_HANDLE; void mrbc_init_class_digital(void); #define GPIO_IN 0x01 #define GPIO_OUT 0x02 #define GPIO_ANALOG 0x04 #define GPIO_HIGH_Z 0x08 #define GPIO_PULL_UP 0x10 #define GPIO_PULL_DOWN 0x20 #define GPIO_OPEN_DRAIN 0x40 #ifdef __cplusplus } #endif #endif digital.cは、newでpinModeを設定できるようにして、以下のようにした。 #include "digital.h" static void c_gpio_new(mrb_vm *vm, mrb_value *v, int argc) { v[0] = mrbc_instance_new(vm, v[0].

rubyからマイコンを使いたいと昔から思っていたが、これまでなかなか手が出なかった。 mrubyというものがあるのは、以前から知っていたが、PCでコンパイルして中間コードを作って、それをマイコン上のVirtual Machineで実行するという、面倒な手順が必要である。 また、mruby/cというさらにコンパクトな実装も出て来たが、これも同様である。 pythonからマイコンを使うのは、micropythonを使えば簡単にできるが、rubyにはこれに対応するものがなかなか出て来なかった。 mruby/cを利用したpicorubyは、micropythonとほぼ同じ感覚で使えるものであり、今後の発展に期待したいが、binaryはraspberry pi pico用しか公開されておらず、EPS32用のものもあるが、自分でコンパイルしなければならない。 mruby-esp32というものもあり、flashにrbファイルまたはmrbファイルを書き込むと、それを実行してくれるという、micropythonを意識して作られたもののようである。 私がマイコンを使う場合には、c言語かArduino(C++)でプログラムを書いて、PCでコンパイルして、それをマイコンに書き込んでいる。 考えてみると、rubyでプログラムを書いて、PCでmrubyを使ってコンパイルして、それをマイコンに書き込んで実行できるのなら、mrubyもそれほど使い勝手は悪く無い気がしてきた。 micropythonのようにコンパイラをマイコンに載せるのは、メモリやflashを余分に必要とするので、無駄なようにも思える。 問題は、使いたいマイコン用のVirtual Machineがなかなか無いことである。 先に触れたmruby-esp32や、ESP32用のライブラリは、その例だろう。 RP2040, PIC32, STM32などで開発が進んでいるようだが、 様々なマイコン用のVirtual Machineを、それぞれ用意するのは手間である。 いろいろと検索していて見付けたのが、mruby/cとArduinoを組み合わせる方法である。 Arduinoは、様々なマイコン用のパッケージが用意されており、ほとんど同じ書き方で異なるマイコンを使うことが出来るようになっている。 そのArduino用の関数をrubyから使えるようにすれば、様々なマイコンをrubyから使えるようになるという考えである。 るびまの記事や esp32用のmrubyc-esp32-arduinoや いくつかのボードで動作するmrubyc_arduinoが それらの例であろう。 この内、最近も更新されている最後のものを使ってみることにした。 まずはESP8266で試してみたが、うまく動かなかった。 メモリも少ないし、なかなか厳しいのだろう。 次に、動くと期待できるESP32で試してみた。 Arduinoには、設定で以下のURLを加えて、ボードマネージャーからesp32をインストールした。 https://dl.espressif.com/dl/package_esp32_index.json そして、以下のコマンドでダウンロードしたファイルを、スケッチ-ライブラリをインクルード-.ZIP形式のライブラリをインストールで、組み込む。 wget https://github.com/aikawaYO/mrubyc_arduino/archive/refs/heads/main.zip スケッチ例-mrubycのところにblink_and_helloというのがあるので、これを動かそうとしたが、そのままではエラーが出てしまった。 digital.cなどの中で使っているArduino用の関数が参照できていなかったので、mrubyc.hにArduino.hをincludeするようにしたら、これはうまく動くようになった。 動作確認されているボードでは、なんで同じエラーが起きないのか不思議だ。 blink_and_helloでは、rubyから使うGPIO用の関数を、inoの中で定義しているので、マイコンの別の機能を使おうと思ったら、inoをいじらないといけない。 GPIO用の関数はdigital.cの中で定義されているようだったので、それを使おうとしたら、それなりに修正が必要だった。 シリアルにエラーメッセージが出るので、それを参考にバグ取りをした。 まず、GPIOクラスが定義されていないと言われたので、digital.cとdigital.h中のmrbc_init_class_digitalの引数をvoidにして、それをino中で実行した。 次に、GPIOのクラス定数が定義されていないので、先の関数の最後に以下を加えた。 mrbc_set_class_const(gpio, mrbc_str_to_symid("IN"), &mrbc_integer_value(GPIO_IN)); mrbc_set_class_const(gpio, mrbc_str_to_symid("OUT"), &mrbc_integer_value(GPIO_OUT)); mrbc_set_class_const(gpio, mrbc_str_to_symid("PULL_UP"), &mrbc_integer_value(GPIO_PULL_UP)); mrbc_set_class_const(gpio, mrbc_str_to_symid("PULL_DOWN"),&mrbc_integer_value(GPIO_PULL_DOWN)); 但し、その前に次のように定数を定義しておく必要がある。 #define GPIO_IN 0x01 #define GPIO_OUT 0x02 #define GPIO_PULL_UP 0x10 #define GPIO_PULL_DOWN 0x20 最後に、digital.hが組込まれていないようだったので、mrubyc.hの中でそれを組み込むようにした。 これらの変更をしたら、以下のようなrubyスクリプトでLEDのon/offができるようになった。

もっとも安価なマイコンボードは何かと考えると、いろいろな候補が考えられるが、最も有力な候補がSTM8S103F3P6ボードであろう。 書込機が必要だし、他のマイコンボードで代替可能なので、これまで敬遠していたが、Arduinoでの使い方を確かめてみた。 STM社のマイコンボードとしては、USBを扱いたくてblue pillを使ったことがあるが、その時は他の人が作ったプログラムを書き込んで使うに滞っていた。

今回試すボードは、HW-177という刻印があるものである。 Arduinoで使うには、環境設定のところにあるURLに

https://github.com/tenbaht/sduino/raw/master/package_sduino_stm8_index.json

を加える。 ボードマネージャーからstm8などを検索すると、Sduinoが出て来るので、それをインストールする。 最新versionは2019年に出た0.5.0のようだ。 ツールのボードからSTM8S BoardsのSTM8S103F3 Breakout Boardを選択する。 しかし、そのままではコンパイル時にエラーが出た。 ボードマネージャーからArduino megaAVR Boardsもインストールしたら、コンパイルができるようになった。

書き込みをするためには、いくつかの前準備が必要となる。 USBの権限の問題をクリアするために、まずは/etc/udev/rules.d/99-stlink.rulesというファイルを作る。

# ST-Link/V2
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE="0666"
# ST-Link/V2-1
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", MODE="0666"
# ST-Link/V3
SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374e", MODE="0666"

そして、この設定を有効にするために、以下のコマンドを実行する。

sudo udevadm control --reload-rules
sudo udevadm trigger

新しいデバイスを使うときには、フラッシュの保護が有効になっていて書き込みができないので、stm8flashのインストールされたフォルダの~/.arduino15/packages/sduino/tools/STM8Tools/2019.02.05/linuxに行って、以下のコマンドでそれを解除する。

./stm8flash -cstlinkv2 -pstm8s103?3 -u

ボードによっては書込端子のGNDが繋っていないものもあるようだが、今回は大丈夫なようだった。 これで準備が完了である。 Arduinoで、書込装置を選択する。 今回はST-Link/V2を用いたが、それとマイコンボードを四本の線で接続する。 そして書き込みボタンを押せば、無事に書き込みが出来て、Lチカが無事に動くことが確認できた。

USBは電源供給のみで書込機が必要だし、ArduinoではC言語しか使えないなど、欠点も多いが、安くしたくて単純な用途には使える気がする。 今後の選択肢の一つとして、使って行こうと思う。

メインPCを久々に更新することにした。 調べてみると、前回更新したのが2020年の5月だったので、実に6年ぶりということになる。 これまでに使ってきたメインのPCは、筐体はmicro ATXで統一しており、OSはメインのHDDまたはSSDに入れて、dataの入ったHDDを載せかえると、dataの移行の必要が無く、楽にPCの更新ができた。

昨年度、測定用にmini PCを買って使ってみたら、それなりに使い易かったし、性能もあまり問題が無いようだったので、今回はメインPCもmini PCにしてみた。 これまでの様に複数のstorageを載せられないので、homeのみ別のパーティションにして、dataはrsyncを使って移行した。 移行したい設定などのファイルもrsyncで移した。

OSはDebian13だが、sleepのときにhung upする可能性があったので、/etc/systemd/sleep.confでは以下のように指定した。

[Sleep]
AllowSuspend=no
AllowHibernation=no
AllowSuspendThenHibernate=no
AllowHybridSleep=no

light-lockerはあまり好きではないので、xscreensaverも入れておいた。 サウンドも認識していないようだったので、pavucontrolを入れて再起動したら、認識したようだ。 スピーカーが無いので、音はならないけど。

少し使った感じでは、うまく動いているようだけど、細々とした違いが出て来るかも知れない。 少しずつ環境を整えていこうと思う。 Linuxの場合、PCの速度による動作の違いは感じ難いけど、動作がきびきびしているように感じる。 さすがに6年の差は大きいのかな。

様々なプログラムが掲載されている場所として，githubの存在は以前から知っていたが，これまで詳しいことは知らなかった． Linuxを構成するコードを複数の人で開発するために作られたのがgithubのようだ． 普段からLinuxは使っているが，その事実は知らなかった．

githubのアカウントの作り方を調べたら，なんだかいろいろと面倒な作業が必要のようで，これまで敬遠していた． 知り合いに聞いたところ，googleアカウントでログインすると，そういった面倒なことは無いと言われた． その方法で試してみたら，ほとんど苦労することなく，githubを使うことが出来た．

githubの使い方を検索した時に，なんでこの事が見つからなかったのかと思ったら，これが可能になったのは，半年前のことのようだ． そのため，まだ情報が広がっておらず，昔の情報の方が検索にかかるのだろう．

これで，様々なプログラムをgithub上で開発することが出来るようになった． しかし私は，プログラムの開発はローカルな環境でやるのが好きで，通常は短いプログラムしか作らないので，公開の場所としては，blogなどで十分な気がする． 今後，どの程度使うかは不明だが，気が向いたら使ってみよう．

私が構築しているArduinoのUIAPduinoボード用のパッケージは，自分で作ったコードと外部のコードを組合わせて作っているが，外部のコードはできるだけ分離しておきたいと考えている． しかし，ボードをインストールする際のjsonの構造を調べたところ，圧縮されたファイルは，hardwareまたはtoolsの中の別々のフォルダとして展開される． 分離したファイルを，hardwareの中の特定のフォルダの中に展開するということは出来ないので，少し工夫が必要になる． 思いついた方法は，私の作っているArduino環境に組み込んでいるArduinoCore-APIをtoolsの中のフォルダに置いて，そのファイルをhardwareの下にあるメインのコードから呼び出せるようにして，コードを分離するという手法である．

相対pathでapiへのシンボリックリンクを作れば，toolsに入れたArduinoCore-APIも参照することができるのでは無いかと思って試してみたら，ローカルのArduino環境ではうまく動くことを確認した． ボードマネージャからインストールした時にもこれを再現するためには，hardwareの下のファイルを圧縮して展開したときに，シンボリックリンクが有効でなければならない． zipでシンボリックリンクのまま圧縮するには，-ryオプション付きで実行すると良いという情報を見てやってみたが，展開したらリンクの名前の普通のファイルになってしまった． 一方，以下のようにtar.gzで圧縮したら，展開してもシンボリックリンクとして働いた．

tar -zcvf filename.tar.gz folder/

このようにして，少なくともLinuxにおいては，コードを分離した状態で，自分の作ったボード環境をインストールできるようになった．

Windowsでも，tar.gz圧縮したシンボリックリンクが働くという情報もあったので，試してみた． Arduinoを通常の権限で立ち上げて，インストールしようとしたら，シンボリックリンクを作る権限が無いというエラーが出た． そこで，Arduinoを管理者として実行して，インストールしたところ，シンボリックリンクも有効になって，無事に動かすことに成功した． Windowsで確かめるべきことはこれで終わりだと思うので，そろそろWindowsを消しても良いかな． もう少し待った方が良いかな．

自分で作ったArduino環境を，ボードマネージャからインストールできるようになったと思う． LinuxとWindowsではざっとチェックしたけど，Macは持っていないので，動作チェックができない． どうしようかな．

新しいハードウェア用のパッケージをArduinoにインストールするには，jsonファイルを入力して，ボードマネージャーから指定する． このjsonファイルがどのような構造になっているのかを調べてみた．

基本的には，パッケージの圧縮ファイルと，アーキテクチャ毎のツールの圧縮ファイルが指定されており，すべてのファイルについて，SHA256とファイルサイズを指定する必要がある． SHA256の値が分かっている場合にはそれをコピペすれば良いが，無い場合には，ファイルを用意して以下のコマンドを使って表示された値を使う．

sha256sum filename

また，サイズが分からない場合には，ファイル全体をダウンロードしなくても，以下のようなコマンドでファイルのヘッダを調べることにより，サイズが分かることがある．

wget --spider --server-response url

ちなみに，ローカルにあるファイルを指定する場合には，以下のように記述する必要がある．

file:///home/user/filename.txt

すべてのアーキテクチャで同じファイルを指定する方法が無いか調べたが，分からなかった． jsonファイルを編集すると，ミスをすることもあるが， ブラウザーで開くと，値などが正しく指定されているかや，文法などをチェックできる．

構造が大体分かったので，私がUIAPduino用に作っているch32funを使ったArduino環境を簡単にインストールできるように，jsonファイルを作ってみた． その環境で取り込んで使っているのは，riscv-none-elf-gccとminichlinkとArduinoCoreAPIとch32funとrv003usbである． gccはxpack-dev-toolsの最新のリリースがv15.2.0-1だったので，それを使えば良いだろう． minichlinkはUIAPduinoの本家のファイルを指定すれば良い． ArduinoCoreAPIの最新のリリースがv1.5.2なのでこれを使いたいのだが，hardwareフォルダの中に自動で組み込む方法が分からなかったので，toolにダウンロードさせて，自分でコピーすることにした． ch32funもv1.0rc2というリリースがあったのだが，その中身はch32funでは無く，ch32v003funになっていた． 実質的には同じかも知れないが，環境を構築するときにch32funを使っており，バグなどが起こると嫌なので，ch32funのファイルを自分で組み込むしかないかな． rv003usbについてはリリースがなく，そのフォルダのzipを指定することもできるが，少しでも修正があったらSHA256が一致しなくなるので，これもファイルを自分で組み込むしかないだろう．

私の作った環境とch32funとrv003usbをzipで圧縮したファイルとjsonファイルはローカルに置いて，それ以外はネットから取って来て，簡単にインストールすることができるようになった． aipのフォルダだけはコピーしないといけないが． シンボリックリングなどをつかって，うまくできないかを考えてみよう． gccのバージョンの違いによる問題が起こる可能性もあるが，後でチェックしよう． 新しく立ち上げたPCには，この方法を使って，インストールしようと思う．

Debianを入れる前のWindowsPCが手元にあったので，改良中のUIAPduino用Arduino環境をWindows11でも試してみた． 結果から先に書くと，多少の苦労をしてWindowsでも無事に動くようになり，やはりUSB serialは動かなかったがHIDのターミナルで代替できる．

Windowsを立ち上げたのだが，秘密の質問を登録しろと言われたところで，挫けそうになったが，なんとか耐えて起動させることが出来た． まず，Arduino2.3.8をインストールして，それにAlexanderManderaさんの環境とUIAPduino環境を導入した． 私の環境を使えるようにするために，Linuxで~/Arduino/hardwareにおいていたファイルを，そのままWindowsのUsers/username/Documents/Arduino/hardwareに移した． 原理的にはこれで動くはずなのだが，コンパイル時にいろいろとエラーが出て，うまくいかなかった． Arduino1.8.19も試してみたが，駄目だった．

バグというのは，見つかってから考え直すと当たり前に思えるのだが，それまではなかなか原因が分からないものである． Linuxではコンパイルできるのに，Windowsではコンパイルできない原因を，様々な観点から探ってみたが，うまく行かなかった． AlexanderManderaさんの環境ではWindowsでもコンパイルできるので，そのplatform.txtを元に，少しずつエラーを解消していったら，その過程で原因を見つけることに成功した． megaavrでは，USB CDC用の関数がCDC.hで宣言されている． 私はそれを参考にして，CH32V003用のファイルを作り，同じくCDC.hという名前にした． 一方，rv003usbでは，USB CDCを使うために，TinyUSBのcdc.hというファイルを利用している． Linuxでは大文字と小文字を完全に別の文字として扱っているが，Windowsではこれらを同一視することがあり，これらの２つのファイル名が干渉していたのが問題だった． CDC.hなどをSerialCDC.hなどという名前に変えて，若干の調整を行ったら，Windowsでもコンパイルが通るようになった．

また，以前ざっと確認して駄目だったUSB serialをもう一度確認してみたが，やはりWindowsでは動かなかった． USB serialをプログラムしたUIAPduinoをUSBに繋ぐと，COM3はできるのだが，デバイスマネージャではビックリマークがついているし，Arduinoのシリアルモニタも動かなかった． なんとか工夫して動かせる可能性もあるかも知れないが，簡単では無いだろう． 一方で，HIDを利用したminichlinkのターミナルは，予想していた通りにWindowsでもうまく動いた． ch32funのminichlinkのフォルダから，minichlink.exeとlibusb-1.0.dllをダウンロードして，実行すると「VCRUNTIME140.dllが見つからないため」とか文句を言われるので，Visal C++再頒布可能パッケージのX64版をインストールする． すると，以下のコマンドでminichlinkのターミナルが開く．

minichlink.exe -kT -c 0x1209d003

キーボードからの入力は，画面には出ないがマイコンに出力され，送受信が可能である． minichlinkのターミナルを併用することで，一台のUIAPduinoのみでPCと通信できるので，バグ取りなどの効率が上がるだろう．

Windowsを使うストレスに耐えられなくなって来たので，動作確認の作業はこれで止めにすることにした． 例えば，コードを編集するために，エディタを選んで[一度だけ]を指定していたのだが，面倒になって[常時]を選択したら，拡張子が表示されなくなって，怒りそうになった． 拡張子を常に表示するように設定する方法を調べるのも面倒なので，そのままやったが，他にも様々なストレスを与えてくるので，私にしては頑張った方だろう． このPCは、そろそろDebianで上書きインストールしようと思う．

Windowsで作動することも確認できたので，あとは細かいバグ取りかな． まだ出来ていないことで思い付くことには，SPIとshiftとpulseの動作確認と，I2Cのslaveの実装があるが，他にも何かあるかも知れない．