複数のマイクロコントローラー間の通信

N個のマイクロコントローラー（N> = 2 MCU）で構成されるシステムの実装を開始したいのですが、相互に通信できるようにする可能性を知りたいと思います。

理想的には、（N-1）マイクロコントローラーはクライアントとして機能する家の中に配置され、最後の（「サーバー」）マイクロコントローラーはUSB経由でPCに接続されます。私が今抱えている問題は、これらの（N-1）マイクロコントローラーを「サーバー」に接続する方法です。クライアントMCUは非常に単純なタスクを実行するため、CAN / PHY-MACを提供するという理由だけで、ARMを使用してこのような単純なジョブを実行することは良い解決策ではない場合があります。

通信は、ほとんどのデバイスで数分に1回、他のデバイスではオンデマンドで行われます。速度はそれほど重要ではありません（メッセージは短いです）：1 Mbit / s私は、私の目的にとっては行き過ぎだと思います。

使用する予定のMCUは次のとおりです。

• Atmel AVR Tiny /メガ
• TI MSP430
• ARM Cortex M3 / M4
• （おそらくAtmel AVR UC3-32ビット）

PICをプログラムする可能性が少ないため（可能性のあるPICを避けたい）（上記のすべてには多少のオープンソースツールといくつかの公式ツールがあります）。

一部のARMがCAN機能を提供していることは知っていますが、他のARM についてはあまりよくわかりません。

今、私はこれらの可能性を思いつきました：

1. データを送信する単純なGPIO（たとえば、メッセージの開始を示すHIGHで16ビット以上、メッセージの終了を示すLOWで16ビットを超える）。ただし、すべてのビットを検出できるようにするには、標準周波数<<（frequency_client、frequency_server）である必要があります。クライアントMCUごとに1本のケーブルのみが必要です。
2. RS-232：これは間違いなく最も一般的に使用されている通信プロトコルだと思いますが、どれだけうまく拡張できるかわかりません。現在、最大64個のクライアントMCUを検討しています（おそらくそれ以降）
3. USB：AFAIKはほとんどRS-232に似ていますが、この場合はあまりうまく拡張できないと思います（USBは多くのデバイスをサポートしていますが-正しく覚えていれば255-このアプリケーションでは複雑すぎるかもしれません）
4. RJ45 /イーサネット：これは、長距離で問題なく（少なくともシールド付き> Cat 6ケーブルで）伝送できるため、これが本当に使いたいものです。問題はコストです（PHY、MAC、トランスなど）。あなたが実際に自宅でうまくはんだ付けできるかどうかはわかりませんが。この方法では、クライアントMCUは必要ありません
5. ワイヤレス/ ZigBee：モジュールは非常に高価ですが、机の後ろの「スパゲッティ」を避けるための方法かもしれません
6. RFモジュール/トランシーバー：私は300 MHz-1 GHz帯域のものを話しているので、自宅ではんだ付けするのは難しいはずです。モジュールはすべて組み込まれていますが、ZigBeeと同じくらい高価です（少なくともMouserのRFのモジュール、SparkfunのRFモジュールはもっと安いようです）。
7. できる？非常に堅牢なようです。車載アプリケーションで使用する予定はありませんが、それでも良い選択肢になる可能性があります。
8. I²C / SPI / UART？繰り返しますが、可能であればケーブルで「スパゲッティ」を避けてください
9. PLCは実際にはオプションではありません。長さが長くなり、電力ネットワークの容量負荷に依存するため、パフォーマンスはかなり低下します。価格面では、イーサネットとほぼ同じだと思います。

さらに、同時送信の場合、どのプロトコルが「より良い」でしょう（2つのデバイスが同時に送信を開始するというまれなケースを想定しましょう。どのプロトコルが最高の「競合管理システム」/「衝突管理システム」を提供しますか？

まとめると：柔軟性（デバイスの最大数、競合/衝突管理システム、...）、価格の両方を考慮して、非常に軽いデータ通信を行う分散クライアントシステムに最適なソリューションをお聞きしたいのですが。 、自宅で簡単に作れる（はんだ付け）、...通信モジュールだけに20ドルを費やすのは避けたいのですが、同時に机の後ろに30本のワイヤーがあると無駄になります。

現在私がイメージしているソリューションは、GPIOまたはRS-232（安い！）で近くのMCU間で基本的な通信を行い、「ゾーン」ごとに1つのMCUでイーサネット/ ZigBee / Wi-Fiを使用してサーバーと通信することです（高価です）、ただし、各クライアントMCUごとに1つのイーサネットモジュールよりもはるかに安価です）。

ケーブルの代わりに、光ファイバー/光ファイバーを使用することも可能です。追加の変換が必要ですが、この場合にそれが最善の解決策になるかどうかはわかりません。私はそれらについての追加の詳細を聞きたいです。

