(57)【特許請求の範囲】
【請求項１】
フレーム同期を用い、コマンドフレームとデータフレームとに異なるフレーム長を割り当ててデータの送信、受信を行うデータ通信方法において、
送信側では、
送信データを前記データフレーム長でブロッキングし、
複数のフレームに分けて送信し、
受信側では、
受信データ長カウンタと受信バッファとファイル書き込み手段とを有し、前記受信データ長カウンタが前記フレーム長によりフレームの種類を判別し、
データフレームと判断した場合は送信されてきた第１のデータフレームの第１のブロックデータを前記受信バッファへ蓄積し、前記受信データ長カウンタを前記第１のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームからもブロックデータを前記受信バッファに前記第１のブロックデータに続けて継ぎ足して格納し、前記受信データ長カウンタを前記第１のデータフレーム長に継ぎ足して更新し、ファイルへの書き込み単位までブロックのデータを蓄積して一括してファイルへ書き込み、或いはすべてのブロックデータの受信が完了した後に受信データを一括してファイルへ書き込むことを特徴とするデータ通信方法。
【請求項２】
複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定することを特徴とする請求項１記載のデータ通信方法。
【請求項３】
受信フレームのフレーム長が所定の基準値の整数倍であるか否かを検出しこの検出結果から当該受信フレームがデータフレームであると認識して受信処理を行なうことを特徴とする請求項１記載のデータ通信方法。
【請求項４】
コマンドフレームとデータフレームに異なるフレーム長を割り当て、フレーム同期を用いたデータ通信を行うデータ送受信装置において、
送信側では、
送信データを前記データフレーム長でブロッキングするフレーム生成部と、
前記ブロッキングにより生成した複数のフレームを送信する送信部と、
を有し、
受信側では、
受信データ長カウンタ部と受信バッファと制御部とファイル書き込み部とを有し、
前記受信データ長カウンタ部が前記フレーム長によりフレームの種類を判別し、
前記制御部は前記受信データ長カウンタ部が受信したデータがデータフレームと判断した場合には第１のデータフレームの第１のブロックデータを前記受信バッファへ蓄積させ、前記受信データ長カウンタ部のカウントを前記第１のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームのブロックデータを前記受信バッファ部に続けて格納して前記受信データ長カウンタ部のカウントを格納したデータ長の分だけ続けて更新するものであり、
前記受信バッファはブロックデータを順次蓄積するものであり、
前記制御部がファイルへの書き込み単位までブロックデータを蓄積し、或いはすべてのブロックデータの受信が完了した後に一括してファイルへ書き込むことを特徴とするデータ送受信装置。
【請求項５】
送信制御手段は、複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定することを特徴とする請求項４記載のデータ送受信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はデータ通信方法及び装置、特に送信データのデータ構成をより簡略化するとともに、データ通信に要する処理時間の短縮化を図ったデータ通信方法及び装置に関するものである。
【０００２】
【従来の技術】
従来のデータ通信プロトコルでは、送信データを通信用の構成に変換したフレームの内部（通常は先頭部分）に「プロトコルヘッダ」のようなヘッダ情報を設け、プロトコルヘッダ内のフレーム識別子により、当該フレームが「コマンドフレーム」であるか「データフレーム」であるかを識別していた。
【０００３】
図９はこのような従来のデータ通信の方式を示す概略説明図である。図９において、符号１は従来における送信データ（以下、この明細書において「送信データ」とは一つのデータ通信処理業務の中で、１回毎のデータのやりとりにおいて送信されるコマンドフレーム或いはデータフレームを指す）であるフレームの一例を概略的に示す図である。このフレーム１はコマンドフレームの例であり、その先頭部分にはプロトコルヘッダ２が設けられてこのフレームの識別子として  「コマンド」のデータが設定され、このフレームがコマンドフレームであることを示している。次に、コマンドコード領域３が設けられ、このコマンドコード領域３には「送信」のデータが設定されこのコマンドフレームが送信を通知するものであることを明示している。さらに次の部分にはパラメータ領域４が設けられこのパラメータ領域４には送信されるデータの総データ長などの情報が格納されている。
【０００４】
データの送信にあたって、先ずデータ送信側から、これからデータを送信することを通知する。このときに、上記コマンドフレーム１が送信データとして通信回線を介してデータ受信側へ送付される。データ受信側では、送信されてきたコマンドフレーム１を受信バッファ１５に格納し、その後受信フレーム１のプロトコルヘッダ２に設定されたフレーム識別子をチェックし、このフレーム１が「コマンドフレーム」であるためコマンドコードを参照し、送信コマンドであることを認識する。
【０００５】
その後データ受信側では自己装置がデータの受信準備ができていることを通知する。この通知に当たっては、データ受信側からデータ送信側へコマンドフレームが送付される。符号５はデータ受信側からデータ送信側へ送付されるコマンドフレームの例を概略的に示す図である。このコマンドフレーム５は、上記コマンドフレーム１と同様、その先頭部分にはプロトコルヘッダ６が設けられてこのフレームの識別子として「コマンド」のデータが設定され、このフレームがコマンドフレームであることを示している。次に、コマンドコード領域７が設けられ、このコマンドコード領域７にはデータの受信準備ができていることを示す「Ｏ  Ｋ」のデータが設定されている。データ送信側では、送信されてきたコマンドフレーム５のプロトコルヘッダ６に設定されたフレーム識別子をチェックし、このフレームが「コマンドフレーム」であるためコマンドコードを参照し、受信ＯＫコマンドであることを認識する。
【０００６】
その後データ送信側からはデータ通信処理業務によって送信されるべきデータ（以下「処理データ」という）がデータ受信側へ送信される。符号８はデータ送信側からデータ受信側へ送付されるデータフレームの例を概略的に示す図である。このコマンドフレーム８は、上記コマンドフレーム１、５の場合と同様、その先頭部分にはプロトコルヘッダ９が設けられてこのフレームの識別子として「データ」を表示するデータが設定され、このフレームがデータフレームであることを示している。その後にはデータ領域１０が設けられ、このデータ領域１０には処理データが設定されている。フレームの長さは通常所定の範囲内の値に決められているものであるのに対し、処理データのデータ量は大量であることが多いので、全部の処理データを送信するには、データ送信側においてこの処理データを適当な長さでブロッキングし、第１のデータフレーム８、第２のデータフレーム１１、・・・第ｎのデータフレーム（最終フレーム）１２、というように複数のフレームに分けて送信される。第１のデータフレーム８にはデータとしてブロック１が格納され、第２のデータフレーム１１にはデータとしてブロック２が格納され、第ｎのデータフレーム１２にはデータとしてブロックｎが格納される。いずれのデータフレーム８、１１、１２もフレーム構成は同じである。
【０００７】
データ受信側では、先ず送信されてきた第１のデータフレーム８を受信バッファ１５に格納し、その後受信フレーム８のプロトコルヘッダ９に設定されたフレーム識別子をチェックし、このフレーム８が「データフレーム」であるためブロック１のデータを編集バッファ１６へ転送する。データ受信側では、次に送信されてきた第２のデータフレーム１１を受信バッファ１５に格納し、その後受信フレーム１１のプロトコルヘッダ９に設定されたフレーム識別子をチェックし、このフレーム１１が「データフレーム」であるためブロック２のデータを編集バッファ１６へ転送する。編集バッファ１６では先のブロック１の次にブロック２を連続して格納することにより、受信データを継ぎ足していく。そして編集バッファ１６は、ファイル１７等への書き込み単位までブロックのデータを蓄積し、一括してファイル１７等へ書き込む。
【０００８】
【発明が解決しようとする課題】
しかしながら、上記のような従来のデータ通信方法によれば、フレームの先頭部分にプロトコルヘッダを設けて通信するようにしているため、送信側ではプロトコルヘッダと送信データとを結合してフレームを生成する処理が必要であり、また受信側では、各フレームのプロトコルヘッダの解析や、プロトコルヘッダを取り除き、送信されたデータのみを取り出す処理（編集処理）を行なうために時間がかかるという不具合がある。また、データフレームにプロトコルヘッダが付加されるため、実際のデータ領域が狭くなり、スループットが上がらず、特に携帯情報端末のように非力なＣＰＵのマシンにおいては転送速度が上がらないという問題もあった。特に近年の高速のデータ通信においては、ダイレクト・メモリアクセス（ＤＭＡ）を用いたデータ転送が主流であり、データ受信とプロトコルヘッダの解析を同時に行なうことが難しくなってきており、データの編集処理は避けられない問題となってきている。
【０００９】
本発明は、このような従来の問題点に鑑みてなされたもので、その目的は、フレームにプロトコルヘッダを必要とせずに、送信データのフレームがデータフレームかコマンドフレームかの識別ができるようにし、プロトコルヘッダのチェック処理を簡略化したデータ通信方法及び装置を提供することである。
【００１０】
【課題を解決するための手段】
本発明は、上記目的を達成するために、フレーム同期を用い、コマンドフレームとデータフレームに異なるフレーム長を割り当ててデータの送信、受信を行うデータ通信方法において、送信側では、送信データを前記データフレーム長でブロッキングし、複数のフレームに分けて送信し、受信側では、受信データ長カウンタと受信バッファとファイル書き込み手段とを有し、前記受信データ長カウンタが前記フレーム長によりフレームの種類を判別し、データフレームと判断した場合は送信されてきた第１のデータフレームの第１のブロックデータを前記受信バッファへ蓄積し、前記受信データ長カウンタを前記第１のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームからもブロックデータを前記受信バッファに前記第１のブロックデータに続けて継ぎ足して格納し、前記受信データ長カウンタを前記第１のデータフレーム長に継ぎ足して更新し、ファイルへの書き込み単位までブロックのデータを蓄積して一括してファイルへ書き込み、或いはすべてのブロックデータの受信が完了した後に受信データを一括してファイルへ書き込むようにしたことを要旨とする。
【００１１】
これによりフレームの内部にプロトコルヘッダ等の固定のエリアを用いずに、フレーム種別毎に異なるフレーム長を割り当てることにより、フレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうことができる。また、受信バッファに送られてきたデータが自動的に蓄積されていくため、受信データから受信すべきデータを抜き出して編集し送られてくるデータを編集することが不要であり、ハードウェア、ソフトウェア資源を節約でき、通信回線上を流れるデータ量を少なくしてデータ通信速度を上げることができる。さらに、プロトコルヘッダなどのデータ領域をフレームから削除することにより、データ処理速度を上げることもでき、全体としてのスループットの向上を達成できる。
【００１２】
【発明の実施の形態】
本発明の請求項１に記載の発明は、フレーム同期を用い、コマンドフレームとデータフレームに異なるフレーム長を割り当ててデータの送信、受信を行うデータ通信方法において、送信側では、送信データを前記データフレーム長でブロッキングし、複数のフレームに分けて送信し、受信側では、受信データ長カウンタと受信バッファとファイル書き込み手段とを有し、前記受信データ長カウンタが前記フレーム長によりフレームの種類を判別し、データフレームと判断した場合は送信されてきた第１のデータフレームの第１のブロックデータを前記受信バッファへ蓄積し、前記受信データ長カウンタを前記第１のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームからもブロックデータを前記受信バッファに前記第１のブロックデータに続けて継ぎ足して格納し、前記受信データ長カウンタを前記第１のデータフレーム長に継ぎ足して更新し、ファイルへの書き込み単位までブロックのデータを蓄積して一括してファイルへ書き込み、或いはすべてのブロックデータの受信が完了した後に受信データを一括してファイルへ書き込むようにしたものであり、フレームの内部にプロトコルヘッダ等の固定のエリアを用いずに、フレーム種別毎に異なるフレーム長を割り当ててフレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうという作用を有する。
【００１３】
本発明の請求項２に記載の発明は、請求項１記載のデータ通信方法において、複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定するようにしたものであり、フレーム長が整数倍であるか否かによりデータフレームかどうかが判別でき、受信処理速度が速くなるという作用を有する。
【００１４】
本発明の請求項３に記載の発明は、請求項１記載のデータ通信方法において、受信フレームのフレーム長が所定の基準値の整数倍であるか否かを検出しこの検出結果から当該受信フレームがデータフレームであると認識して受信処理を行なうようにしたものであり、フレーム長が整数倍であるか否かによりデータフレームかどうかが判別でき、受信処理速度が速くなるという作用を有する。
【００１５】
本発明の請求項４に記載の発明は、コマンドフレームとデータフレームに異なるフレーム長を割り当て、フレーム同期を用いたデータ通信を行うデータ送受信装置において、送信側では、送信データを前記データフレーム長でブロッキングするフレーム生成部と、前記ブロッキングにより生成した複数のフレームを送信する送信部と、を有し、受信側では、受信データ長カウンタ部と受信バッファと制御部とファイル書き込み部とを有し、前記受信データ長カウンタ部が前記フレーム長によりフレームの種類を判別し、前記制御部は前記受信データ長カウンタ部が受信したデータがデータフレームと判断した場合には第１のデータフレームの第１のブロックデータを前記受信バッファへ蓄積させ、前記受信データ長カウンタ部のカウントを前記第１のデータフレーム長の分だけ更新し、次以降に送信されてきたデータフレームのブロックデータを前記受信バッファ部に続けて格納して前記受信データ長カウンタ部のカウントを格納したデータ長の分だけ続けて更新するものであり、前記受信バッファはブロックデータを順次蓄積するものであり、前記制御部がファイルへの書き込み単位までブロックデータを蓄積し、或いはすべてのブロックデータの受信が完了した後に一括してファイルへ書き込むことを特徴とするものであり、フレーム長をチェックするのみで、フレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうことができ受信処理速度が上がるという作用を有する。
【００１６】
本発明の請求項５に記載の発明は、請求項４記載のデータ送信装置において、送信制御手段は、複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定するようにしたものであり、フレーム長が整数倍であるか否かによりデータフレームかどうかが判別でき、受信処理速度が速くなるという作用を有する。
【００３２】
以下、本発明の実施の形態について図面を用いて説明する。
【００３３】
（実施の形態１）
図１は本発明によるデータ通信方法を実現するためのデータ送受信装置の構成および接続関係を、集配信装置と携帯端末装置との間のデータ通信システムの例で示すブロック図である。図１において、２１はパソコン、２２は集配信装置、２３は携帯端末装置である。パソコン２１は集配信装置２２へ入力されるデータを生成し、また集配信装置２２の動作をコントロールする中央処理装置としての役割を持つ。集配信装置２２は携帯端末装置２３との間でデータの送信または受信のデータ転送を行なう。携帯端末装置２３は各担当者に携帯されるため複数個２３ａ、２３ｂ、・・・２３ｎが用いられ各種のデータが入力される。集配信装置２２は、パソコン２１との間でデータの送受信を行なうための通信手段２４と、各種のデータやプログラムが格納されるメモリ２５と、メモリ２５へのデータの書き込みおよび読み出し動作をコントロールするＤＭＡ（ダイレクト・メモリ・アクセス）コントローラ２７と、これらの各機能部の動作をコントロールする制御部２８とを備えている。
【００３４】
制御部２８は送信するデータをフレーム構造に変換するフレーム生成手段と、送信データがコマンドであるか処理データであるかを判定するデータ検出手段と、データ検出手段の検出結果に基づきフレーム生成手段で生成されるフレームに割り当てられるフレーム長データを格納するフレーム長データ格納メモリとを備えている。携帯端末装置２３は、集配信装置２２との間でデータの送受信を行なうための通信手段２９と、各種のデータやプログラムが格納されるメモリ３０と、メモリ３０へのデータの書き込みおよび読み出し動作をコントロールするＤＭＡコントローラ３１と、各種ファイルや処理データが格納されるハードディスクなどの記憶手段３２と、各種のデータが入力されるタッチパネル等の入力部３３と、データがイメージの形で表示される液晶等の表示部３４と、これらの各機能部の動作をコントロールする制御部３５とを備えている。
【００３５】
制御部３５は受信したデータがコマンドフレームであるかデータフレームであるかを判定するフレーム検出手段を備えている。一例としては、このフレーム検出手段は、受信フレームのフレーム長を検出し、そのフレームがコマンドフレームであるか、データフレームであるかを判定するための受信データ長カウンタ５０により構成されている。制御部３５はまた、データ通信されるデータの総データ長を一時格納する総データ長レジスタ５１を備えている。なお、パソコン２１と集配信装置２２とは通信回線３６により接続され、また集配信装置２２と携帯端末装置２３とは通信回線３７により接続されている。これらの通信回線３６、３７は有線回線、無線回線など種々の形態ものを使うことができる。
【００３６】
かかる構成を有するデータ送受信装置について、動作を説明する。ここでは集配信装置２２をデータ送信装置、携帯端末装置２３（２３ａ、２３ｂ、２３ｎのいずれでもよい）をデータ受信装置とする。
【００３７】
図２は本実施の形態においてデータ通信のためにフレームが生成され、これが通信回線を通して送信側と受信側との間で送受信される状態を模式的に表す図である。集配信装置２２では、データの送信にあたって、これからデータを送信することを通知する。このときに、コマンドフレームが送信データとして通信回線を介してデータ受信側へ送付される。符号４１は本発明における送信データであるフレームの一例である。このフレーム４１はコマンドフレームの例であり、その先頭部分にはプロトコルヘッダが設けられておらず、コマンドコード領域４２が設けられている。そして、このコマンドコード領域４２には「送信」のデータが設定されこのコマンドフレームが送信を通知するものであることを明示している。さらに次の部分にはパラメータ領域４３が設けられこのパラメータ領域４３には送信されるデータの総データ長などの情報が格納されている。このコマンドフレーム４１を作成するに当たって、集配信装置２２では、制御部２８に設けられたデータ検出手段が、送信データはコマンドであるか、それとも処理データであるかを検出し、この検出結果をフレーム生成手段へ通知する。フレーム生成手段は、データ検出手段からの検出結果に基づいて、コマンドフレーム或いはデータフレーム等のフレームの種類に応じて、フレームの種別毎に固定のフレーム長を割り当て、フレーム長データ格納メモリからフレーム長データを読み出してフレームの種類毎に異なったフレーム長を有するフレームを生成する。
【００３８】
携帯端末装置２３側では、送信されてきたコマンドフレーム４１を受信バッファ１５に格納し、その後、制御部に設けられた受信データ長カウンタ５０が受信フレーム４１のフレーム長をチェックし、このフレーム４１が「コマンドフレーム」であるためコマンドコードを参照し、送信コマンドであることを認識する。また、同じく制御部に設けられた送信総データ長レジスタ５１が「送信総データ長」を保持する。
【００３９】
その後携帯端末装置２３では自己装置がデータの受信準備ができていることを通知する。この通知に当たっては、携帯端末装置２３からデータ送信側へコマンドフレームが送付される。符号４４は携帯端末装置２３から集配信装置２２へ送付されるコマンドフレームの例である。このコマンドフレーム４４は、上記コマンドフレーム４１と同様、その先頭部分にはプロトコルヘッダが設けられておらず、コマンドコード領域４５が設けられている。このコマンドコード領域４５にはデータの受信準備ができていることを示す「ＯＫ」のデータが設定されている。データ送信側では、送信されてきたコマンドフレーム４４のフレーム長をチェックし、このフレームが「コマンドフレーム」であるためコマンドコードを参照し、受信ＯＫコマンドであることを認識する。
【００４０】
その後集配信装置２２からはデータ通信処理業務によって送信されるべき処理データが携帯端末装置２３へ送信される。図３は本実施の形態におけるブロック１のデータフレームの作成および送信動作を説明する動作説明図である。この図において、符号４６は集配信装置２２から携帯端末装置２３へ送付されるデータフレームの例である。このデータフレーム４６は、上記コマンドフレーム４１、４４の場合と同様、その先頭部分にはプロトコルヘッダが設けられておらず、データ領域４７のみから構成されている。このデータ領域４７には処理データが設定されている。集配信装置２２では、データフレームの生成に当たって、上述の場合（コマンドフレーム作成時）と同様に、制御部２８に設けられたデータ検出手段が、送信データはコマンドであるか、それとも処理データであるかを検出し、この（今回は処理データである）検出結果をフレーム生成手段へ通知する。フレーム生成手段は、データ検出手段からの検出結果に基づいて、データフレームに対応するフレーム長を割り当て、フレーム長データ格納メモリからデータフレーム用のフレーム長データを読み出してデータフレームを生成する。このデータフレームのフレーム長は、先のコマンドフレームのフレーム長とは異なった値のものである。
【００４１】
全部の処理データをフレーム化して送信するには、集配信装置２２においてこの処理データを上記与えられたフレーム長さでブロッキングし、第１のデータフレーム４６、第２のデータフレーム４７（ブロック２）、・・・第ｎのデータフレーム（ブロックｎ：最終フレーム）４８、というように複数のフレームに分けて送信する。図４は本実施の形態におけるブロック２のデータフレームの作成および送信動作を説明する動作説明図であり、また図５は本実施の形態におけるブロックｎのデータフレームの作成および送信動作を説明する動作説明図である。第１のデータフレーム４６にはデータとしてブロック１が格納され、第２のデータフレーム４７にはデータとしてブロック２が格納され、第ｎのデータフレーム４８にはデータとしてブロックｎが格納される。いずれのデータフレーム４６、４７、４８もフレーム構成は同じである。
【００４２】
携帯端末装置２３では、先ず送信されてきた第１のデータフレーム８を受信バッファ１５に格納し、その後、制御部３５に設けられた受信データ長カウンタ５０が受信フレーム４６のフレーム長をチェックし、このフレーム４６が「データフレーム」であるためブロック１のデータを受信バッファ１６へ蓄積する。そして、上記受信データ長カウンタ５０はデータフレーム長の分だけ更新される。
【００４３】
次に、携帯端末装置２３では、次に送信されてきた第２のデータフレーム４７を受信バッファ１５に格納し、その後、受信データ長カウンタ５０が受信フレーム４７のフレーム長をチェックし、このフレーム４７が「データフレーム」であるため受信バッファ１６の内部でブロック１の次にブロック２を連続して蓄積することにより継ぎ足していく。そして、上記受信データ長カウンタ５０はデータフレーム長の分だけ更新される。
【００４４】
このようにして、ブロック２以降、ブロックｎにいたるまでの各のブロックについてもデータフレームの送信が行なわれるとともに携帯端末装置２２側では受信バッファ１５へ受信データのブロックが順次蓄積され、さらに受信データ長カウンタ５０はデータフレーム長の分だけ更新される。そして受信バッファ１５は、ファイル１７等への書き込み単位までブロックのデータを蓄積し、一括してファイル１７等へ書き込む。或いはブロックｎまでの全てのデータの受信が完了した後に受信データを一括してファイル１７等へ書き込む。
【００４５】
図６は携帯端末装置２３におけるデータ受信動作を説明するフロー図である。データ受信処理が開始されると、処理ステップ（以下、単にステップという）ＳＴ６１においてフレーム受信待状態となる。フレームが受信されると、このフレームのフレーム長はコマンドフレームのものであるか否かをチェックし（ステップＳＴ６２）、コマンドフレームのものである場合は、コマンドコードは「送  信」であるか否かをチェックする（ステップＳＴ６３）。このチェック処理においてコマンドコードが「送信」である場合は送信総データ長をレジスタ５１に保持し（ステップＳＴ６４）、ステップＳＴ６１の処理に戻る。またコマンドコードが「送信」でない場合は送信以外のコマンド処理を行なって（ステップＳＴ６５）ステップＳＴ６１の処理に戻る。
【００４６】
他方、上記ステップＳＴ６２のチェック処理において受信フレームのフレーム長はコマンドフレームのものでない場合は、このフレームのフレーム長はデータフレームのものであるか否かをチェックし（ステップＳＴ６６）、データフレームのものでない場合は、プロトコル異常処理を行なって（ステップＳＴ６７）一連の受信動作を終了する。他方、ステップＳＴ６６において受信フレームのフレーム長はデータフレームのものである場合は、受信データ長カウンタ５０にフレーム長を足し（ステップＳＴ６８）、次に受信データ長カウンタ５０の値は送信総データ長以上であるか否かをチェックする（ステップＳＴ６９）。ここで、受信データ長カウンタ５０の値は送信総データ長以上でない場合はステップＳＴ６１の処理に戻る一方、受信データ長カウンタ５０の値は送信総データ長以上である場合は受信バッファ１５の先頭から送信総データ長だけのデータをファイル１７等に書き込んで（ステップＳＴ７０）一連の受信動作を終了する。
【００４７】
図７は本発明の他の実施の形態を示す図である。この実施の形態においては、フレームがコマンドフレームであるとき、さらにコマンドの種別毎に固定のフレーム長を割り当て、コマンドの種類毎に異なったフレーム長を有するフレームを生成するようにしている。図７の例では、フレーム長が１バイトであるときはリセットコマンドのフレームを表し、フレーム長が２バイトであるときはランプ点灯コマンドのフレームを表す。また、フレーム長が３バイトであるときはランプ消灯コマンドのフレームを表し、フレーム長が４バイトであるときはデータ送信コマンドのフレームを表すというものである。そして最後に、フレーム長が２０４８バイトであるときは送信データのフレームを表すようにしている。この場合において、より頻繁に使用されるコマンドのフレームにより短いフレーム長を割り当てるようにすることが好ましい。これにより通信回線上を流れるデータ量をより少なくすることができる。
【００４８】
また、データフレーム用のフレーム長を複数種類定義し、フレームがデータフレームであるとき、送信データ長に応じて適切なフレーム長を選択してフレームを生成するようにしてもよい。これによりデータのブロック分けが効率的に行なえ通信効率を上げることが可能となる。また、定義されたフレーム長以外の長さのフレームを受信した場合に即座に通信異常であることが認識でき、通信チェックにかかる時間の短縮化を図ることができる。
【００４９】
さらに複数種類定義されたデータフレーム用のフレーム長を、所定の基準値の整数倍に設定するようにすることもできる。こうすることにより、フレーム長が或る値で割り切れるかどうかをチェックすることによりデータフレームであることを認識することが可能となる。
【００５０】
また、所定のフレーム長より小さいフレームをコマンドフレーム、前記所定のフレーム長より長いフレームをデータフレームとする規約を設定し、この規約にしたがってフレームの種別毎のフレームを生成することもできる。通常コマンドデータは少ないデータ量で足りることが多く、したがってフレーム長も少なくて済むからである。
【００５１】
図８は上記のようにコマンドの種別毎に固定のフレーム長を割り当て、コマンドの種類毎に異なったフレーム長を有するフレームを生成するようにした場合におけるコマンド処理動作を説明するフロー図である。このコマンド処理が開始されると、先ずフレーム受信待ちの処理が行なわれ（ステップＳＴ８１）、次にフレームが受信されると、フレーム長チェックが行なわれる（ステップＳＴ８２）。そして、図７に基づいて説明したように、フレーム長が１バイトであるときはリセットコマンドのフレームであると判断してリセット処理を実行し（ステップＳＴ８３）、その後ステップＳＴ８１の処理に戻る。またフレーム長が２バイトであるときはランプ点灯コマンドのフレームであると判断してランプ点灯処理を実行し（ステップＳＴ８４）、その後ステップＳＴ８１の処理に戻る。また、フレーム長が３バイトであるときはランプ消灯コマンドのフレームであると判断してランプ消灯処理を実行し（ステップＳＴ８５）、その後ステップＳＴ８１の処理に戻る。次に、フレーム長が４バイトであるときはデータ送信コマンドのフレームであると判断してデータ送信処理を実行し（ステップＳＴ８６）、その後ステップＳＴ８１の処理に戻る。さらにフレーム長が２０４８バイトであるときは送信データのフレームであると判断してデータ格納処理を実行し（ステップＳＴ８７）、その後ステップＳＴ８１の処理に戻る。そして最後に、フレーム長が上記のいずれでもないときは通信異常であると判断して通信異常処理を実行し（ステップＳＴ８８）、その後ステップＳＴ８１の処理に戻る。
【００５２】
【発明の効果】
以上説明したように、本発明によれば、フレーム同期を用いたデータ通信を行なうに際して、コマンドフレーム或いはデータフレーム等のフレームの種類に応じて、フレームの種別毎に固定のフレーム長を割り当て、フレームの種類毎に異なったフレーム長を有し且つヘッダ情報を付けないフレームを生成し、このフレームを送信および受信するようにしたため、フレームの内部にプロトコルヘッダ等の固定のエリアを用いずに、フレーム種別毎に固定のフレーム長を割り当てることにより、フレーム種別を認識し、そのフレームに応じた受信、応答動作を行なうことができるようになり、通信回線上を流れるデータ量を少なくしてデータ通信速度を上げることができる。また、プロトコルヘッダなどのデータ領域をフレームから削除することにより、データ処理速度を上げることもでき、全体としてのスループットの向上を達成できる等種々の効果が得られる。
【図面の簡単な説明】
【図１】本発明の一実施の形態によるデータ通信システムの全体構成を示すブロック図
【図２】前記実施の形態におけるコマンドフレームの作成および送信、応答動作を説明する動作説明図
【図３】前記実施の形態におけるブロック１のデータフレームの作成および送信動作を説明する動作説明図
【図４】前記実施の形態におけるブロック２のデータフレームの作成および送信動作を説明する動作説明図
【図５】前記実施の形態におけるブロックｎのデータフレームの作成および送信動作を説明する動作説明図
【図６】前記実施の形態におけるデータ受信処理動作を説明するフロー図
【図７】本発明の他の実施の形態におけるフレームの構成を説明する図
【図８】前記実施の形態にフレームの受信処理動作を説明するフロー図
【図９】従来のデータ通信方法によるフレーム構成および送信、応答動作を説明する動作説明図
【符号の説明】
２１  パソコン
２２  集配信装置ク
２３  携帯端末装置
２４、２７、２９  通信手段
２５、３０  メモリ
２６、３１  ＤＭＡコントローラ
２８、３５  制御部
３２  ハードディスク
３３  入力部
３４  表示部
【図１】
0003961128.tif 000002
【図２】
0003961128.tif 000003
【図３】
0003961128.tif 000004
【図４】
0003961128.tif 000005
【図５】
0003961128.tif 000006
【図６】
0003961128.tif 000007
【図７】
0003961128.tif 000008
【図８】
0003961128.tif 000009
【図９】
0003961128.tif 000010