■ASK光通信プロトコル

このプロトコルはPIシリーズの赤外線通信に必要なものです。

MIシリーズの場合はマイクロソフト赤外線通信ドライバが対応している赤外線インタフェースを利用する場合にはプロトコルを意識する必要はありません。


オプションポート15の通信は比較的単純で、ターミナルや通信ソフトでも通信できるのですが、ASK光通信にはプロトコル(通信制御手順)というものが存在します。

このプロトコルを正しく解釈して、プログラムに反映させないと正常な通信はできません。

現在、光通信に関する公式情報はソフトバンク刊:ザウルスSUPER TOOLS のCDROMに収録されている、過去に「ザウル出現Mark2 添付FD」収録されていたデータが存在します。(技術評論社:「ざべ(The BASIC) 」1995年7月号にも光通信解説記事もあります。)

通信タイミング関係はこちらの内容を参考にしています。

ただし、上記文書には欠落があり、そのままの情報を利用しても転送が正常にできない場合があります。


通信に使うシリアルポートの設定

 9600,O,8,1 (9600BPS、奇数パリティ、データ8、ストップ1ビット)
 調歩同期、半二重通信
 フロー制御は「なし」でよい

 パリティが奇数である点が曲者でOSによっては設定できない場合があります。


■光通信プロトコルの基本

 光通信は半二重通信です。

 制御コードを交換することで、送信側、受信側を切り替えます。

 下の例では、送信側をパソコン、受信側をザウルスとした場合の例です。
 逆の場合もありますが、そのときはこのプロトコルを逆に適用して下さい。

■通常のデータブロック

方向
PC->ZAU
内容 意   味
ENQ ザウルスが受信できる状態か確認
SYN ザウルスは受信可能である
ヘッダ データブロックを送るためのヘッダ
  ブロック番号 0001〜FFFFhまでインクリメント 
  01 04 FE  定数
  データ長 0〜512(200h)まで
  データ本体 この部分はテキストデータ
  チェックサム データ本体部分のチェックサム
ACK 正常受信できたことを示す

通常のブロックは上記を1単位としてデータが終わるまで繰り返されます。
ENQ,SYNなどのコントロールコードや、ヘッダ部分にはプリアンプル・コードがつきますので、こちらをご参照の上、実際のデータパターンをご理解下さい。

コントロールコードの送受信タイミング等は後述します。


■最終データブロック

方向 内容 意   味
ENQ ザウルスが受信できる状態か確認
SYN ザウルスは受信可能である
DH データブロックを送るためのヘッダ
  ブロック番号 最終ブロックはFFFFh(固定)
  01 04 FE 定数
  データ長 0〜512(200h)まで
  データ本体 この部分はテキストデータ
  EOF (1Ah)データの最後を表す
  チェックサム データ本体+EOFのチェックサム
ACK 正常受信できたことを示す

最終ブロックに関しては、ブロック番号がFFFFh(2番目のブロックが最後だとしても、FFFFh)になることと、データ本体の最後にEOFが付加されることが、通常ブロックとの違いです。

EOF を埋め込むタイミングですが、本来はザウルスのデータを受信した時にEOF を付加してファイルに保存するべきですが、配布されているデータ中にはEOFが含まれない場合がありますので、転送前にファイルをチェックして最後にEOFを追加するようにした方が良いと思います。

これは、データ長が512バイトの時、特殊処理が必要になりますが、プログラミングの際EOFがファイル中に付加されていないことが前提になると余分な処理をする必要が生じプログラムの手間と、処理速度の低下を招くためです。(特殊処理は後述)


■通信開始までの手続き

通信開始時のシンクロ

  1.  相手機器が通信可能になっているかをサンプリングする(ENQの送信)
  2.  ENQを送信して500ms以内にSYN レスポンスが返らない場合は再度ENQ を送信する
  3.  SYNが返らない場合、ENQ送信の繰り返しは6分間続く
  4.  SYN が返ってきたら、実際のデータを送信する

データブロックの構成

