メディア
特集
» 2006年06月01日 00時00分 公開

実践プロジェクト:低価格で再構成可能なマイクロコントローラを設計する

再構成可能なマイクロコントローラには、応用機器の要求を満す多くのアナログ/デジタル機能がある。

[Nicholas Cravotta,EDN]

 一般にマイクロコントローラは1つの完成されたSoC(system on chip)である。プログラム済みのICチップに電源とグランドを接続すれば、メモリーと周辺回路を備えたパワフルなプロセッサが完成する。マイクロコントローラを使えば部品と周辺回路を統合する手間が省けるため、設計時間を大幅に短縮することができる。

 今日の8ビットマイクロコントローラの多くには、ハードウエアベースのA-DコンバータやD-Aコンバータ、PWM(pulse width modulation)をサポートし、各種シリアル/パラレルインターフェースといったさまざまな機能が組み込まれている。小規模なシステムであれば、用途に必要な周辺回路とインターフェースのすべてを1つのマイクロコントローラに内蔵できる。しかしマイクロコントローラにも、インターフェースの数と特性に限界があるという欠点がある。例えば、13本のインターフェース端子のうち、マイクロコントローラが12ビットA-Dコンバータをサポートできるのは2本しかない場合がある。3個のA-Dコンバータが必要な場合や、14ビットA-Dコンバータを必要とする場合には、別のアプローチをとらなければならない。

 今回の実践プロジェクトでは、多くの用途に不可欠な汎用センサーコントロールモジュールの設計における柔軟性に焦点を当てた。マイクロプロセッサについては、LEDやボタン、ダイヤル、LCDパネルなどの単純なマンマシンインターフェースを動作できること、データビットを劣化させずに、周波数をサンプリングするセンサーからデータを取得できること、モーターやアナログ出力部品といったアナログ/デジタル周辺回路をコントロールできることを要件とする。この設計では、データ収集とデータ転送の両方の機構系へのやりとりに必要なデータ送受信において、1つの決まった場所へのデータロギングをサポートしなくてはならない。また、ハブ、デイジーチェイン、あるいはピアツーピア・アーキテクチャを介して複数のモジュールを階層化できるように、メッシュ・階層ネットワークをサポートする必要がある。

柔軟性の確保

図1 PSoCを使ったレイアウト 図1 PSoCを使ったこのレイアウトでは、左側のバスは再構成可能なブロックの入力用として使われ、ブロックの上側の配線を経由して外部端子に接続される。また右側のバスは、再構成可能なブロックの下側の配線を経由して出力用として外部端子に接続されている。この図では使っていないブロックが一つおきに置かれており、白い色で描かれている。それらはこれらのバスではない別の配線でつながっている。

 サポートするインターフェースが限定されている8ビットマイクロコントローラで必要とされるPWM、A-Dコンバータ、D-Aコンバータ、シリアルインターフェースの数がそれぞれ異なる多様な用途をサポートしたいと考えていた。そこで柔軟性のあるマイクロコントローラを探したところ、米Cypress Semiconductor社(www.cypress.com)のPSoC(programmable system on chip)を見つけた(図1)。このPSoCには再構成可能な論理ゲートと、インターフェース端子の機能を定義するためのスイッチングファブリックが組み込まれている。価格は用途にもよるが、同等の機能をもつマイクロコントローラよりも若干高い。

 私はPSoCを慎重に調べた。再構成可能という柔軟性は欲しかった。しかし、LEDやセンサー、モーターへの簡単なインターフェースを作成するためにVHDLと合成ツールの知識をわざわざ学習したくなかった。PSoCにはそのようなわずらわしさがない。開発者はPSoC内の論理ゲートに個別にアクセスできず、機能レベルからアクセスする必要がある。ブロックを作成できるだけの十分なリソースがあれば、複雑な機能の組み合わせを定義して、それらをインターフェース端子に配線することができる。

 設計者は構成可能なブロックを使ってデジタル/アナログ機能を実装する。アナログ機能を実行するブロックもあれば、デジタル機能を実行するブロックもある。これらの機能をファブリック経由で接続すれば、複数のIC間で電源ライン、グランドライン、信号ラインを配線する必要がなくなる。利用可能なブロックを増やせば複雑な信号処理回路をハードウエアで実現することもでき、プロセッササイクルをムダに消費することなく高いパフォーマンスを達成できる。また、さまざまなブロックを組み合わせることで、1つのチップ上にアナログ/デジタル回路を混載することができる。PSoC開発環境では、8ビットPWMや16ビットA-Dコンバータなど、実現したい機能ブロックを自由に選択できる。これらの固定ブロックは起動時にフラッシュメモリー内のレジスタから初期化し、ソフトウエアAPI(application programming interfaces)を介して動的に再構成できるが、PSoCではこれらブロックの基本機能が事前に定義されている。

 この再構成の制約が、PSoCの最大の長所でもある。ブロックが事前に定義されているため、論理回路の研究や構成済みコードの解読をしなくても、すぐに適切なPWMが得られた。また少し時間をかければ、PWMを簡単にいくつも複製することができた。定義済みブロックであるがためにすべてのAPIコードに整合性があり、使いやすい。

