通信インタフェースの選択, 組み込みプラットフォームの選択について
今年, 私は高専ロボコンに特別要員としてむりやり参加させられた (まぁ楽しかったのでﾖｼ！) のですが, そのとき工作物, 主にロボットに使う通信インタフェースの選び方やマイコン等組み込み周りのプラットフォーム選定があまりにも適当すぎる現状を知りました。まぁ, こうゆうこともあり結局大会でロボットは動かなかったんですよね… スタートゾーンから (笑) ということであくまで自分なりにどう通信インタフェースを決定するか, 組み込みプラットフォームを選定しているのかを書こうと思います。
通信インタフェース
マイコンを触っている方ならパラレル, シリアルという言葉は理解しているでしょう。情報・通信機器間の通信は主に電気信号で行う必要があり, それの送り方をパラレル, シリアルと大別しています。通信インタフェースは機能間の通信を担う要素なので, 当然選択を誤ると無駄に通信速度が遅くなったり, 連続性が欲しいデータにジッタが現れたりします。今回, 高専ロボコンではマイコン間での通信にEthernet (TCP/IP) を, 無線通信に WiFi (IEEE 802.11) を使っていました。残念ながら, 僕が呼ばれた時にはコレを採用する流れになっていまして, 今思えば全力で止めるべきでしたね…。
通信の種類
工作界隈でよく使われてそうなインタフェース, 方式, 無線を並べます。
・RS-232 (UARTと呼ばれたら大体コレ)
・I2C
・SPI
・CAN
・Parallel (GPIO controlled)
・WiFi
…くらいですかね。
通信の種類によるメリットデメリット
各通信方式, 通信バスにはそれぞれ特徴があり, 適材適所といった所です。選択を誤ると無駄に開発時間がかかったり通信が遅くてイライラしたり…。簡単に書いておきます。
RS232
「UART」と言われたら大体RS232の事を言っているのでしょう。 一般的なシリアル通信の規格です。今のマイコンには大抵UARTが乗ってるので, マイコン間通信, マイコン-PC間通信に最も多く利用されてる通信ですね。まず, UARTは非同期式なのでマイコンがデータの到着を知ることはできません。(UARTバッファの要素数を読んで現在何バイトデータがたまっているかを知る事はできます。) 非同期通信の難しいところはデータを取るタイミングでしょう。非同期という名の通り, データ送信側はデータを送りたいときに送り, 受信側は取りたいときに取ります。大抵のマイコンには 32～512 byte のUART受信バッファが乗っているので物理的にデータが到着してからソフトがデータを取るまである程度時間的余裕がありますが, データの到着速度に対してソフトの読み取りが遅いとUART受信バッファの内容は順次破棄され, 正しいデータを得ることができません。うーん, 言葉で説明するのは難しいですね (^_^;)
例えば…
・受信バッファが32byteのUARTに対して1秒間に8バイトデータ送信すると, 受信側は何もしなければ4秒後にはバッファがあふれる。
・受信側のマイコンはソフトでUART受信バッファからデータを1byte読み出すとUARTバッファからデータが順次1byteずつ抜き取られる。
・到達するデータより読み取るデータの方が多ければバッファはあふれずデータはちゃんと読み出せる。
・到達するデータが読み取るデータより多ければいずれバッファはあふれる。
ってかんじでしょうか。絵に描かないとわかりづらいかも(^_^;)
よって, デメリットはデータレートとソフトで読み出せる速度を考えないとデータが壊れるという事でしょうか。これはボーレートをいじればある程度解決する問題ではあるんですけどね。
メリットとしては, 対応してるデバイスが多い, 配線が簡単, 多少のノイズに耐える, くらいでしょうか。非同期通信は回路を簡単にできる分, ソフト面で考えることが多いんですよね…。
マイコンの設定によりパリティチェック, オーバーランエラーチェック, チェックサム, CRC を行えるので, データの保障もある程度はできます。
I2C
I2C (Inter Integrated Circuit, IIC) は低速な2線通信バスです。速度で言えばノーマルモード 100kbit/s, fastモードで 400kbit/s ほどです。場合により1Mbit/sでも可能。データ配線(SDA)とクロック配線(SCL)はプルアップされたオープンコレクタ信号で, このプルアップ抵抗を忘れて通信できねーってなる人も多いはず…。こいつのデメリットは, ノイズに弱い, なにより配線長を伸ばせない事でしょう。そもそもオープンコレクタ信号線を1ｍとか引き伸ばすものではありませんね。あくまで基板内通信ですから, 配線をビローンと伸ばしてデバイスを接続するような方法はあまりよろしくありません。あまり配線を長くしすぎるとデータが読み出せず, マイコンによってはI2CのACK信号を待機し続けフリーズしてしまうでしょう。メリットは, 対応してるマイコンが多い, 配線が楽, アドレスを振って同配線で複数のデバイスを共存可能, ってとこでしょうか。あと同期通信なのでデータの送受信タイミング自由に設計できます。
SPI
同期3線式のシリアル通信インタフェースです。通信速度は数Mbit/sほどまでいけます。I2Cに比べると信号線の本数が増えますが, 配線の長さに!2Cより自由がある印象です。はっきりと定義されている通信ではありませんが, 通信の仕組みはとても簡単で, デバイスを自作するときなんかに一番実装しやすいインタフェースだったりします。デメリットは信号線が増えること, メリットは高速, SS(スレーブセレクト)信号により複数スレーブ対応, ロジックICだけでも実装できるほど単純, くらいですかね。
CAN
CAN (Controller Area Network) はマイコンやデバイス間が直接通信できる, ノイズに強い車載向け通信バスです。自動車だけでなく, 工業機械やロボットの内部通信にも多く用いられています。マルチホスト通信で, 差動信号線信号線により複数ノード間のデータ通信を行いますので, 40mとか配線を伸ばしても1Mbit/sの通信ができたりします。デメリットは対応しているマイコンがそれほど多くなく外部にCANコントローラを用意する必要があるかもしれない事, メリットは配線長を伸ばせる, データの到着タイミングが保障される, くらいですかね。
Ethernet
RJ45コネクタでつなげる有線LANとかのアレです。通信プロトコルは工作で使うものだとTCP/IPかUDPじゃないでしょうか。この通信は市販のLANケーブルがそのまま使えるので配線のハンダ付けの必要が無く, またパソコンで最も扱いやすい通信でしょう。WireSharkなどの解析ソフトを用いれば, マイコンから送られてくるデータをPCでモニタリングできたり, ブロードキャストが使えたり, スイッチを使ってデバイスを簡単に増設できたりします。デメリットは, Ethernetに対応してるマイコンが少なく外部にコントローラやパルストランスを用意する必要があること, ホストコンピュータの処理処理, OSの状態によっては通信が停止したり, 数百msの遅延やジッタが発生したりすること, バッファを適切に設定しないと通信速度がモロに低下するなど。メリットは, デバイスの増設が楽, PCでモニタリング, 制御が簡単であることくらいですかね。
Parallel
パラレル通信です。回路の配線引き回し設計は慎重に行わなければ成りませんが, 大抵シリアル通信より高速にデータ送受信ができます。また, GPIO (汎用入出力)より簡単に実装できますので, どのマイコンでも実装できます。マイコンによっては専用のパラレル通信コントローラが載ってる場合もありますが, 基本的にIOレジスタを叩くだけで通信ができるので特別なコントローラ無くデバイスを制御できます。デメリットは, 配線本数がデータのビット数に応じて多くなること, メリットは高速に通信できること, どのマイコンでも実現できること, デバイスによって自分で通信規格を実装できること, くらいですかね。
WiFi
WiFiです。
Bluetooth
Bluetoothです。
Zigbee
IEEE802.15.4で規格化されている低速短距離無線通信。日本だと電波法的に2.4GHz帯なので普通に混信しますが, Zigbeeモジュールなんかは簡単に手に入るのでとっつきやすい無線ではあります。
通信インタフェース, 方式の選び方
各通信を適当に紹介しましたが, どれもメリットデメリットがあって使う場所と場合を考えないといけません。でないと, 弊学ロボコン部みたいに通信で詰むことになりますのでw といっても, どれもこれもコントローラの性能やソフトの処理によって大きく左右されるので, それもディベロッパーが考慮しなければなりません。
まず, データの信頼性を保障したい場所 (この場合は, データが届くか届くかではなく, 届いたときにデータ壊れていない事) ではUART, Ethernet(UDP), SPI, パラレルは適さない場合が多いですね。まぁ, エラーチェックがあるかないかで大きく変わるところがあるので微妙なんですけど^^; データの内容を保障できるのは I2C, CAN, Ethernet (TCP/IP) ぐらいでしょう。
データの時間的安定性を保障したい場所では, UART, SPI, I2C, CAN, パラレルのどれかでしょう。Ethernetはホストコンピュータの処理によって数ms～数百msの遅延が常時発生しますので, リアルタイムでデータを取りたい場合には向いていません。
簡単に実装できる事を優先させる場合には, UART, I2C, SPI, パラレルが簡単です。それ以外では専用コントローラが必要になる場合が多いです。
耐ノイズ性を保障する場合は, UART, SPI, CAN, Ethernet でしょう。
拡張性を求めるなら I2C, SPI, CAN, Ethernet かな。
総じて考えると, ロボットのようなリアルタイム性重視でかつ過酷な状況下で動かす事を想定する場合はCANでの通信が一番強そうであることが言えます。まぁ, そうゆう規格ですしね。しかしコントローラの用意が少しばかりめんどうですね…実はArduino Dueでできたりするんですけどね。標準関数だと何故か使えないのでそのうちCANライブラリを公開しようかなぁとも思ってたり。ちなみに, ロボットの制御系全体にEthernetを使ったのが弊学ロボコン部です(^^) こうゆう場面で一番向いてない通信ですよね…ｳﾝ…。
無線通信の場合, 周りの状況に配慮しないと混信を起こし, まともにデータ通信できなくなります。例えば人ごみの中でWiFi通信をしようとすると, 大量のスマホからアクセスポイント等情報が飛んできまくり絶望します。Bluetoothも同じです。この場合は, 800MHz帯等周りが使ってなさそうな帯域の無線通信をするなどして解決するしかないでしょう。ロボコン会場でWiFi, Bluetooth通信を使ったのが弊学ロボコン部です(^^)
通信インタフェースまとめ
結論 : 必要な利点と必要でない利点を良く考えて通信方式を選ぼうね！！
組み込みプラットフォーム
場所と場合によってデバイスを選択する能力によって, 今後の開発効率やできる事, モチベが大きく変わってきます。(まじです。) 結論から言えば「慣れてるデバイスが一番！」に限るんですが, 案外そうは行かないこともあるんですよね。例えば, 慣れてるデバイスだと実装したい機能が実現できないジャン！とか。
組み込みプラットフォームを選ぶ基準は大きく次のようだと考えます。
・処理速度は十分か
・機能は十分使いやすいか
・インタフェースの量は十分か
・ドキュメントは充実しているか
・開発環境が使いやすいか
・開発に慣れているか
僕の判断基準では, 例えば
・LEDの点灯, リレーの駆動やパルス生成等レベルの低い分野, リアルタイム性が求められる場面
→ AVRマイコン, FPGA, PIC16, PIC24等
・それより少しレベルの高い領域 (簡単なベクトル計算, 三角関数など多用する場面)
→ SAMマイコン, STMマイコン等 ARM Cortex M シリーズのコアを搭載したリアルタイムマイコン
・さらに少し高度な処理 (リアルタイム信号処理, DSP等)
→ i.mx RT ファミリーやdsPIC等
・更に高度なアプリケーション寄り処理 (LCDの描画, アプリケーションの実行等)
→ PIC32 や i.mx 8 等 Cortex Aシリーズコア搭載チップ, FPGA
って感じですかね。
これらは全てプラットフォームの性能で判断しましたが, これだけでは不十分な場合があります。それは, 使いやすいアーキテクチャになっているか, 開発環境やドキュメントが充実(可読性が高い資料が豊富)してるかも重要な要素だからです。
アーキテクチャに関しては, 十分なメモリとコアの性能, ペリフェラルの性能が必要なのは大前提で, 結構気になるのはペリフェラルの使い方です。基本コントロールレジスタで制御することになると思いますが, この辺の設計が変だと開発で変な時間もってかれます。
開発環境について, これはあくまで僕の意見ですが, Arduino IDEは非常に簡素なUIで操作も簡単, リファレンスも日本語で充実してますので, Arduino = ちょっとしたテストや脳死で実装できる部分に使おう って感じになってるんですよね。ST Micro の CubeMXはGUIにも関わらず十分高度なコンフィグレーションができますし, サードパーティのエディタやドキュメントも充実してますので, 本格的に実装したい部分, とにかく開発速度を得たい部分なんかに使います。FPGA使うときなんかもQuartusは分かりやすいと思いますし, ちょっと動かしたいときにシミュレーションからコンフィグレーションまでパパッと実現できます。
ちなみに, Microchip 製品 (PICとか) は個人的に好きではありません。MP Labはメモリは無駄に食いますし, Harmony等, コンフィグレータにもバグが多いですし。なによりドキュメントが冗長でクソ読みにくい…エラッタも多くてどうも使う気になれませんね…。(といってもPIC32はMZをちょっと触った限りですが^^;)
現に弊学ロボコン部でも, 回路班がPIC32とMP Labに苦しめられてましたからね。アレに関しては, 素直にPICを切り捨ててARMに移行してた方が時間もコストもかからなかったように思いますが…。できないプラットフォームに執着するより一般的で親しみやすいプラットフォームを探して移行する方が賢明ですよ。ホントに。
組み込みプラットフォームまとめ
結論 : 身の丈にあったプラットフォームを探そう！
おわりに
はい, これら全て僕の意見なので, あんまり鵜呑みにしないほうが良いかと思います。結局は, 手を動かして地道に最適解を探すしかないんですよねぇ…。変な先入観や周りの意見にとらわれていると, 結果として後悔することになりますし。にしても, 私個人としては, 後輩, チームメイトなんかには経験を伝えることしかできませんのでね。難しいところです。。
