2014年6月22日日曜日

AVR-GCC でタイマ割り込みに間に合わない場合(部分的に最適化レベルを変える)

タイマ割り込み中に行う処理は、当然だが割り込み間隔以下の時間で実行が終わるステップ数で書かないといけない。

AVR-GCC でコンパイルするときには、できるだけコードサイズを節約するために、最適化オプションをコードサイズ優先 (-Os) にすることが多い。しかし、タイマ割り込み中に実行する命令が多すぎて、割り込み間隔に間に合わないときには、割り込みハンドラの部分だけを速度優先 (-O3) で最適化してほしい。

これは下記のように 割り込みハンドラの前に #pragma を置いて最適化レベルを速度優先 (-O3) と指定すれば実現できる。割り込みハンドラの後ろにも #pragma を置いて、最適化レベルをコードサイズ優先 (-Os)に戻す

#pragma GCC optimize ("O3")
ISR(SIG_OUTPUT_COMPARE0A) {
  タイマ割り込み中に行う処理
} 
#pragma GCC optimize ("Os")

コンパイルするときに下記のように -Os オプションを付ければ、割り込みハンドラ以外はコードサイズ優先 (-Os) で、割り込みハンドラ部分だけ速度優先 (-O3) で最適化される。

% avr-gcc -g -Os -mmcu=atmega8 -o out.o main.c

2014年6月19日木曜日

AVR-GCC 用内蔵 EEPROM 簡易ファイルシステム

ダウンロード

MEGA8 と TINY85 で動作確認したが、おそらく他の AVR でも使える。avr-gcc, avr-libc でプログラミングする人向け。

解説

多くの AVR マイコンには EEPROM (不揮発性メモリ) が内蔵されている。容量は少ない機種で 64Byte、多くても数キロバイト程度だが、電源を切っても消えないので、設定やデータをちょっと保存するのに便利だ。

AVR 用のライブラリ avr-libc には EEPROM を読み書きする関数があるので、バイト単位やワード単位でアドレスを指定して読み書きできる。しかし、EEPROM に複数の可変長のデータを保存したい時など、もう少しだけ扱いやすい読み書きの手段が欲しい。自分は赤外線リモコンを作った時に学習データ(可変長。複数。学習のたびに書き換えが必要)を保存するために必要だった。

そこで、AVR 内蔵 EEPROM 用に簡易ファイルシステムを作ってみた。C 言語でファイルアクセスする時の open(), close() といったスタイルをまねてはいるが、必要最小限の機能のみに絞った。原理はおそらく誰もが思いつく一番単純な方式。

コードサイズは1kB弱。使わない関数をコメントアウトすればもう少しだけ小さくできる。

使用例


例として、MEGA8 を PC のシリアルポートに接続して、MEGA8 から出力した文字列を PC に表示させる回路を作った。



MEGA8 に書き込んだデモのコードは次の通り。このプログラムは、文字列を直接シリアルポートに出力するのではなく、一旦ファイルに保存して、ファイルから読みだした文字列をシリアルポートに出力するというもの。

// EEPROM 用簡易ファイルシステムのデモ (ATMEGA8)
#include <avr/io.h>
#include <avr/eeprom.h>
#include "fs.h"

// シリアルポートの初期化(1200bps, MCU クロック=1MHz)
void uart_init(void) {
  UCSRB  = _BV(TXEN);
  UBRRH=0;  UBRRL= 51;
}

//
// シリアルポートに1文字出力
//
void  uart_putchar(char c) {
  loop_until_bit_is_set(UCSRA, UDRE);
  UDR = c;
  return;
}

// メイン
//
int main(void) {

  uint8_t fileName;
  char buf[100];
  char *pt;

  uart_init();
  fs_init();

  fileName = 0;
  if (fs_ropen(fileName) == FS_OK) {
    // ファイル0 がオープンできたら、ファイルからシリアルポートに出力
    // 1行目表示
    while (!fs_EOF()) uart_putchar(fs_read_b());
    // 2行目表示
    fileName = 1;
    fs_str_r(buf, fileName, 100);
    pt=buf;
    while (*pt) { uart_putchar(*pt); pt++; }
  } else {
    // ファイル0 がオープンできなかったら、文章をファイルに書き込む
    fileName = 0;
    if (fs_wopen(fileName) == FS_OK) {
      char* pt = "恥の多い生涯を送って来ました。"
        "自分には、人間の生活というものが、見当つかないのです。\r\n";
      while (*pt!='\0') { fs_write_b(*pt); pt++; }
      fs_wclose();
      fileName = 1;
      fs_str_w("自分は東北の田舎に生れましたので、汽車をはじめて見たのは、"
               "よほど大きくなってからでした。\r\n", fileName);
    }
  }
  while (1); // どちらかの処理をした後は無限ループ
  return 0;
}


このソースファイル(main.c) と同じ場所に "fs.c" と "fs.h" を置き、コンパイルするときに fs.c にある関数がリンクされるようにする。コンパイルの手順はこんな感じ。

# コンパイルとリンク,Intel HEX 形式の出力
% avr-gcc -g -Os -mmcu=atmega8 -o out.o main.c fs.c
% avr-objcopy -j .text -j .data -O ihex out.o out.hex

ヒューズは MEGA8 のデフォルト(hfuse=0xd9, lfuse=0xe1)にする。

生成した out.hex を MEGA8 に書きこんだら、上記の回路図に従って MEGA8  を PC のシリアルポートに接続して、PC 上で TeraTerm を起動する。TeraTerm でシリアルポートを 1200bps に設定する。

1回目の電源ONではファイルが存在しないため、fs_ropen(fileName) はエラーを返すので、ファイルに文字列が書き込まれるだけで、シリアルポートには何も出力されない。2回目以降の電源 ON ではファイルが存在するので fs_ropen(fileName) に成功して分岐し、ファイルから文字列が読み出されシリアルポートに出力される。Teraterm で見ると、2回目以降の実行ではちゃんと文字列が出力されている。



ファイルシステム fs.c の使い方

 使い方は次の通り。ファイル名(というかファイル番号) は、0~255 の値1バイトのみ。

