そこそこ使いやすい感じなのを学習しながら書いてみた。

使いかた

マスターの場合

割込みを利用はしてますが、APIとしてはブロックする同期なものしか用意してません。

uint8_t data[7];
uint8_t ret;

i2c_set_bitrate(100);
// Set target slave address
i2c_master_init(0x60);
ret = i2c_master_write((uint8_t*)"\x04", 1);
if (ret) goto error;
ret = i2c_master_read(data, 8);
if (ret) goto error;
i2c_master_stop();

error:
    i2c_master_stop();
スレーブの場合

スレーブの場合、特定のメモリ領域を登録すると、そこに対して read も write もできる、という感じの設計になっています。

// Slave memory map (must be smaller than 254 (0xfe) bytes)
uint8_t data[9];
// Enter to slave receive mode with data and size.
// After this operation, data will be changed automatically by TWI interrupt.
i2c_slave_init(0x65, data, 10);

// Access (set or get) to I2C data block
data[0] = 0x10;
// Or more readable code with struct
struct {
    uint8_t foo_flag1;
    uint8_t foo_flag2;
    uint16_t bar_value1;
    uint16_t bar_value2;
    uint16_t bar_value3;
    uint16_t bar_value4;
} data;

i2c_slave_init(0x65, &data, 10);

割込みでいつのまにかデータが変化する感じなので、マルチバイトデータの読み書きではデータが化ける可能性があります。

マルチバイトデータの読み書きを行う場合、

  • 書く場合
    • i2c_state を見て、I2C_STATE_IDLE であることを確認してから
  • 読む場合
    • i2c_state を見て、I2C_STATE_IDLE であることを確認してから
    • cli してから

が必要だと思います。通信中のデータはコピーして別で持っておけばいいんですが、もったいないし、そんなに問題にならなそうだしお手軽なのでこんな感じです。

実装にあたって

I2C は仕様書の日本語訳で公開されている。本家?はi2c-bus.org かな。

ポイントとしては

  • 送信・受信の切替えにあたっては必ず再度アドレスの送信が必要
  • Repeated START というのは単に STOP + START 相当のことを START だけでできるようにしているに過ぎない (バスを連続して占有し続けられるというだけ)
  • NACK は ACK を返さない状態のことを言ってる
    • エラーと区別はない
    • 転送終了とか、受信終了とかの意味付けされてるけど、応答がないのでもう何もしない、って感じ
  • START コンディション、STOP コンディション、クロックは常にマスターが生成する

マルチマスターまわりとゼネラルコール(マルチキャスト)まわりはいまいち理解できてない (今のところ必要性を感じてない)。

I2C 上のプロトコル

I2C 自体は任意長のバイトの送受信しか定義してない (言及はあるけど) ので「特定のアドレスのデータを読みだしたい」みたいな場合は、その上にプロトコルを乗せる必要がある。デファクトスタンダードっぽいのは

  1. アドレスを1バイト送信する
  2. Repeated START (たぶん STOP + START でも同じだけど…)
  3. データをnバイト受信する

というもののようだ。ステートフルなので、読み出される側は読まれようとしているアドレスを記憶しておく必要があり、1バイト読まれるごとにインクリメントする必要がある。送信と受信は別々にアドレスを指定する必要があるので、この場合2度アドレス送信が行われる。

AVR での実装

ポイントは

  • 割込みがかかったら何か必要なことをして TWINT を 1 にする、というのをくりかえす
    • TWINT をクリアしないと無限に割込みが入り続けるし、SCL がローのままになるのでバスが解放されず一切I2Cできなくなる
    • すべきこと (何をしたら次どういう状態になるか) はデータシートにモードごとに書いてある
  • データシートにある "TWINT Flag is set" な状態というは TWINT が 0 の状態のことで、TWINT Flag を clear するというのは TWINT に 1 を書くということらしい。論理逆なの?
  • TWINT Flag が set されている間 SCL はローになる
    • ソフトウェア処理に時間がかかった場合自動でクロックストレッチングされる
  • MR, MT, SR, ST ({Master,Slave} {Receiver,Transmitter}) の定義を先に読んどかないと意味不明

基本がわかればあとはそんなに難しくなく、試行錯誤したらできる感じだった。ただ、割込みの中で余計なことをすると、うまく次の割込みが入らなくなるということがあったりするので、動作を観測するのが難しい。LED チカらせてデバッグするしかないことがある。

備考

Linux の I2C まわりを調べていて出てくる SMBus とかいうのはPCの電源管理とかで使われるプロトコルで、基礎プロトコルとしてI2Cを利用している。I2C レイヤーの上に SMBus というレイヤーがあるイメージ。

  1. トップ
  2. tech
  3. AVR TWI (I2C) 用のライブラリ
  1. トップ
  2. avr
  3. AVR TWI (I2C) 用のライブラリ
  1. トップ
  2. arduino
  3. AVR TWI (I2C) 用のライブラリ

