開発ボード・ツールガイド

開発ボードやツールは、エンジニアが自宅で試作品を作成したり、既にあるシステムやプログラムをテスト・改善する為に役立ちます。このガイドでは、高度なものから、必要最小限の回路を備えたシンプルなものまで、いくつかの一般的な開発ツールとボードを紹介し、最適なものを決定する手助けをします。

多くのエンジニアは開発環境を使用せず、コードにデバッグポイントを組み込み、テスト装置を使ってハードウェアを検証することを好みます。しかし、開発ツールを使用することには明確な利点があり、それらは大まかに以下の3つに分類されます。

• 並列エンジニアリング
• 市場投入までの時間短縮
• 既知の優れた回路

並列エンジニアリングは、おそらくこれらの中で最も単純なものです。多くのプロジェクトでは複数のエンジニアが作業しており、例えばソフトウェアエンジニアが、システムPCBが利用可能になる前にコードのテストを開始できるのは素晴らしいことです。ターゲット基板がBGAのような複雑なパッケージを必要とする場合や、回路がASICのようなリードタイムの長い要素を必要とする場合は特にそうです。さらに、テスト用のツールに多額の投資をしなくても、複数のボードを使用して異なる製品を比較対照することが可能です。パラレルエンジニアリングは時間とリソースを節約し、市場投入までの時間を短縮します。

市場投入までの時間は、エンジニアリングにおいて重要なパラメーターであり、しばしば製品の商業的な成否を左右します。では、開発ツールはどのように役立つのでしょうか？第一に、多くの開発キット（特にMCU分野）には、パッケージの一部としてプロダクションツールが付属しています。このようなツールの例としては、周辺機器用のデバイスドライバや、特定のデバイス用のリアルタイムオペレーティングシステムの移植版があります。これにより、コーディング（プロジェクトのタイムスケールにおける主要な決定要因であることが多い）が加速され、より決定論的になることで、製品リコールの可能性を減らすことができます。

開発ボードが開発を加速させるもう一つの分野は、サプライヤーがガーバーファイルのような回路レイアウトの詳細を提供する場合です。これはアナログシステムや高速システムでは非常に重要です。研究可能な情報へのアクセス、あるいは最終的な分析でコピーすることで、何時間もの重労働を省くことができ、さらに重要なこととして、何度もPCBを反復することができます。

最後に、既知の優れた回路についてです。多くのエンジニアは、「最終的な」PCB段階まで慎重に行ったにもかかわらず、システムのどこかで断続的なバグに遭遇するという状況に陥ったことがあります。既知の動作基板を持つことは、そのようなフラストレーションのたまる問題を見つけるのに役立ちます。この例として、レイアウトの寄生容量が計算より大きいためにスイッチング電源のフィードバック回路が不安定になることがあります。評価ボードのガーバーファイルの検査は、最終段階の前にこの問題を切り分けるのに非常に役立ちます。

マイクロコントローラのようなプログラマブル・デバイスを評価する場合には、評価ボードをコーディングに使用できます。多くのボードには小規模なアプリケーションを完成させるのに十分なフリーウェアのコンパイラやデバッガが付属しています。多くのサプライヤーが、Arduinoのような標準的な開発ボード（これらはシールドとして知られています）とインターフェースするためにボードを装備する方向に向かっていることは注目に値します。使いやすくするため、多くのメーカーは自社のボードにArduino互換のI/Oシステムを持たせ、ユーザーが世界中のさまざまなシールドにアクセスできるようにしています。この規格のリリースは、他のサプライヤーによるシールドの完全なエコシステムを生み出し、非常に洗練されたシステムを構築することを可能にしました。

メーカーが提供する開発ツールには、通常、評価ボードよりも充実したリソースが搭載されています。これは特に厳密に定義されたアプリケーション向けの場合に当てはまります。このような場合、メーカーは、ターゲットアプリケーションに実装するのに適していると判断したすべてのコンポーネントをボードに装備します。例えば、自動車用ダッシュボードアプリケーションをターゲットとするサプライヤーの場合、ボードにはMCU、CANコントローラー/インターフェース、何らかのディスプレイ、そして最低限でも堅牢な電源設計が搭載されている可能性が高いのです。追加部品が余計なものに見えても、開発目的には非常に有用であることに変わりはありません。メーカーは、ボードに拡張機能を持たせたり、少なくともI/Oにアクセスできるようにしたりと、十分に実用的な設計をしています。積極的な点として、多くのサプライヤー開発システムは汎用ツールとして設計されており、コーディングやデバッグ用のソフトウェアが充実しています。

サプライヤー主導の開発ツールについて議論する際、しばしば遭遇する用語のひとつに「リファレンス・デザイン」があります。リファレンス・デザインは、単一のアプリケーションに焦点を絞ったもので、開発ボードとは異なり、コストや消費電力、あるいはスペースが最適化されている可能性が高く、一般的な使用にはあまり適していません（もちろん、特定の分野の製品を設計しようとしている場合には非常に便利です）。開発ボードの利点は、最適化され、徹底的にテストされているため、従うべき設計ルールについて深い知見が得られることです。

サードパーティ製ツールの多くは、マイクロコントローラー市場に特化してます。これらは通常、JTAGをベースとしたメーカーのオンチップ・エミュレーション・システムを利用していおり、開発ツールは非侵襲的にMCUの「内部に入る」ことができ、ユーザーはブレークポイントを設定したり、コードパスをトレースしたり、内部メモリの内容を調べたりすることができます。これらの開発ツールには一般的に、「C」または「C++」コンパイラと、統合開発環境（IDE）として知られるデバッグシステムが付属しています。IDEを使えば、昔のアセンブラコードとはかけ離れた抽象度の高いレベルで、実行中のソフトウェアにアクセスできます。つまり、グローバル／ローカル変数にアクセスでき、変数のデータ型、配列、構造体の内容などを評価することができます。さらに、低レベルコード、I/O、ボードレベルのハードウェアへのアクセスも可能で、ロジックアナライザーの機能に近いものさえあります。これらすべては、多くの組み込み設計に実装された複雑なリアルタイムシステムをデバッグする際に不可欠です。サードパーティボードの供給元は数多くあり、コンパイラのサプライヤが自社のツールチェーン用のターゲットボードを提供するものから、インサーキットエミュレータメーカー、そして前述のエコシステムに対応する企業まで様々です。このため、幅広い価格帯とシステムの複雑さをカバーする豊富な選択肢があります。

何百種類もあるツールを評価する場合、その選択は以下の複数の重要なポイントに絞られる傾向があります：

• 予算の制約

  • 数千円から数１００万円のツールがあります。

• 設計するシステムの複雑さ

  • 完全な機能を備えたソリューションが必要かどうか。

• 開発ツールへの習熟度

  • 既に使い慣れているツールがあるか。

• ツールの洗練度

  • コンパイラのコード密度やデバイスドライバの有無などの要素。

• コラボレーション

  • 開発チーム内の複数ユーザーをサポートする能力。

• フリーウェアかライセンスか

  • フリーウェアを使えるか、ライセンスソフトウェアとそれに伴うサポートコストが必要か。

これらの決定ポイントはすべて、評価フェーズの延長につながりますが、最初に正しく決定することで、設計ライフサイクルの短縮と市場投入のスピードアップにつながります。今日のエンジニアは、選択可能な開発ツールの数と種類に恵まれています。しかし、このような選択肢の多さは、それ自体が挑戦でもあります。しかし確実に言えることは、適切なツールを選択することで、プロジェクトの開発期間を何週間も短縮できるということです。