ファイルから読み込む場合は、まず fs_ropen(fileName) でファイルを読み込みモードでオープンする。続けて fs_read_b() (8bitの場合)または fs_read_w() (16bitの場合) を繰り返して読み込む。読むと自動でポインタが進む。最後まで読むと fs_EOF() が真になる。読み込みモードでオープンした場合はクローズはしなくてもよい。

ファイルに書き込む場合は、まず fs_wopen(fileName) でファイルを書き込みモードでオープンする。fs_write_b(8bit値) または fs_write_w(16bit値) を繰り返して書き込む。書き込むと自動でポインタが進む。書き終わったら fs_wclose() でクローズする必要がある。

オープンできるファイルは、読み込みと書き込み合わせて1つだけ。同時オープンはできない(EEPROM の書きこみ/読み込み位置を保持している変数が1つしかないため)。

オープン、クローズの手続きが不要で、文字列を一気に読み込む fs_str_r(buf, fileName, maxlen) という関数と、 同じく文字列を一気に書き込む fs_str_w(buf、fileName) という関数もある。文字列を扱うならそちらの方が便利。

構造

全てのファイルの先頭に3バイトのヘッダを付けて EEPROM に格納する。ヘッダの1バイト目はファイル名、2~3バイト目はファイルサイズ。ファイルは詰めて記録し、最後のファイルの後に終了マークとして 0xFF を3バイト書く。構造はこれだけ。

ファイルが何もない状態から、ファイル名=2 のファイル(サイズ=10バイト)を書き込み、次にファイル名=0のファイル(サイズ=15バイト)を書き込むと、EEPROM は下の図のような状態になる。

もし下記のような状態でファイル2が削除されたときは、その下にあるファイル0を上方向(低アドレス側)に詰める。つまりファイル0のヘッダとファイル0の実体、終了マーク全体を13バイト上にずらす EEPROM のコピーの動作が自動的に行われる。非効率的で遅いが、EEPROM のサイズは小さいので、このような力技でもなんとかなる。もっとも頻繁にファイルの削除や更新が発生する用途やタイムクリティカルな用途には向かない。

fs.h で指定された EEPROM のアドレス範囲外には書き込みが行われないようにアドレス範囲をチェックしていて、もしアドレス範囲をオーバーしている時は実際の書き込みは行わず、戻り値でエラー(FS_DISKFULL) を返す。ファイルの書き込み後にはファイルクローズが必要だが、クローズ時にアドレス範囲のオーバーが発生していないことを再度確認している。なので、書き込み後にはファイルをクローズして fs_wclose() の戻り値が FS_OK になっていることを確認する必要がある。

EEPROM のデータ構造 (ファイル2とファイル0の2個のファイルが保存されている状態)


定義

注: ソースファイルの方の変数の型の書き方を変更しました (例: unsigned char → uint8_t など)。プログラムの動作は変わりませんが、下記の説明の型とは食い違っています。

定数
#define EEPROM_FS ((uint8_t *)0)
ファイルシステムで使用したい EEPROM の先頭アドレスを fs.h 内のこの #define 文で指定すること。普通はこの例のようにアドレスに 0 を指定すればよい。 EEPROM の先頭アドレスから使用される。


定数
#define FS_SIZE (E2END-(unsigned int)EEPROM_FS+1-4)
ファイルシステムで使用したい EEPROM のサイズを fs.h 内のこの #define 文で指定すること。E2END が EEPROM の最終アドレス(avr-libc で定義済み)。EEPROM の全領域を使用するなら E2END-EEPROM_FS+1 を指定する。ただし EEPROM の末尾 4バイトはフラッシュメモリの書き込み回数の記録に使われることが多いので、普通はこの例のように -4 して末尾 4 バイトを空けたほうが良い。

マクロ
char fs_EOF()
fs_ropen() による読み込みオープン中のみ有効。オープン中のファイルに、まだ読めるデータが残っていれば偽、すでに最後まで読み終わっていれば真になる。実体はマクロ。

引数
  なし
戻り値
  ファイルを最後まで読み終わっていれば真

マクロ
void fs_format()
ファイルをすべて削除する。ファイルシステムに割り当てられた EEPROM の全領域に 0xff を書き込む(実際は先頭3バイトと末尾3バイトのみに 0xff を書きこめば事足りるが、コードの簡略化のため全領域に書いている)。出荷時の AVR の EEPROM は全領域が 0xff なので、フォーマット済みとして扱える。実体はマクロ。

引数
  なし
戻り値
  なし

関数
void fs_init(void);
ファイルシステム関係の変数を初期化する。コードの先頭で1回実行する。

引数
  なし
戻り値
  なし

関数
unsigned char fs_delete(unsigned char fn); 
指定したファイルを削除する。

引数
  fn: ファイル名
戻り値
  FS_OK: 削除に成功した
  FS_NOTFOUND: 指定されたファイルは存在しない

関数
unsigned char fs_ropen(unsigned char fn);
引数で指定したファイルを読み込みモードでオープンする。読み込みでオープンした場合はクローズはしなくてもよい。ファイルがオープンされている間は次の変数が使える(下記の変数は読み込みのみ。変更してはいけない)。

unsigned int fs_size: オープン中のファイルのサイズ
uint8_t *fs_pt: 現在の読み込み位置(EEPROM のアドレス)

引数
  fn: ファイル名
戻り値
  FS_OK: オープンに成功した
  FS_NOTFOUND: 指定されたファイルは存在しない

関数
unsigned char fs_read_b(void);
読み込みモードでオープン中のファイルから 8bit 値を読み込む。

引数
  なし
戻り値
  8bit値

関数
unsigned int fs_read_w(void);
読み込みモードでオープン中のファイルから 16bit 値を読み込む。EEPROM での 16bit 値のバイトオーダーは下位-上位の順(リトルエンディアン)。

引数
  なし
戻り値
  16bit値

関数
unsigned char fs_wopen(unsigned char fn);
指定したファイルを書き込みモードでオープンする。引数で指定したファイルがすでに存在していた場合は、書き込みモードでオープンした時点で削除される。ファイルがオープンされている間は次の変数が使える(下記の変数は読み込みのみ。変更してはいけない)。

