1つの大きなマイクロコントローラーですか、それとも多くの小さなマイクロコントローラーですか?


24

私は、マイクロコントローラを使って基本的で簡単なことを比較的よくやっています。こうした、LEDを駆動する文字のLCDにモーター、基本ルーチン、GUIを実行している、というように、常に同じようなもの1つの最も少数の小さな側のタスクにしてキータスク。これらの場合に必要なのは本当にそれだけなので、これはローエンドの製品に追いやられました。

もっと複雑なものの設計を開始したいのですが、マイクロコントローラーの連続体の上側は、私が十分に触れたことではありません。したがって、私は多くのタスクを同時に実行するマイクロコントローラーを選択するのに非常に困難な時間を過ごしてきました。する。

たとえば、PIルーチンを使用して2つのBLDCモーターを制御し、いくつかのシリアルおよびUSB通信、GUI、およびその他の多数のタスクを制御したいと思います。モーターごとにマイクロコントローラーを用意し、次に雑多なタスク用にマイクロコントローラーを用意したいので、雑多なものからのオーバーヘッドが重要なモーター機能を妨げないことを保証できます。しかし、それが実際に良いアイデアなのか、物事を進めるための素朴な方法なのかはわかりません。

私の質問は本当に2つあると思います:

  1. 多くのマルチタスクを実行する必要がある場合、オールインワンアプローチは良いアイデアですか、またはセグメント化して分離する方が良いですか?

  2. 私が見ているマイクロコントローラーがタスクのリストに基づいて必要なことを行うのに十分な計算能力を持っているかどうかを直感的に見つけるにはどうすればよいですか?

RTOSを実行するARM SoCまで、中程度のdsPIC33を検討しています。必要なものを整理する体系的な方法は、私を大いに助けてくれるでしょう。




4
すでに多くの答えがありますが、同じボード上で多くのプログラム可能なマイクロをすべて同じ言語で話すことは、たぶんいくつかのインテリジェントな周辺機器で単一のマイクロを使用するよりもはるかに多くの作業です。
エリックフリーゼン14

回答:


10

質問に対する答えは、最終目標が何であるかによって異なります。これらのデバイスを少数またはそれ以下必要とする場合、部品のコストを気にせずに開発を容易にする必要があります。これらを1000個以上作成する場合は、要件を分析し、デバイスハードウェアのコストを削減する価値があります。

少量

これらのデバイスを1回限りまたは小規模に実行する場合、開発努力によりアイテムごとのコストが圧迫されるため、コスト/開発コストではなく、開発が最も簡単/最速のものに集中する必要があります。マイクロエレクトロニクスのサイズ。

一般に、カプセル化により複雑さが軽減され、生産性が向上します。BLDC制御、PIDループなど、いくつかの厳しいリアルタイム要件がある場合は、ユーザーインターフェイスやその他の非リアルタイムを保持するコントローラーと通信するタスク専用のコントローラーを個別に使用する方が速い場合があります。時間のタスク。

したがって、この場合、質問に対する答えは次のとおりです。

多くのマルチタスクを実行する必要がある場合、オールインワンアプローチは良いアイデアですか、またはセグメント化して分離する方が良いですか?

スケールは、セグメンテーションと分離に向けてわずかに傾いています。主な理由は、リアルタイムシステムのデバッグには非常に時間がかかる可能性があり、そのようなタスクを独自のプロセッサに保持すると、何かが正しく動作しない理由を見つけるために測定または制御する必要がある変数が制限されるためです。

私が見ているマイクロコントローラーがタスクのリストに基づいて必要なことを行うのに十分な計算能力を持っているかどうかを直感的に見つけるにはどうすればよいですか?

この場合、多くのリソースを備えた32ビットプロセッサと限られたリソースを備えた8ビットプロセッサのコストの差は、開発に費やす時間に比べて小さくなります。どれだけの電力が必要なのか試してみる理由はほとんどありません。開発して使用できると感じる最大のプロセッサを入手するだけです。後の時点で設計のコストを最適化する必要がある場合、実際のプロセッサリソース使用量を比較的簡単に測定し、実際の負荷を処理できる貸手プロセッサを選択します。それまでは、最大のものを使用し、「最適」を見つけることを心配しないでください。

大量生産