内容 実データ バイト数 意味
光通信データヘッダ(DH) 00 00 00 00 00 96 81 10 8 定数扱いで良い
ブロック番号 01 00 2 ブロック番号は1から順次カウントアップされる
下位-上位バイトの並び
デバイスコード他 01 40 FE 3 01 制御コード
40 デバイスコード
FE ???????
(定数扱いで良い)
データ長 02 00 2 実際のデータブロックの長さ
00 00 〜 02 00
データ本体 テキストファイルをバイナリ
イメージで転送
0〜512 ファイル内容をそのまま送信
チェックサム XX XX 2 データ本体部の単純加算チェックサムの
下位2バイト

■イレギュラーな通信(通信キャンセルと、リトライ発生条件)

ENQ (ザウルスが受信できる状態か確認)を送った時の応答

正常応答 SYN ザウルスは受信可能である
異常応答 CAN ザウルス側で通信中止
  その他 信異常が発生したとして処理
(無データも含む)

異常応答時の処理

通信キャンセルの場合は通信処理を終了する

その他の場合は最初のデータブロック転送時には6分間、2番目以降のデータブロックの場合は10秒間、500ms間隔でSYNを送信し、応答が返るのを待つ
応答が返らなければ、通信異常が発生したものとして通信処理を終了する


データブロックを1ブロック送信後の応答

正常応答 ACK ザウルス側は正常に受信完了
異常応答 NACK 通信異常の原因がチェックサムであることを示す
リトライ処理を行う
  その他 信異常が発生したとしてリトライ処理
(無データも含む)

異常応答時の処理

  1.  リトライ処理を行う
  2.  ENQの送信から始め、エラーが発生したブロックを再度送信する
  3. ※リトライの回数

    2回(最初のデータ転送を併せて3回)行い、それでも転送不可能なときは、通信を中断する。


■通信タイミングとリトライまたは、通信中断条件

 経験者からのアドバイス

転送タイミングに関しては、ms単位で指定があるものの通常の処理を行う限りシビアになることはありませんが、ENQ-SYN に関しては最優先処理が必要です。

実際にZauBASE のプログラムを組む際には、ENQ-SYN 500ms の部分のみインターバルタイマを利用してチェックを行っています。

通信状態   通信タイミング、リトライ、中断条件
シンクロ時 →ENQ
←SYN
 ENQ 送信後、受信側が500ms 以内にSYN を返さない場合は、ENQ を再送しSYN が返るまで初期リンク時6分間、通常時10秒間ENQ 再送を繰り返す。
 受信側はENQ 待ち状態になり、初期リンク6分間、通常時10秒以内にENQ が送られてこない場合通信中断となる。
データ転送時 ←SYN
→DH 
 SYN が戻った後、送信側が200ms 以内に DH以降のデータを送る必要がある。
 受信側は、SYN 送信後、400mS 以内にDH 以降のデータを受信できない場合はリトライ処理に入る
正常受信確認時 →DATA
←ACK
 受信側はデータブロックの最後の1バイトを受信後、400ms 以内にACKを送信する必要がある。
 送信側はACK が送られてくるのを1秒待ち、ACK がこない場合はリトライ処理をする。
 データブロックを転送するときは、送信側は4秒以内に全てのデータを転送する必要がある。(9600BPS なら十分この制限をクリアできる)
 受信側は最初の1バイト受信後、5秒間データブロックを受信し続けるが、5秒以内にデータブロックの最後まで受信できないときはリトライ処理する。

★一口メモ★

データの最後に EOF(1Ah) を付加することを忘れないようにして下さい。

シャープの純正インタフェースを利用した場合、光通信エコー(送信したデータがそのまま、受信データとなる)がありますので、それを考慮したプログラムが必要になります。

また、ノートPC等に内蔵されているIrDA-ASK互換インタフェース、PCMCIAカードタイプのインタフェースについては、CS(ハードウェアフロー)を有効にすると、ハングアップするものがあります。

原因は良くわからないのですが、CSを無効にすると正常に通信できます。

シリアルポートのフロー制御については、テキストデータの通常通信時のみXon,Xoffを指定し、それ以外はNon で大丈夫です。


参考文献:ソフトバンク株式会社 ZAURUS Super Tools  PIRICA編 付録CD-ROM