この場合、CANが最も適切に聞こえます。家の中の距離は、500 kbit / sでCANによって処理できます。これは、ニーズに十分な帯域幅があるように聞こえます。最後のノードは、既製のUSB-CANインターフェイスにすることができます。これにより、コンピューターのソフトウェアがCANメッセージを送信し、バス上のすべてのメッセージを確認できます。これをTCPサーバーなどとして外部に提示したい場合、残りはソフトウェアです。

CANが唯一の通信手段であるということは、I / Oラインで独自にロールすることを除いて、実際にバスであるということです。イーサネットを含む他のすべてはポイントツーポイントです。イーサネットは、論理的にスイッチのあるバスのように見せることができますが、個々の接続は依然としてポイントツーポイントであり、論理バストポロジの取得には費用がかかります。各プロセッサのファームウェアオーバーヘッドもCANよりもかなり多くなります。

CANの良い点は、最も少ない数のプロトコル層がハードウェアで処理されることです。たとえば、複数のノードが同時に送信を試みることができますが、ハードウェアが衝突の検出と処理を処理します。ハードウェアは、CRCチェックサムの生成と検証を含むパケット全体の送受信を処理します。

PICを避ける理由は何の意味もありません。プログラマーのために、自分で設計するための設計がたくさんあります。1つはLProgで、そのページの下部から回路図を入手できます。ただし、1時間あたりの時間を重視しない限り、独自の建物を作成しても費用対効果は高くありません。また、単なるプログラマー以上のものです。デバッグに役立つものが必要になります。Microchip PicKit 2または3は、非常に低コストのプログラマーおよびデバッガーです。私は彼らと個人的な経験はありませんが、他の人が日常的にそれらを使用していると聞きます。

追加：

RS-485にはいくつかの推奨事項がありますが、CANと比較してそれは良い考えではありません。RS-485は電気のみの規格です。これは差動バスであるため、複数のノードを使用でき、優れたノイズ耐性を備えています。ただし、CANにはすべてがあり、さらに多くの機能があります。CANは通常、差動バスとしても実装されます。RS-485は電気的に簡単に接続できると主張する人もいます。これは事実ですが、CANも同様です。いずれにせよ、単一のチップがそれを行います。CANの場合、MCP2551は良い例です。

したがって、CANとRS-485には電気的にほぼ同じ利点があります。CANの大きな利点は、そのレイヤーの上にあります。RS-485では、その層の上には何もありません。あなたは自分の好きにしなさい。バスの調停、パケット検証、タイムアウト、再試行などを処理するプロトコルを設計することは可能ですが、実際にこれを実現することは、ほとんどの人が理解するよりもはるかに難しいです。

CANプロトコルは、パケット、チェックサム、衝突処理、再試行などを定義します。すでにそこにあり、考え抜かれてテストされているだけでなく、多くのマイクロコントローラーのシリコンに直接実装されているという大きな利点があります。ファームウェアは、パケットを送受信するレベルでCAN周辺機器とインターフェイスします。送信のために、ハードウェアは衝突検出、バックオフ、再試行、およびCRCチェックサム生成を行います。受信のために、パケット検出、クロックスキュー調整、CRCチェックサム検証を行います。はい。CAN周辺機器は、RS-485でよく使用されるUARTよりも多くのファームウェアを駆動する必要がありますが、シリコンが低レベルのプロトコルの詳細の多くを処理するため、全体的にはるかに少ないコードで済みます。

つまり、RS-485は過去の時代のものであり、今日の新しいシステムにはほとんど意味がありません。主な問題は、過去にRS-485を使い続け、CANが何らかの形で「複雑」になっていると考えていた人たちのようです。低レベルのCANは複雑ですが、有能なRS-485の実装も複雑です。RS-485に基づくいくつかのよく知られたプロトコルは、CANに基づく新しいバージョンに置き換えられていることに注意してください。NMEA2000は、このような新しいCANベースの標準の一例です。CANベースのOBD-IIおよびJ-1939で現在はほとんど使用されていない別の自動車規格J-J1708（RS-485ベース）があります。

この機能はコントローラーネットワーキングの目的にぴったりであるため、CANを使用したコントローラーをお勧めします。

RS232は簡単に実装できますが、2ノード以上の通信を実装しようとすると、本当に困難になります（この目的のために構築されていないため）。

イーサネットの実装に自然ないくつかのホストとクライアントの相互接続について述べたので、イーサネットも甘いオプションです。

同じラインをすべてのデバイスに配線する可能性がある場合、複数のワイヤを使用するRS-485はここでうまく機能します。

