PIC32MX USBMSC USBメモリで音声再生4_読みだす単位を4096byteへ変更

20200225(+6.0h)

前回のUSBメモリとのデータ転送とNAKの問題を解決しました。　USBメモリからの1回のデータ転送のByte数をセクタに合わせて512Byteに設定していたのが問題でした。　これを8倍の4096Byteにしたところ、NAKの返信回数が減り、16bit-Stereoのデータもそれなりに再生できるようになりました。


USBメモリをフォーマットする時にアロケーションサイズを指定できます。　このアロケーションサイズに合わせて一回のデータ転送Byte数を設定したいところですが、最近のUSBメモリのアロケーションサイズは8Kbyteや16Kbyteと大きめです。 PIC32MXマイコンはRAMの容量が限られていますで、しかたなく4096Byteとしました。　

PIC32MX USB PLAYER 16bit Stereo 20200225

USBからのデータ転送を4096byte単位にして 16bit Stereo dataの再生に間に合うようになりました。

PIC32MX USB PLAYER 8bit Mono 20200225

比較用の 8bit Mono dataの再生。　USBからのNAKが減り、処理自体が安定しました。

PIC32MX USBMSC USBメモリで音声再生3_何とか再生、しかし、、

PIC32MX USB PLAYER  8bit Mono
開発中の USBメモリから音楽データを演奏するPLAYER のテスト1。　
8bit 1Channel(Mono) のデータを再生し、パソコンのマイクで拾って録音した再生音です。

https://youtu.be/B0l3OPqjvjg

PIC32MX USB PLAYER  16bit Stereo
開発中の USBメモリから音楽データを演奏するPLAYER のテスト2。
16bit 2Channel(Stereoo) のデータを再生し、パソコンのマイクで拾って録音した音声です。
USBの転送レート12Mbps(Full Spead)では、データの転送が音楽の再生に間に合わず、音がわれてしまっています。　手持ちの中でも応答の速いbuffaloのUSBメモリをつかっていますので何とか聞き取れます。　

https://youtu.be/Yj5Gu7LXn14

しかし応答の遅い格安USBメモリになると、NAKの返信が多くなり、まともに音声を再生できません。

PIC32MX USBMSC USBメモリで音声再生2

20200216
wave file の再生プログラムのコーディングで、またまたトラブル発生。
短いテキストファイルを、ダーッと表示するだけならば問題なく表示されるのですが、ちょっと長いwave file を読みだそうとすると途中で無応答となりエラー(オレンジ色)となる現象が発生。

※黄色の'N'の連続は、メモリがNAKを返している部分です。

これは、トークン処理の終了を通知するU1IRbits.TRNIFのONを上手くとらえる事が出来ていない現象でした。

割り込み処理で同じU1IRレジスタのU1IRbits.SOFIFフラグをチェックしているのですが、このビットクリアをすると、ほかのU1IRのビットもクリアされてしまっていました。
これについては、一旦U1IRbits.TRNIFを別変数で保存してそれを参照・チェックする暫定処理を入れて逃げています。　


ここが何とか通ったと思ったら、次は　U1EIR.EOFEF(END OF FRAMEを検出)エラーが出るようになりました。これについては、U1SOF(SOF Threshold)の幅を0x4A→0x80に増やしてしのぎました。 20200216(+4h)


先に対応した、トークン処理の終了を通知するU1IRbits.TRNIFのONが上手くとらえる事が出来ない現象ですが、どうやってもまれに取りこぼしが発生します。　
いろいろと検討して、U1CONのトークン処理BUSYフラグの状態とBDTのUOWNフラグの状態を組み合わせてチェックする事で何とか解決出来ました。20200217(+4.0)

PIC32MX USBMSC USBメモリで音声再生１

20200210
USBメモリのアクセスがそこそこ出来るようになったので（アクセス出来ないUSBメモリには目をつむって）、次はUSBメモリを使って音声再生するガジェットを作ります。 WAVE PLAYER／PCM PLAYERというやつですね。