コンフィギュレーションの管理

 同じ機能ブロックを複数コピーして使うときに、いくつかの問題に直面した。できるだけ多くのマクロとサブルーチンを使いたかったので、PWMxと定義した。しかし、ブロックをいったん配置したら、その順序と配線を変更することは困難であることがわかった。PWM3をPWM1とPWM2の間に置いたため、この順序の間違いを修正したかった。そのためにはPWM3とPWM2を削除して、正しい位置で再定義する必要があったが、ドラッグ・アンド・ドロップ機能ではうまくいかなかった。

 この経験から、アナログ/デジタル回路ブロックとインターフェース端子は慎重に割り当てなくてはならないことを学んだ。最初から無計画にブロックを配置してしまうと回路ブロックが切り離されてしまい、複雑な機能を果たすように構成できなくなったり、特定の出力端子を使えなくなったりする可能性がある。例えば、私はI2Cインターフェースを作成するための十分なリソースを持っていたのにもかかわらず、必要なところで使えなかった。つまり、特定のI/O端子に他の回路ブロックと機能を割り当ててしまっていたのだ。回路ブロックを割り当てなおすという面倒な作業によってこの問題は解決できたが、回路ブロックをすぐ割り当てずに配置計画を検討していたら避けられたかもしれない問題であった。

 もう1つの問題は、コンパイラがマクロ内のマクロをサポートしていなかったことだ。1つの機能の具体例を記述するために個々のコードブロックを複数コピーすることが難しい。例えば、汎用PWMマクロはその中の特殊マクロを呼び出せないため、マクロのユーティリティは大部分が使えない。その代わり、PSoCは間接参照機能をサポートしているため、この機能を使用して記録構造をエミュレートすれば、関連する変数群とオフセット群を関数ベクターに簡単に渡すことができる。この方法でプログラムメモリーは節約できるが、機能の間接参照と抽象化によりレイテンシが延びる可能性がある。

 この間接参照機能を理解するまでに少し時間がかかった。開発キットに付属している応用例のサンプルはどれも役に立ちそうになかった。コンパイラのメモリー割り当てモデルにはいくつかのバリエーションがあるが、1つの変数の宣言方法を示しているサンプルがない。そして、ようやく変数の宣言方法がわかったと思ったら、今度はその直接参照と間接参照の方法がわからない。最初からトラブルに直面するのは自分のせいもあるが、そもそもPSoC開発キットに付属しているマニュアルに問題がある。電子マニュアルにはメモリーモデル内での変数宣言方法を示した例が含まれておらず、ほとんど役に立たない。擬似コードはフレームワーク内の正しい場所に配置しないかぎり機能せず、マニュアルにはその配置方法の記述もない。幸いにも、こうしたトラブルの回避方法を説明した文献を見つけることができ、大きなミスをせずに済んだ*1)

