高性能で低消費電力、32ビット・マイコンへ移行すべきか（前編）

　組み込み機器の世界は常に変化している。変化に気付いていないかもしれないが、10年前のマイクロコントローラを搭載した機器と、今日の最新マイクロコントローラを搭載した機器を比較すれば明らかだ。基板設計や部品パッケージ、集積度、クロック周波数、メモリーの容量など、すべてがいくつもの世代を経て変化していることに気付くだろう。

　組み込み機器の世界において、注目を集めている話題がある。8ビットや16ビットのマイクロコントローラをいまだに使い続けているユーザーが、最新の32ビット・マイクロコントローラにいつ移行するのかという話題だ。

　ここ数年、32ビット・マイクロコントローラへ移行する組み込み機器開発者が急激に増えている。本稿では、この移行を促している要因をいくつか取り上げて、前編、中編、後編の3編で検証していく。

　まずは、組み込み機器の開発者が32ビット・マイクロコントローラへの移行を検討すべき理由について述べる。

　最大の理由としては、組み込み製品に対する顧客や市場の要求が複雑になっているということが挙げられる。組み込み機器がインターネットへつながるようになり、より多彩な機能を提供するようになっている。8ビットや16ビットのマイクロコントローラの処理能力では、このように複雑で多様な要求に対応することが難しい。

　たとえ、8ビットや16ビットのマイクロコントローラを用いて現時点で進行しているプロジェクトに対応できたとしても、製品をアップグレードできる余地が極端に減ったり、同様の機器の開発でコードを再利用することが不可能になるなどの重大なリスクを抱えることになる。

　2つ目の理由としては、組み込み機器開発者が32ビット・マイクロコントローラに移行する利点に気付き始めたということが挙げられる。32ビット・マイクロコントローラは、8ビットや16ビットのマイクロコントローラに比べて、10倍以上の処理性能を発揮する。さらに、8ビットや16ビットのマイクロコントローラに比べて消費電力を低く抑えられ、プログラムのサイズを縮小でき、ソフトウエアの開発期間の短縮も可能になり、ソフトウエアの再利用率が高まる。ここに挙げた利点については後に詳述する。

　もう1つの理由として、32ビット・マイクロコントローラの品ぞろえ、入手しやすさが挙げられる。例えば、今日ではかなり多くのマイクロコントローラ・ベンダーが英ARM社のアーキテクチャを採用したマイクロコントローラを提供している。周辺回路や性能、メモリー容量、パッケージ形態、価格など、さまざまな面で異なる多様な製品群から自由に選べる。

　特に、ARM社の「Cortex-M」シリーズ（図1）は、これまで8ビットや16ビットのマイクロコントローラを搭載してきた機器に向けた機能を多く備えている。これらの機能のおかげで、ARMアーキテクチャのマイクロコントローラの用途は大きく広がった。さらに、ARMアーキテクチャのマイクロコントローラの価格はここ5年で大幅に低下している。開発ツールの低価格化も進み、無償の開発ツールも登場している。

図1　英ARM社の32ビット・マイクロコントローラ「Cortex-M0」と「Cortex-M3」
どちらも、8ビットや16ビットのマイクロコントローラの置き換えを狙った製品だ。

　ARMアーキテクチャのマイクロコントローラを選択すると、ほかのアーキテクチャを選んだときに比べて、投資を無駄にすることなく、有効に活用できる。ARMアーキテクチャのマイクロコントローラ向けにプログラム・コードを書けば、さまざまなメーカーが出荷しているARMアーキテクチャのマイクロコントローラで再利用できるからだ。メーカーは、今後も長期間にわたってARMアーキテクチャのマイクロコントローラを出荷し続けるので、一度書いたコードを長期間再利用できるのだ。

