【Android USB oscilloscope】(27) STM32でAOA 重箱の隅

余っているAndroidスマホをオシロにしよう！

STM32をUSB hostにする取り組みで悩んでいましたが、少し前進しました．

なお、今回は重箱の隅ですので重箱の隅を覗きたい人だけ下へ進みましょう．

【いきさつ】

こんなブロックでスマホの画面をオシロ画面として活用したいというのが最終目標．

開発要素はこの３つ．

・ハードウエア（STM32)　　←入手難で絶賛死亡中

・STM32のfirmware（STM32CubeIDE C言語)

・スマホアプリ（Kotlin）

今はSTM32 firmwareをやってるところ．

firmwareのひな型としてこの画面のMiddleWareを利用しています．

スマホに外部からUSB dataを流し込むには、AOAという聞きなれないUSBプロトコルを使います．AOAについては過去投稿を参照してください．ひな形firmwareにAOAは実装されてません．

【Android USB oscilloscope】(14) Android open Accessory

【Android USB oscilloscope】(16) AOA --- Android～Linux hostとのUSB BULK通信 (化物)

AOAは曲者です．AOAこんな手順でUSB接続します．

・スマホにUSBを挿すと、、、

・最初はMass Storage接続だったりするのは誰もが見る光景なのだが、、、　①

・裏でUSB hostが特殊コマンドを送信すると、、、

・スマホがUSB接続を一旦切断し、別のVID/PIDで再接続してくる

・再接続したスマホはAOA接続になっている　　　②

①はUSB classなので型にはまっていて使いづらい．②はclassではないのでユーザーが好き勝手出来るのでわたしにとってはAOA接続の方が便利．それがAOAを使う理由です．

本シリーズの過去投稿で、PC(Linux)でAOA接続の動作確認はできています．

なので現在取り組んでいるのは、同じものをSTM32 USB hostに移植すること．

だけどなかなか上手く動かなかったんだよね．数日間悩んでた．

【動かないってどこが？】

・Linux hostなら動くけれど、STM32 hostだと動きません

・AOAの特徴である、接続断→再接続のときに死にます

・codeを眺めていてもおかしな点はない

・USBプロトコルアナライザ(wireshark)でおかしなpacketは飛んでない

・接続断処理が正常に完了してないので再接続が滞っているのではないか？

・接続断処理に要する時間をオシロで観測したら１秒ぐらいかかっている　　③

・接続断→再接続の間隔を実測したら250mSecしかない　　④

・③＞④なので死んでいる

【USBの原則とAOA】

一般にCPUが外界の事象にコミットするには割り込みを使わないと上手くいきません．USBでも同様で、USBの様々なイベントに即応するべく割り込み(callback関数)がたくさん用意されています．

ただし「callback多数」はUSB deviceの場合に限ります．USB hostはほとんど割り込みを使いません．それはSTM32CubeIDEが吐き出すsample codeを眺めると分かります．USB hostではcallback関数が３つしかないんです．

　１）USB disconnect callback

　２）USB connect callback

　３）SOF callback

これはUSB deviceに比べたら鬼のように少ないです．てか割り込み処理しようという気が基本的に無い設計思想といえます．

後日訂正：setupに割込みは少ないですが、data転送にはIRQが盛んに発生しているようです．調査中．

どうしてこんな仕組みになっているのか？

USBではデータの流れを全てhostが握っています．hostはdeviceに「しゃべっていいぞ」と命じ、deviceは返答します．

deviceが勝手にイベントを発生させる場面は「基本的に」ありません．

「基本的に」というからには例外があるものでして、hostのcallback関数にも見られる通りこの２場面では「deviceがイベント発生」させてもOKOK．人力でケーブル引っこ抜くのに時間制限なんかないですからね．

　１）deviceが落ちるとき

　２）deviceが接続するとき

なので、AOAが接続断→再接続するのはスマホが好き勝手にやります．わたしがdebugに使っているHuweiのスマホでは接続断→再接続の間隔はたったの250mSecです．１秒程度の余裕があってもいいんじゃね？　これだから接続断→再接続ってあまり関わりたくないです．

【余談】

USB機器には、USBメモリのような高速応答の物もあれば、プリンタのような応答速度が数秒かかる物もあります．

LinuxのUSBの挙動をプロトコルアナライザを見ているとこんな場面が多々あります．

　プリンタへ要求

　　↓

　USBメモリへ要求

　　↓

　USBメモリが応答

　　↓

　プリンタが応答　　　←順序おかしい

つまり、hostは要求を乱れ撃ちします．結果としてdeviceからの応答も因果関係無視の乱れ撃ちになります．driverがキューを参照して対応関係を並び替えしてるんでしょう．

ところが、STM32のsample programは乱れ撃ち非対応です．ゆえにやたら応答が遅いdeviceが在ったらhostの処理が滞ります．（RTOSを実装したら違うかもだけど）

【余談２】

STM32 sample programにおいては、hostはdevice応答をいつまでも待ち続けると書きました．また、hostは割り込みをほとんど使わないと書きました．

では．hostはどこで待っているんでしょうか？

大雑把にいえばmain loopです．ここでpollingしまくってます．なんか懐かしい感じｗ

main()　{

    while(1) {

        polling()　　←ここでフラグをチェックしつつ待つ

    }

}

以下はcodeの説明などをするつもりですがそれは後ほど追記します．project folder詰め合わせもDLできるようにします．

追記： BULK転送まで一気に実装してsource codeを公開しようと思ったのですが、BULK転送が全然動かないわSTM32がhung-upするわで挫折．今宵はここまでにしとう御座います．

２６へ　　　　２８へ

かしこ