JP3961128B2 - Data communication method and transmitter / receiver - Google Patents
Data communication method and transmitter / receiver Download PDFInfo
- Publication number
- JP3961128B2 JP3961128B2 JP28032898A JP28032898A JP3961128B2 JP 3961128 B2 JP3961128 B2 JP 3961128B2 JP 28032898 A JP28032898 A JP 28032898A JP 28032898 A JP28032898 A JP 28032898A JP 3961128 B2 JP3961128 B2 JP 3961128B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- frame
- length
- reception
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Time-Division Multiplex Systems (AREA)
- Communication Control (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
- Mobile Radio Communication Systems (AREA)
Description
【0001】
【発明の属する技術分野】
本発明はデータ通信方法及び装置、特に送信データのデータ構成をより簡略化するとともに、データ通信に要する処理時間の短縮化を図ったデータ通信方法及び装置に関するものである。
【0002】
【従来の技術】
従来のデータ通信プロトコルでは、送信データを通信用の構成に変換したフレームの内部(通常は先頭部分)に「プロトコルヘッダ」のようなヘッダ情報を設け、プロトコルヘッダ内のフレーム識別子により、当該フレームが「コマンドフレーム」であるか「データフレーム」であるかを識別していた。
【0003】
図9はこのような従来のデータ通信の方式を示す概略説明図である。図9において、符号1は従来における送信データ(以下、この明細書において「送信データ」とは一つのデータ通信処理業務の中で、1回毎のデータのやりとりにおいて送信されるコマンドフレーム或いはデータフレームを指す)であるフレームの一例を概略的に示す図である。このフレーム1はコマンドフレームの例であり、その先頭部分にはプロトコルヘッダ2が設けられてこのフレームの識別子として 「コマンド」のデータが設定され、このフレームがコマンドフレームであることを示している。次に、コマンドコード領域3が設けられ、このコマンドコード領域3には「送信」のデータが設定されこのコマンドフレームが送信を通知するものであることを明示している。さらに次の部分にはパラメータ領域4が設けられこのパラメータ領域4には送信されるデータの総データ長などの情報が格納されている。
【0004】
データの送信にあたって、先ずデータ送信側から、これからデータを送信することを通知する。このときに、上記コマンドフレーム1が送信データとして通信回線を介してデータ受信側へ送付される。データ受信側では、送信されてきたコマンドフレーム1を受信バッファ15に格納し、その後受信フレーム1のプロトコルヘッダ2に設定されたフレーム識別子をチェックし、このフレーム1が「コマンドフレーム」であるためコマンドコードを参照し、送信コマンドであることを認識する。
【0005】
その後データ受信側では自己装置がデータの受信準備ができていることを通知する。この通知に当たっては、データ受信側からデータ送信側へコマンドフレームが送付される。符号5はデータ受信側からデータ送信側へ送付されるコマンドフレームの例を概略的に示す図である。このコマンドフレーム5は、上記コマンドフレーム1と同様、その先頭部分にはプロトコルヘッダ6が設けられてこのフレームの識別子として「コマンド」のデータが設定され、このフレームがコマンドフレームであることを示している。次に、コマンドコード領域7が設けられ、このコマンドコード領域7にはデータの受信準備ができていることを示す「O K」のデータが設定されている。データ送信側では、送信されてきたコマンドフレーム5のプロトコルヘッダ6に設定されたフレーム識別子をチェックし、このフレームが「コマンドフレーム」であるためコマンドコードを参照し、受信OKコマンドであることを認識する。
【0006】
その後データ送信側からはデータ通信処理業務によって送信されるべきデータ(以下「処理データ」という)がデータ受信側へ送信される。符号8はデータ送信側からデータ受信側へ送付されるデータフレームの例を概略的に示す図である。このコマンドフレーム8は、上記コマンドフレーム1、5の場合と同様、その先頭部分にはプロトコルヘッダ9が設けられてこのフレームの識別子として「データ」を表示するデータが設定され、このフレームがデータフレームであることを示している。その後にはデータ領域10が設けられ、このデータ領域10には処理データが設定されている。フレームの長さは通常所定の範囲内の値に決められているものであるのに対し、処理データのデータ量は大量であることが多いので、全部の処理データを送信するには、データ送信側においてこの処理データを適当な長さでブロッキングし、第1のデータフレーム8、第2のデータフレーム11、・・・第nのデータフレーム(最終フレーム)12、というように複数のフレームに分けて送信される。第1のデータフレーム8にはデータとしてブロック1が格納され、第2のデータフレーム11にはデータとしてブロック2が格納され、第nのデータフレーム12にはデータとしてブロックnが格納される。いずれのデータフレーム8、11、12もフレーム構成は同じである。
【0007】
データ受信側では、先ず送信されてきた第1のデータフレーム8を受信バッファ15に格納し、その後受信フレーム8のプロトコルヘッダ9に設定されたフレーム識別子をチェックし、このフレーム8が「データフレーム」であるためブロック1のデータを編集バッファ16へ転送する。データ受信側では、次に送信されてきた第2のデータフレーム11を受信バッファ15に格納し、その後受信フレーム11のプロトコルヘッダ9に設定されたフレーム識別子をチェックし、このフレーム11が「データフレーム」であるためブロック2のデータを編集バッファ16へ転送する。編集バッファ16では先のブロック1の次にブロック2を連続して格納することにより、受信データを継ぎ足していく。そして編集バッファ16は、ファイル17等への書き込み単位までブロックのデータを蓄積し、一括してファイル17等へ書き込む。
【0008】
【発明が解決しようとする課題】
しかしながら、上記のような従来のデータ通信方法によれば、フレームの先頭部分にプロトコルヘッダを設けて通信するようにしているため、送信側ではプロトコルヘッダと送信データとを結合してフレームを生成する処理が必要であり、また受信側では、各フレームのプロトコルヘッダの解析や、プロトコルヘッダを取り除き、送信されたデータのみを取り出す処理(編集処理)を行なうために時間がかかるという不具合がある。また、データフレームにプロトコルヘッダが付加されるため、実際のデータ領域が狭くなり、スループットが上がらず、特に携帯情報端末のように非力なCPUのマシンにおいては転送速度が上がらないという問題もあった。特に近年の高速のデータ通信においては、ダイレクト・メモリアクセス(DMA)を用いたデータ転送が主流であり、データ受信とプロトコルヘッダの解析を同時に行なうことが難しくなってきており、データの編集処理は避けられない問題となってきている。
【0009】
本発明は、このような従来の問題点に鑑みてなされたもので、その目的は、フレームにプロトコルヘッダを必要とせずに、送信データのフレームがデータフレームかコマンドフレームかの識別ができるようにし、プロトコルヘッダのチェック処理を簡略化したデータ通信方法及び装置を提供することである。
【0010】
【課題を解決するための手段】
本発明は、上記目的を達成するために、フレーム同期を用い、コマンドフレームとデータフレームに異なるフレーム長を割り当ててデータの送信、受信を行うデータ通信方法において、送信側では、送信データを前記データフレーム長でブロッキングし、複数のフレームに分けて送信し、受信側では、受信データ長カウンタと受信バッファとファイル書き込み手段とを有し、前記受信データ長カウンタが前記フレーム長によりフレームの種類を判別し、データフレームと判断した場合は送信されてきた第1のデータフレームの第1のブロックデータを前記受信バッファへ蓄積し、前記受信データ長カウンタを前記第1のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームからもブロックデータを前記受信バッファに前記第1のブロックデータに続けて継ぎ足して格納し、前記受信データ長カウンタを前記第1のデータフレーム長に継ぎ足して更新し、ファイルへの書き込み単位までブロックのデータを蓄積して一括してファイルへ書き込み、或いはすべてのブロックデータの受信が完了した後に受信データを一括してファイルへ書き込むようにしたことを要旨とする。
【0011】
これによりフレームの内部にプロトコルヘッダ等の固定のエリアを用いずに、フレーム種別毎に異なるフレーム長を割り当てることにより、フレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうことができる。また、受信バッファに送られてきたデータが自動的に蓄積されていくため、受信データから受信すべきデータを抜き出して編集し送られてくるデータを編集することが不要であり、ハードウェア、ソフトウェア資源を節約でき、通信回線上を流れるデータ量を少なくしてデータ通信速度を上げることができる。さらに、プロトコルヘッダなどのデータ領域をフレームから削除することにより、データ処理速度を上げることもでき、全体としてのスループットの向上を達成できる。
【0012】
【発明の実施の形態】
本発明の請求項1に記載の発明は、フレーム同期を用い、コマンドフレームとデータフレームに異なるフレーム長を割り当ててデータの送信、受信を行うデータ通信方法において、送信側では、送信データを前記データフレーム長でブロッキングし、複数のフレームに分けて送信し、受信側では、受信データ長カウンタと受信バッファとファイル書き込み手段とを有し、前記受信データ長カウンタが前記フレーム長によりフレームの種類を判別し、データフレームと判断した場合は送信されてきた第1のデータフレームの第1のブロックデータを前記受信バッファへ蓄積し、前記受信データ長カウンタを前記第1のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームからもブロックデータを前記受信バッファに前記第1のブロックデータに続けて継ぎ足して格納し、前記受信データ長カウンタを前記第1のデータフレーム長に継ぎ足して更新し、ファイルへの書き込み単位までブロックのデータを蓄積して一括してファイルへ書き込み、或いはすべてのブロックデータの受信が完了した後に受信データを一括してファイルへ書き込むようにしたものであり、フレームの内部にプロトコルヘッダ等の固定のエリアを用いずに、フレーム種別毎に異なるフレーム長を割り当ててフレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうという作用を有する。
【0013】
本発明の請求項2に記載の発明は、請求項1記載のデータ通信方法において、複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定するようにしたものであり、フレーム長が整数倍であるか否かによりデータフレームかどうかが判別でき、受信処理速度が速くなるという作用を有する。
【0014】
本発明の請求項3に記載の発明は、請求項1記載のデータ通信方法において、受信フレームのフレーム長が所定の基準値の整数倍であるか否かを検出しこの検出結果から当該受信フレームがデータフレームであると認識して受信処理を行なうようにしたものであり、フレーム長が整数倍であるか否かによりデータフレームかどうかが判別でき、受信処理速度が速くなるという作用を有する。
【0015】
本発明の請求項4に記載の発明は、コマンドフレームとデータフレームに異なるフレーム長を割り当て、フレーム同期を用いたデータ通信を行うデータ送受信装置において、送信側では、送信データを前記データフレーム長でブロッキングするフレーム生成部と、前記ブロッキングにより生成した複数のフレームを送信する送信部と、を有し、受信側では、受信データ長カウンタ部と受信バッファと制御部とファイル書き込み部とを有し、前記受信データ長カウンタ部が前記フレーム長によりフレームの種類を判別し、前記制御部は前記受信データ長カウンタ部が受信したデータがデータフレームと判断した場合には第1のデータフレームの第1のブロックデータを前記受信バッファへ蓄積させ、前記受信データ長カウンタ部のカウントを前記第1のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームのブロックデータを前記受信バッファ部に続けて格納して前記受信データ長カウンタ部のカウントを格納したデータ長の分だけ続けて更新するものであり、前記受信バッファはブロックデータを順次蓄積するものであり、前記制御部がファイルへの書き込み単位までブロックデータを蓄積し、或いはすべてのブロックデータの受信が完了した後に一括してファイルへ書き込むことを特徴とするものであり、フレーム長をチェックするのみで、フレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうことができ受信処理速度が上がるという作用を有する。
【0016】
本発明の請求項5に記載の発明は、請求項4記載のデータ送信装置において、送信制御手段は、複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定するようにしたものであり、フレーム長が整数倍であるか否かによりデータフレームかどうかが判別でき、受信処理速度が速くなるという作用を有する。
【0032】
以下、本発明の実施の形態について図面を用いて説明する。
【0033】
(実施の形態1)
図1は本発明によるデータ通信方法を実現するためのデータ送受信装置の構成および接続関係を、集配信装置と携帯端末装置との間のデータ通信システムの例で示すブロック図である。図1において、21はパソコン、22は集配信装置、23は携帯端末装置である。パソコン21は集配信装置22へ入力されるデータを生成し、また集配信装置22の動作をコントロールする中央処理装置としての役割を持つ。集配信装置22は携帯端末装置23との間でデータの送信または受信のデータ転送を行なう。携帯端末装置23は各担当者に携帯されるため複数個23a、23b、・・・23nが用いられ各種のデータが入力される。集配信装置22は、パソコン21との間でデータの送受信を行なうための通信手段24と、各種のデータやプログラムが格納されるメモリ25と、メモリ25へのデータの書き込みおよび読み出し動作をコントロールするDMA(ダイレクト・メモリ・アクセス)コントローラ27と、これらの各機能部の動作をコントロールする制御部28とを備えている。
【0034】
制御部28は送信するデータをフレーム構造に変換するフレーム生成手段と、送信データがコマンドであるか処理データであるかを判定するデータ検出手段と、データ検出手段の検出結果に基づきフレーム生成手段で生成されるフレームに割り当てられるフレーム長データを格納するフレーム長データ格納メモリとを備えている。携帯端末装置23は、集配信装置22との間でデータの送受信を行なうための通信手段29と、各種のデータやプログラムが格納されるメモリ30と、メモリ30へのデータの書き込みおよび読み出し動作をコントロールするDMAコントローラ31と、各種ファイルや処理データが格納されるハードディスクなどの記憶手段32と、各種のデータが入力されるタッチパネル等の入力部33と、データがイメージの形で表示される液晶等の表示部34と、これらの各機能部の動作をコントロールする制御部35とを備えている。
【0035】
制御部35は受信したデータがコマンドフレームであるかデータフレームであるかを判定するフレーム検出手段を備えている。一例としては、このフレーム検出手段は、受信フレームのフレーム長を検出し、そのフレームがコマンドフレームであるか、データフレームであるかを判定するための受信データ長カウンタ50により構成されている。制御部35はまた、データ通信されるデータの総データ長を一時格納する総データ長レジスタ51を備えている。なお、パソコン21と集配信装置22とは通信回線36により接続され、また集配信装置22と携帯端末装置23とは通信回線37により接続されている。これらの通信回線36、37は有線回線、無線回線など種々の形態ものを使うことができる。
【0036】
かかる構成を有するデータ送受信装置について、動作を説明する。ここでは集配信装置22をデータ送信装置、携帯端末装置23(23a、23b、23nのいずれでもよい)をデータ受信装置とする。
【0037】
図2は本実施の形態においてデータ通信のためにフレームが生成され、これが通信回線を通して送信側と受信側との間で送受信される状態を模式的に表す図である。集配信装置22では、データの送信にあたって、これからデータを送信することを通知する。このときに、コマンドフレームが送信データとして通信回線を介してデータ受信側へ送付される。符号41は本発明における送信データであるフレームの一例である。このフレーム41はコマンドフレームの例であり、その先頭部分にはプロトコルヘッダが設けられておらず、コマンドコード領域42が設けられている。そして、このコマンドコード領域42には「送信」のデータが設定されこのコマンドフレームが送信を通知するものであることを明示している。さらに次の部分にはパラメータ領域43が設けられこのパラメータ領域43には送信されるデータの総データ長などの情報が格納されている。このコマンドフレーム41を作成するに当たって、集配信装置22では、制御部28に設けられたデータ検出手段が、送信データはコマンドであるか、それとも処理データであるかを検出し、この検出結果をフレーム生成手段へ通知する。フレーム生成手段は、データ検出手段からの検出結果に基づいて、コマンドフレーム或いはデータフレーム等のフレームの種類に応じて、フレームの種別毎に固定のフレーム長を割り当て、フレーム長データ格納メモリからフレーム長データを読み出してフレームの種類毎に異なったフレーム長を有するフレームを生成する。
【0038】
携帯端末装置23側では、送信されてきたコマンドフレーム41を受信バッファ15に格納し、その後、制御部に設けられた受信データ長カウンタ50が受信フレーム41のフレーム長をチェックし、このフレーム41が「コマンドフレーム」であるためコマンドコードを参照し、送信コマンドであることを認識する。また、同じく制御部に設けられた送信総データ長レジスタ51が「送信総データ長」を保持する。
【0039】
その後携帯端末装置23では自己装置がデータの受信準備ができていることを通知する。この通知に当たっては、携帯端末装置23からデータ送信側へコマンドフレームが送付される。符号44は携帯端末装置23から集配信装置22へ送付されるコマンドフレームの例である。このコマンドフレーム44は、上記コマンドフレーム41と同様、その先頭部分にはプロトコルヘッダが設けられておらず、コマンドコード領域45が設けられている。このコマンドコード領域45にはデータの受信準備ができていることを示す「OK」のデータが設定されている。データ送信側では、送信されてきたコマンドフレーム44のフレーム長をチェックし、このフレームが「コマンドフレーム」であるためコマンドコードを参照し、受信OKコマンドであることを認識する。
【0040】
その後集配信装置22からはデータ通信処理業務によって送信されるべき処理データが携帯端末装置23へ送信される。図3は本実施の形態におけるブロック1のデータフレームの作成および送信動作を説明する動作説明図である。この図において、符号46は集配信装置22から携帯端末装置23へ送付されるデータフレームの例である。このデータフレーム46は、上記コマンドフレーム41、44の場合と同様、その先頭部分にはプロトコルヘッダが設けられておらず、データ領域47のみから構成されている。このデータ領域47には処理データが設定されている。集配信装置22では、データフレームの生成に当たって、上述の場合(コマンドフレーム作成時)と同様に、制御部28に設けられたデータ検出手段が、送信データはコマンドであるか、それとも処理データであるかを検出し、この(今回は処理データである)検出結果をフレーム生成手段へ通知する。フレーム生成手段は、データ検出手段からの検出結果に基づいて、データフレームに対応するフレーム長を割り当て、フレーム長データ格納メモリからデータフレーム用のフレーム長データを読み出してデータフレームを生成する。このデータフレームのフレーム長は、先のコマンドフレームのフレーム長とは異なった値のものである。
【0041】
全部の処理データをフレーム化して送信するには、集配信装置22においてこの処理データを上記与えられたフレーム長さでブロッキングし、第1のデータフレーム46、第2のデータフレーム47(ブロック2)、・・・第nのデータフレーム(ブロックn:最終フレーム)48、というように複数のフレームに分けて送信する。図4は本実施の形態におけるブロック2のデータフレームの作成および送信動作を説明する動作説明図であり、また図5は本実施の形態におけるブロックnのデータフレームの作成および送信動作を説明する動作説明図である。第1のデータフレーム46にはデータとしてブロック1が格納され、第2のデータフレーム47にはデータとしてブロック2が格納され、第nのデータフレーム48にはデータとしてブロックnが格納される。いずれのデータフレーム46、47、48もフレーム構成は同じである。
【0042】
携帯端末装置23では、先ず送信されてきた第1のデータフレーム8を受信バッファ15に格納し、その後、制御部35に設けられた受信データ長カウンタ50が受信フレーム46のフレーム長をチェックし、このフレーム46が「データフレーム」であるためブロック1のデータを受信バッファ16へ蓄積する。そして、上記受信データ長カウンタ50はデータフレーム長の分だけ更新される。
【0043】
次に、携帯端末装置23では、次に送信されてきた第2のデータフレーム47を受信バッファ15に格納し、その後、受信データ長カウンタ50が受信フレーム47のフレーム長をチェックし、このフレーム47が「データフレーム」であるため受信バッファ16の内部でブロック1の次にブロック2を連続して蓄積することにより継ぎ足していく。そして、上記受信データ長カウンタ50はデータフレーム長の分だけ更新される。
【0044】
このようにして、ブロック2以降、ブロックnにいたるまでの各のブロックについてもデータフレームの送信が行なわれるとともに携帯端末装置22側では受信バッファ15へ受信データのブロックが順次蓄積され、さらに受信データ長カウンタ50はデータフレーム長の分だけ更新される。そして受信バッファ15は、ファイル17等への書き込み単位までブロックのデータを蓄積し、一括してファイル17等へ書き込む。或いはブロックnまでの全てのデータの受信が完了した後に受信データを一括してファイル17等へ書き込む。
【0045】
図6は携帯端末装置23におけるデータ受信動作を説明するフロー図である。データ受信処理が開始されると、処理ステップ(以下、単にステップという)ST61においてフレーム受信待状態となる。フレームが受信されると、このフレームのフレーム長はコマンドフレームのものであるか否かをチェックし(ステップST62)、コマンドフレームのものである場合は、コマンドコードは「送 信」であるか否かをチェックする(ステップST63)。このチェック処理においてコマンドコードが「送信」である場合は送信総データ長をレジスタ51に保持し(ステップST64)、ステップST61の処理に戻る。またコマンドコードが「送信」でない場合は送信以外のコマンド処理を行なって(ステップST65)ステップST61の処理に戻る。
【0046】
他方、上記ステップST62のチェック処理において受信フレームのフレーム長はコマンドフレームのものでない場合は、このフレームのフレーム長はデータフレームのものであるか否かをチェックし(ステップST66)、データフレームのものでない場合は、プロトコル異常処理を行なって(ステップST67)一連の受信動作を終了する。他方、ステップST66において受信フレームのフレーム長はデータフレームのものである場合は、受信データ長カウンタ50にフレーム長を足し(ステップST68)、次に受信データ長カウンタ50の値は送信総データ長以上であるか否かをチェックする(ステップST69)。ここで、受信データ長カウンタ50の値は送信総データ長以上でない場合はステップST61の処理に戻る一方、受信データ長カウンタ50の値は送信総データ長以上である場合は受信バッファ15の先頭から送信総データ長だけのデータをファイル17等に書き込んで(ステップST70)一連の受信動作を終了する。
【0047】
図7は本発明の他の実施の形態を示す図である。この実施の形態においては、フレームがコマンドフレームであるとき、さらにコマンドの種別毎に固定のフレーム長を割り当て、コマンドの種類毎に異なったフレーム長を有するフレームを生成するようにしている。図7の例では、フレーム長が1バイトであるときはリセットコマンドのフレームを表し、フレーム長が2バイトであるときはランプ点灯コマンドのフレームを表す。また、フレーム長が3バイトであるときはランプ消灯コマンドのフレームを表し、フレーム長が4バイトであるときはデータ送信コマンドのフレームを表すというものである。そして最後に、フレーム長が2048バイトであるときは送信データのフレームを表すようにしている。この場合において、より頻繁に使用されるコマンドのフレームにより短いフレーム長を割り当てるようにすることが好ましい。これにより通信回線上を流れるデータ量をより少なくすることができる。
【0048】
また、データフレーム用のフレーム長を複数種類定義し、フレームがデータフレームであるとき、送信データ長に応じて適切なフレーム長を選択してフレームを生成するようにしてもよい。これによりデータのブロック分けが効率的に行なえ通信効率を上げることが可能となる。また、定義されたフレーム長以外の長さのフレームを受信した場合に即座に通信異常であることが認識でき、通信チェックにかかる時間の短縮化を図ることができる。
【0049】
さらに複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定するようにすることもできる。こうすることにより、フレーム長が或る値で割り切れるかどうかをチェックすることによりデータフレームであることを認識することが可能となる。
【0050】
また、所定のフレーム長より小さいフレームをコマンドフレーム、前記所定のフレーム長より長いフレームをデータフレームとする規約を設定し、この規約にしたがってフレームの種別毎のフレームを生成することもできる。通常コマンドデータは少ないデータ量で足りることが多く、したがってフレーム長も少なくて済むからである。
【0051】
図8は上記のようにコマンドの種別毎に固定のフレーム長を割り当て、コマンドの種類毎に異なったフレーム長を有するフレームを生成するようにした場合におけるコマンド処理動作を説明するフロー図である。このコマンド処理が開始されると、先ずフレーム受信待ちの処理が行なわれ(ステップST81)、次にフレームが受信されると、フレーム長チェックが行なわれる(ステップST82)。そして、図7に基づいて説明したように、フレーム長が1バイトであるときはリセットコマンドのフレームであると判断してリセット処理を実行し(ステップST83)、その後ステップST81の処理に戻る。またフレーム長が2バイトであるときはランプ点灯コマンドのフレームであると判断してランプ点灯処理を実行し(ステップST84)、その後ステップST81の処理に戻る。また、フレーム長が3バイトであるときはランプ消灯コマンドのフレームであると判断してランプ消灯処理を実行し(ステップST85)、その後ステップST81の処理に戻る。次に、フレーム長が4バイトであるときはデータ送信コマンドのフレームであると判断してデータ送信処理を実行し(ステップST86)、その後ステップST81の処理に戻る。さらにフレーム長が2048バイトであるときは送信データのフレームであると判断してデータ格納処理を実行し(ステップST87)、その後ステップST81の処理に戻る。そして最後に、フレーム長が上記のいずれでもないときは通信異常であると判断して通信異常処理を実行し(ステップST88)、その後ステップST81の処理に戻る。
【0052】
【発明の効果】
以上説明したように、本発明によれば、フレーム同期を用いたデータ通信を行なうに際して、コマンドフレーム或いはデータフレーム等のフレームの種類に応じて、フレームの種別毎に固定のフレーム長を割り当て、フレームの種類毎に異なったフレーム長を有し且つヘッダ情報を付けないフレームを生成し、このフレームを送信および受信するようにしたため、フレームの内部にプロトコルヘッダ等の固定のエリアを用いずに、フレーム種別毎に固定のフレーム長を割り当てることにより、フレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうことができるようになり、通信回線上を流れるデータ量を少なくしてデータ通信速度を上げることができる。また、プロトコルヘッダなどのデータ領域をフレームから削除することにより、データ処理速度を上げることもでき、全体としてのスループットの向上を達成できる等種々の効果が得られる。
【図面の簡単な説明】
【図1】本発明の一実施の形態によるデータ通信システムの全体構成を示すブロック図
【図2】前記実施の形態におけるコマンドフレームの作成および送信、応答動作を説明する動作説明図
【図3】前記実施の形態におけるブロック1のデータフレームの作成および送信動作を説明する動作説明図
【図4】前記実施の形態におけるブロック2のデータフレームの作成および送信動作を説明する動作説明図
【図5】前記実施の形態におけるブロックnのデータフレームの作成および送信動作を説明する動作説明図
【図6】前記実施の形態におけるデータ受信処理動作を説明するフロー図
【図7】本発明の他の実施の形態におけるフレームの構成を説明する図
【図8】前記実施の形態にフレームの受信処理動作を説明するフロー図
【図9】従来のデータ通信方法によるフレーム構成および送信、応答動作を説明する動作説明図
【符号の説明】
21 パソコン
22 集配信装置ク
23 携帯端末装置
24、27、29 通信手段
25、30 メモリ
26、31 DMAコントローラ
28、35 制御部
32 ハードディスク
33 入力部
34 表示部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a data communication method and apparatus, and more particularly to a data communication method and apparatus that further simplify the data structure of transmission data and reduce the processing time required for data communication.
[0002]
[Prior art]
In the conventional data communication protocol, header information such as a “protocol header” is provided in the frame (usually the head portion) obtained by converting transmission data into a communication configuration, and the frame is identified by a frame identifier in the protocol header. It was identified whether it was a “command frame” or a “data frame”.
[0003]
FIG. 9 is a schematic explanatory view showing such a conventional data communication system. In FIG. 9,
[0004]
In transmitting data, first, the data transmitting side notifies that data will be transmitted. At this time, the
[0005]
Thereafter, the data receiving side notifies that its own device is ready to receive data. For this notification, a command frame is sent from the data receiving side to the data transmitting side. Reference numeral 5 is a diagram schematically showing an example of a command frame sent from the data receiving side to the data transmitting side. Like the
[0006]
Thereafter, data to be transmitted by the data communication processing service (hereinafter referred to as “process data”) is transmitted from the data transmission side to the data reception side. Reference numeral 8 is a diagram schematically showing an example of a data frame sent from the data transmission side to the data reception side. As in the case of the
[0007]
At the data receiving side, first the first data frame 8 transmitted is stored in the
[0008]
[Problems to be solved by the invention]
However, according to the conventional data communication method as described above, since the protocol header is provided at the head of the frame for communication, the transmission side generates a frame by combining the protocol header and the transmission data. Processing is necessary, and the receiving side has a problem that it takes time to analyze the protocol header of each frame and to perform processing (editing processing) of removing only the transmitted data by removing the protocol header. In addition, since the protocol header is added to the data frame, there is a problem that the actual data area is narrowed, the throughput is not increased, and the transfer speed is not increased particularly in a powerless CPU machine such as a portable information terminal. . Especially in recent high-speed data communication, data transfer using direct memory access (DMA) is the mainstream, and it is difficult to simultaneously perform data reception and protocol header analysis. It has become an inevitable problem.
[0009]
The present invention has been made in view of such conventional problems, and an object of the present invention is to make it possible to identify whether a frame of transmission data is a data frame or a command frame without requiring a protocol header in the frame. Another object of the present invention is to provide a data communication method and apparatus that simplify protocol header check processing.
[0010]
[Means for Solving the Problems]
In order to achieve the above object, the present invention provides In a data communication method for transmitting and receiving data by assigning different frame lengths to a command frame and a data frame using frame synchronization, on the transmission side, the transmission data is blocked by the data frame length and divided into a plurality of frames. The transmission side has a reception data length counter, a reception buffer, and a file writing means. The reception data length counter determines the type of frame based on the frame length, and is transmitted when it is determined as a data frame. The first block data of the first data frame is accumulated in the reception buffer, the reception data length counter is updated by the length of the first data frame length, and the data frame transmitted from the next time onward is also updated. Block data is added to the reception buffer following the first block data. The received data length counter is updated by adding to the first data frame length, the block data is accumulated up to the unit of writing to the file, and written to the file all at once, or all block data is received. After receiving is completed, the received data is written to the file all at once. The summary is as follows.
[0011]
This allows each frame type to be used without using a fixed area such as a protocol header inside the frame. Different By assigning the frame length, the frame type can be recognized, and reception and response operations corresponding to the frame can be performed. Also, Since the data sent to the receive buffer is automatically accumulated, it is not necessary to extract the data to be received from the received data, edit it, and edit the sent data. Can save, The amount of data flowing on the communication line can be reduced to increase the data communication speed. Furthermore, by deleting the data area such as the protocol header from the frame, the data processing speed can be increased, and the overall throughput can be improved.
[0012]
DETAILED DESCRIPTION OF THE INVENTION
The invention according to
[0013]
The invention according to
[0014]
The invention according to
[0015]
The invention according to claim 4 of the present invention is In a data transmission / reception apparatus that assigns different frame lengths to a command frame and a data frame and performs data communication using frame synchronization, a transmission side generates a frame generation unit that blocks transmission data by the data frame length, and generates the data by the blocking A transmission unit that transmits a plurality of frames, and a reception side includes a reception data length counter unit, a reception buffer, a control unit, and a file writing unit. When the data received by the reception data length counter is a data frame, the control unit accumulates the first block data of the first data frame in the reception buffer, and receives the reception data. Count the data length counter unit by the length of the first data frame Newly, the block data of the data frame transmitted after the next is stored continuously in the reception buffer unit, and the count of the reception data length counter unit is continuously updated by the data length, The reception buffer sequentially accumulates block data, and the control unit accumulates block data up to a unit for writing to a file, or writes to a file in a lump after reception of all block data is completed. By simply checking the frame length, the frame type can be recognized, and reception and response operations can be performed according to the frame, increasing the reception processing speed. It has the action.
[0016]
The invention according to claim 5 of the present invention is 5. The data transmission device according to claim 4, wherein the transmission control means sets the frame length for a plurality of types of defined data frames to an integral multiple of a predetermined reference value, and the frame length is an integral multiple. Whether it is a data frame can be determined by whether or not it is, and the reception processing speed increases. It has the action.
[0032]
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0033]
(Embodiment 1)
FIG. 1 is a block diagram showing an example of a data communication system between a collection / distribution device and a portable terminal device, showing the configuration and connection relationship of a data transmission / reception device for realizing a data communication method according to the present invention. In FIG. 1, 21 is a personal computer, 22 is a collection and distribution device, and 23 is a portable terminal device. The
[0034]
The
[0035]
The
[0036]
The operation of the data transmitting / receiving apparatus having such a configuration will be described. Here, the collection / delivery device 22 is a data transmission device, and the portable terminal device 23 (which may be any of 23a, 23b, and 23n) is a data reception device.
[0037]
FIG. 2 is a diagram schematically showing a state in which a frame is generated for data communication in the present embodiment and transmitted and received between the transmission side and the reception side through the communication line. In the data collection / delivery device 22, when data is transmitted, it is notified that data will be transmitted. At this time, the command frame is sent as transmission data to the data receiving side via the communication line. Reference numeral 41 is an example of a frame which is transmission data in the present invention. This frame 41 is an example of a command frame, and a protocol code is not provided at the head of the frame 41 but a
[0038]
On the mobile terminal device 23 side, the transmitted command frame 41 is stored in the
[0039]
Thereafter, the mobile terminal device 23 notifies that its own device is ready to receive data. For this notification, a command frame is sent from the portable terminal device 23 to the data transmission side. Reference numeral 44 is an example of a command frame sent from the portable terminal device 23 to the collection and distribution device 22. Similar to the command frame 41, the command frame 44 is provided with a
[0040]
Thereafter, processing data to be transmitted by the data communication processing business is transmitted from the collection and distribution device 22 to the portable terminal device 23. FIG. 3 is an operation explanatory diagram for explaining the data frame creation and transmission operation of
[0041]
In order to transmit all the processed data in a frame, the collection / distribution device 22 blocks the processed data with the given frame length, and the
[0042]
In the mobile terminal device 23, first the first data frame 8 transmitted is stored in the
[0043]
Next, the mobile terminal device 23 stores the
[0044]
In this manner, the data frame is transmitted also for each block from
[0045]
FIG. 6 is a flowchart for explaining a data reception operation in the mobile terminal device 23. When the data reception process is started, a frame reception waiting state is entered in a processing step (hereinafter simply referred to as step) ST61. When a frame is received, it is checked whether the frame length of this frame is that of a command frame (step ST62). If it is that of a command frame, whether or not the command code is “send”. Is checked (step ST63). If the command code is “transmission” in this check process, the total transmission data length is held in the register 51 (step ST64), and the process returns to step ST61. If the command code is not “transmission”, command processing other than transmission is performed (step ST65), and the process returns to step ST61.
[0046]
On the other hand, if the frame length of the received frame is not that of the command frame in the check process of step ST62, it is checked whether or not the frame length of this frame is that of the data frame (step ST66). If not, the protocol abnormality process is performed (step ST67), and the series of reception operations is terminated. On the other hand, if the frame length of the received frame is that of the data frame in step ST66, the frame length is added to the received data length counter 50 (step ST68), and the value of the received
[0047]
FIG. 7 is a diagram showing another embodiment of the present invention. In this embodiment, when the frame is a command frame, a fixed frame length is assigned to each command type, and a frame having a different frame length is generated for each command type. In the example of FIG. 7, when the frame length is 1 byte, it represents a reset command frame, and when the frame length is 2 bytes, it represents a lamp lighting command frame. When the frame length is 3 bytes, it indicates a lamp turn-off command frame, and when the frame length is 4 bytes, it indicates a data transmission command frame. Finally, when the frame length is 2048 bytes, it represents a frame of transmission data. In this case, it is preferable to assign a shorter frame length to a frame of a command that is used more frequently. As a result, the amount of data flowing on the communication line can be further reduced.
[0048]
Also, a plurality of types of frame lengths for data frames may be defined, and when a frame is a data frame, a frame may be generated by selecting an appropriate frame length according to the transmission data length. This makes it possible to efficiently perform data block division and increase communication efficiency. Further, when a frame having a length other than the defined frame length is received, it can be immediately recognized that the communication is abnormal, and the time required for the communication check can be shortened.
[0049]
Furthermore, the frame length for a plurality of types of defined data frames can be set to an integer multiple of a predetermined reference value. By doing this, it is possible to recognize a data frame by checking whether the frame length is divisible by a certain value.
[0050]
It is also possible to set a rule that a frame smaller than a predetermined frame length is a command frame and a frame longer than the predetermined frame length is a data frame, and a frame for each frame type can be generated according to this rule. This is because the command data usually requires a small amount of data, and therefore the frame length is also small.
[0051]
FIG. 8 is a flowchart for explaining the command processing operation when a fixed frame length is assigned to each command type as described above and a frame having a different frame length is generated for each command type. When this command processing is started, frame reception waiting processing is first performed (step ST81), and when a frame is received next, a frame length check is performed (step ST82). Then, as described with reference to FIG. 7, when the frame length is 1 byte, it is determined that the frame is a reset command frame, a reset process is executed (step ST83), and then the process returns to step ST81. When the frame length is 2 bytes, it is determined that the frame is a lamp lighting command frame, lamp lighting processing is executed (step ST84), and then the processing returns to step ST81. If the frame length is 3 bytes, it is determined that the frame is a lamp turn-off command frame, lamp turn-off processing is executed (step ST85), and then the process returns to step ST81. Next, when the frame length is 4 bytes, it is determined that the frame is a data transmission command frame, data transmission processing is executed (step ST86), and then the processing returns to step ST81. If the frame length is 2048 bytes, it is determined that the frame is a frame of transmission data, data storage processing is executed (step ST87), and then the processing returns to step ST81. Finally, when the frame length is not any of the above, it is determined that there is a communication abnormality, a communication abnormality process is executed (step ST88), and then the process returns to step ST81.
[0052]
【The invention's effect】
As described above, according to the present invention, when performing data communication using frame synchronization, a fixed frame length is assigned to each frame type according to the type of frame such as a command frame or a data frame. Since a frame having a different frame length for each type and without header information is generated, and this frame is transmitted and received, the frame is not used within the frame without using a fixed area such as a protocol header. By assigning a fixed frame length for each type, it becomes possible to recognize the frame type and perform reception and response operations according to that frame, reducing the amount of data flowing on the communication line and reducing the data communication speed Can be raised. Further, by deleting the data area such as the protocol header from the frame, it is possible to increase the data processing speed, and various effects can be obtained such as improvement of the overall throughput.
[Brief description of the drawings]
FIG. 1 is a block diagram showing the overall configuration of a data communication system according to an embodiment of the present invention.
FIG. 2 is an operation explanatory diagram for explaining creation, transmission, and response operation of a command frame in the embodiment.
FIG. 3 is an operation explanatory diagram for explaining a data frame creation and transmission operation of
FIG. 4 is an operation explanatory diagram for explaining a data frame creation and transmission operation of
FIG. 5 is an operation explanatory diagram illustrating the creation and transmission operation of a data frame of block n in the embodiment.
FIG. 6 is a flowchart for explaining a data reception processing operation in the embodiment.
FIG. 7 is a diagram illustrating a frame configuration according to another embodiment of the present invention.
FIG. 8 is a flowchart for explaining a frame reception processing operation in the embodiment;
FIG. 9 is an operation explanatory diagram illustrating frame configuration, transmission, and response operation according to a conventional data communication method.
[Explanation of symbols]
21 PC
22 Collection and distribution equipment
23 Mobile terminal device
24, 27, 29 Communication means
25, 30 memory
26, 31 DMA controller
28, 35 Control unit
32 hard disk
33 Input section
34 Display section
Claims (5)
送信側では、
送信データを前記データフレーム長でブロッキングし、
複数のフレームに分けて送信し、
受信側では、
受信データ長カウンタと受信バッファとファイル書き込み手段とを有し、前記受信データ長カウンタが前記フレーム長によりフレームの種類を判別し、
データフレームと判断した場合は送信されてきた第1のデータフレームの第1のブロックデータを前記受信バッファへ蓄積し、前記受信データ長カウンタを前記第1のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームからもブロックデータを前記受信バッファに前記第1のブロックデータに続けて継ぎ足して格納し、前記受信データ長カウンタを前記第1のデータフレーム長に継ぎ足して更新し、ファイルへの書き込み単位までブロックのデータを蓄積して一括してファイルへ書き込み、或いはすべてのブロックデータの受信が完了した後に受信データを一括してファイルへ書き込むことを特徴とするデータ通信方法。 In a data communication method for transmitting and receiving data by assigning different frame lengths to a command frame and a data frame using frame synchronization,
On the sending side,
Blocking transmission data with the data frame length;
Send in multiple frames,
On the receiving side,
A reception data length counter, a reception buffer, and file writing means, wherein the reception data length counter determines a frame type based on the frame length;
When the data frame is determined, the first block data of the transmitted first data frame is accumulated in the reception buffer, the reception data length counter is updated by the amount corresponding to the first data frame length, and The block data is stored in the reception buffer after the first block data is added and stored from the data frame transmitted thereafter, and the reception data length counter is updated and added to the first data frame length, A data communication method characterized by accumulating block data up to a unit for writing to a file and writing it to a file at once, or writing received data to a file at a time after reception of all block data is completed .
送信側では、On the sending side,
送信データを前記データフレーム長でブロッキングするフレーム生成部と、A frame generator that blocks transmission data at the data frame length;
前記ブロッキングにより生成した複数のフレームを送信する送信部と、A transmitter for transmitting a plurality of frames generated by the blocking;
を有し、Have
受信側では、On the receiving side,
受信データ長カウンタ部と受信バッファと制御部とファイル書き込み部とを有し、A reception data length counter unit, a reception buffer, a control unit, and a file writing unit;
前記受信データ長カウンタ部が前記フレーム長によりフレームの種類を判別し、The received data length counter unit determines the type of frame based on the frame length,
前記制御部は前記受信データ長カウンタ部が受信したデータがデータフレームと判断した場合には第1のデータフレームの第1のブロックデータを前記受信バッファへ蓄積させ、前記受信データ長カウンタ部のカウントを前記第1のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームのブロックデータを前記受信バッファ部に続けて格納して前記受信データ長カウンタ部のカウントを格納したデータ長の分だけ続けて更新するものであり、When the control unit determines that the data received by the reception data length counter unit is a data frame, the control unit accumulates the first block data of the first data frame in the reception buffer, and counts the reception data length counter unit Is updated by the length of the first data frame length, the block length of the data frame transmitted after the next is stored in the reception buffer section, and the count of the reception data length counter section is stored. , And continue to update
前記受信バッファはブロックデータを順次蓄積するものであり、The reception buffer sequentially accumulates block data,
前記制御部がファイルへの書き込み単位までブロックデータを蓄積し、或いはすべてのブロックデータの受信が完了した後に一括してファイルへ書き込むことを特徴とするデータ送受信装置。A data transmitting / receiving apparatus, wherein the control unit accumulates block data up to a unit for writing to a file, or writes the data to a file in a lump after reception of all the block data is completed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28032898A JP3961128B2 (en) | 1998-10-01 | 1998-10-01 | Data communication method and transmitter / receiver |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP28032898A JP3961128B2 (en) | 1998-10-01 | 1998-10-01 | Data communication method and transmitter / receiver |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000115281A JP2000115281A (en) | 2000-04-21 |
| JP3961128B2 true JP3961128B2 (en) | 2007-08-22 |
Family
ID=17623486
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP28032898A Expired - Fee Related JP3961128B2 (en) | 1998-10-01 | 1998-10-01 | Data communication method and transmitter / receiver |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3961128B2 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2599128T3 (en) | 2009-06-25 | 2017-01-31 | Koninklijke Philips N.V. | Method and device to process data packets |
| JP6638922B2 (en) * | 2018-08-02 | 2020-02-05 | 学校法人 関西大学 | Wireless device, wireless communication system including the same, and program executed in wireless device |
-
1998
- 1998-10-01 JP JP28032898A patent/JP3961128B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000115281A (en) | 2000-04-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107590099B (en) | Method for accessing slave machines by multiple hosts, extension device and storage medium | |
| US20120278575A1 (en) | Method and Computer Program Product For Exchanging Message Data In A Distributed Computer System | |
| US7822040B2 (en) | Method for increasing network transmission efficiency by increasing a data updating rate of a memory | |
| US8230137B2 (en) | Network processor, reception controller and data reception processing method performing direct memory access transfer | |
| JP3961128B2 (en) | Data communication method and transmitter / receiver | |
| KR20110134465A (en) | Data transmission system and its data reading method | |
| CN110569933B (en) | Smart card management device and method | |
| JP2001067299A (en) | Interface control device and computer system | |
| KR100615694B1 (en) | Control system to control multiple function blocks | |
| JP7332660B2 (en) | RELAYER, PROGRAM, SYSTEM, COMMUNICATION TERMINAL AND METHOD | |
| US20080214194A1 (en) | Radio network controller and transport network control method for performing relocation | |
| JP3674207B2 (en) | Peripheral device and buffer control method in half-duplex communication system | |
| JP4147799B2 (en) | Data transfer system | |
| JP2000200210A (en) | Memory managing device | |
| JPH08263433A (en) | Data bus controller | |
| JP2823625B2 (en) | Data processing device | |
| CN119892768A (en) | Network traffic mirroring method and device, electronic equipment and storage medium | |
| JP2001014183A (en) | Buffer controller, method and device for buffer evaluation, recording medium where program is recorded, central processor, and information processor | |
| JPS6198050A (en) | Transfer system for received data | |
| JPH10105438A (en) | Monitoring and control equipment | |
| JP3302033B2 (en) | Data transmission equipment | |
| JPH0759097B2 (en) | Communication method between processors in electronic exchange | |
| JPH1049479A (en) | Master device | |
| JPH0926943A (en) | Data communication method and device | |
| JPH10136027A (en) | Communication controller |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050216 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061227 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070130 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070330 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070424 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070516 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110525 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110525 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120525 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120525 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130525 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130525 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |