コグノスケ

JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信改善

目次: Arduino

M5Stamp C3 + Raspberry Piを組み合わせて作った的あてゲーム、秋葉原のTarget-1（お店のサイト）で壊れることなく1年ほど安定稼働しているようです。良かった良かった。しかし最近、故障ではないもののタイトル画面に戻ってしまう頻度が増えているそうです。

ゲーム画面の例

以前に日記で紹介したとおり、的あてゲームのシステムはM5Stamp C3をBluetooth LEデバイスにして、Linux PCもしくはRaspberry PiなどのLinux SBCと通信しています。Bluetoothの接続が切れるとタイトル画面に戻って再接続する実装にしていますので、不意にタイトル画面に戻る = Bluetoothの接続が切断されていることを意味します。

原因の仮説と対策

お店での運用を見ていると、ゲームリザルト画面で放置されることが多いです。今の実装ではリザルト画面でBluetoothの通信を一切行いません。あまりにも長い間通信しないとBluetooth接続が切れてしまう？のかもしれません。

とりあえず今回は小手先の対処として、リザルト画面でM5Stamp C3本体のLEDを点滅させる指令を送り続け、Bluetooth接続を維持するようにしました。家でテストしてみたところ1日以上放置しても接続を維持できています。

代償として消費電力が0.1Wくらい増えますが、何度もタイトル画面に戻されるよりはマシでしょう……。

目指すは先代の実績？

先代のTSS（ターゲットシューティングシステム、作者さんの紹介サイト）は5年位稼働していたらしい（すごい！）ので、追いつくにはあと4年ですか、長いな〜……。

4年後を考えてみると、Linux側のマシンROCK 3Cはほぼ確実にEOL（End Of Life、生産終了、販売終了）だと思います。Linux側のシステムはHW依存は少ないし、SWも枯れたやつが多いので、そのとき販売されているお買い得なARM SBCボード（Raspberry Pi 6とか7とか？ROCK 3C後継のボードとか）への乗り換えは容易だと思います。

困るのはM5Stamp C3ですね。EOLになると別ボードへのSW移植とドッキングするためのボード再設計が必要でしょう。M5Stampは安くて良いんですけど、世代ごとに形がガンガン変わって互換性ゼロなのが良くない点ですね。作り直すとしたら、今のM5Stamp C3の2枚使い設計はダサいので、I/Oピン数の多いボード1枚に改めると思います。

timespecの操作関数

目次: C言語とlibc

POSIXには時間を表す構造体が2つあります。マイクロ秒単位のstruct timevalと、ナノ秒単位のstruct timespecです。struct timespecの方が後発なのか、比較的新しいAPIはstruct timespecを使う傾向にありますが、基本的には混在しています。

struct timeval {
    time_t      tv_sec;     /* 秒 */
    suseconds_t tv_usec;    /* マイクロ秒 */
};

struct timespec {
    time_t tv_sec;     /* 秒 */
    long   tv_nsec;    /* ナノ秒 */
};

見てのとおり構造体ですから、足し算や引き算をするにも桁上がりを考える必要があって一苦労必要かと思いきや、POSIXはtimeradd/timersubなどのマクロを用意しており、struct timevalの加減算と比較などが比較的簡単に行えます。便利ですね。

ではstruct timespecにも同様にtimespecadd/timespecsubがあると思いますよね？ところが一部のlibc（BSD系やnewlib）以外は実装していません。なぜ……！？

#define timespecadd(a, b, res)					\
	do {							\
		(res)->tv_sec = (a)->tv_sec + (b)->tv_sec;	\
		(res)->tv_nsec = (a)->tv_nsec + (b)->tv_nsec;	\
		if ((res)->tv_nsec >= 1000000000) {		\
			(res)->tv_sec++;			\
			(res)->tv_nsec -= 1000000000;		\
		}						\
	} while (0)
#define timespecsub(a, b, res)					\
	do {							\
		(res)->tv_sec = (a)->tv_sec - (b)->tv_sec;	\
		(res)->tv_nsec = (a)->tv_nsec - (b)->tv_nsec;	\
		if ((res)->tv_nsec < 0) {			\
			(res)->tv_sec--;			\
			(res)->tv_nsec += 1000000000;		\
		}						\
	} while (0)
#define timespecclear(tsp)    ((tsp)->tv_sec = (tsp)->tv_nsec = 0)
#define timespecisset(tsp)    ((tsp)->tv_sec || (tsp)->tv_nsec)
#define timespeccmp(a, b, cmp)					\
	(((a)->tv_sec == (b)->tv_sec) ?				\
		((a)->tv_nsec cmp (b)->tv_nsec) :		\
		((a)->tv_sec cmp (b)->tv_sec))

いつもstruct timespecを要求するAPIを使うたびにtimespecadd/timespecsubがなくて演算しづらさにイライラするので、コピペで使い回せるように実装例をメモしておきます。この程度なら誰が書いてもほとんど同じコードになると思いますが、気になる方のためにもし著作権が発生する場合はBSD 3条項ライセンス扱いでお願いします。

首都高バトルSteam版、フルチューン後の姿 - その3

目次: ゲーム

首都高バトル（Steam版）高ランクの車をひたすらフルチューンするやつの続きです。前回と合わせて8車種ほどフルチューンしました。もう飽きました。

SUZUKI SWIFT Sport(ZC33S)フルチューン

TOYOTA SUPRA RZ(JZA80)フルチューン

検索用にフルチューン後の主要パラメータを書いておきます。ちなみにスピード指標はギア比を最高速重視にすると高い数値になるので、参考程度です。

あとはインプレッサのどれかをフルチューンするかもなあくらいですが、あまり気力が沸きません。

ローダウンの謎

アップデート前は車高は下げれば下げるほどカーブが速くなる謎システムでしたが、アップデート後は限界まで車高を下げるとストレートで地面と擦って火花が出る＆逆に遅くなる変更が入ったそうです。キャプチャでは5段階のうち4まで下げた状態で撮っています。個人的には見た目は3か2くらいが一番バランスが良いですね。

RX-7のフロントRIDE HIGHT = -5

5まで下げるとおかしなことが起きる車もあって、RX-7はフロントを限界まで下げるとタイヤがフェンダーとボンネットを貫通して変な表示になります……。