unsigned int fs_size: 書き込んだサイズ
uint8_t *fs_pt: 現在の書き込み位置(EEPROM のアドレス)

引数
  fn: ファイル名
戻り値
  FS_OK: オープンに成功した

関数 
unsigned char fs_write_b(unsigned char val);
書き込みモードでオープン中のファイルに 8bit 値を書き込む。

引数
  val: 8bit値
戻り値
  FS_OK: 書き込みに成功した
  FS_NOTFOUND: 書き込みモードでオープンされていない
  FS_DISKFULL: 容量の限界のため書き込めなかった

関数
unsigned char fs_write_w(unsigned int val);
書き込みモードでオープン中のファイルに 16bit 値を書き込む。EEPROM での 16bit 値のバイトオーダーは下位-上位の順(リトルエンディアン)。

引数
  val: 16bit値
戻り値
  FS_OK: 書き込みに成功した
  FS_NOTFOUND: 書き込みモードでオープンされていない
  FS_DISKFULL: 容量の限界のため書き込めなかった

関数
unsigned char fs_wclose(void);
書き込みモードでオープン中のファイルをクローズする。この関数が FS_OK を返さなかった場合はファイルは書き込まれていない。書き込み後にこの関数を呼ばなかった場合も、ファイルには書きこまれない。

引数
  なし
戻り値
  FS_OK: 書き込みに成功した
  FS_NOTFOUND: 書き込みモードでオープンされていない
  FS_DISKFULL: 容量の限界のため書き込めなかった

関数
void fs_str_w(char* str, unsigned int fn);
fn で指定したファイルに、文字列 str を書き込む。 str は '\0' で終端されている必要がある。処理はこの関数だけで完結するので、別途ファイルをオープン、クローズする必要はない。

引数
  str: 書き込む文字列へのポインタ
  fn: ファイル名
戻り値
  なし

関数
char* fs_str_r(char* str, unsigned char fn, unsigned int maxlen); 
fn で指定したファイルから、文字列 str に読み込む。maxlen には str に読み込める最大の長さ(終端のための '\0' を含む)を指定する。読み終わった場合も、maxlen の制限で読み込みが中断した場合も str は '\0' で終端される。処理はこの関数だけで完結するので、別途ファイルをオープン、クローズする必要はない。

引数
  str: 書き込む文字列へのポインタ
  fn: ファイル名
  maxlen: str に読み込める最大の長さ(終端のための '\0' を含む)
戻り値
  str: str のポインタを返す

関数
unsigned int fs_free(void);
空き容量を返す。

引数
  なし
戻り値
  空き容量を返す
 

公開される変数
extern unsigned char fs_filename;
  オープン中のファイル名

公開される変数
extern unsigned int fs_size;
オープン中のファイルのサイズ。特定のファイルのファイルサイズを知りたいときは、試しにfs_ropen(unsigned char fn) してから fs_size の値を読む。


公開される変数
extern uint8_t *fs_pt;
  現在読み書き中のポインタ(EEPROM のアドレス)


2014年6月3日火曜日

AVR がウォッチドッグタイマ発動後に再起動を繰り返す問題

AVR マイコンにはウォッチドッグタイマが搭載されている。 ウォッチドッグタイマとは、メインプログラムの実行とは独立に勝手にカウントアップされていくカウンタで、そのカウンタがオーバーフローすると強制的にマイコンにリセットがかかるというものである。よってウォッチドッグタイマを有効にしたときには、メインプログラム側で、定期的にウォッチドッグタイマの値を0にクリアする命令を実行しないといけない。

これが何の役に立つかというと、例えば異常が発生してメインプログラムが無限ループにはまった時には、ウォッチドッグタイマがオーバーフローして自動的にリセットしてくれる。よって、完全に固まるという最悪の状況だけは避けることができる。

※ もっとも、運悪く無限ループの中にウォッチドッグタイマの値を0にクリアする命令が含まれていた場合は、ウォッチドッグタイマを有効にしていたとしても固まってしまうが。

他の使い方もある。例えば AVR にはリセット命令がないので、ソフトウェアからリセットするには、ウォッチドッグタイマを有効にした上で無限ループを実行するのが正規のやり方だそうである。

今回、赤外線リモコンの制作で、AVR が暴走した時のために、ATTiny85 のウォッチドッグタイマを 有効にした。AVR-libc のマクロ (avr/wdt.h) を使えば簡単に設定できる。実際に無限ループに陥った時には、ウォッチドッグタイマはきちんと動作して、リセットがかかってくれた。ところがその後がよくない。リセットがかかった直後にまたウォッチドッグタイマによるリセットが再発生し、再起動を繰り返してしまう。

これは一部の新しい AVR のみに発生する現象のようで、AVR-libc のマニュアルに回避策が書いてあった。ただ意味がちょっとわかりにくかったので、その部分をチョー訳してみた。

ソースファイルのどこかに下記の緑色の部分のコードを書いておけば、ウォッチドッグタイマによるリセットの後に、自動的にウォッチドッグタイマが無効になる。main() の途中で改めて wdt_enable() を使ってウォッチドッグタイマを有効にすればよい。

AVR-libc のドキュメントWatchdog timer (日本語)より


(原文)
Detailed Description
#include <avr/wdt.h>
This header file declares the interface to some inline macros handling the watchdog timer present in many AVR devices. In order to prevent the watchdog timer configuration from being accidentally altered by a crashing application, a special timed sequence is required in order to change it. The macros within this header file handle the required sequence automatically before changing any value. Interrupts will be disabled during the manipulation.

Note:
Depending on the fuse configuration of the particular device, further restrictions might apply, in particular it might be disallowed to turn off the watchdog timer.

Note that for newer devices (ATmega88 and newer, effectively any AVR that has the option to also generate interrupts), the watchdog timer remains active even after a system reset (except a power-on condition), using the fastest prescaler value (approximately 15 ms). It is therefore required to turn off the watchdog early during program startup, the datasheet recommends a sequence like the following:

    
#include <stdint.h>
#include <avr/wdt.h>
uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) __attribute__((naked)) __attribute__((section(".init3")));
void get_mcusr(void)
{
  mcusr_mirror = MCUSR;
  MCUSR = 0;
  wdt_disable();
}