　さらに、ARMアーキテクチャは広く普及しているので、ARMアーキテクチャ向けプログラム開発の経験を積んだソフトウエア・エンジニアは多い。ほかのアーキテクチャのプログラム開発をしてきたエンジニアに比べると、ARMアーキテクチャに慣れたエンジニアは探しやすく、雇いやすい。このような理由から、ARMアーキテクチャのマイクロコントローラを使うと、製品ラインの将来や、組み込み開発者が持つ技術の将来を保証できるのだ。

32ビット・マイコンのコード・サイズは大きくない

　8ビット・マイクロコントローラの強みといえば、プログラムのコード・サイズを思いつくだろう。コード・サイズの競争に、32ビット・マイクロコントローラがどのようにして打ち勝ったのかを解説しよう。

　多くの開発者は、8ビット・マイクロコントローラは8ビット命令を使用し、32ビット・マイクロコントローラは32ビット命令を使用するものだという印象を抱いている。

　しかしよく調べると、8ビット・マイクロコントローラの命令には、16ビットや24ビットなど、8ビットよりも大きなサイズのものも多い。例えば米Microchip Technology社の8ビット・マイクロコントローラ「PIC18」の命令長は16ビットだ。今では古くなった米Intel社の「Intel 8051」アーキテクチャでも、一部の命令は8ビット長だが、多くの命令は16ビット長または24ビット長である。

　ARM社の「Cortex-M0」と「Cortex-M3」は、「Thumb-2」という技術を搭載している。この技術によって、プログラム・コードの密度をぐんと高めることができる。Thumb-2技術で利用できる「Thumb」命令セットには、16ビット長の命令と32ビット長の命令が混在しており、32ビット長命令の機能は、16ビット長命令セットのスーパーセットになる。32ビット命令を使用すると限定しない限り、ほとんどの場合、Cコンパイラは16ビット長の命令を使用する。

　Cortex-Mシリーズ向けにコンパイルしたプログラムを調べると、32ビット命令をほんの少ししか使っていないことが分かる。例えば、整数演算性能を計測するベンチマーク・プログラムとして有名な「Dhrystone」のソース・コードをコンパイルして調べてみよう。Cortex-M3向けにコンパイルしたDhrystoneプログラムでは、32ビット命令は、全命令数のわずか15.8％を占めるにすぎない（平均命令長は18.53ビット）。Cortex-M0なら、32ビット命令の割合はさらに低くなり、全体の5.4％になる（平均命令長は16.9ビット）。

効率が良いARM命令セット

　Cortex-Mシリーズで使用するThumb命令セットは、プログラムのコード・サイズを圧縮するだけでなく、効率良く動作するプログラムを作ることを可能にする。例えば、ARMアーキテクチャのマイクロコントローラが備える、複数のデータをロードする命令や複数のデータをストアする命令、スタック・プッシュ、スタック・ポップの各命令では、単一の命令でデータ転送を複数回実行できる。

　ARMアーキテクチャのマイクロコントローラは、多様なアドレッシング・モードを持っており、メモリー・アクセスの手順を簡略化できる。例えば、単一の命令で、レジスタ値の分だけアドレス値をオフセット（加算、減算）できるほか、命令に書いてある分だけオフセット、プログラム・カウンタの値からオフセット、スタック・ポインタの利用（ローカル変数に有用）などの方法で主記憶にアクセスできる。

　8ビットと16ビットのデータを扱うとき、ARMアーキテクチャのマイクロコントローラは非常に効率良く処理する。符号のあるなしにかかわらず8ビットや16ビット、32ビットのデータにアクセスするためのコンパクトな命令がそろっている。データ型変換用の命令も持っている。ARMのマイクロコントローラにおける8ビット・データと16ビット・データの扱いは、32ビット・データの扱いとほとんど同じぐらい簡単で、効率が良い。

　ARMアーキテクチャのマイクロコントローラは、実行条件付き命令のほか、比較と分岐の組み合わせ命令も備えている。データに符号が付いているか否かで分岐する機能もある。