制限ある再構成機能

 再構成機能に制限があるということは、PSoCを用いた設計をスピードアップさせる重要な要素といえる。しかし一方で、ハードウエアブロックを修正したくてもできないという問題がある。例えば、私はよく使ういくつかの機能を作成したが、周波数をスムーズに落とすPWMを使用したランプアップ/ダウン回路もその1つである。この簡単な機能によってPWMのデューティ比を低減する。しかし、この機能を実行するためにハードウエアタイマーと割り込みを使用しなくてはならなかった。それは多くのプロセッササイクルを費やすうえに、割り込みバーストを生じる結果となった。

 複数のPWMが同時に変化すると、プロセッサ上への負荷によって残りの用途が大きく影響する。さらに、管理しなくてはならない同時割り込みが多いと、制御のリアルタイム性が損なわれる。私が開発しようとしたシステムにはリアルタイムの遅延条件がなかったため、割り込みの競合を無視できたが、それでもプロセッサへの負荷の問題と格闘しなければならなかった。複数のPWMのランピング機能を1つの割り込みにまとめて割り込みの数を減らそうかとも思った。しかし私の能力からいって、この方法を採用すれば目的とする狙いからそれぞれのPWMを切り離すことができなくなろう。

 理想を言えば、ランピング機能を再構成可能な回路内に実現できればよかったが、PSoCでは再構成可能なブロックを修正することができない。この機能はごく単純なもので、プロセッサの負荷を軽減する効果がある。ハードウエア機能ブロックを変更できれば私の設計を保護することもできるはずだ。ハードウエアの一部にIPを組み込むことで、リバースエンジニアリングがもっとしづらくなるからだ。フィールドでのアップグレードをサポートする必要がある場合はこの機能が特に重要となる。たとえプロセッサによってハードウエアコードが保護されていても、バイナリファイルで提供されていればそのコードは露呈する。結局のところ、ハードウエアブロックはソースコードがないライブラリファイルに等しい。ソースコードがあれば、チップ内での動作を知らなくてもプログラマブルゲートを定義して適切に使うことができる。

ソフトウエアの競合

 デジタル/アナログ混在部分がプログラム可能であることの利点の1つは、ハードウエアとソフトウエアのリアルタイムコードとアプリケーションコードを簡単に区分けできることだ。例えば、実装が決まっているマイクロコントローラでも、PWMの組み込みは比較的簡単に行える。1つのPWMに必要なものは1つのタイマーだけで、他のシステムイベントとうまく統合できる。しかし、設計のスケーリング拡張は1つの例を実現するのとは訳が違う。この場合、機能ブロックを使った手法を用いれば、1つのPWMの詳細にとらわれずに済む。しかし、複数のPWMを同時に処理するとなると、従来のマイクロコントローラでは無理だろう。

 複数のPWMをサポートしたマイクロコントローラがあったとしても、サポートできる数を超えるPWMを必要とする用途では難しい。PWMを追加するにはソフトウエアで実現するためのコストがかかるからだ。この余分な作業が、処理能力を少しずつでも増やしていかねばならない新しい市場への参入を阻んでいる。2つ目のPWMを追加する作業は、1つ目のソフトウエアPWMを複製すれば済むような単純な作業ではない。PWMをハードウエアで実現する場合は、動的再構成時以外ではメインプロセッサへの影響はない。しかし、複数のPWMをソフトウエアで実現する場合には、タイマーリソースの不足などにより、割り込みのスケジューリング、競合、リアルタイム処理などの問題が発生する。さらには割り込み処理によりオーバーヘッドが増大し、同期の問題が起こる。つまり、複数の割り込みが同時に発生し、リアルタイム処理を要求する可能性がある。また、リアルタイムイベント処理の優先度をめぐってアプリケーションコードが競合する。

 この時点で、PWMによるプロセッサの占有時間とレイテンシを極力抑える再設計が完了しているはずだった。しかしこの作業は容易ではない。さらに今回のプロジェクトでは回路を作成することではなく機能させることに重点を置いていた。基本的に新しいものを創り出すことよりも、有効な機能を限られたスペースで実現することに専念していた。もし今回のプロジェクトでライブラリにあるソフトウエアPWMを使っていたら、競合問題を解決するためにこのコードを分析する必要があったはずだ。

 設計を拡張するとき、競合は予想以上に深刻な問題となる。設計内のリソース共有が増えるほど、競合を解決するための作業も増える。また、PSoCを使う場合は、PWMの再構成と他の機能ブロックの管理を必要とする、すべての動的変更を管理しなくてはならない。CPUサイクルを基本的なPWM機能と共有しなくてはならない場合は、プロセッサやアプリケーションのリソースをもっと費やさざるを得なくなるだろう。