(日本語訳)
詳細説明
#include <avr/wdt.h>
このヘッダファイルには、多くのAVRデバイスでサポートされているウォッチドッグタイマを扱うためのインラインマクロへのインタフェースが書かれている。アプリケーションがクラッシュして誤った警報を出さないように、ウォッチドッグタイマの設定を変更する時は特殊なタイミングの手続きが必要である。このヘッダファイルにあるマクロを使って変更すれば、変更前にその手続きが自動的に行われる。 変更中は割り込みは禁止される。

注意:
デバイスのヒューズの設定によっては、とくにウォッチドッグタイマの無効化が禁止されている場合には、さらなる制約がかかることがある。

新しいデバイス(ATmega88 以降。割り込みを生成するオプションがあるデバイス)では、(電源 ON の直後を除く)システムリセットの後でもなお、ウォッチドッグタイマが有効のままになり、最速のプリスケーラ値(約15ms)が設定されることに注意が必要である。そのため、データシートでは、プログラムの起動時の最初の方で、次のようなシーケンスでウォッチドッグを無効にするように要求している。
    
#include <stdint.h>
#include <avr/wdt.h>
uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void get_mcusr(void) __attribute__((naked)) __attribute__((section(".init3")));
void get_mcusr(void)
{
  mcusr_mirror = MCUSR;
  MCUSR = 0;
  wdt_disable();
}
 



さて、この問題が起こる「新しいデバイス」とはどのデバイスのことなのか。マニュアルの記載からはわかりにくいが、ウォッチドッグタイマのオーバーフロー割り込みを持つ AVR マイコンという事だと思う。

同じく AVR-libc のマニュアルの「interrupt」の所に、各割り込みを持つデバイスはどれかの表がある。表によれば、下記の (1)~(3) に名前があるデバイスには上記の対応が必要のようだ。

(1) WATCHDOG_vect (SIG_WATCHDOG_TIMEOUT)
ATtiny24, ATtiny44, ATtiny84

(2) WDT_OVERFLOW_vect (SIG_WATCHDOG_TIMEOUT, SIG_WDT_OVERFLOW)
ATtiny2313

(3) WDT_vect (SIG_WDT, SIG_WATCHDOG_TIMEOUT)
AT90PWM3, AT90PWM2, AT90PWM1, ATmega1284P, ATmega168P, ATmega328P, ATmega32HVB, ATmega406, ATmega48P, ATmega88P, ATmega168, ATmega48, ATmega88, ATmega640, ATmega1280, ATmega1281, ATmega2560, ATmega2561, ATmega324P, ATmega164P, ATmega644P, ATmega644, ATmega16HVA, ATtiny13, ATtiny43U, ATtiny48, ATtiny45, ATtiny25, ATtiny85, ATtiny261, ATtiny461, ATtiny861, AT90USB162, AT90USB82, AT90USB1287, AT90USB1286, AT90USB647, AT90USB646

たとえば、自分の使っているデバイスでは、ATmega8, ATmega64 はこのリストにないが、ATmega88, ATtiny85 は含まれている。

2014年6月2日月曜日

どんな信号でも学習できる赤外線リモコンを作りたい

(2015/2/28 補足) 本文中に部品選択に関する記述がありますが、いろいろな製品で試した結果、現在推奨している赤外線受信ユニットは GP1UXC41QS、赤外線 LED は L-53F3BT です。

(2016/7/1 補足) Digispark 赤外線受信シールドに使われている赤外線受信ユニット TSOP38238 も適していますが、国内での入手が難しいかもしれません。

 まえがき

AVR マイコンATTiny85 で学習型万能赤外線リモコンを作った。

※ エアコンのリモコンも学習できるようになった
※ 実際に作ってみたい方は Wiki (←リンク) を参照 。
※ この技術を応用して USB から制御できる赤外線リモコン(リンク)を作成した。

プリント基板版

ブレッドボード版


実際に作ってみるまで分からなかったことが結構あって、今後赤外線リモコンを一から自作する人の参考になるかもしれないので、こちらのブログに、感想とか工夫した点とかノウハウっぽいことを書いておく。

赤外線リモコンの制作は電子工作ワールドでは人気テーマで、検索すると制作例が山のように出てくるので、新しく開発するからには何か特徴がないとおもしろくない。そういうわけで、今回の設計では「リモコンの種類(通信フォーマット)によらずなんでも学習できる」赤外線リモコンを作ることを目標にした。

また、ピン数の足りない安い8pinのマイコンで作れるように、学習と送信とその他の操作を全て1ボタンで操作できるようにした。

「なんでも学習できる」リモコンをわずかなメモリしかないマイコンで作るのは大変だ。受信した赤外線データを生のまま不揮発メモリ(内蔵EEPROM)に記憶して、それを送信する仕組みにすれば「なんでも学習できる」は実現できるが、そのためには生データを記憶しておくための不揮発メモリが大量に必要になるためだ。

これを解決するにはデータを圧縮するしかない。しかし、どんなデータでもきっちり圧縮できる (ZIPみたいな) 本物の圧縮アルゴリズムを作るのは難しいし、特にコード用のメモリも RAM も少ないマイコンで実装するのは簡単ではなさそうだ。そこで「赤外線リモコンに特化した、簡単で万能で効率の良い圧縮アルゴリズムを考える」という作戦にした。

工夫の結果、自分の身の回りのリモコンについてはほとんど学習して不揮発メモリに保存できるようになった。ただ圧縮がリアルタイムではできない(赤外線信号をサンプリングする速度に追いつかない)ため、圧縮前の生データを一時的にマイコンのメイン RAM に記録する必要があり、そこがネックになっている。メイン RAM のサイズが 512バイトのマイコンでは、1つの信号が RAM サイズを超えるために学習できなかったエアコンのリモコンがある。可能ならいずれ改良したい。 → この問題は、赤外線の受信中にリアルタイムにランレングス圧縮を行う機能を実装して解決した。

赤外線リモコンのフォーマット