以前作った、おしゃべり時計のプログラムを移植すれば行けそうです。　しかしながら、昔コーディングしたプログラムでは、いろいろ拙いところが目に付くので、手を入れたいところ。。。

まずはFIFOの処理あたりから見直そうと修正したのですが、しかしながら見直したロジックではちっとも動かず。一体なにが悪いのか？　一度作戦を練り直さねば。20200210(+4.0h)

FIFO処理の見直しは一旦横において置いて、以前作ったSpeakingClockからメインとなる処理をCopyしてテストしています。　一日ほどの作業でファイル操作関連の処理がそれなりに動くようになりました。　短いファイルならば問題なくファイルの中のデータを取得表示できるのですが、音楽ファイルはどうやっても途中でUSBメモリの読み出しが途切れてしまいます。20200212(+8.0h)


以前アクセスできなかった アマゾンの格安メモリですが、最初につないだ直後なら、それなりにUSBメモリのファイルにアクセス出来ることに気が付きました。　しかしながら、エラーになるとドライバの初期化手順を実施しただけでは復帰しません。　USBメモリデバイス自体をリセットするような方策が必要なようです。20200214

※左側の青いUSBメモリだけアクセスできない。

PIC32MX USBMSC USBメモリのアクセス、不調の原因

アクセスがエラーになるUSBメモリがあるものの、それ以外のUSBメモリのアクセスが出来るようになりましたので、FatFsを組み込んで、いつものpicクラブの情報交換会に発表に行ってまいりました。

しかしながら持参したパソコンの調子が悪く、後閑先生からノートパソコンをお借りしてデモを実施したのですが、これがどうやっても途中でエラーが発生して、USBメモリのアクセスが上手くいきません。　なんとか持参したパソコンを再起動して、情報交換会の最後でデモを行う事ができました。　

この事象により今まで不安定だった原因がいくらか判明しました。
実はこのプロジェクトで作成したデモ用の基板は、秋月のUSB-シリアル変換器からのバスパワーで動かしています。　この USB-シリアル変換器の回路図を確認したところ、バスパワーの供給ラインの途中に保護用に100mAのポリスイッチが入っていました。



　
つまり、このUSB-シリアル変換器で供給できる電流は100mAまでです。USBによってはアクセスが発生した場合に大きな電流を消費し電源電圧が下がって不安定になったものと思われます。

この100mAのポリスイッチをバイパスし、USBメモリの根本に100uFのコンデンサを追加してかなり安定してUSBメモリにアクセスが出来るようになりました。

今回判明したUSBメモリの消費量が意外に大きいので、これは今後の設計の課題となりそうです。

20200204

PIC32MX USBMSC USBメモリのアクセスが出来ない

なかなか進まない、USBメモリドライバの開発です。
PIC32MXでUSBメモリにアクセスするの、ようやく何とか出来るようになってきました。

20200111
前回までで、下記写真の右側のUSBメモリに、SCSIコマンドでアクセス出来るようになりましたが、左側のアマゾンで買った格安の青いUSBメモリと黒いUSBメモリが上手く動きません。　その為今一度、全てのUSBのDESCRIPTORを調べてみました。

20200115
DESCRIPTORを調べて対応して、下記写真の右側については、SCSIコマンドも上手く通りリードライトが出来るようになりました。
前回より一歩進んで黒いUSBメモリにもアクセス出来るようになりました。

黒いメモリが読めなかった原因が、IN/OUTのエンドポイント番号が他のUSBメモリと異なっていた為で、前回まで決め打ちでIN=EP1、OUT=EP2としていたのを、ENDPOINT DESCRIPTORを読込んで対応するようにしました。

その他、通信の各エンドポイントのDATA0/1の切り換えとか、BDTテーブルのピンポンバッファの指定が上手くなかったようでそのあたりも見直しました。