これらのデバイスの多くを作成する場合は、慎重な分析により大幅なコスト削減が実現します。一般的に、大型のマイクロコントローラーは、必要な特定のタスクに応じて例外がありますが、単一のマイクロコントローラーを置き換えることができる2つのマイクロコントローラーよりも安価です。これらの数量では、ハードウェアのコストは開発コストよりもはるかに大きくなる可能性があるため、要件を分析して開発を実行する時間は、ごく少数の場合よりも多くなると予想されるはずです。

多くのマルチタスクを実行する必要がある場合、オールインワンアプローチは良いアイデアですか、それともセグメント化して分離する方が良いでしょうか?

一般に、オールインワンアプローチは、複数のプロセッサよりもプロジェクト全体の期間にわたって安価です。さまざまなタスクが競合しないことを確認するには、より多くの開発およびデバッグ時間が必要になりますが、厳密なソフトウェア設計では、個別のハードウェアを使用する場合とほぼ同じくらい制限されます。

私が見ているマイクロコントローラーがタスクのリストに基づいて必要なことを行うのに十分な計算能力を持っているかどうかを直感的に見つけるにはどうすればよいですか?

実行したいタスクと、それらがどれだけのリソースを使用するかを理解する必要があります。次のことが当てはまると仮定します。

BLDC PIルーチンは、1秒間に100回のプロセッサ時間のXサイクルを消費します。各ルーチンには、動作に約50バイトのRAM、チューニングに16バイトのEEPROM、コードに1kフラッシュが必要です。マイクロコントローラーには、それぞれ3つの16ビットPWM周辺機器が必要です。特定の割り込みレイテンシ要件を持つジッタを指定する必要がある場合があります。

USBおよびシリアルルーチンは、必要に応じてYサイクルのプロセッサ時間、2k RAM、64バイトEEPROM、および8kフラッシュを消費します。USBおよびシリアル周辺機器が必要です。

GUIは1秒間に30回のプロセッサパワーのZサイクルを消費し、2kのRAM、128バイトのEEPROM、および10kのフラッシュを必要とします。LCD、ボタン、ノブなどとの通信に19 I / Oを使用します。

初めて起動するとき、X、Y、Zが実際に何であるかを理解するのは難しいかもしれません。これは、プロセッサーのアーキテクチャーによって少し変わります。ただし、概算で、設計に必要なRAM、EEPROM、フラッシュの量、および必要な周辺機器を理解できる必要があります。メモリと周辺機器の要件を満たし、そのファミリ内で幅広いパフォーマンスオプションを備えたプロセッサフ​​ァミリを選択できます。その時点で、開発のために、ファミリで最も強力なプロセッサを使用できます。設計を実装したら、設計または開発環境を変更せずに、低コストのオプションに簡単に移行できます。

これらの設計を十分に行った後、X、Y、およびZをより適切に推定できるようになります。BLDC PIルーチンは、頻繁に実行されますが、非常に小さく、必要なサイクルが非常に少ないことがわかります。USBおよびシリアルルーチンは多くのサイクルを必要としますが、まれにしか発生しません。ユーザーインターフェイスは、変更を見つけるために頻繁に数サイクルを必要としますが、たとえば、ディスプレイを更新するために頻繁に多くのサイクルを必要とします。


11

私はモーター制御を分離し、2つのBLDCモーターのそれぞれにPWM(おそらくPIC18)を含む個別のマイクロコントローラーを使用します。両方のマイクロで使用できます。I²Cなどのインターフェースを介してメインマイクロコントローラーに接続し直し、必要に応じてそこからPI制御のパラメーターをダウンロードできます。これにより、GUIでそれらを変更できます。

次に、PIC24など、メインのマイクロコントローラーで他のすべてを実行します(リストしたタスクに基づいて、PIC32はおそらく過剰です)。さらに、最速のPIC24EはPIC32とほぼ同じ速度で実行できます。

マイクロコントローラーを選択するとき、まず必要なフラッシュとRAMの量を見積もり、次に語長とプロセッサー速度を調べます。後者の場合、満たすことが最も難しい要件は多くの場合、処理が予想される最速の割り込みです。たとえば、16 KHzのサウンドを出力していて、62.5 µsごとに割り込みが発生する場合、マイクロコントローラの命令時間は数十ナノ秒になります。完了しました。


7

答えを生成するために使用できる半形式的なアプローチがあります。ホワイトの「組み込みシステムの設計」の第2章を読むことを強くお勧めします。そのほとんどはGoogleブックスで入手できます。。