赤外線リモコンのフォーマットについては、ELM さんの「赤外線リモコンの通信フォーマット」がとても詳しい。これによると、日本では主に NECフォーマット、家製協(AEHA)フォーマット、SONYフォーマットが使われているので、この三種類の規格に対応できればよさそうだ。

と思っていたがこれはだいぶ甘くて、実際に身の回りのリモコンの信号をサンプリングして見てみると、微妙に規格に沿っていないものがかなり多かった。

まずは手持ちのリモコンの信号を片っ端からサンプリングして見てみることにする。AVR マイコンでサンプリングした信号をシリアルで出力して、可視化するプログラムを VisualBasic 2008 で作ってみた。やはり可視化は重要で、生の数字を見るよりはるかに分かりやすい(赤い線と緑の線があるが、圧縮する際の参考用に色を変えているだけなのでここでは無視してよい)。

サンプリングした信号を可視化するプログラム(Visual Basic 2008)
Hが点灯、Lが消灯状態。赤外線受信モジュールの出力は負論理でこの図とは逆なので注意。
搬送波は赤外線受信モジュールで除去済み。

テレビのリモコンのフォーマットはばらばら

ビデオプレイヤーなどの AV 機器のリモコンにはたいてい他社のテレビを操作する機能がある。試しに Panasonic のブルーレイレコーダ DMR-BR670V のリモコンで、各社のテレビのリモコンの「電源」ボタンの信号をサンプリングしてみた。メーカー名の後のカッコの数字はこのブルーレイレコーダ独自のメーカーコード。同じメーカーに複数のメーカーコードが割り当てられているのは、同じメーカーでもテレビの機種によって送信するデータが異なる場合があるということ。


上の図を元の大きさで表示する
 ※ 図の1ドット=50[μs]。Hが点灯、Lが消灯状態。赤外線受信モジュールの出力は負論理でこの図とは逆なので注意。
各社のテレビのリモコンの赤外線フォーマット(各社対応リモコンからサンプリング)
サンプリング結果を観察してまとめてみたのが上の表。フォーマットはかなりばらばらだ。特に特殊なのはシャープ、ビクター、三菱のテレビだが、それ以外にも独自フォーマットの機種がある(上の図と対応させるために、全く同じデータの場合も表には重複して載せている)。

独自フォーマットのシャープ(02)とシャープ(11)にはリーダーがない。 また 30~50[ms]の間隔をあけて2つの異なるパターンが連続で送られてくるので、両方記録しないといけない(※図にはないが、シャープのVHSビデオデッキ VC-VS1 もこれと同じフォーマットだった)。シャープ(21)は素直な家製協フォーマット。シャープは昔は独自フォーマットだったが、最近の製品は家製協フォーマットに準拠したということだろうか。

ビクター(14)はリーダに続いてまず16bitのデータを送信する。その後同じデータが反復されて送られてくるが、反復の方にはリーダがなく、いきなり16bitデータから始まっている。手元にあったビクター製VHS/DVDデッキ用リモコン(RM-SHR013J)も同じフォーマットなので、これがビクター独自のフォーマットなのだろう。

三菱(08)と三菱(12)はリーダはなく、データも6bitのみ。必要最小限といった感じ。

受信側の機器の挙動にも注意が必要。Panasonic のアナログテレビ TH-15FA5 は、電源を OFF にするときは、素直な家製協フォーマットの信号に反応する。その直後は同じ信号で電源 ON にできる。しかし、電源を OFF にしたあと数分たつと、テレビが内部的にパワーセーブモード(?)になるらしい。パワーセーブモードからは、電源 ON のパターン1つを受信しただけでは ON にならず、最低1回は同じデータを反復受信しないと電源が入らない。さらにその場合は、最初のデータと反復データの間が40ms以上開いていないと電源が入らなかった。誤動作しないように、電源 ON のボタンだけは厳密に判定しているようだ(※シャープの AQUOS テレビ LC-20DZ3(家製協フォーマット) も同じような挙動)。

テレビ以外のリモコンのフォーマット

テレビ以外の機器のリモコンもサンプリングしてみた。

上の図を元の大きさで表示する
※ 図の1ドット=50[μs]。Hが点灯、Lが消灯状態。赤外線受信モジュールの出力は負論理でこの図とは逆なので注意。
テレビ以外のリモコンの赤外線フォーマット


三洋のプロジェクタ LP-XP100L は天吊りの大型のもの。ビクターの DVD プレイヤー RM-SHR013Jはビクターの独自フォーマットだった。シャープのエアコン(AY-Z22VX)は家製協フォーマットのようだがやたらに長い。蛍光灯のリモコンの信号もやたら長い。

TV会議システム VSX7000 は、米国 POLYCOM 社の製品。
これはちょっとクセのある挙動をする。1つのボタンに2つのパターンが割り当てられていることがあって(数字ボタンなど)、そのボタンを押すたびに2つのパターンが交互に出力される。また、リモコン本体を床から持ち上げるとスイッチが入って、自動でいくつかの信号を送信する。

WOLFVISION の卓上カメラはこういう製品。リモコンのフォーマットはソニーフォーマットに似ていた。(後に自作リモコンが完成した後に試したところ、電源 OFF は確実にできたが、電源 ON に失敗することが多い。原因は不明) → (2015/2/28 補足: 若干長めに学習してしまうバグがあったため。修正したら ON/OFF ともできるようになった。ただし赤外線の到達距離が短く、近距離からのみ)。





赤外線信号の保存形式(EEPROM 保存時の圧縮)


以上の観察結果をふまえて、赤外線信号の保存形式を設計することにする。

万能のリモコンにするためには、どんなフォーマットだったとしても正しく保存・再生ができる必要がある。また、容量の節約のためにできる限り短いデータ形式で保存したい。そこで、受信した赤外線信号を次の形式で EEPROM に保存する。

まず、基本方針として、一連の赤外線パルスの発光時間を、そのまま生で保存することにする。ただし、信号の途中にビット列とみなして短縮(圧縮)形式で保存できる部分が見つかった場合は、その部分は可能な限り短縮形式で保存する。

