その件について最後に記したのは2022年5月13日．ずいぶん古い出来事だったように感じていましたが、あの敗北からまだ１年と経ってなかったか....
余ったスマホをオシロの表示デバイスにするという構想でした．外付けのプリント基板でADCして、波形データをUSB経由でスマホに送る．画面表示はなんとかなるさ、と．
ところが、スマホのUSB2.0転送レートが1MB/Secにも届かず、ダメだこりゃと匙を投げてしまいました．
首尾よく出来たら夏コミケで売ろうとも思ってたんだったっけ....
やる気を失ったとはいえ、また復活させるつもりは少しありました．やり残した事があるからです．
ここでUSB2.0の転送レートの期待値を考えてみます．
チャネルレート： 480Mbit/Sec≒60MByte/Sec
60MB/Secはずいぶんと高速ですが、飽くまでも理論値なのでこんなには出ません．
packetレート： packetは125uSec毎に送信される
ということは、1 packetに7500Byte詰め込める計算ですが、実際はヘッダ情報などの無駄があるのでそんなに詰め込めません．
マルチpacket転送：
例えば2000Byteを送信したいとすると、USB controller ICが適当にぶつ切りしてくれて、自動的に複数のpacketに分けて送受信してくれます．記憶がウロですが、512Byteまでなら１packetに載るけどそれ以上なら複数packetになるよな感じかと思います．
ヘッダ情報などによる損失を避けるためには、500Byteを４回送信するよりも、2000Byteを１回送信する方が高速化できると想像されますが、実際にその通りになります．
実測16MB/Sec：
最善で16MB/Secが出ました．これくらいがUSB2.0の限界なのでしょう．
ーーーー
Androidスマホで900kByte/Secしか出ないのはあまりにもショボイので改善するには？
律速はスマホだと判っています．スマホ側の改善プランとは、、、
１）マルチpacketにする
残念ながら、STM32のsample codeはバグっていて、マルチpacketが動かないらしい．これはかなりfuckなバグです．しかも未解決だとか．なので900kByte/Secを出したのは511Byte転送のsingle packetでした．
２）packet受信を別スレッドでやる
これは当然そうするべきでしょう．
900kByte/Secの時はメインスレッドで受信していました．
しかしKotlinでスレッドで受信するのがよくわかりません．お勉強中なう．
３）スマホをUSB hostにする
↓900kByte/Secの時は、STM32がUSB host、スマホはUSB deviceでした．スマホはSTM32から押し付けられるpacketを漏れなく処理しなければなりません．しかしそれはAndroid OSにとっては酷なのかもしれません．いろいろと多忙ざんしょ？
↓そこで、データ転送の主導権をスマホに返上すべく、スマホ＝USB hostに昇格させるのがいろいろと円満なのではないかと思っています．これならOSが忙しい時にオシロ処理を急かされる心配は減りますから．
↓OTG cableが必要になってしまう．
というわけで、ヨタヨタと再起動です．あまり期待しないでください．
かしこ
0 件のコメント:
コメントを投稿