　Cortex-M0とCortex-M3のどちらも、1クロック・サイクルで32ビットの乗算を実行できる。さらにCortex-M3は、符号付きと符号なしの整数除算や、けたあふれを起こさない飽和演算、32ビットと64ビットの積和演算（MAC：Multiply and Accumulation）、いくつかのビット・フィールド演算命令も用意している。

整数型やポインタの大きさに注意

　多くの組み込み機器開発者は、自分たちが開発する機器は8ビットのデータしか処理しないから、32ビット・マイクロコントローラへ移行する必要はないと誤解している。C言語のコンパイラのマニュアルを少し詳しく調べてみよう。8ビット・マイクロコントローラで扱う整数型（int）は、実際には16ビットだ。つまり、整数演算を実行するたびに、あるいは整数演算を必要とするC言語のライブラリ関数を実行するたびに、16ビットのデータを処理していることになる。8ビット・マイクロコントローラは、整数型のデータを処理するために、連続する複数の命令を実行しなければならない。つまり、多くのクロック・サイクルを消費することになる。

　同じことがポインタでも言える。ほとんどの8ビットや16ビット・マイクロコントローラでは、主記憶のアドレスを示すポインタには少なくとも16ビットが必要になる。16ビット以上必要になることもある。

　例えば、8051が備える「Generic Pointers：ジェネリック・ポインタ」を使うと、参照する主記憶の位置を正確に示すための追加情報が必要となるため、3バイト（24ビット）必要になる。メモリー・バンクの切り替えなどの手法を使用して64Kバイトの障壁を超えるときも、16ビットのポインタを使うことが多くなる。結果として、8ビットのシステムで主記憶の位置を示すポインタを処理することは、極めて効率が悪い処理になっている可能性がある。

　8ビット・マイクロコントローラで、レジスタ・バンクに整数型の変数を格納するには、複数のレジスタが必要になる。つまり、整数型を使用すると、主記憶へのアクセス回数が増えるのだ。また、主記憶からの読み出し/書き込みのための命令の数が増大し、スタック演算の命令も増えてしまう。このような問題はすべて、8ビット・マイクロコントローラ上のプログラム・コードのサイズを大幅に増大させる。

　実例で比較してみよう。ある特定のソース・コードをコンパイルして、バイナリ・ファイルが最も小さくなるのはどのマイクロコントローラだろうか。整数演算性能を計測するベンチマーク・プログラムであるDhrystoneのソース・コードを3種類の異なるマイクロコントローラ向けにコンパイルしてみた。

　Cortex-M0とCortex-M3の比較対象として8ビット・マイクロコントローラの米Silicon Laboratories社の「C8051F320」（8051アーキテクチャ）を選んだ。開発ツール（コンパイラ）は、C8051F320向けには米Keil社の「μVision 3.8 PK51 8.18」を、Cortex-Mシリーズ向けには英ARM社の「RealView Development Suite 4.0 SP2」を使用した。その結果が表1だ。

表1　3種の異なるマイクロコントローラ向けにDhrystoneのソース・コードをコンパイルした結果
8ビット・マイクロコントローラよりも、32ビットのCortex-Mシリーズの方がバイナリ・ファイルが小さくまとまっている。

　この結果から、組み込み機器用プログラムの多くは、ARM Cortex-Mシリーズのマイクロコントローラに移行することで、コード・サイズを縮小できることが分かる。つまり、同じ機能を持ち、同じ性能を発揮する組み込み機器を作るときに、Cortex-Mシリーズを選べば、メモリーの容量を小さくでき、部品コストを下げられるということである。

　コード・サイズが小さくなる理由としては、命令セットの効率の良さ、命令長の小ささが挙げられる。そして、実際にはほとんどの組み込みアプリケーション・ソフトウエアで16ビット以上のデータを処理しているが、8ビットや16ビットのマイコンでは16ビット以上のデータを処理するのに多くの命令を費やすという点も挙げられる。

　中編では、8ビットや16ビット・マイクロコントローラと、32ビットのマイクロコントローラを性能と消費電力の面から比較し、その結果を分析する。