まずは圧縮せずに、発光時間を生のまま保存する方法について。信号がうまく圧縮できない場合はこの方式で記録することになる (ただし後述の方法で、部分的にでも圧縮できるところは圧縮する)。

どんな赤外線信号でも、最初は赤外線 ON から始まって一定時間継続し、その後にOFF が一定時間継続する。これの繰り返しである。そこで、ONの継続時間と OFF の継続時間を測定して、15bit の値としてそのまま保存する(時間は2バイト値で保存するが、後述する短縮形式との区別のため、最上位ビット(MSB)は常に0にしておく。そのため実際のデータが保存できるのは 15bit)。この形式では必ず ON と OFF のペアで記録することにし、一つの ON+OFF のペアで 4バイトのメモリを消費する。時間の計測は 72kHz の割り込みで行っているので、1[秒]÷72[kHz] = 13[μs] が1単位になる。15bit 値では 32767 まで表現できるので、ON も OFF も最大 32767 * 13[μs] = 425971[μs] = 425.971[ms] までの時間が記録できる。



赤外線信号の記録形式 (EEPROM上のフォーマット)

次に圧縮の方法を考える。圧縮のための短縮形式で記録する方法について。

赤外線信号にはさまざまなフォーマットがあるが、大抵どれも下の図に示した 「短いON」「長いOFF」「長いON」「短いOFF」 の4種類の時間の組み合わせで表現できる(リーダーや区切りなど特殊な部分以外は)。そこで、取り込んだ信号全体を一度プレスキャンして、4種類の時間がそれぞれ何μs になっているかを、パルス長の平均をとるなどしてがんばって求める。そしてこの4種類の長さを EEPROM の別の領域に保存しておく。
赤外線信号を構成する4種類の長さ

実はここに工夫できる余地がある。一種類のリモコンには、普通はこの4種類の時間のうち3種類しか存在しない。なぜかというと、一般的なフォーマット(NEC、家製協、ソニー、ビクターなど) はどれも、ON か OFF かどちらかの長さは固定で、もう片方の長さで1か0かを表現しているから。そのため、普通は、プレスキャンした結果を見ると「(A) 短いONと長いONは同じ長さだった」 または「(B) 長いOFFと短いOFFは同じ長さだった」のどちらかの結果になる。つまり4つの値のうち、(A)または(B)は同じ値になる。

同じ値があっても気にせずに、取り込んだ一連の信号と上の4つの値を順次比較し、取り込んだ信号の中に「長いON+長いOFF」 が見つかったら 1 「短いON+短いOFF」が見つかったら 0、としてエンコードする。この2種類以外のパターンは考慮しなくてよい(比較する時には測定誤差を考慮して若干のマージンを持たせる)。

以上の方法で判定すると、結局、下の表の上の段の4つのパターンは1として、下の段の2つのパターンが0として判定される。 これだけで、一般的なフォーマット(NEC、家製協、ソニー、ビクターなど) なら、うまい具合に 0 と 1 のビット列に変換でき、後から同じ波形を再生できる。再生する時は、同じ4つの値を使って、ビットが1なら「長いON+長いOFF」 を、0なら「短いON+短いOFF」を出力すればよい。

※ 分かりにくいので補足: 要するに長いONまたは長いOFFのどちらかを含むパターンは1、どちらも含まないパターンは0とエンコードするということ。一般的なフォーマット(NEC、家製協、ソニー、ビクターなど)ならこの方法で再現できる。


※ ただし1と0のパルス長が同じ長さのフォーマット(変調方式が PPM でない)もあり、その場合はこの方式でビット列化できない 。YUASA の扇風機のリモコンはそうだった。その場合は圧縮できないので生で記録するしかない。

 0 と 1 の列に変換したら、ヘッダを付けて 0/1 のビット列を記録する。ヘッダは目印として MSB(最上位ビット) を 1 にする。ヘッダの MSB 以外の 7bit には、その後に続くデータのビット数を格納する。続くデータの長さが中途半端な場合は 8bit 単位でパディングする。

もしこの方法でエンコードしている最中に、0とも1とも判定されない長さのパルスが出てきたら(信号の途中にリーダーや区切りが入っているとそうなる)、一旦パディングしてビット列の短縮記録を止め、その特殊な長さのパルスだけは生のまま4バイトを使って記録す る。その後にまたヘッダを付けて、ビット列の記録を再開する。

受信した信号を 0/1 の列に変換する (EEPROM上のフォーマット)

一旦ビット列に直せれば、その後はいろいろな圧縮アルゴリズムが適用できるが、今回はこれ以上圧縮せずにそのまま記録している。

最悪のケースでは、全くビットに直せない信号の場合には全て生のまま記録することになるが、ともかくこの方法なら、どんな信号がやってきても記録することができる。

追加: リアルタイムランレングス圧縮 (エアコンのリモコン対策)


上に 「赤外線信号の保存形式(EEPROM 保存時の圧縮)」 として、EEPROM に保存する時に容量を節約する方法について書いた。これによって、保存先の容量は少なくてもよくなった。大抵のリモコンの信号が96バイト以内に収まるようになるので EEPROM が512バイトのマイコンでもある程度の信号が保存可能である。

保存するときはそれでよいが、問題はリアルタイムに学習している最中のメモリ不足。学習中は受信した赤外線を一旦 RAM に記録し、これをあとで上記の方法で圧縮することになる。ところが TINY84 は EEPROM だけでなく、RAM も 512 バイトしかない。しかも、信号の保存専用に使える EEPROM と違って、RAM は変数やスタック (割り込みを使うと、割り込みの前後で多数のレジスタをスタックに PUSH/POP しないといけないため、結構なスタックが必要になる) のために消費されるので、赤外線信号の記録に使える RAM は、実質的には 330バイトくらいしかない。TV などの通常のリモコンなら収まるが、エアコンなどの長い信号は 330 バイトに収まりきらなくなる。そうなると学習できないという事になる。

そこで、学習時には RAM に記録する前にリアルタイムにランレングス圧縮を行い、RAM から読みだす時はリアルタイムに展開するようにした。この方法で、従来の方法では RAM 不足で学習できなかったダイキン、日立製エアコンの学習が可能になった

