FT2232H

FTDIがFT2232Hを使ったミニモジュールの販売を開始していることに気が付きました。値段も3,000円程度ならリーゾナブルですね。ただし送料が同じくらいかかってしまうので、ここはやはりDigikeyやMouserあたりで他の部品と一緒に購入した方が良さそうです。ついでがなければ、HDLのボードの方がいいかもしれません。

OpenOCDのFT2232H対応をやっている人もいるようなので、そのうちに、このモジュール使ったJTAGが使えるようになるかもしれないと期待が膨らみます。わたしのように、もっぱらAT91SAM7のフラッシュを焼くのを主目的にJTAGを使っているような人には、どの程度高速化のメリットがあるのか疑問ですが、EEPROMもモジュール上に載っているので、簡単な工作で自作JTAG作れそうなのが嬉しいです。

複合デバイスは動いたが

CDC+MSCの複合デバイスは、SD R/Wを修正することでどうにかちゃんと動くようになりました。デバイスマネージャでの表示は、下図のようになりました。



CDC経由のシリアルコンソールを使ってタスクを表示すると、こんな↓感じです。msd_taskがMass Storage Deviceの処理をおこなうために追加したタスクです。usb_taskが受信したパケットのクラスを判別して、MSCの場合には msd_taskに、CDCの場合には console_taskに処理を引き継ぐようにしています。



Mass Strorageの方だけを Windowsの「ハードウェアの安全な取り外し」操作で取り外しても、残ったCDCの方のシリアルコンソール機能はちゃんと動いてくれています。このように複合デバイスとして動かすことには一応成功したのですが、MSDとしてのアクセス速度が遅いです。12MBほどのファイルのコピーで実験してみると

   Read:  30秒弱  (400KB/sec)
   Write: 約60秒  (200KB/sec)

という悲惨な成績。最初は512バイトSD/USBから読み出してはUSB/SDに書き出すという1ブロック単位のR/Wだったのでもっと遅かったのですが、8ブロック毎のR/Wにしたところ、現在の数字になっています。特に、書き込みの遅さは耐えられない感じがします。ATMELのライブラリのコードでは、ACMD4323による書き込みブロック数の設定をおこなっていないので、書き込み前の消去に余分な時間を費やしているのかもしれません。このあたりの変更から始めて、改善を試みようかと思います。

100,000番代に到達

SDカードの読み書きを修正したところ、USB Mass Storageが動き始めました。もう少し、動作確認をしてから整理して記事にしようと思います。

さて、ここしばらくソフトばかりやっていたので、そろそろまたハンダ付けをしたくなってきました。まだ次の計画ができたわけでもないのですが、いくつかパーツの手配を進めておきたくなってきました。とりあえず、久し振りにSparkfunにちょっと注文。届いた注文確認メールをみると Order Noの桁が増えて 6桁、100000番代に入っていました。

注文履歴を確認してみると、前回、昨年の9月終わりに発注した時には80000番のちょっと手前でしたから、5か月ほどで２万件の注文を受けているようです。スゴイ人気あるんですねぇ。

ちなみにわたしが最初に注文したのは、2006年の１月のこと。サイトが新しくなって、現在のカートシステムが稼働し始めた直後でしたので、注文番号は400番でした。

残り容量間違いの原因

USB Mass Strorageでディスクの残り容量が間違っている原因がわかりました。MSCに関連するUSBの処理の方を中心に見ていましたが、原因はSDカードからの読み取りの方にありました。いままで短いテキストファイルを読み出す程度の試験しかしていなかったので気づかずにいましたが、ATMELのライブラリコードがちょっとおかしいようです。

まずは、問題の症状から。参考にしたATMELのライブライのコードでは、SD/MMCからの読み出しにCmd18 (Read Multiple Block)を使っています。例えば、ブロック#200から2ブロックを連続して読みだすと、合計1024バイトを連続して読みだします。



ところが、この2ブロックを1ブロックづつに分けて読み出すと。。。



なんと、2ブロック目であるブロック#201の最初の部分が読めていないではありませんか。そこで、もう一度#201を読み出してみると、



今度はちゃんと読めています。こんな怪しい動きをしていたのが影響してちゃんとFATを読めていなかったようです。

トレースからもわかるように、連続したブロックを2度に分けて読み出した時には、新たなコマンドは投入されていません。Cmd12を入れるまではCmd18が生きていますので、ライブラリの設計者は最初のブロックの読み出し終了時にいったん止めておいたクロックを再投入してやれば、読み出しの続きができるだろうと考えたようです。ところが、実際には最初のブロックの読み出し終了後、SDカードにはクロックがいくつか送られてしまいデータが読み捨てられてしまっているのではないかと思われます。

ここは素直に、一度に複数ブロックを読むのであればCmd18を、1ブロックしか読まないのであれば、Cmd17を使うようにしてやれば問題は修正できるでしょう。ソースを読むと、書き込みも同じ処理になっているので、こちらも修正が必要なようです。FatFsを使って音声を録音した際にも同じ問題が発生していたのかもしれませんが、クラスタ単位で連続して書きこんでいるために音声のとびには気が付きにくかったのかもしれません。