beeさん
STXの後にパケット長を入れるとか色々ありますけども、パケット構成は思想次第ですねー。リーズナブルに安定的な通信ができるといいですね。
SUM,ETXの順がキレイでいいので、ひとつアイデアです。SUMの計算をデータの上位4bitと下位4bitに分けて、4bit単位で加算していって、SUMを7bitで表現してSUMの最上位bit7を1固定にすれば、80～FFHの値(≠02h)をとるので問題なくなるのかなと思います。パリティやチェックサム、CRC付加は、確率論の世界なので、冗長なほどエラー検出力が高くなりますけれども、逆にチェックサムが8bitから1bit減って7bitになっても、確率的にはエラー検出力に大きな違いはありません。(ただし、8bit単位でサムを取ってbit7を1固定にすると、エラー検出力が著しく落ちてしまうので、注意が必要ですけども)
これとは別に、パケットとパケット間の空き時間が一定時間を越えたら、受信を仕切り直すとかの処理をいれると、よりロバストになるかと思います。
＞PC側の担当者から 「SUMはETXの前に入れ、16進ASCII表記2バイトにした方が良いのでは」
ＰＣ側担当者からすればバイナリ可変長はうっとおしい
出来れば全部アスキーで終了コードはＣＲ
それが一番簡単で初心者でも出来る
それなりのベテランでもシリアル通信やったこと無い人がバイナリ通信するとハマル
最近はＰＣにシリアルポートが付いてないし
シリアル通信を知らないプログラマは多い
ＤＯＳ時代にはシリアル通信はごく普通にあったけれど
事務系でもバーコードリーダとかで
最近のバーコードリーダはＵＳＢだし
アスキーにすると通信バイト数は増えるが
よほど高速大容量通信する必要がなければそれほど困る事も無い
まさか画像データとか送る訳でもなかろう
計測器とかで計測した数値を送るだけなら
そもそもですが
本件でバイナリ通信にしなければならない事情は何でしょう？
マイコン側メモリが少ないとか？
チェックサムの位置の話ではなく、データをASCIIで送るかバイナリーで送るかのように思えます。たとえば、01abhは、「SUMはETXの前に入れ、16進ASCII表記2バイト」だと02h,30h,31h,41h,42h,30h,32h,03hで、バイナリーなら02h,01h,abh,aah,03hですよね。ASCIIの場合はCRやセミコロン、03hなどでパケットの終了を示せるのでデータ長を変えるのが簡単です。一方で、バイナリーの場合は固定長かデータ長の挿入が必要そうです。私も一度だけですが、ASCII表記の通信をマイコン側で受けたことがあります。ASCII表のマイコン側ソフトウエアはデコードとエンコードともにかなり面倒です。私はVCとWindows前のターボＣを少しかじった程度なので良く分かりませんがPC側のソフトウエアにはメリットがあるかもしれません。お客様の要求なので、理由ははっきりと聞けませんでした。データがASCIIならチェックサムもASCIIではないですか？ で、ETXの前になります。バイナリーなら、02h(Send Of Message),Data,CheckSum,03h(End Of Message)のように思えます。やっぱり、チェックサムはEOMの前ですね。