残るは、左側のアマゾンで買った格安のUSBメモリです。　これについてはSCSIコマンドのINQUIRYコマンドまでしか通らず、SCSIコマンドでのREAD・WRITEコマンドが出来ません。

20200116
アマゾンで買った格安USBメモリ(左の青いやつ)がどうしてもエラーとなるので、パソコンにWiresharkというソフトをインストールして、パソコンとUSBメモリとの通信をキャプチャする事にしました。　パソコンと 問題のUSBメモリとの間でどんなやり取りをしているのかを参考にしようというわけです。※パソコンからは問題のUSBメモリが普通に使える。

1点見つけたのは、"Test Unit Ready"のSCSIコマンドが上手く行かなかった原因が、CBWCB長（SCSIコマンド長）の指定が間違っていたことでした。そこを直し"Test Unit Ready"コマンドが通るようになりました。

このWiresharkというソフトは優れものでパソコンのいろんな通信の内容をパケットキャプチャできるのですが、残念ながら実際のUSBとパソコンの間の通信をキャプチャしている訳ではないので、PID、DATA0/1 などのいくつかの情報は取れないようです。　気になっていた、通信上のDATA0/1の遷移はわかりませんでした。


                       https://www.wireshark.org/

20200121
左側のアマゾンで購入した青い格安USBメモリは、どうしてもアクセス出来ないのでついに諦めました。。。パソコンからは読み書きできるのですけど、何が悪いんだろうなぁ。

PIC32MX USBMSC ドライバ試作

PIC32MX USBMSC ドライバがようやく何とか動き始めたので、一旦Githubにアップロードしました。

https://github.com/PlanetxGear/PIC32MX_USBMSC_Driver_sample

PIC24F用に作成したUSBMSCドライバをPIC32MX用に移植したのですが、これがどうやっても動かない。。。USBメモリのAttach/Detachは検出するものの、USBメモリに最初にAddressを書き込みに行ったところでウンともスンとも言わなくなる状態です。　結局、USBのコントロールレジスタにBDTテーブルのメモリアドレスを設定する箇所が間違っていて、ここを「仮想アドレスから物理アドレスに変換して」設定しないといけなかったのです。　ここを見つけるのに一月かかってしまいました。　うっすらと以前に同じ経験をしたような記憶も、、、忘れていましたが。。。　なんにせよDMAなどを使うときは要注意、、いやいやDMAをもっと活用して「仮想アドレスから物理アドレスに変換する」ことを頭に入れておかないといけないですね。

20200105

ついでにこの問題点について、どうやって気づいたかも記載しておきます。

つまずいた点は、PIC側からUSBに向けて USB Addressを設定する SETUPコマンドを送信しても、それが ACKなのかNAKなのかのリターンが帰ってこない現象です。（※実際はBDTのアドレス設定が間違っていたので、そこにACK,NAKが書き込めていない。）

USB peripheral のレジスタ設定手順と、USBへの供給クロック設定を何度も見直しましたが原因わからず、、結果USBへの供給クロック設定についての以下の2点について疑問が残りました。
１．USB PLL のロックステータスフラグ(ULOCK@OSCCON)がどうやっても”１”が立たない。
２．DEVCONF2のUSBENBLの設定が、DATASHEETの記述と、MCCの設定表記と食い違いがあるように思える。
※ちなみに1.2.について現状はまだ判然としていません。20200108

これらについて、実際にPIC32MXでどのように設定されるのかネットを色々さがしたのですが見つからず、Harmony v3 で作ったプロジェクトと比較してみる事にしました。しかしながら Harmony v3は使った事が無かったので、プロジェクトを作るのにも一苦労して出来上がったプロジェクトも　またロクに動かすことができませんでした。　
USBモジュールやクロック設定した空のプロジェクトは出来てコンパイルも通す所までできますが、USB関連のFunctionが多くどれをどの順番でMain処理に並べて行けばよいのかがよくわからなかったのです。