たとえば、従来のカテゴリ5eネットワークケーブルで使用する場合、2ペアを使用して両方向のデータ伝送を行い（全二重モジュールを使用）、1ペアまたは場合によっては1本のワイヤを共通のグランドとして使用し、残りをネゴシエートすることができますどのデバイスがどの瞬間に送信するのか。RS-232よりも少し複雑ですが、モジュールはCANやイーサネットよりも安く、ケーブルの制限は1200 mです。欠点は、独自の競合解決プロトコルを作成する必要があることです。たぶん、送信したいデバイスが1本の専用線をチェックし、それが高いかどうかを確認してください。そうでない場合は高くし、通信を開始します。そうでない場合は、ランダムな期間待機します。それでも、これが長距離でどの程度うまく機能するかはわかりません。

マンチェスターエンコーディングデータで動作するRS-485バスを選択します。

RS-485の理由：

• 安いです
• 実装が簡単です
• ローパワーを使用しています
• 長距離（最大1200メートル）が可能
• 高データレート（最大10 Mbps）
• 干渉に対する高い耐性
• 同じバスで最大256個のデバイスを使用できるトランシーバーがあります
• 少ない部品数

マンチェスターエンコーディング：

• 実装が簡単です
• 自己同期可能

データの整合性のために、メッセージには長さとCRCフィールドを含めることができます。

CRC関数の例：

unsigned char crc_calc(unsigned char buffer[], unsigned short size)
{
  unsigned long i;
  unsigned char crc;

  crc = CRC_INIT;

  for (i=0;i<size * 8;i++)
  {
    crc = (crc << 1) | (crc >> (7));

    if (buffer[i/8] & (0x80 >> (i%8)))
    {
      crc ^= CRC_POLY;
    }
  }

  return crc;
}

CRC_INITおよびCRC_POLYCRCの計算に使用される任意の値です。

長さとCRCフィールドを持つメッセージの例：

好みの選択肢であるイーサネットと、好みの選択肢であるCANを比較してみましょう。

必要なコンポーネント：

• イーサネット：RJ45コネクタ、磁気、Phyチップ（MCUに統合されていない場合）。また、スイッチとスイッチから各ノードへのケーブルが必要です。各PCBには、かなりの数のコンデンサと終端抵抗、場合によってはフェライトも必要です。適切なPCBデザインが必要です。
• CAN：トランシーバーチップ（安価）、任意のコネクタ、安価なケーブルは、サイトの周りのループでノード間をホップできます。トランシーバに必要なコンデンサは1つだけで、バスの各端に終端抵抗が1つだけ必要です。

あなたは1ドルのマイクロコントローラについて話している。バスのコストには、MCUよりもはるかに多くのものがあります。実際に安価なソリューションを知るには、各ソリューションの総コストを合計する必要があります。MCU、コネクター、トランシーバー、受動部品、PCB、ケーブルなどのコストを合計します。

NXPのLPC11C24にはCANトランシーバーが統合されており、CANO​​penはROMでサポートされています（32 Kのデータフラッシュを浪費しません）。LPCXpresso 11c24ボードは20ユーロ（DB9コネクタ用のスペースが用意されています）なので、実際にワイヤを追加するだけです:-)

別の同様の質問から再投稿します。 2つのマイクロコントローラー間の低コストのシンプルな通信

TLDR：特に安価ではありませんが、いくつかのユースケースで信頼性の高い適合性。

ボックスの外側を見ると、ここで最近出会ったチップをフォローするなど、他のソリューションがいくつかあるかもしれません。もちろん、それはあなたが何をしたいかに依存します。両方のMCUを同じボード上に置いた場合、または分離した場合は手動でESD保護することを計画している場合、UARTなどが思い浮かびます。

IO-Linkアプリケーション用のマスターおよびデバイスソリューション

L6360   Master
L6362A  Device

このような解決策を検討する場合：

1. フロンティアチップは完全に保護されています。これは、各MCUを別々のボードに配置し、露出したピン（ネジ留め式端子など）を扱う場合に重要です。
   • 逆極性
   • カットオフ機能を備えた過負荷
   • 過熱
   • 低電圧および過電圧
   • GNDおよびVCCのオープンワイヤ
2. 相互運用性。他の誰かが反対側を設計する場合、彼が知る必要があるのは、IO-Linkを介してデータを集中させることです。
3. 統合レギュレータ Vcc(in) 7~30v, Vdd(out) 3.3/5v

私にとっては面白そうに聞こえたので、それをそこに置くと思いました。

それは、アプリケーションとマイクロコントローラーの規模に依存します。Atmel tiny / megaに言及しましたが、非常に小さいです。その場合、I2C / SPI / UARTにはハードウェアで実装されているため、使いやすいという利点があります。