今回とった方法は以下の通り。まず RAM 上で数値を記録する時の表記方法の規定。下記の3種類のいずれかの形式で表現することにする。
RAM 上のフォーマット
0~63 までの数値は形式1、64~16383 までの数値は形式2で保存する (16384 以上の数値は表現できない)。形式2では、上位-下位の順に記録する。形式3はランレングス圧縮された値を示し、保存してある「直前の値」 を 「繰り返し長」の回数繰り返す。

「直前の値」について、今回の工夫として、RAM の奇数バイト目と偶数バイト目を分けて扱うことで圧縮効率を上げている。RAM に記録すべき生のリモコンの信号は 、ON の時間長と OFF の時間長を交互に並べたデータである。よって、常に偶数バイト目は ON の時間長、奇数バイト目は OFF の時間長を表している。ON 同士、OFF 同士は同じ値になることが多い。そこで、今回は「直前の値」として、着目しているのが奇数バイト目なら直前の奇数バイト目の値、偶数バイト目なら直前の偶数バイト目の値を使うことにした。

上記の表の表現形式でランレングス圧縮を行えば、データは短くなることはあっても長くなることはない。(奇偶ごとに1個おきに)同じ値が頻出する赤外線信号では、これだけで必要な RAM の量はかなり減る。

問題はマイコンでのランレングス圧縮の処理時間だった。赤外線信号の送受信はタイミングが重要なので、72kHz のタイマー割り込みのイベントハンドラ内で行っている。そのため、期間内(13.9μs)に送受信に関する全ての処理を終わらせないといけない。クロック数で言うと 222 クロックしかないわけで、今回そこにランレングス圧縮の処理が加わることになる。これは難しいかと思ったが、AVR-GCC の最適化オプションを速度優先 (-O3) にすることで何とか間に合った。

学習結果の EEPROM への保存

学習結果は AVR 内蔵の EEPROM (容量 512バイト) に保存する。その際、独自に開発した AVR-GCC 用内蔵 EEPROM 簡易ファイルシステム を使っている。ファイルシステムについては別途記事を書いたので、そちら (←リンク)を参照。



部品の選択

重要な部品は AVR マイコン、赤外線LED、赤外線受光ユニット、ピエゾブザーである。


AVR マイコン

ATTINY85-20PU-ND

回路の心臓部のマイコンには ATTiny85 を採用した。DIP 8pin(表面実装でないタイプ)の製品。価格は Digikeyで1個買うと199円。25個まとめ買いすると1個当たり161.16円。Aliexpress では 20個まとめ買いで1個当たり US$1.25 くらいの店があるようだ(Aliexpress は中国の通販サイト。送料無料の店もあるが、その場合注文してから届くまで遅いときには1か月くらいかかる)。マルツだと215円、秋月では扱っていない(2014年6月)。Futurlec は $5 の送料がかかるが(またこちらも届くまでちょっと時間がかかるが) 1個 $1.15 と安い。たくさん買うなら Futurlecで。

スペックは、フラッシュメモリ8KB, RAM512B, EEPROM512B。電源電圧は4.5~5.5V。以前 LAN から操作できる赤外線リモコンをATMega64(フラッシュメモリ64kB, RAM 4kB, EEPROM 2kB) で作成したことがあるが、今回の ATTiny85はそれと比べるとかなり非力。

ATTiny85 は CPU クロックに、内蔵発振回路(外付け部品なし)の 16MHzが使える(High Frequency PLL Clock)。これはとても重要。クロックを遅くすれば消費電力が減るので省電力的には有利なのだが、今回は RAM の少なさをカバーするため、学習中にランレングス圧縮を行うなど結構なことをしていて、72kHz の割り込み時間内にそれらの処理を完了させる必要がある。そのためクロックが 16MHz でないと間に合わないところがあった。

ATTiny85 にはシリアルインタフェースがない。学習したデータを出力して PCで確認する必要があったので、そのために後日ソフトウェア UART (送信部分のみ)を自作した。(追記: 後日受信部分も作成して、PC から本機をコントロールできるようにした)。

ケースの都合上、回路をボタン電池 LR44*3個の 4.5V で駆動する必要があり、 省電力が重要になった。一定時間操作がないときは AVR をパワーダウン状態にしている。パワーダウン中の消費電流は 2μA 以下。消費電力を削減するために、ADC やコンパレータをソフトウェア的に OFF にしている。また、内蔵プルアップ抵抗を使うとパワーダウン中の消費電力が激増するので、内蔵プルアップは使わず、外付けのプルアップ抵抗(10kΩ)にした。

問題はパワーダウン状態にするときに BOD(Brown-out Detector) を無効にしないと、パワーダウン中の消費電流が 20μA 以上に跳ね上がること。ATTiny85 のデータシートには「ソフトウェアで BOD  を無効にするためにはリビジョンが C 以降(ATtiny85, revision C, and newer) でないといけない」と書いてあるが、リビジョンの調べ方がわからない。リビジョンについて、まず米国 Digikey に問い合わせてみたが、明確な回答は得られず。次にアトメルジャパンに問い合わせたところ、「リビジョン C 以降にあたる製品は車載用の型番のみで、通常品では BOD をソフトウェアで ON/OFF することはできない」とのこと。やむを得ず、ヒューズビットの設定で BOD を常時無効にした。BOD が常時無効だと、ショックで EEPROM が消えることがあるがしかたがない。

ソフトウェアの開発には GCC (avr-gcc-4.5.1_1) を使った。 開発は FreeBSD9.2 で行った。avr-libc-1.8.0,1 を利用し、ソフトウェアは本当に一から全部作った。AVR への書き込みには FreeBSD でavrdude-5.11 を使い、FreeBSD マシンのパラレルポートと ATTiny85 を直結して書き込んだ。これらの必要なソフト (avr-gcc-4.5.1_1 avr-libc-1.8.0,1 avr-binutils-2.20.1_1 avrdude-5.11) は FreeBSD 9.2 の ports に全部あった。