この章では、システムアーキテクチャの設計について説明し、タスクを最適にカプセル化するための準形式的なアプローチを提供します。この章は主に1つのコントローラーシステムに関するものですが、複数のコントローラーに簡単に拡張できます。どのリソースを共有する必要があるかを想像し、各タスクのカプセル化のレベルを選択するのに役立ちます。

彼女は考慮すべきさまざまなビューを提供しています。そのうちの1つを以下に示しますが、多くの便利な操作があります。もちろん、これだけではあまり意味がありませんが、この章をご覧になることをお勧めします。

White、Making Embedded Systems、第2章から

「十分なコントローラーがあるかどうかを知る方法」に関して、私自身の好みは、サンドボックスの設計にできるだけ多くの電力を投入し、設計がうまくいけばどれだけのリソースを削減できるかを把握することです方法。プロトタイピングの目的での10ドルのマイクロコントローラーと3ドルのマイクロコントローラーの価格の違いは、新しい部品を待って親指を改造して数週間調整するだけかもしれませんが、十分な電力がある場合は常に設計が動き続けます。


5

私はあなたが説明している大まかに言ってシステムに取り組んでいます-モーター、IO、ディスプレイ、3x UART + Coldfire 52259(ミッドレンジ32ビット〜80MHzマイクロ)で実行されているSPI + I2Cソフトウェアアーキテクチャの権利は重要です-ハードウェアと割り込み(ハードウェアが単独で処理できるものはすべて、割り込み付きのハードウェアとサービスで実行されます)で実行されるものがたくさんあり、main()ループからすべてのハウスキーピングを行います。

個人的に私はこれまで見たほとんどのRTOSが嫌いです。ローエンドではプロジェクトを肥大化し、学習するために別のことを追加し、物事を直接実行することでハードウェアのパフォーマンスを向上させます(利用可能なハードウェア関数+割り込みを使用)ソフトウェアで偽造するのではなく。

ハイエンドでは、最近では、MCUの間に余白がほとんどないようです RTOSと組み込みLinuxを実行するだけの何か(SoC)の恩恵を受けるです。

ただし、その場合、メインの「ブレイン」CPUのコマンドの下で重要な機能(タイミングや制限での停止が重要なEGモーター制御)を処理するために小さな安価なマイクロを使用することに価値があると言うでしょう「非リアルタイム」OSで、タイムリーに何かをする。


3

他の誰もが答える方が良いですが、私はそれが役に立つかもしれないと少し付け加えます。これは少し外れている可能性があり、コメントとして追加したいのですが、50 repルールがあります:(

簡単な答えは、それは上記に依存しますが、プロセッサの利点についても考えてみてください。

小型のプロセッサの利点について考えてみませんか。これは、結局プロセッサに関する質問です。数学的および特定の非反復タスクの場合、複数のプロセッサーが対数ブーストを生成できます。アムダールの規則は、11p+psしかし、これは来る。Pは分割可能な計算の割合で、sは高速化です(操作の数、ハードウェアなどに依存します)。

もちろん、コスト、実装の容易さ。なども重要であり、さらに重要です。


1

答えは実装の詳細に依存します。いくつかのタスクは、別々のマイクロコントローラーでクリーンかつ堅牢な方法で実装するのが簡単です。消費電力も考慮に入れることができます。一般的に、複数のタスクを処理する単一のマイクロは、単一のタスクを処理する複数のマイクロよりも少ない電力で済みます。


1

「馬力」は、リアルタイムの制約を満たすことができるかどうかに次ぐものです。

2つのPWM出力があり、両方をまったく同時に切り替える必要がある場合は、それを行うために必要な並列処理が必要です。正確なタイミングを処理する専用のPWMコントローラーがある場合、かなり小さなマイクロコントローラーでも動作しますが、GPIOベースのソリューションは、多くの計算能力が利用できる場合でも非常に複雑になります。

ほとんどのプロトコルについて、最新のMCUにはリアルタイム制約のあるプロトコルの部分の実装が組み込まれているため、必要な周辺機器を備え、データフローを処理するために必要なCPU速度を備えたMCUを見つけることができますフォームのソフトリアルタイム要件(「いっぱいになる前にFIFOから読み取ることができ、いっぱいになるよりも速くなる」)に最適です。

そのようなソリューションが存在しない場合、オプションは、CPU + FPGAソリューション(ハードARMコアを備えたFPGAなど)を使用して機能を個別のコントローラーに移動するか、純粋なFPGAソリューション(複雑さの要件に応じてソフトCPUを使用)のいずれかです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.