KISSプロトコルとは・・・

KISSプロトコル。

少し前に発売されたTinyTrak4でもファームの入れ替えで
KISSプロトコルがサポートされるようになってます。

dsPICでTNCを作るとして、その出力をどうするか？
つまりデータリンク層のプロトコルを何にするかって考えたとき、
やはり既存のものと共通化しておくべきだでしょう。

ならば、もっともシンプルなものになると思うので
KISSプロトコルってことになるかな～って


実際にTNCをKISSモードにして確認したり、
Web上のドキュメントをみたりして調べた結果、
次のようなことがわかった。


データは0xC0で挟まれて流れてくる。
AX.25の0x7eに相当するものと考えて差し支えなし。

0xC0の次には、送信先(送信元も?)+コマンドが流れてくる。
これによって複数のTNCを区別したり、
TX DelayをKISS上から設定できたりするようだ。
基本は0x00で送られてくるっぽい。

そのあとに実際のデータが続く。
ただし、受信したデータがズラズラそのまんま。
つまり、アドレス(コールサインやらデジパスやら)のところも、
AX.25の規約のとおり、順番やら1ビットシフトも変えずに送られてくる。
(e.g.) アドレスの場合'J'=0x4a は 1ビット左シフトされた0x94で流れてくる。

CRCチェックはTNC側のお仕事。
受信した限りでは、CRCは付加されてこなかった。
Webドキュメントでは、CRC付きのものも解説されていたけれど、その区別は不明(要調査)


以上より、仕事の分担がわかりましたし、
非常にシンプルなフローでTNCを作れそうです。
したがって、これに沿ってTNCを製作していくつもりです

CRCの計算アルゴリズム

PICTNCのソースから、CRCアルゴリズムを解析しました。
わかりやすくするために16ビットの数値を8ビットで計算しているところなどは省略します。

以下、変数・定数
data: 受信 or 送信するデータ(8ビット)
CRC: CRCの値を格納(16ビット)
Poly: 生成多項式(16ビット定数)

PolyはAX.25では0x8408
CRCは計算前に0xFFFFで初期化します。


dataを右へ1ビットシフトします。このとき最下位のビットがCビットに出ます。
↓
C=1ならば、CRC xor 0x0001 -> CRC
↓
CRCを右1ビットシフト。同様に最下位ビットがCビットに出ます。
↓
C=0ならば、計算終了
C=1ならば、CRC xor Poly  -> CRC


以上で計算は終了です。
アセンブラならおよそ10サイクルくらいで計算できると思います