シングルチップマイコンでよく使われるシリアル通信プロトコルフレーム
序文
最近シリアルポートがよく使われるようになりましたが、使用されている通信プロトコルのフレームを簡単にまとめて通信する必要があると感じましたので、必要に応じて直接参照していただけますようお願いいたします。
1. MCUシリアルポートの概要
マイコンのシリアルポート(UART)はシングルバイト送受信の通信方式で、通常は3本の配線で十分です。標準的な配線シーケンスで接続する場合は9ピンのDB9タイプになります。 3 線 (rx tx gnd | AB gnd) はシンプルで使いやすく、接続されているデバイスの数が少ない短距離通信によく使用されます。
シリアル ポートに外部制御チップを追加すると、シリアル ポートが RS232 と RS485 の 2 つの通信タイプのレベルに変更されます。RS232 のロジック 1 と 0 は +15V と -15V、RS485 のロジック 1 と 0 に分割されます。 ABポートの+2～+6と-2～-6の電圧差に対応します。RS232は複数のサブデバイスを接続できず全二重通信が実現できますが、RS485は複数のデバイスを搭載して単二重通信が実現できます。
1バイトの送受信であるため、解析して送信するためには所定の通信フォーマットが必要となり、これが通信プロトコルとなります。
2. 一般的に使用される通信プロトコルの種類
1.フォーマットなし
場合によっては、重要な形式がないため、多くのデバイス メーカーが文字列命令制御を直接使用しています。例えば
/s1000
速度を 1000 に設定します
/r0000
工場出荷時の設定を復元。
これには、キューやキャッシュを使用せずに、一般的なリソースとパフォーマンスを備えた一部のデバイスで直接使用でき、割り込みでデータを直接読み取って割り当てるという利点がありますが、これは単純で失礼です。スイッチのケースは簡単に解決されます。単純な短いコマンドや短いデータの場合に適しています。
欠点は通信データが長くなりすぎて誤操作が起こりやすいこと（むやみやたらにデータを送ってコアデータを書き換えてしまったら終わり）です。
2. フレームヘッダーとフレームテール+データ
| フレームヘッダー | データ長 | データ | チェックデジット | フレームの終わり |
|---|---|---|---|---|
| 0XF5 | 0X4 | 0X01 0X02 0X03 0X04 | 0XC5 | 0X5F |
シンプルで一般的に使用される形式は、フレーム ヘッダーとフレーム末尾またはチェック ディジットを備えたこの形式です。通常、データはシングルチップマイコンで受信されてキャッシュキューに格納され、メインループでフレームヘッダーとフレームテールに従ってキャッシュキュー内のデータが抽出され、フレームの割り当て演算が実行されます。フレームごとに。
サムチェックやCRCなどチェックサムはたくさんありますが、ここでは暗号化も実装できると思います 暗号化アルゴリズムを自分で設定でき、暗号化アルゴリズムを使用してチェックデジットを取得できます。デバイスの暗号化アルゴリズム。通信プロトコルのみを駆動できません。(動作を示します。多くはチェックデジットさえありません。シンプルであるほど信頼性が高くなります)
これは少しシンプルで信頼性が高く、上位コンピューターと下位コンピューターは通信形式に従って簡単にデータのやり取りを行うことができ、長いデータに適しています伝染 ; 感染。
3. フレームヘッダーおよびフレームテール + データ + 追加機能コード
| フレームヘッダー | ファンクションコード | データ長 | データ | チェックデジット | フレームの終わり |
|---|---|---|---|---|---|
| 0XF5 | 0X01 | 0X4 | 0X01 0X02 0X03 0X04 | 0XC5 | 0X5F |
この形式は 2 番目の形式と互換性があり、読み取りや書き込みなどのさまざまな種類のコマンドを処理できます。
関数コードは、2 つの関数コードを使用するなど、無制限に追加できます。1 つはどの変数を操作するかを示し、もう 1 つは読み取りか書き込みかを示します。これは最も広く使用されており、作業負荷はそれほど大きくなく、自分でデバッグするのが簡単です。
4. フレームヘッダーおよびフレームテール + データ + 追加機能コード + ターゲットアドレス
| フレームヘッダー | 住所 | ファンクションコード | データ長 | データ | チェックデジット | フレームの終わり |
|---|---|---|---|---|---|---|
| 0XF5 | 0XCC | 0X01 | 0X4 | 0X01 0X02 0X03 0X04 | 0XC5 | 0X5F |
この種のアドレス指定は興味深いものであり、デバイスを識別する機能があります。たとえば、同じタイプでアドレスが異なるデバイスにランダムにアクセスした場合、コマンドを送信してもデバイスはユーザーを強制終了しません。これは 485 通信バスでの使用に適しており、すべてのデバイスがアドレスに従って実行するかどうかを識別します。
485通信に適した機器識別機能とコマンド実行の一意性を備えていることが利点です。
欠点は、232 を使用すると少し味気ないことです。485にせよ232にせよ、私がこれまで見てきたのはこの種の通信がほとんどでした（実際にはアドレスもファンクションコードなので大した問題ではありません）。
5. フレームヘッダーおよびフレームテール + データ + 追加機能コード + 転送機能
| フレームヘッダー | ソースの長さ | 送信元アドレス | 目標の長さ | ターゲットアドレス | ファンクションコード | データ長 | データ | チェックデジット | フレームの終わり |
|---|---|---|---|---|---|---|---|---|---|
| 0XF5 | 0X01 | 0XCC | 0X02 | 0XDD 0XBB | 0X01 | 0X4 | 0X01 0X02 0X03 0X04 | 0XC5 | 0X5F |
これは私がこれまで使用した中で最も強力なシリアル ポート通信プロトコルであり、アドレス長とアドレス フィールドを通じて次のレベルの転送が必要か、または操作コマンドを実行する必要があるかを判断するために使用できます。
このコマンドのプロセスは次のとおりです。0XCC のデバイスはコマンド フレームを 0XDD のデバイスに送信し、0XDD のデバイスはそれが最終ターゲットではないことを検出し、フレームを再構成して、次のレベルのデバイスに次のアドレスで送信します。 0XBB、およびコマンドを受信した後、0XBB 自体が最終ターゲットであることが判明したため、コマンドを実行します。
この通信プロトコルの利点は、機能が充実しており、転送を実現できることです。
欠点は、フレームを解析する手順が複雑で、転送を追加すると再フレーム化に時間がかかり、転送が増えるほど時間がかかることです。(しかし、これほど多くのサブレベルを文字列化するためにシリアル ポートを使用できる人がいるでしょうか?体調が悪いですか?他の通信方法の使用を検討してください。)これは、シリアル ポートを他の通信方法 (can、tcp/ip など) に適応させる必要があります
。 , など)、プログラムが適切に処理されれば、さまざまな通信方法を組み合わせて使用できるはずです。たとえば、メイン ボードはシリアル ポートを介して送信し、次のレベルは CAN を介してより多くのデバイスに送信します。転送では、ある程度の通信互換性があります。
シリアル ポートに 4 番目の方法を使用するのは少し複雑です。
6.モドバスRTU
これはすごいですね、使ったことないんですが、言わせてください。このシングルチップ マイコンは 485 通信を使用する必要があります。これは正式な統一規格です。既製の統合モジュールがあり、購入後に使用できます。PLC は電気産業の制御によく使用されます。
Modbus-RTU モードとは、コントローラが Modbus ネットワーク上で RTU (リモート ターミナル モード) モードで通信するように設定されている場合、メッセージ内の各 8 ビットに 2 つの 4 ビット 16 進文字が含まれることを意味します。Markdown はテキストを HTML 1に変換します。
演算方法は 4 の演算方法と似ています (ただし、人々はそれを標準として認識しており、これは強気です)、レジスタに対するより多くの演算が含まれます。レジスタは一般にビット単位で演算され、各ビットには各ビットの機能を一度に拡張でき、さまざまな用途に使用できます。
7. その他
その他、ひとまとめにできるいくつかの方法があり、これらはほとんどが上記のタイプの組み合わせです。フレーム ヘッダーはあるがフレーム トレーラーがないもの、フレーム トレーラーはあるがアドレスをフレーム ヘッダーとして使用するもの、チェックサムを追加しないもの、フレーム トレーラーの機能を実現するために固定長を使用するもの、および奇妙なものもありますアドレスをフレーム ヘッダーとして使用します。フレームの終わりのチェックサムは固定長ではありません。
要約する
シリアルポートの基本的な通信プロトコルのフレームはこれだけなので、後で思いついたときに追加します。やみくもに機能を追求するのではなく、シンプルで実用的なものが最も信頼できます。通信プロトコルは追加しないことをお勧めします。
突然思いついたアイデアですが、MCU プログラムも上記のプロトコル フレームの各機能ビットをモジュール化して完全な互換性を実現できないでしょうか。たとえば、フレーム ヘッダーを使用する場合、追加プログラムを呼び出してフレーム ヘッダーを追加します。機能コードを使用する場合は、機能コードを配置する機能コード ビットを追加して、外部に大きなパッケージを作成すると、通信テンプレートがすべての通信プロトコルと互換性を持つことが容易になります。(おそらく必要ではありません。ほとんどは非常に単純で、抽出されたデータはそれほど大きくありません。言うまでもなく、私の C++ はまだ混乱しています。体力があるときに考えます。パニックにならないでください)