そんな訳で続いて挑戦したのが、気分を変えてPIC32MMのテスト基板の組み上げと、MPLAB Xでのプロジェクト作成です。 PIC32MMのプロジェクトは、MCCからUSB（CDC、HID）の設定ができるので、 つまりこれを参考にしようというわけです。
MCCの設定は慣れたものなのでサクっと作り上げて、動かしてみたところDMA関係のレジスタに設定されたアドレス値が想定と異なっていたのでようやく気が付きました。　
後でマニュアルを確認しましたが Note にちゃんと「物理アドレスを設定せよ」と書いてありました。

最近は、取り組むプロジェクトが長丁場になる傾向があるのでブレッドボードはやめて、ユニバーサル基板にハンダ付けして組み上げるのですが、適当に作るのでいかんせん雑になります。作業も遅いので今回作ったPIC32MMの簡単なテスト基板でも４~５時間はかかってしまいました。

左から、PIC24FJ64GB002 / PIC32MX250F128B / PIC32MM0256GPM028

PIC24 USBMSC＆FatFs sample project

細々と作っていた、PIC24FJ64GB002のUSBメモリドライバが何とか動くようになり、FatFsを組み込んでUSBメモリ内が見れるようになりました。

MPLAB XのプロジェクトはGithabにあげてあります。

https://github.com/PlanetxGear/PIC24_USBMSC_ff13c_sample

20191204

USB MSC ドライバ 試作・テスト

USB始めました。　*USB MSC について、

FatFsで USBメモリをコントロールしたくて、PICマイコンでUSBのホストコントロールに挑戦しています。

いくつかのPICマイコンは、USBホストとして動く OTGモジュールを持っています。　これをUSBホストとして動かすためには通常、1.Harmonyを導入する。　2.MLAを導入する。　いずれかの方法となります。　
最近(2019)は MCCでも USBホスト機能を実装できるようになってきていますが、残念ながら HIDやCDC のみであり、MSCとしての実装がありませんでした。

MCCにUSB-MSCの設定が無い理由として考えられるのは、、MSCを使うには、USB通信ドライバの上に、SCSIインターフェース、ファイルシステムを構築を構築する必要があり、アプリケーションが大きくなる為ではないかと思われます。　ただでさえ複雑なUSBのエニュメレーション処理に加え、さらに２つの処理層が必要となりプログラムが大きくなってしまう為ではないでしょうか。


しかしながら、Interface 2014年11月号のUsbStadyの記事によれば、単純に一つのUSBデバイスをマイコンに接続するだけならば、エニュメレーションをすっ飛ばして
USBにアドレスとCONFIGを設定するだけで、後は単純なシリアル通信なので、HarmonyやMLAのような巨大なソースは必要ないと説いています。

UsbStady記事では、PIC24FJ64GB002を使用したサンプルプロジェクトも公開されており、これをベースに自分好みの USB MSC ドライバを構築できそうだと考え、やって見ることにしました。

1か月間悪戦苦闘して、サンプルプロジェクトから自分好みに組み直して、曲がりなりにも動くようになりました。　いろいろと気づいた点を以下メモしておきます。

・PICマイコンに搭載されている USBモジュールは、設定やステータスのレジスタが多く、使い方が複雑です。

・ホストモード・クライアントモードを切替え出来るように作られている為か、レジスタもそれぞれ用の設定が入り乱れているように思われます。

・USBモジュールのレジスタで U1EPxという名前のレジスタがあるのですが、これが各USB通信のエンドポイントと対応した名前となっています。　しかしながら、ホストモードでは、U1EP0 のレジスタのみ使用するとあり（BDTについても同様"0"のみ使用)これを使用して、通信のEP0,EP1,EP2 をコントロールする為さらに混乱しました。

