中間目標達成!!

.03 2010 AVR-USB comment(0) trackback(0)
昨日はコマンドで
% setled 0x55
としてLEDをそのパターンに光らせるところまで行きました。

しかし、0x00から0xffまですべての値で試したところ、0x02や0xf3、それに0x7eなどではかなりの確率で値が変になったり、最悪の場合そのまま応答がなくなってしまっていました。

0や1が6個以上並ぶ特定の数値でしかこの現象が起こらないのでbit stuffingが怪しいこと、それに確率現象なので数値そのものが間違っているのではないことまではすぐに特定できたのですがその先が絞れず苦戦しました。

特にデバイスが停止してしまうとホスト側でもWriteFile関数が停止してしまい、そのスレッドが腐ってしまうので大問題です。

そんなわけで今日は朝からずーっとこの問題を考えていたのですが、結局原因は非常に簡単なことでした。

受信するときは、SE0状態(EOP)が確認できないまま一定量を受信すると、その先はSE0になるまでひたすら待ち続けるようになっています。
ホスト側はACKが帰ってくるまで処理が止まります。

ここで受信時にホストが発行したSE0を見落としたとします。するとそのままSE0を待つところに飛びますが、ホストはデバイスのACKがくるまで何もしません。したがって次のパケットも送られてこないので永久にSE0にならず、停止すると考えられます。
つまりSE0の検出に失敗していた可能性が非常に高いわけです。

また、0x3f3f3f3fが0x7e7e7f3fのように少しずれて受信されることがあることをあわせて考えると、特定のbitにおけるbit-stuffingの処理時間がずれていることが考えられます。

で、良く見ると…
recv_bit6:

	...

recv_bit5:					; 8clk
	recvbit	x2, x1			; 4 (macro)
	cpi		recvbuf, 4		; 1
	brlo	rx_stuff5		; 1
	rjmp	recv_bit6		; 2

	...

rx_stuff4:					; 1(branch)
	stuff	x1, 0b11100000	; 5 (macro)
	rjmp	recv_bit5		; 2
rx_stuff5:					; 1(branch)
	stuff	x2, 0b11000000	; 5 (macro)
	rjmp	recv_bit6		; 2

5bit目でbit-stuffingがはいるとき、これでは5bit目の受信からstuffed bitの受信までの時間が6clkになっています。正しくは
rx_stuff5:
	nop2
	stuff	x2, 0b11000000
	rjmp	recv_bit6

ですね。これは気づかなかった…

これを直すと安定して受信できるようになりました。あーすっきりした^^

一応まだ気になる現象がありますが、必ず起こる現象である上、特に支障はないので明日は最終目標のAVRライタの作成に取り掛かります。
その「気になる現象」については進展があったらメモします。
関連記事

  • comment
  • secret
  • 管理者にだけ表示を許可する

trackbackURL:http://yuranos.blog11.fc2.com/tb.php/65-9dc3dcff