ソフトウェア開発って、他人が過去に作ったものに対する発見を重ねるみたいなところがあって、人工的に作られた過去の遺物を発見してうまく解釈するという、なんかよくSFモノにある、失なわれた技術を発掘していくみたいな、そういう感じ。

ソフトウェアは書いた通りにしか動かない。ソフトウェアのどこかの部品が壊れて(バグって)いたら必ず、なにかしら観測可能な状態に落としこめるような環境が整っている。

ハードウェア部分は、人間が工夫して設計しているとはいえ、基本は物理現象(電子の動き)を利用していて、それが自分には不思議で面白い。ソフトウェアレイヤーをいじっている限りでは物理現象を利用しているという感覚は一切なく「他人がどういう意図で設計したか?」という、物理というよりは精神なことを考えていることが多い。

ハードウェア、回路レベルの設計は全体的にパズル的で、動いているのが不思議な感じがする。ソフトウェアでこういうパズル的なことをやろうとしたらテストを書かないと殺されると思うけど、頑張ってだいたいうまく動いてる感じで感心すると同時に、こんなので大丈夫なのかと心配になる。

しかし実際には精度良くハードウェアは動くように設計されていて、そういう頑張ってる感じのパズル的に動くロジックの大量の組合せでCPUが構成されて、その上で機械語が実行されていて、機械語を生成するための言語があって、Cから機械語を生成するためのツールチェインがあって、それらを利用してさらに抽象化されたレイヤーで書けるLLがあって、なんだか考えていると、LLでコードを書くのはジェンガの上のほうでコードを書いている感じに思えてくる。

GPIO の操作はいろいろやる方法があるみたいだけど、LL からだと sysfs への IO を行うのが一番簡単っぽい。以下のような感じでかなり簡単に書ける。この程度だとライブラリを使う必要はない。

pin の数値は、RPi Low-level peripherals で書いてあるような GPIO n の n の部分を指定する。(物理的なピンの並びとは関係ない)

  • export で指定した GPIO ピンを使えるようにする
  • direction で方向を指定する (入力か、出力か)
  • read/write で 0/1 を読み書きする

この例だと GPIO 25 (22pin) で指定時間ごとに論理が反転する。

#!/usr/bin/env ruby
# coding: utf-8

module GPIO
	def self.export(pin)
		File.open("/sys/class/gpio/export", "w") do |f|
			f.write(pin)
		end
	end

	def self.unexport(pin)
		File.open("/sys/class/gpio/unexport", "w") do |f|
			f.write(pin)
		end
	end

	def self.direction(pin, direction)
		[:in, :out].include?(direction) or raise "direction must be :in or :out"
		File.open("/sys/class/gpio/gpio#{pin}/direction", "w") do |f|
			f.write(direction)
		end
	end

	def self.read(pin)
		File.open("/sys/class/gpio/gpio#{pin}/value", "r") do |f|
			f.read.to_i
		end
	end

	def self.write(pin, val)
		File.open("/sys/class/gpio/gpio#{pin}/value", "w") do |f|
			f.write(val && val.nonzero? ? "1" : "0")
		end
	end
end

GPIO.export(25)
GPIO.direction(25, :out)

led = true
loop do
	GPIO.write(25, led)
	led = !led
	sleep 0.5
end
  1. トップ
  2. tech
  3. Ruby で sysfs 経由での GPIO 操作
  1. トップ
  2. raspberrypi
  3. Ruby で sysfs 経由での GPIO 操作

無線のPCモールスUSBインターフェイスって結構高価なのが多いんだけど、Raspberry Pi だと GPIO 経由で普通にキーイングできるし、単体で HDMI やコンポジットビデオ出力できるから、これで十分すぎる感じがする。

GPIO に UART があるけど、デフォルトではシリアルコンソールとして使うことが想定されていて、カーネルメッセージとかが流れる。これを無効にして、普通のシリアルポートとして使う。

/etc/inittab を書きかえる。ttyAMA0 の行をコメントアウトする

#Spawn a getty on Raspberry Pi serial line
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

/boot/cmdline.txt を書きかえる。デフォルトだと以下のようになっているので

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
  • console=ttyAMA0,115200 を削除 (シリアルコンソールのオプション)
  • kgdboc=ttyAMA0,115200 を削除 (カーネルデバッグ用のオプション ref. kgdboc

して以下のように

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

で reboot すると普通にユーザレベルで自由に使えるようになる。

3.3V なので、RS-232C レベルにするなら 3.3V でも使えるドライバICを使う必要がある。ICL3232 だと100円ぐらい。

回路

FET らへんは GPIO 25 (22pin) をオンにしているときだけスイッチを入れるための仕組みなので RS-232C のためには必須ではない (GND を普通に繋ぐだけ)

  1. トップ
  2. tech
  3. Raspberry Pi の GPIO でシリアル通信
  1. トップ
  2. raspberrypi
  3. Raspberry Pi の GPIO でシリアル通信