・USB通信の一つのトランザクションは、トークン → データ → ハンドシェイク　の流れですが、トークンは、U1TOKレジスタを更新した段階で自動発行され、またハンドシェイクは、U1EP0.EPHSHK bitをセットすればUSBモジュールが自動で発行・取得してくれます。　マニュアルにハンドシェイクはソフトウェアで行えとの記述があり、しばし迷いました。
　取得したハンドシェイクのPID情報は、BDTテーブルのPIDへと反映されます。　またデータについては、BDTテーブルに設定するアドレスのバッファへDMAで格納、もしくはバッファからDMAで転送されます。

・また SOFパケットも U1CON.SOFEN bitをセットすれば、自動で 1ms事にUSBモジュールが発行するので、一度送信設定すれば、後は気にする必要はありません。

・問題はUSBメモリ側が返す NAK です。　USB側の動作は非常に遅い(使用したUSBメモリが古い)ので マイコンのUSBモジュールがコマンドを 発行すると、USBメモリ側からは NAK ばかりが返信されてきます。
USB通信の受信（マイコンのUSBモジュールではRX）でUSBメモリから帰ってくる NAK については、すぐさま受信をリトライし続けると、無応答となってしまいますが、1msのインターバル(SOFトークン1回分のwait）を設けてリトライすれば、無応答とはならずに、NAKを返し続けてくれて最後はACKとなり受信が完了する事ができました。（この現象はUSBにアドレスを設定するところで顕著でした。USBのアドレス設定は重たい処理なのかもしれません。）
USB通信の送信（マイコンのUSBモジュールではTX）においては、SCSIでWRITEコマンドを発行し、続いて ６４バイトのデータを８回（計５１２バイト）連続して送と、NAKすら返さずいきなり無応答となってしまう現象が発生しました。　試行錯誤して、６４バイト送るごとに 4msのインターバルを入れる事で、無応答となるのを回避する事ができました。（速いUSBメモリでは1msのインターバルでOK）　その為 512バイトを書き込むのでさえ36msかかってしまう事になってしまいましたが、目をつむることにしました。
20190829+64h??

下記に成果物をアップしておきます。
PIC24_USBMSCtest プロジェクト






　

PIC24F USB OTG ホスト機能 BDTについて、

PIC24FのUSB OTG ホスト機能について調べています。20190711+5.0h
USB OTG機能の BDT（バッファディスクリプタテーブル）の使い方が難しく難航しています。

• PIC24 USB OTG 日本語マニュアル
• USB通信プロトコル (picfun/電子工作の実験室)

そこで備忘録としてBDTについてメモをしておきます。

BDTは、USB機能のSIE（シリアルインターフェースエンジン）とCPU(PIC)とのデータ受け渡しとなるメモリバッファ(EPn)のアドレス情報などが格納されたテーブルとなります。USB機能はBDTに設定された情報をもとに、PICのメモリにDMAで読み書きします。

• BDTの配置は512バイト境界に合わせる必要がある。
• U1BDTP1 レジスタにBDTのアドレスの上位7bitを格納する。
• ホスト機能の場合、EP0の領域のみを使用する。　※USBの通信がEP1やEP2で通信が行われていても ホスト機能のはBDTのEP0領域のみ使用。
• EPnにはRX(受信)のエリアとTX(送信)のエリアがそれぞれある。
• RX,TXのエリアはそれぞれ レジスタ2Byte＋アドレス２Byte構成となり、EP0だけで8Byte必要となる。
• BDT
• EP0
• RX
• RXレジスタ--------------16 bits
• RXバッファアドレス-----16 bits

•  TX
• TXレジスタ--------------16 bits
• TXバッファアドレス-----16 bits

• data0, data1 を別々のバッファ（ピンポンバッファ）として使う場合は、上記をそれぞれに用意する為、16Byte必要となる。　
• data0 EVEN(偶数) BD
• data1 ODD(奇数) BD