ＴＴＬでＣＰＵを作ろう！

~~標準ＴＴＬ~~だけ（！）でCPUをつくろう！（組立てキットです！）
(ホントは７４ＨＣ、ＣＭＯＳなんだけど…）
［第５１１回］

●いよいよ「ＰＩＣ１８Ｆ１４Ｋ５０でＵＳＢを認識できません」というお話です

［第４９９回］で、ＰＩＣ１８Ｆ２５５０ではうまくいったＵＳＢのプログラムがＰＩＣ１８Ｆ１４Ｋ５０では動いてくれなくて、みごとに泥沼にはまってしまいました、と書きました。
もちろん、現在はクリアしてＰＩＣ１８Ｆ１４Ｋ５０でもＵＳＢにアクセスできるようになりました。
しかし、最初に、ＰＩＣ１８Ｆ２５５０でちゃんと動いているＵＳＢプログラムをＰＩＣ１８Ｆ１４Ｋ５０に移植したときは、それこそまったくうんともすんともいってくれなくて、ほんと、途方に暮れてしまいました。

その悪戦苦闘の記録です。

とにかく。
ＰＩＣ１８Ｆ２５５０では、ＵＳＢケーブルを接続すると、デバイスマネージャーでちゃんとＨＩＤデバイスとして認識してくれます。

ところが、どういうわけかＰＩＣ１８Ｆ１４Ｋ５０では、全く反応がありません。
？も！も何もなしです。

むむ。
いくらなんでも、これは、ちょっとひどいのではありませんかあ？

もちろん、４８ＭＨｚクロックについては先刻確認済みですし、ＵＳＢバッファのアドレスもちゃんと変更いたしました（もっとも、実はそこのところにもミスがあって、変更できていないアドレスが残っていたために、事態はより混沌としたものになってしまったのでありますが）。

それこそ目を皿のようにして、ＤａｔａＳｈｅｅｔを繰り返し読んではみたのですが、とりたててＰＩＣ１８Ｆ２５５０とＰＩＣ１８Ｆ１４Ｋ５０との違いは見当たりませんでした。
これも、実はあとになってみると、フシ穴もいいところで、ＰＩＣ１８Ｆ２５５０とＰＩＣ１８Ｆ１４Ｋ５０との間には、とんでもない、まったくもってけしからぬ相違があったのでありますが、ま、それにつきましてはいずれ後ほど。

とにかく、途方に暮れてしまいました。
どこからさぐってよいのやら、これではてがかりもなにもあったものではありません。
なにしろ、全く反応なしで、接続してもしなくても、全然変化なしという状況です。

こうなってきますと、誰しも考えることは大抵同じことになりまして、まずはハードを疑うことになります。
ＰＩＣ１８Ｆ１４Ｋ５０はとりあえず２個購入しましたから、その両方で試してみましたし、簡単な動作プログラムを何回も書き込んで繰り返し動作テストをして、チップが破損していたり、書き込みミスがあったりする可能性はまず考えられないことはほぼ確信いたしました。
ハードではないとすると、一体どこに原因があるのでしょう？
やっぱりソフトにその原因を求めるしかないのでは？

で、プログラムのあちこちにトラップを仕掛けて（なんていうとなんだか滅法格好がよいのでありますが、その実は適当なところにポートのビット出力を仕込んで、それをＬＥＤで確認する、というきわめて原始的な方法に過ぎないのであります）、全く気乗りのしないまま追求を開始いたしました。

だんだん絞り込んでいきましたところ、なんと。
ＰＩＣ１８Ｆ１４Ｋ５０は、全然、ぜーんぜん、ＵＳＢを認識していないらしいことがわかってきました。

お話の進行につれまして、徐々にＵＳＢの仕組みについても、触れていくつもりなのですが、とにかく。
ＵＳＢは、ホストからデバイスに対して、ＳＥＴＵＰコマンドを送るところから始まります。
このあたりの信号につきましては、［第４２４回］のあたりで、すこしだけ説明をいたしました。

ＵＳＢは、最初にホスト（パソコン）からのデータ信号送出で開始されます。
情報はパケットという単位で送られます。
パケットの最初は信号の同期をとるためのＳＹＮＣという８ビットの信号から始まります。
ＳＹＮＣは８０Ｈ（１０００００００）という値です。
その次に、そのパケットがどういう種類であるかを示す、ＰＩＤという信号が続きます。
ＰＩＤは４ビットからなっていて、その後にＰＩＤの各ビットを反転したＰＩＤ＿が続きます。

ＵＳＢは、ホストからＳＥＴＵＰパケットが送出されることで開始されます。
ＳＥＴＵＰのＰＩＤ信号は、１１０１です（その後に各ビットの１と０を反転した００１０が続きます）。

［出典］Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ（Ｒｅｖｉｓｉｏｎ２．０）

ＵＳＢデバイスはこの信号をキャッチして、そこからセットアップための情報をホストからの指示にしたがって送信する（Ｅｎｕｍｅｒａｔｉｏｎ）ことになります。

ＰＩＣ１８Ｆ１４Ｋ５０の動作を追及していきましたところ、その肝心かなめの、ＳＥＴＵＰ信号を全く認識していないらしいことが明らかになってきました。

テストに使ったプログラムはＰＩＣ１８Ｆ２５５０でＨＩＤの送受信に成功したところまでの全てを含むプログラムですからかなり長いものです。
その最初のＳＥＴＵＰを認識するあたりのところにＬＥＤ出力を挿入して動作を確認してみました。
下はプログラムのその部分です。

;
	movlw 0ff
	movwf PORTC
	movlw 48
	movwf UCON;clear bit4,for SIE enbl
loop_ucon
	btfss UCON,4
	goto loop_ucon
	bcf PORTC,0
;

む？
ＵＣＯＮてなんだ？
知らんぞ。そんなレジスタは。今まで見たこともないぞ。

ごもっともです。
ＵＣＯＮはＵＳＢのためだけに用意された特殊なレジスタです。

［出典］ＭＩＣＲＯＣＨＩＰ社ＰＩＣ１８Ｆ１ｘＫ５０ＤａｔａＳｈｅｅｔ

いきなりＰＩＣ１８Ｆ１４Ｋ５０のＵＳＢコントロールレジスタが出て来てしまいます。
順をおって説明するつもりだったのですけれど…。

ＰＩＣ１８Ｆ１４Ｋ５０でＵＳＢを使うためには、いくつかのＵＳＢ関連のレジスタを設定する必要があります。
このＵＣＯＮレジスタもそのひとつです。
ＰＩＣでＵＳＢを制御するプログラムでは一般には、ＳＥＴＵＰ信号はこれとは別の手続きで認識することが多いようです。
しかし私は、ＵＣＯＮのｂｉｔ４のコメントに着目しました。
ＵＣＯＮのｂｉｔ４を０にしないとＳＩＥ（ＰＩＣ内蔵ＵＳＢコントローラ）はパケットの送信も受信もできません。
当然このビットを０にしてスタートすることになります。

ところがどういう理由によるのかはわかりませんが、説明によると、このビットはＳＩＥがホストからのＳＥＴＵＰを受け取ると、１になるのです。

［出典］ＭＩＣＲＯＣＨＩＰ社ＰＩＣ１８Ｆ１ｘＫ５０ＤａｔａＳｈｅｅｔ

そこで、さきほどのプログラムです。
ＵＣＯＮのビット４をひたすら監視していて、ビット４が１になったらＰＯＲＴＣのビット０から０を出力するようなプログラムを実行すれば、そこに接続したＬＥＤの表示によって、ＰＩＣ１８Ｆ１４Ｋ５０がＳＥＴＵＰ信号をキャッチできたことがわかるはずです。
あ。
もちろん、それだけでＵＳＢ接続が完了する、などという甘いものではありません。
これは、はじめのはじめの第1歩で、これからながながと退屈なＥｎｕｍｅｒａｔｉｏｎという手続きが始まります。

しかし、ともあれ、とりあえずはここだけ見れば、ホストから送られてきたＳＥＴＵＰ信号をチェックすることはできる、はずなのです。
論より証拠。
ＰＩＣ１８Ｆ２５５０で実行してみますと、ＵＳＢケーブルを接続した途端に、ＰＯＲＴＣのビット０に取り付けたＬＥＤが消灯します。

ところが、ＰＩＣ１８Ｆ１４Ｋ５０だと、ＵＳＢケーブルを接続しても、ＬＥＤは点灯したまま、だったのです。
２０１０．５．２９ｕｐｌｏａｄ
２０１０．５．３０一部追記

前へ
 次へ
 ホームページトップへ戻る