きもと特急電子設計は、ハード・ソフト・ウェブシステム開発(試作〜小ロット)が得意な、独立13年、経験40年の個人エンジニアです。急ぎの試作でできる分野は、以下の通りです。
< 通信プロトコル対応・設計
TCP/IP。
MIDI。
有線プロトコル設計。
無線プロトコル設計。
- 通信プロトコルでいちばん大事なのは、異常な状態からの回復です。
- もう一つ難易度が高いのは、電池を長持ちさせることです。
- 通信の種類によりますが、エラーによってデータが化けたり、そこまでいかなくてもデータが欠落する可能性はあります。
- ですから、このようなデータ異常が発生した場合でも、異常な状態になったり、正しい状態に戻れなくなったりしないように設計することが重要です。
- 例えば「データを送ったら、相手から応答を返し、もし応答がなかったらもう一度送る」という通信プロトコルには、トラブルの芽がいくつも隠れています。
- 応答が返るまで次のデータを送れないのか、応答と、相手からのデータをきちんと区別できるのか、もし相手が(RaspberryPiなどのように)すぐに応答できるとは限らない場合に再送がかかってしまい、以降のデータが1つずつズレてしまったりしないのか、などが思いつきます。
- 電池を長持ちさせるという点については、有線通信の場合と無線通信の場合とがあります。
- 有線通信の場合は、通信によって相手の待機状態(消費電力を抑えるためマイコンが止まっている状態)を解除できるように設計すると、通信がないときに待機状態に入ることができます。
- これによって、電池を長持ちさせることができます。
- 無線通信の場合は、通信を待っている(受信機がオンになっている)だけで電池を消費します。
- そこで、コンセントからの電気をもらっている側は電気を消費しても構わないので受信状態にしておき、電池で動かす側が送信することでプロトコルがスタートするように作ります。
- こうすると、電池で動かす側は、何もないときは受信機をオフにしておけるため、電池を長持ちさせることができます。
- 正直申し上げて、通信プロトコルはいろいろなことを考える必要がありますし、途中で修正する場合は送信側と受信側の両方をアップグレードする必要がありますから、修正の手間や不具合が入るリスクも大きくなります。
- もし慣れない方が独自のプロトコルを作られる場合は、(きもと特急電子設計でなくてもいいので)詳しい人にレビューしてもらうことをおすすめします。