モジュールに関する考察

 今回のプロジェクトでは、センサーコントロールモジュールに特定のアーキテクチャ方式を使うことができたかもしれない。例えば、モジュールは外部に実装することも、プリント基板上に直接実装することもできる。I/Oインターフェースの配線にスイッチと汎用コネクタのどちらを使うかを選択することもできた。PSoCの集積度から、このチップ自体を1つのモジュールとして使うことを考えた。この点においては設計を縮小して、1つのPSoCと電圧レギュレータを試作基板に実装してみた。

 逆に、外部モジュールを作成して、利用可能なI/Oインターフェースを拡張することもできるだろう。例えば、I2Cバスを介してモジュールをメインシステムに接続するというアイデアもある。このモジュールは、モジュールに接続するすべてのI/Oを独立したサブシステムとして動作する。メインシステムは特定のプロトコルに基づき、I2Cバスを介してこのI/Oへのアクセスとコントロールを行う。

 結局、問題はどれほどの柔軟性を確保できるかということに尽きる。私が初めて設計したものはかなり低い生産性のため、設計数を減らせばコストをかなり節約することができる。例えば、多数の再構成用のモジュールと、他のすべてのコンフィギュレーションを処理する1つのモジュールを組み込んだ部品を使ってセンサーシステムを構築することもできる。しかし、最適化されたモジュールごとにNRE(nonrecurring engineering)コストがかかる。このような部品をいくつか実装するだけでエンジニアリングコストが膨らみ、実装にかかる時間も限度を超えてしまう。1つの構成にかかるコストを50米セント削減するのに50時間もかけられるだろうか。

 このトレードオフは複雑な問題で、製品の多様性と市場シェアを拡げるためにどれほどの時間と資金を投入できるかにかかっている。柔軟性の高いモジュールを作成することの利点は、当初のNREコストと在庫の種類を減らせることである。さらには工場とのやり取りの回数が減り、生産工程が集約されることから、初期モジュールにかかる全体的なコストが下がる。この段階ではどの構成が大量に売れるのかを予測することはできない。モジュールは構成が量産可能であることが証明されてから最適化すればよい。市場が成熟するまで売れない在庫を抱える必要もない。柔軟性のある部品は、値引きして売らなくても適正な価格で販売できる。

 量産向けにアーキテクチャを最適化して将来のコストを節約するか、複数の用途にわたって1つの基本アーキテクチャを維持するかのトレードオフを評価することは大事だ。モジュールはその特性からいって、ソフトウエア部品とハードウエア部品で機能を分ける。モジュールは他のシステム部品から独立して動作するために、この区別が後の最適化を難しくすることがある。例えば、今回のプロジェクトで使ったモジュールは1つの独立したシステムでなくてはならなかった。そのため、データを取得し、評価し、転送できるスマートセンシングシステムを作製するだけのリソースをこのモジュールで提供する必要があった。しかし、これらのリソースを他のシステム部品に使うことが非常に難しいため、特定用途向けのセンサーがほとんど処理しない場合は無駄になってしまう。

 今回のプロジェクトでは、16本のインターフェースを実装しようとしたためにコストが高くついた。39本のI/Oインターフェースを必要とする用途を考えてみよう。1個の16インターフェースモジュールで15本のインターフェースを提供できる。少なくとも1本のインターフェース(バスを使うならば2本)を使ってこのモジュールを他のモジュールに接続する場合、ハブとして動作するモジュールにはn-1のインターフェースが必要となる。3個のモジュールでインターフェース数は48となり、そのうちの4本で2個のモジュールをハブとして動作する3番目のモジュールに接続する。このシナリオでは5本のインターフェースが余る。統合アプローチをとれば、4本の通信インターフェースを使う必要はない。したがって、この部品には用途に必要な数よりも9本分多くのインターフェースコストが余計にかかっていることになる。

 コストの増加と信頼性の低下につながるもう1つの主な要因は、汎用コネクタを使うことにある。汎用コネクタを用いればモジュールの柔軟性が高まる。モジュールを使う用途に必要なLED、モーター、I2Cポートの最小の数がわかっていたら、適切な数のインターフェースとコネクタを使えるだろう。しかし大半のケースでは、1個のモジュール上に部品をまとめることで、そのモジュール自体の処理性能が高まる。例えば、14個のセンサーと14個のLEDを必要とするシステムがあるとする。LEDは各センサーの状態を示す。LEDが点灯していれば対応するセンサーが動作中である。LEDが点滅していればセンサーがイベントを検知している。さらにLEDが高速で点滅していればセンサーが処理を要求していることをそれぞれ意味する。この用途では、各LEDを適切なセンサーに対応させてグループ化するのが合理的である。例えば、通信リンク用に2本のI/Oを備えたモジュールごとに7個のセンサーと7個のLEDをまとめればよい。

 一方で、複数センサーをまとめることによってシステム全体に関する情報をLEDが伝達することも考えられる。例えば、1つのセンサー群が同じシステム部品を違う場所から監視するかもしれない。部品の状態を決めるには、すべてのセンサーからのデータを使う必要がある。このセンサー群が2個のモジュールの近くにある場合には、これらのモジュールは大量のデータを送受信しなければならず、部品の状態を解決するために、余計な遅延が生じる可能性がある。この用途では、14個のセンサーをグループ化することでセンサーを最も効率的に管理できる。センサーモジュールは各LEDの状態をLEDモジュールに転送するだけでよい。論理的な観点から言えば、LEDモジュールはセンサーモジュールのI/O拡張として機能し、センサーモジュールはメインシステムのI/O拡張として機能する。

 使用できるA-DコンバータやLEDドライバの数など、モジュール構成に制約条件がある場合は、適切な数のインターフェースを確保するために、より多くのモジュールが必要となる。従来のマイクロコントローラのほとんどにこのアーキテクチャモデルが採用されている。マイクロコントローラ製品ファミリにはインターフェース構成の異なるものが含まれているが、その範囲と規模は制限されている。

 低価格の再構成可能なプログラマブル部品が入手できるようになったことで、産業用コントロール、モーター、LED、センサー管理システムなどの組み込みシステム用途の設計者は、今ではソフトウエアではなくハードウエアで機能を実現できる。そして設計者は、より少ないプロセッサでシステムを管理し、ハードウエアインターフェースを動的に調整することでマイクロコントローラの柔軟性を高められるようになった。

 一番の問題は、どれほどの柔軟性と機能が必要なのかを決めることだ。この決定により、自分の用途に合う特定のマイクロコントローラアーキテクチャが決まる。例えば、2個のA-Dコンバータと多くの汎用I/Oを必要する用途では、市販のマイクロコントローラは集積度は高いがそれほど複雑ではない。時間の経過とともに設計したI/Oを変更する可能性がある場合や、PWMなどの機能例をマイクロコントローラで一般に提供されているよりも多く必要とするような用途では、再構成可能アーキテクチャを使う方が明らかに有利だ。私にとって一番大事なことはその製品によってどのようなイノベーションを生み出せるかということだ。再構成可能なアーキテクチャのPSoCには、今回の実践プロジェクトの範囲を超える多くの機能がある。しかしながら、新しいモジュール群を追加するだけで設計を大幅に拡張できるという柔軟性があるのは素晴らしい。


脚注

※1…Ashby, Robert, Designer's Guide to the Cypress PSoC, Newnes Publishing, 2005.


Copyright © ITmedia, Inc. All Rights Reserved.

RSSフィード

公式SNS

EDN 海外ネットワーク

All material on this site Copyright © ITmedia, Inc. All Rights Reserved.
This site contains articles under license from AspenCore LLC.