デバイス側の232C通信/TCP通信を作成する方へのお願い

IoTの流行で、RaspberryPiなどの小型のデバイスで計測したデータを送信したり、外部機器と通信したりするプログラムを自作する機会も増えていると思いますが、以下の点に注意してもらえれば、あなた以外の人がそのデバイスと通信する時に余計な苦労をしなくてすみます。ぜひご検討ください。

1.アスキーデータ

データの終端にはデリミタを必ずつけましょう。
特に、垂れ流し出力の場合は必ずデリミタをつけるようにしましょう。
232Cの場合のデリミタは、CR, LF, CR/LFのいずれか、TCP/IPの場合のデリミタはCR/LFを推奨します。
また、あくまでも、CR/LFであって、LF/CRはだめですからね。
もしも、うっかり特定のケースの時だけデリミタつけない、つけるのを忘れたという場合、相手側からすれば、かなり面倒な類の「不具合」なので、つべこべいわずにとっとと直しましょう。
そして、アスキーデータというからには、アスキーコード以外のデータは入れないでください。（アスキーデータといいつつ途中に00Hなんか入ったりするとトラブルになりやすい。）

まれですが、ターミナルソフトで通信することを想定して、初心者でもわかりやすいように "\n\r>"などプロンプトを送信するのものがありますが、コンピュータ同士で通信する場合には、余計なお世話、です。
プロンプトなど、コンピュータ同士で通信するのに意味のないデータはつけないでください。

2.バイナリデータ

バイナリデータの送信時のフォーマットで、データの末尾につける終端コードにETX(03H)をつけるのはあまり意味がありません。
データの途中にETXと同じコード(03H)が含まれていたら、データ終了と誤って判定してしまうので、受信側はデータ終端の判定には使えません。CRやLFでも同様です。
バイナリデータの送受信の場合は、バイト数を決めて出力するようにしましょう。または、先頭にデータの長さ（バイト数）を入れるという方法もあります。

3.起動時の出力

起動時に、スタートアップの意味でファームウェアのバージョンなどを出力するものがありますが、通信の邪魔になるのでやめましょう。
通信中に、なんらかの理由でデバイス側が再起動してしまった時に、相手がその出力を受け取ってしまうと、受け側のソフトは予期しないデータを受け取ることになり、それをフィルターするプログラミングにどれだけ無駄な時間がかかるのか。最悪、フィルターしきれずに誤動作する可能性があります。
せっかく、性能のよいデバイスを作っても、通信で誤動作が頻発してたらデバイスの信頼性を疑われてしまいます。

4.エコーバック出力

デバイス側が受け取ったコマンドをそのまま送り返すエコーバックですが、基本的にエコーバック出力はしないか、もしくは、オプションなどの設定でエコーバックの有無を切り換えられるようにしましょう。
たぶん親切心でやっているのかもしれませんが、エコーバックは無駄です。

5.通信プロトコルの説明

送信するコマンドの書式については正確に記載されていても、デバイスから返す応答メッセージについての記載は、なおざりだったりします。ろくに書いてない場合も多々あります。
デバイスと実際に通信すればわかる、ということなのでしょうが、そのデバイスが手元にある場合はそれでいいのですが、そうでない場合もあるのです。
成功した時、SyntaxErrorだった時、範囲外だった時に、どういう応答メッセージを返すのかできる限り具体的に記載しましょう。
最低限、終端につけるのはCRなのか、LFなのかCR/LFなのかくらいは、きちんと書きましょう。
また、応答メッセージのフォーマットが、各コマンドでばらばらだったりしないよう、統一感のあるものにしましょう。