ArduinoとGR-SAKURAでLチカコラボ 2

  • LINEで送る

第1回では受光素子であるCdSを利用してGR-SAKURA側のLED発光を検知し、Arduino側で同期発光するサンプルを作成しました。

第2回以降では単純な同期だけではなく、発光/受光による通信について考えたいと思います。

システム全体像

利用する基板はGR-SAKURAとArduinoです。こちらは前回と変わりませんが送受信するデータを指示、確認するためにパソコンを追加しました。
LEDclb01

通信を行うには

どんな通信にも言えることですが、約束事が必要です(約束事をプロトコルとも言います)。

  1. 開始の合図
  2. 通信の速さ
  3. データの構造
  4. 誤り訂正
  5. 終了の合図

ぱっと思いつくだけでも上記5項目がありますが、今回は複雑に考えずに1、2、3、5について定義をします。

一般の通信には誤り訂正は必要ですが、今回の通信は低速である事、誤りが発生しても特に支障がないので行いません。通信の内容がクリティカルなシステムでは誤り訂正だけではなく、暗号化など通信そのものの堅牢性も検討する必要があります。

通信プロトコル

では通信開始の合図について考えてみます。
LEDclb02

  • 普段の通信が発生していない状態(待機状態)をLED消灯とします。
  • 止まっている状態を意味するのでLEDも消灯させます。

  • GR-SAKURAは送信データがある時にLEDを100ms発光(開始合図)します。
  • シリアル非同期通信(または調歩同期)で言うスタートビット※1に相当します。100msもとる必要はないと思いますが、受光側がCdSであり、受光遅延があってはいけないので十分に長い時間※2をとることにしました。

※1 ビットは情報の最小単位です。8ビット→1バイト、32ビット→4バイト、64ビット→8バイト
※2 今回は”当たり”をつけて進めていますが、実際のシステムを組む際にはデータシートを確認の上ご検討ください。

続いてデータの送受信について検討してみます。
LEDclb03
データを送受信するにはコード化とビットシリアル化が必要になります。かつてはパラレル通信というものもあり、シリアル化は省略できるケースもありましたが、現在はほとんどお目にかかれません。
今回のコード化にはASCIIコードを利用します(利用と言っても半角英数記号はASCIIが一般的なので、特に意識する必要はないです)。上記例ではアルファベットの「E」を送信しています。アルファベットの「E」はASCIIコード表で言うところの0x45(16進数)です。

進数変換(「^」は累乗を意味しています)
16進数→0x45
10進数→4×16^1 + 5×16^0 = 64 + 5 = 69
2進数→0x2^7 + 1×2^6 + 0x2^5 + 0x2^4 + 0x2^3 + 1×2^2 + 0x2^1 + 1×2^0 = 01000101
ASCIIコード表の他にはJISやS-JIS、UNICODEなど多種あります。同じコード表でも地域(ヨーロッパ、アメリカ)によっては割り当てられている文字が異なる場合があるので注意が必要です。
EBCDICなんてコード体系もありますが余程特殊な事情が無い限り使うことはないと思います。

送信側はコード化されたデータを最上位ビット(MSB)から順番に1ビット単位で送信(1:発光/0:消灯)します。

受信側は100msの開始合図を確認すると最初の1ビットは50ms後に、以降は100ms毎にLEDの発光状態を確認します。送信は100ms間隔で発光/消灯を行うので中間地点でLEDの状態を確認するようにしました。
データは最上位ビット(MSB)から順番に送られてくるので最下位ビット(LSB)から順番にシフトしながら埋めていきます。
LEDclb04
以上の手順で「文字データ→コード化→シリアル化→光データ→シリアル化→コード化→文字データ」の光通信を行います。

次回はこのプロトコルで通信を行うためのプログラムについて検討します。

SNSでもご購読できます。

役に立ったよ!

本記事が役に立った!と思っていただけましたら下記ボタンからチップをお受けしております。

 

E.P.ラボにチップ

スポンサー リンク

コメントを残す

*

CAPTCHA


このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

%d人のブロガーが「いいね」をつけました。