Raspberry Pi 日記 (part2)

長嶋 洋一

2013年6月28日(金)

もう週末である。 朝、研究室に出て来ると、卒業生の山村さんから こんな素敵なプレゼント が届いていた(^_^)。 山村さんの作品「おはなしパネル」は今年もオープンキャンパスで展示するので、さっそく明日、展示プロジェクトの「40虎」メンバーに紹介しよう。 関連して、「SUACインスタレーション」 ★ ★ ★ のページに加筆改訂して、オープンキャンパスでの展示記録と「動態保存作品」を付記した。 今日は、ゼミのミーティングに加えて、企画立案演習でコマ撮りアニメに初挑戦(^_^;)という無謀なグループを応援するアポも入っている。

ゼミまでの時間にちょっと実験、というのを思いついたのでやってみた。 水曜日に作った「LED_blink」(起動時に自動実行)のソースは これ であるが、要するに7+8=15ビットのLEDをバイナリ2進数としてインクリメントして表示している。 ただしメインルーブでは以下のように、インクリメントするたびに「bcm2835_delay(1); // 1msec interval」を入れている。 

	while(1){
		for (j=0; j<128; j++) {
			EXT_out(j, 1);
			for (i=0; i<256; i++) {
				GPIO_out(i, 1);
				bcm2835_delay(1); // 1msec interval
			}
		}
	}
この状態だと、下位8ビットが一周するのに256msec、その上の7ビットのLSBは512msecの点灯と消灯を繰り返すのでおよそ1秒の間隔で点滅し、7ビットのMSBは64秒、つまりおよそ1分間というインターバルで点滅している。 この、「1msecのウェイト」を取ったらどうなるのか、というのはまず、実験してみる意義がある。 Raspberry Piの、このGPIOアクセス手法での最高速度を見てみたい、という事である。

そこで これ の「bcm2835_delay(1); // 1msec interval」を消した「blibk.c」 を作って、 Raspberry Piにrcpして、「gcc blink.c -l bcm2835」でコンパイルして、「sudo ./a.out」すると、15ビットの最上位ビットのLEDだけがわずかに高速点滅しているように見えて、他のビットは全て点灯しているだけ、つまり「相当に高速」(^_^;)と判明した。

これでは判らないので、次に以下のように、「15ビットのうち下位8ビットを最高速度でインクリメント表示する」というループを1000回ループするごとに、15ビットのうち上位7ビットを1だけインクリメントする、というように変更した。1000分の1のスローモーションという事である。 すると7ビットのうち「ビット3」をストップウォッチで測ったら、およそ2.7秒程度の点灯/消灯時間だった。 

#include <bcm2835.h>

int assign[15] = {17,18,27,22,23,24,25,4,2,3,10,9,11,8,7};

void GPIO_out(int data, int mode){
	int i;
	mode = mode & 1;	// mode=0 : active high / mode=1 : active low
	data = data & 255;
	for (i=0; i<8; i++) {
		bcm2835_gpio_write( assign[i], ( ( (data >>i) & 1) ^ mode ) );
	}
}

void EXT_out(int data, int mode){
	int i;
	mode = mode & 1;	// mode=0 : active high / mode=1 : active low
	data = data & 127;
	for (i=0; i<7; i++) {
		bcm2835_gpio_write( assign[i+8], ( ( (data >>i) & 1) ^ mode ) );
	}
}

int main()
{
	int i, j, k;

	if (!bcm2835_init())
		return 1;
	for (i=0; i<15; i++)
		bcm2835_gpio_fsel(assign[i], BCM2835_GPIO_FSEL_OUTP);

	EXT_out(0, 1);
	GPIO_out(0, 1);

	while(1){
		for (j=0; j<128; j++) {
			EXT_out(j, 1);
			for (k=0; k<1000; k++) {
				for (i=0; i<256; i++) {
					GPIO_out(i, 1);
				}
			}
		}
	}

	EXT_out(0, 1);
	GPIO_out(0, 1);

	bcm2835_close();
}

YouTube

つまり、7ビットのLSBの点灯時間は2700÷8=337.5ミリ秒となり、この時間内に「GPIO_out(i, 1);」を256000回、実行しているので、計算上は「GPIO_out(i, 1);」を1回実行する処理時間は1.3μ秒、という概算となる。 ただし「GPIO_out()」の中身としては、引き数の8ビットバイナリデータに対して、「bcm2835_gpio_write( assign[i], ( ( (data >>i) & 1) ^ mode ) );」ということで、ビットごとにビットシフト・論理積・排他的論理和の演算を行って8回、GPIOに書き出しアクセスしている。 つまり、「bcm2835_gpio_write()」のGPIOアクセス時間は0.1μ秒のオーダという事である。 これは、なかなかに、速い(^_^)。

ここで2限にゼミがあり、3人の進捗確認や関連映像などで勉強した。 そして午後には、「企画立案演習」でコマ撮りアニメに初挑戦というグループを支援して、久しぶりにFinalCutProで静止画を連結して映像化し、サウンドトラックを仕込む、というデモを行った。 サンプルとして、デスメタル版の「トトロ」→「ポニョ」というメドレーのシュールな映像が出来たのだが、YouTubeに叱られるので残念ながらここには上げられない(^_^;)。 そしてこの4限を挟んで、以下のように研究室LANからLANハブを切り離して、2台となったMacBookAirそれぞれをホストとして、3台のRaspberry Piがネットワーク接続され、MacからsshとかVNCでそれぞれのRaspberry Piに接続できる確認を行った。

このネットワーク接続確認作業そのものは順調に出来たのだが、ここで驚くべき現象に遭遇した。 これまで世界各地/国内各地を一緒に出張してきた、MacBookAirの1号機の方が、突然に画面が真っ暗になったのである。 ただし「落ちた」のではなくて、よく見るとバックライトを最低にした時のように、画面内にうっすらと何か出ている時もあり、また完全に真っ暗になる時もある。 PRAMリセットでも戻らず、リセットとかスリープとかの反応から、落ちるのではなくてバックライトがゼロになる現象のように見えた。 USBに接続しているLANアダプタのLEDは点灯しているので、パソコン本体は生きているのだ。 サブモニタに出すVGAアダプタを差し込むとスパッと画面が出た(バックライト正常復帰)現象もヒントになりそうである。

これは過去のG4PowerBookの時代の経験からすれば、ディスプレイの開け閉めのヒンジ部分で、ディスプレイと本体内のマザーボードを連結しているリボンケーブルの断線とか接触不良、という嫌なパターンである。 しかしタイミングとして、棚ぼたでMacBookAirの2号機がやってきたそのタイミングでこれが起きるというのは、まるで2号さんが来て本妻が拗ねるという古典的シナリオみたいである(^_^;)。

さっそくネットで「MacBookAir + 画面　+　真っ暗」で゛検索してみると、出るわ出るわ、 これ とか これ とか これ とか これ とか これ とか これ とか これ とか これ とか、ゾロゾロ出て来た。 これはもう、MacBookAirの定番トラブルのようである。 そして、 ここ にあった情報から、「システム環境設定＞ディスプレイ＞ディスプレイの輝度の自動調整」のチェックを外したところ、無事に復帰した。 これは別にOFFでも困らないので、十分である。 以下のように両方のMacBookAirのOFFを確認して、やれやれである。


「Raspberry Pi日記」トップに戻る