モータの鳴らし方byHanDen

　今回はステッピングモータを演奏する基板以降で共通システムとして使ってる通信システムについて紹介します。

　

　私の作ってる基板は原則分散型の処理にしているため基板ごとにマイコンを搭載しています。そしてそのマイコンが乗った基板(スレーブ)をマスター装置から指令を与えて特定の動作をさせています。今回はそのシステムについてのお話です。

 

マイコンの通信機能

　一般的にマイコンに搭載されている通信機能はI2CやSPIそしてUARTなどがあります。この中でもI2CとSPIは標準でバス通信に対応していますが、I2Cは高機能ではあるものの基板内通信を前提に設計された通信のため基板外への通信となると安定性が悪化してしまいます。また、SPIはスレーブ1つにつき制御ピンが1つ必要となりスレーブの数が増えるとその分ピン数が増え不都合です。それに対し、UARTは標準ではマルチスレーブ機能に対応できませんが、RS485に比べると劣るものの基板外に出てもよほど長距離でなければ十分運用できる程度の通信の安定性があるのが特徴です。

 

アイデアの元

　システムを考えていた時にふと目に入ったのがシリアル制御のサーボモータでした。シリアル制御のサーボモータはRS485やUARTでありながらIDを指定することでマルチスレーブに対応できるのが特徴です。システム的にはI2Cにも似ているのものの、ベースはUARTやRS485というだけで信頼性は十分にあります。そこで、UARTをID指令式で運用するという方針でシステムの設計を行いました。

 

ハードウェア構成

　各基板同士を同一のシステムとして扱えるようにするためにハードウェアも共通化します。しかし、構造は非常にシンプルで回路図的には以下のような形です。

　使用感覚としてはUSBのような感覚で使えるようにするためマイコン駆動の電源と通信線を同一のコネクタにまとめています。これによりコネクタ1つでロジック側の電源確保と通信回路が構成できます。また、ピンサインもUSBに近い形として1番ピンに電源、2,3番ピンで通信、4番ピンをGNDとしています。

　また、配線量節約のため各基板に並列接続された2つのコネクタを設け数珠つなぎに対応させています。もちろんマスター側で分岐してからスレーブに接続することも可能です。

　データはすべてRXピンから受信します。TXピンは将来的な拡張用でデータ異常時に再送要求を送る場合や、マスターから指示があった場合にスレーブから情報送信を出来るようにしています。

 

通信プロトコル

　モタドラとして運用する場合の高い信頼性と演奏システムとして使う場合の大量送信を行うことを考え、連続的にデータを送信できてかつ受信データ抜けがあってもその後の通信には影響を与えないシステムを前提とします。そのため、特定のバイト数ごとにIDを送信するといったシステムは読み飛ばしなどで正しく動作しなくなるためＮＧです。つまり、何かしらの方法でIDデータを区別できるようにする必要があります。しかし、IDの前に間隔を置くと連続送信ができなくなるのでNGとします。

　この条件をまとめると各データがIDなのかそうじゃないのかを区別する方法を考える必要があるというわけです。

ここで使うのが、MIDIのシステムの考え方です。MIDIは先頭のbitでチャンネル情報かそれ以外の情報かの区別を行っています。これと同様に先頭のbitが0か1かでIDデータの判別を行い。それに続くデータを送信内容(スレーブに送るデータ)にします。これにより、データの読み飛ばしがあった場合でも次のデータからは正しく読み込めるほか、連続したデータ送信にも対応できます。

bit番号	7	6	5	4	3	2	1	0
内容	ID判定	データbit {bit7 = 0 : 送信データ   bit7=1:ID}

 このような構成にすることで複数バイトのデータ送信も簡単にできます。また、モタドラと演奏などIDごとに機能が違ってデータバイト数の違う基板を混在させることもできます。

 

さらなる信頼性向上

　演奏の場合は通信速度の方が重要なので以上で紹介したシステムでデータ送信をしていますが、モタドラモードの場合はデータの化けやマスター側のトラブルなどで暴走などが起きると大問題になります。そのため、信頼性向上のためにさらに通信を拡張させています。拡張内容としては以下の2つです。

・パリティーチェック

・ウォッチドッグタイマー

 

まず1つ目のパリティーチェックについて紹介します。

　このシステムでのパリティーは送信データ(ID以外)の各データをXORのbit演算を行ったものとしています。

まずは、マスター側で送信する各データをXORでbit演算し送信データの最後に付加します。

続いてスレーブ側では受け取ったデータをXORでbit演算し最後に送られてきたパリティーを比較して同一かの判定を行います。もしも異なった場合はそのデータは破損データとして無視する設定にしています。データ破損の場合は再送要求をするなどでさらなる信頼性向上も可能です。

 

続いてウォッチドッグタイマーです。

　こちらは一定時間ごとにデータを送信し、一定時間以上データが途切れた場合にモータを停止させます。しかし、各モータの制御信号をウォッチドッグタイマリセット用に毎回送るとデータ量が非常に増えてしまいます。そのため、ウォッチドッグタイマリセット用のIDを別に作り、そのIDをマスターから送ることでデータ量を削減しています。スレーブ側は解除IDを受信すればウォッチドッグタイマーをリセットします。

　

以上で自分の演奏システムとかの通信関連のシステムとなります。

本ブログの記事はKiCad4.0.7をベースに記載を行っています。KiCad5.0になっても基本的な機能は同様に使うことができますが、一部異なる機能があります。以下現在確認済みの異なる箇所を記載します。

KiCad編　第1回　ライブラリ参照箇所 
 4.0.7は既定ではGitHubn参照→5.0では既定ではローカルライブラリ参照（筆者環境)
 ライブラリ名にも変更があり。


KiCad編　第5~8回
　KiCad5.0では初回起動時にGPUのアクセラレーションに関する質問がありOKを押すとデフォルトでモダンツールセット(4.0.7のデフォルトはレガシー)になり、配線関連で機能追加や変更があります。特に第6回の自動配置関連、第7回の配線のドラッグや削除関連および押しのけ配線などに変化があります。
ブログと同様に近い方法をで作業を行いたい場合は「設定」メニューから「レガシーツールセット(s)」に変更してください。ただし、第6回の自動配置の機能は使えなくなっています。

また、その他項目名やアイコンに変更がありますが、それらは似たものを選択すれば基本的には使えると思います。