#追記(2014/6/8)
マイコンに ATTiny85 を選択したのはなかなか絶妙だったかも。DIP 品があり、外付け部品なしでクロック16MHz が実現できる AVR 製品がほかにない。ATTiny85の難点は RAM が 512Byte な点。本当は RAM が 1kByte の品(ATMega8など)を使いたいのだが、ATMega8 を 16MHz で動かすには外付け部品が必要。ATMega8U2 なら、外付け部品なしでも 16MHz で動かせそうだが、DIP 品がない(おまけに高い)。

赤外線LED


OSIR5113A
(現在は L-53F3BT を推奨します)

ボタン電池 LR44*3個の 4.5V 電源で数mの距離から使えるリモコンを作るには、実質この赤外線 LED を選ぶしかなかった(2014/6/25: 電源をリチウムコイン電池 2個直列の 6V にする場合は、東芝の赤外線 LED,  TLN105B の方が照射角度が広くてよい。到達距離は結構短くなるが)。

2014/8/20 追記: TLN105B は入手しにくい(ディスコン?)。広角に照射したい場合は共立エレショップで取り扱いのある L-53F3BT を使う。

赤外線 LEDの使い方は通常の LED と同じだが、光っても肉眼で見えないので選ぶのが難しい。最終的には実際にリモコンとして使ってみて動作を見るしかなかったりする。主なパラメータは順方向電圧(VF)、最大電流、放射強度、半値全角など。もちろん小さい電流で放射強度が大きく、半値全角が広い方がよいが、トレードオフになっていて、どれかを犠牲にして選ばなくてはいけない。 TLN105B, TLN103, OSIR5113A などを試して、最終的にOSIR5113A を使うことにした(高輝度版のOSI5FU5113Aというのもあったが試していない→2014/6/21 高輝度版のOSI5FU5113A で試してみたが、大きな違いは見られなかった)。 OSIR5113A は VF=1.25V, 最大電流が 100mA, 半値全角が15度。指向性が強いので受信部を狙わないといけない。秋月で100個まとめ買いすると1個7円。安い。

電源がひ弱なアルカリボタン電池(4.5V)なので、赤外線 LED に直列に入れる電流制限抵抗の選び方は難しい。抵抗値が大きいと赤外線 LED の発光が弱すぎて本当に近くからしか使えなくなる。かといって抵抗値が小さいとボタン電池が電源の場合は、発光時に電源電圧が瞬間的に下がって誤動作するし、スイッチング電源などを電源にすると AVR に過電流が流れてリセットがかかる。ぎりぎりの選択で 51Ωにした。

2014/8/20 追記: 電源が 6V の場合は 100Ω にする。

赤外線受信モジュール


RPM7138-R
(現在は GP1UXC41QS を推奨します)

電源、GND、信号出力(VOUT)の三本足。電源を入れると VOUT が H になり、赤外線を受信している間だけ L になる。これもいろいろな製品が出ている。これまではずっと秋月で 1個50円くらいの製品(OSRB38C9AA等) を買って使っていたが、動作がデリケートで、電気的ノイズ、周囲の明るさや蛍光灯の影響で、赤外線信号が入っていないのに誤検出することがよくあって困っていた。

一度近所のマルツ仙台店で RPM7138-R を買ってみたら、使い勝手がすこぶるよかったので、以後少々高いけれどもずっとそれを使っている。まずこの製品は電源電圧がかなり下がってしまってもなんとか動作してくれる。また、オシロスコープを使って確認してみると、赤外線信号をかなり忠実にサンプリングできている。日本のロームという会社の製品で、ロームの赤外線モジュールのカタログを読んでみると、正確に受信するためにかなりいろいろな工夫をしていることがわかった。プラスチックパッケージで、電源電圧は 4.5-5.5V。消費電流は 1.5mA。マルツだと1個158円。Digikeyだと1個200円。10個まとめ買いすると1個当たり157.7円。

消費電流の 1.5mA は結構大きいので、赤外線受信モジュールの電源 を AVR の出力ピンからとって、不要なときは電源を切るようにしている。このような使い方をする時の注意点として、赤外線受信モジュールの電源を ON にした直後にすぐに受信を開始してはいけない。誤動作する。動作が安定するまで 100ms くらい待ってから受信をスタートするようにした。

低電圧(2.7V)で動作する版(RPM7238-R)も存在し、本当はそちらを使いたいのだがまだ手に入らない。低電圧版が手に入れば、システム全体を 3V のリチウムコイン電池で駆動できそうなのだが。

2014/7/7 追記:  低電圧で動作するロームの赤外線受信モジュール RPM7238-H8R(電源電圧: 推奨2.7~3.6V, 最大6.3V) を入手して試したところ、システム全体を 3V のリチウムコイン電池で駆動できた。赤外線信号の学習も特に問題なくできた。ただし低電圧版モジュールにはプラスチックパッケージ版がなく、全て金属シールド付きなので、回路はそのままでよいが、部品の配置を変更する必要がある。

2014/7/7 追記: RPM7238-H8R の金属シールドを外せば形状は 5V品の RPM7138-R と同じ。シールドを外してみても一応動作はしたが、ノイズ耐性などは不明。

2014/8/20 追記: 秋月の GP1UXC41QS が 2.7V~5.5V で動作し、ノイズにも強くてよいことが分かった。金属シールドはなく、外装はプラスチック。ピン配列はロームの赤外線モジュールと同じ。


ピエゾブザー


PKM13EPYH4000-A0

学習開始やエラーなどをビープ音で知らせるために、ムラタのピエゾブザー PKM13EPYH4000-A0 を使っている。秋月で1個30円。Digikey で1個68円。なぜかこの製品だけ安い。サイズが小さくてよいが音が少し小さい(今回は操作確認音に使うので音は小さくてもよしとする)。ブザー単品(円盤状の金属)だけでも売られていることがあるが、その状態だと本当にかすかな蚊の鳴くような音しか出ない。黒い樹脂ケース部分の設計が重要のようだ。ピエゾブザーは電圧をかけただけでは鳴らず、AVR で鳴らしたい音程のパルスを生成して送る必要がある。今回はタイマ割り込みで 440Hz と 880Hz の矩形波を作って鳴らしている。