余っているAndroidスマホをオシロにしよう！
通常人は海に山にと忙しいGWですが、わたしは北千住で飲んだあの日以外は引きこもってSTM32のBULK転送を動かそうとしています．がっ、うまく動きません．もう10日間ぐらい悩んでいるように思うけど、せいぜい５日間ぐらいでした．
STM32→スマホのBULK転送は一応動いたんです．しかしバリバリとpacket落ちしてる．
Net検索すると「STM32でBULK転送するやり方を教えて」的な海外のスレがちょくちょく在るけれどモロ参考になる投稿にはお目にかかってません．単純明快にBULKのpacket送信するやり方を知りたいだけなのですがね、そうゆうのが無いんだよ、くそぅ．
そんなわけで、STM32CubeIDEが吐き出すMass Storage Class(MSC)をひな形にして改造しているのだけれど、MSCは複雑すぎてcodeを追うのがつらいです．単純にBULK転送する場面は何処にもなくて、MSC標準のFATアクセスする構造体をガツガツ形成して見通しが悪くてかなわん．
現状でかろうじて動いているBULK転送は、MSCのclass用codeを無視して、low level関数を組み合わせて自己流で組んだもの．BULK送信はできていると思うんだが、スマホから打ち返される完了ステータスの処理が死んでいてbuffer overflowで死亡という有様と思われます．
ちなみに、連載16回目でAOA及びBULK転送の動作確認をしたときのhostはLinuxのlibusbでした．libusbではスマホの受信完了packetを待ってから次のBULK packetを送信していました．ところが、STM32の現状ではスマホのステータスなんかお構いなしに撃ちまくって死んでる模様．
どうもMSCをひな型にしたのは失敗だったみたいです．CDCの方がcodeが簡単なのでCDCに乗り換えようと思っているところ．作っては捨てを延々と繰り返す他にアセンションへの道など無い．
ーーーーーーー
ぎょえーっと思っちゃったネタを２つ挙げとく．
１）Android StudioのLogcatでなぜかLog.d()が表示されない
これねぇ、Huawei端末だけの特殊事情だそうです．アプリの動作速度低下防止のため、HuaweiのOSがLog.d()を抑圧している．解除するには、、、 →こちら
*#*#2846579#*#* にダイアルすると謎の設定画面が出るんです．グラディウスかこのヤローと端末をぶん投げたくなりました．上上下下左右......
２）Androidスマホのデバッガwifi接続
wifiデバッグといえばAndroid11．
この投稿でAndroid11を入手したのですが、作業服のポケットに入れたまま洗濯してしまってお陀仏にしちゃいました．仕方なくAndroid7のHuaweiスマホを使ってデバッグしています．
デバッガwifi接続はAndroid11じゃないとダメというのは間違いで、11より古いOSでも面倒くさいけどwifiデバッグできます．まぁwifiデバッグはいつも調子が悪く、すぐに接続が切れるので使いづらいのですが、今回はOS7ということでOS11よりもトラブルが多発しました．
トラブル回避するためのwifiデバッグ接続手順（OS10以前）
０）adbのpathを通しておく
わたしのwindowsではこんな辺鄙な場所がAndroid SDKのインスト場所です．
C:\Users\hira\AppData\Local\Android\Sdk
１）スマホの設定画面→スリープ無しにできればする．できなければ10分とか長くする
２）スマホの開発者向けオプションにて
・USBデバッグ
・スリープモードにしない
・充電専用モードでADBデバッグを許可
３）USBケーブルでhostマシンと接続する、デバッグダイアログが出るかもしんない
４）hostマシンとスマホを同じWIFI APへ接続する
スマホのwifi設定画面でIPアドレスをメモっておく
５）windowsなら管理者モードでpowershellを起動
６）shellでコマンドを打つ
ping 192.168.10.104 ←スマホのIP
adb kill-server
adb start-server
adb emu kill ←へんなemulatorが残ってることがあるため
adb usb
adb tcpip 5555 ①
adb connect 192.168.10.104 ②
adb devices
７）USBケーブルを抜いてOK
８）せっかく接続できたとしても、スマホがスリープに入ると切れてしまうので、USBケーブルを再度接続し、６からやり直す
①でこうゆう表示が出ればOK
restarting in TCP mode port: 5555
②でこうゆう表示が出たらOK
connected to 192.168.10.104:5555
失敗すると②でこんな表示が出ます．うぜー
cannot connect to 192.168.10.104:5555: 接続済みの呼び出し先が一定の時間を過ぎても正しく応答しなかったため、接続できませ んでした。または接続済みのホストが応答しなかったため、確立された接続は失敗しました。
その時は①と②をやり直すと接続できるケースが多いです．（100%とは言えない）
かしこ
スリープモードになるとWifiのpingにさえ応答しなくなるのは困りますが、スマホがスリープモードになれないのも困るでしょうから、しょうがないのでしょうね。Bluetoothはスリープモードでも少なくともl2pingに応答するので、BluetoothでSDKが動けば接続エラーがなくなるのではないでしょうか。l2pingは実験済みですが、SDKは未経験です。想像ですいません。
返信削除l2pingって初耳でした．
削除BTデバッグでも使えればなんでもいいので誰か作ってくれたらうれぴーです．
>*#*#2846579#*#* にダイアルすると謎の設定画面が出る
返信削除Androidって、何だか知りませんが、こういう
「謎番号に電話する」と、裏画面が出てくる
って仕様が多いですよね。（ネットで検索すると、色々出てくる。「電波の強さ」を、リアルタイムに表示する画面とかもある。）
※私は初めて買ったスマホが「中華スマホ」（中国出張の時に、現地で買った奴。もちろん、日本に帰っても使えるように、日本バンドにも対応した奴を買いましたが。）で、
これは基本メニューが「中国語」だったのですが、それを日本で使えるようにいろいろ設定（Android自体は、元々インターナショナル仕様(文字コードはユニコードだし)なので、フォントの設定とかするだけで、日本語の表示自体はできる。）してた時に知りました。
つか、Androidは、実は「カーネルはlinuxそのもの」なので、linuxも動かす気になれば動きますが。
＞「謎番号に電話する」と、裏画面が出てくる
削除あそうなんですか、こうゆうのって初耳でした．
libusbがスマホで動いたらそれでもいいですがね．
それはさておきグラディウス.....
そういう意味では、Androidって、
削除「Java VM を、効率的に動かすことに特化した linux」
と、言えるかもしれません。「VM」なのは、セキュリティを重視してるからです。
「サンドボックス」を、作りたいからというか。
>libusb
は、動かないんじゃないかな・・・レイヤーが変えられてるような気がする。
linux カーネルといっても、いわば「超魔改造カーネル」なので、「ふつーのライブラリ」は、動かないんじゃないかな？
adb コマンドなんて、要は「魔改造ssh」みたいな感じだし。
「a kind of 組み込みlinux」なんでしょうね。PC-linux とは違って、ホントに
削除「必要な機能しかない」カーネルって感じ。
※もちろん、カーネル自体は「ソース公開」されてるから、自分で機能を組み込めば出来るハズですが・・・そこまでやるか？という感じ。
元のkernelやライブラリを削除しただけでは知恵が足りないんでしょうね．消費電力も下げなくちゃいけないし．
削除家電にもLinuxはいろいろ使われていて、Linux作った人にはノーベル賞をあげてもいい．
グラディウス....
>家電にもLinuxはいろいろ使われていて
削除我が家は、ケーブルテレビなんですが、それの STB（Set Top Box）は、Help をみると、しっかり 「linux は、云々(もちろん英語ですが)」とか、書いてあったような。
>Linux作った人にはノーベル賞
「ノーベル賞」には、工学部門がないから無理ですね。
（コンピュータサイエンスとかなら、ノーベル賞はアリだと思いますが、そういうのとも違うからなぁ・・・）
まぁでも、リーナス・トーバルズ（まさに、Linux作った人）は、もう既にいろんな賞を受けてるんだよね。
身の回りの製品の中身はLinux kernelだらけかなぁ
削除じゃぁノーベル平和賞で.....
ってICBMにもLinux載ってるでしょうね、げすー