blog画像が表示されないページは、元画像を間違えて削除してしまっているためです。データが残っていないので、想像力で補ってください。SDKドキュメントのシーケンスいつも探してしまうので、メモを残す。SDKドキュメントにアプリとSoftDeviceのシーケンス図がある。ここ、とか、ここ、とか。以前は、ページだけでシーケンス図が載ってない時代もあったんだけど、さっき見た限りでは大丈夫そうだ。アプリとSoftDeviceの図ではあるのだが、PEERというライフラインが出てきているので、これで無線のシーケンスもある程度は意識できるかもしれん。普通の勉強をしてからですな。v8.0になって、また仕様が変わる久々にnRF51822を触ろうと思い、まずはSoftDeviceをv8にした。SDKもv8.0にしたのだが、以前作っていたアプリにmakeが通らない。今見つけたエラーは、APP_TIMER_INIT()というマクロ。引数が4つあるんだけど、4番目の仕様が変更になったみたいでね。以前まではboolで、スケジューラを使うかどうかという選択だったものが、今回からスケジューラのイベントハンドラを指定するようになったのだ。スケジューラを使う場合は、includeするのがapp_timer_appsh.hになって、APP_TIMER_APPSH_INIT()というマクロになるっぽい。ボタンの初期化はAPP_BUTTON_INIT()だったけど、こっちは定義すらない。app_button_init()のコメントにはマクロを使えって書いてあるのに・・・。サンプルではbspにあるものを使っていて、見るとapp_button_init()を呼び出していた。うん、なるべく最新を追っていこうと思っていたけど、もう限界だ。うちのチップではSDKがv6.1.0まで(SoftDeviceはv7.0.0)ってなってることもあるし、今回は見送ろう。SDKはv7.2.0、SoftDeviceはv7.1.0にしておこう。最新版を見送るって、なんか勇気がいるのよね。nRF512015/03/29[mbed]PublishしてみたmbedにLCDを挿したとき、ライブラリがあったのでimportし、すぐに使えた。私も、RC-S730のライブラリをimportできるようにしておこうと考えた。これは「Publish」というメニューからできるようだ。コミットしてなければ、commitを求められる。次にPublishのダイアログが出てくるので、適当に埋めればおしまい。http://developer.mbed.org/users/hiro99ma/code/RCS730/Publicも2種類あって、Activityの欄に出てくるPublicと、出てこないPublic(unlist)。英語で書いてみたんだけど、まあ、単語が並んでたらわかるだろうレベルでやっている。Docs」というのがあって、それやると出てきた。出てきたけど、中身が空っぽで・・・。Doxygen形式にするんだけど、classに対してbriefに相当するものを書かないとまったく出てこないようだ。やって見ると、コールバックが不親切だな。Linkが返すデータ形式を呼び出し側でわかってないとうまくいかないようになっている。改良の余地はあるけど、ドキュメント見ながらじゃないと使わないだろう、とか思ってしまい、このままになっている。Linkのライブラリをmbedで作っていたのだけど、ちょっとバグっていた。はて、mbedのデバッグってどうやるんだろう?あまり深く考えず、ProgramをKeil形式でエクスポートし、Keil5で開いた。Keil4形式のプロジェクトだったためか警告が出たが、開ける。ビルドするとヘッダでエラーが出たが(SPI関係のマクロがないとか)、使ってないのでコメントアウト。そのままデバッグモードにすると、あっさりデバッグできた。ブレークポイントにも止まるし、ウォッチもできる。そんなわけで、特にデバッグについて注意するようなことはなかった。Linkの読み書き時I2Cパケット前回「動いた」と記事にはしたのだが、それだけだと味気がないので波形を取った。それを全部載せるとわかりにくくなるので、ロジアナにパケットだけを抜き出してくれる機能があったから、それを使ってみた。うちのロジアナはZeroPlusのLAP-Cだ。Encryptionを行っている。以下で、簡単に説明をしていく。FT転送設定」を参照しながら読んでいただくとよろしいか。IRQの立ち下がりをトリガにしてキャプチャしている。Linkのデフォルト状態ではIRQ割込設定(割込マスクレジスタ)は全部マスクしてあるので、どこかで許可させる必要がある。マスク設定はNon-Volatileで保持されるので、一度変更しておけばよい。外すマスクは、ユーザマニュアルの推奨に合わせてint_tag_rw_rx_done2にした。作ったソフトでは、mbedの起動時にPlugモードへの変更(動作モード設定レジスタ)とマスクの設定を行い、IRQ待ちにしている。Encryptionを行っている。Androidとかで試すと準備がいらなくてよいのだが、どういうアクセスの仕方をされるかわからないので、Windowsで作ったアプリを使ってアクセスさせた。IRQ割込が来たときには、既にメモリの0x0C00から読み込んだデータが入っているので、それを読込む。割込み要因を調べるため、割込ステータスレジスタ(0x0B28)を4byte読込んでいる。レジスタアクセスは、アドレスはビッグエンディアンで書込み、レジスタ値はリトルエンディアン(4byte)になっている。よってここでは、0x00000008が読み込めたことになる。int_tag_rw_rx_done2での割込だったことがわかるので、ようやく0x0C00のデータを読みにいく。ここでは、まず12byte読込み、まだ読込む必要があれば再度読込みにいっている。・・・なんだこの12byteって・・・。返信するときのデータ長が最短でも12byteになるから、それと間違えているな。R/Wから来るデータの最短は16byteになるので、あとで修正しておこう。APIを使っているからこういう書き方にしたが、自分でI2C含めて書くのだったら、最初の1byteでLENを取って、あとはLEN-1回回すような作りにするだろうな。ブロックリストは、本来2byteタイプと3byteタイプがあるのだが、R/W側のアプリは2byteタイプでしかアクセスしに来ないので、割り切って作っている。レスポンスデータも、同じく0x0C00に書込むことになっている。Linkが自動で作成することになっているので、ここでは変更が必要なところしか書き換えていない。ブロックデータ)が必要な箇所になる。Linkにそのことを通知(タグモード送信制御レジスタ)のtag_rf_send_enableに1を立てて書込む。LinkはR/Wにレスポンスを返してくれる。最後に、割込クリアレジスタに書込んで、割り込み要因を消している。この動作が必要かどうかは調べてないのだが、わざわざ用意しているくらいだからやるんだろう。IRQ端子の説明としても、マスクされていない割込が1つ以上発生している場合、となっている。このレジスタに書込んでから25usecくらい後にIRQ=Hになっているから、やるのかな。Encryptionの場合は、こんな感じ。スレーブアドレス0x3Eはデバッグで使っているLCDなので、気にしないでおくれ。ここには出てこないが、RFDETは特に使っていない。割込はさせてるけど、それでLEDを点灯させている程度だ。F411RE)で動かす件。先ほどようやく、PlugモードでPaSoRiから1ブロックだけ読み出すことができた。Linkの部分は、自分の実装ミス以外は悩むところがなかった。なんというか、仕様書通りに作ったら、仕様書通りに動いた、というところ。動かなかったのは、自分の実装ミスだ。なんだけど、mbedのI2Cインターフェースも反省すべき点はあると思う、うん。Write"というのがあり、書込み先のアドレスを指定したら、あとは書込みたい分だけ書く、という使い方だ。mbedのI2Cインターフェースは書き込みについては2つあって、1つはスレーブアドレスとバッファとサイズを指定して、一気に書込むAPI(API1と呼ぶ)。1つは、最後に書いた続きから1byte書込むAPI(API2と呼ぶ)。私はメモリ確保を端折るため、書込み先アドレス指定をAPI1、書き込むデータをAPI2でぐるぐる回すような実装にしていた。それはよいのだけど、API1とAPI2で戻り値が異なることに気付いてなかった。API1は成功すると0、API2はACKが返ってくると1。・・・想像がついたと思うけど、私はAPI2も成功が0と思って実装し、うまく書き込めてなかったのだ。API2の戻りはACK受信時に0でもよかったと思うのだ。Linkの扱いは思ったよりも楽だということがわかった。LinkにはLite-S/FTモードがあるので、既存のメモリを生かしつつ、拡張したいところだけThroughでやる、なんてことも考えられそうだ。Linkを使ってみよう!・・・使ってみようよぅ、みんな。Payとかと絡めないと触手が伸びないのか。なんとなく、少々のR/Wだと読めそうな気がしないのだが、iPhone6は持ってないからわからんな。15年くらい使っていた腕時計が動かなくなったので、買い替えたいとは思っている。思っているんだけど、せめて10年くらいは電池交換とか無しで動いてくれないとなぁ。よいことだが、mbedのプロジェクトをZIP形式で落としてくると、.hgフォルダがある。gitとかじゃなくて、mercurialなんだな。launchpadにあったnfcpyを落としてきたときがそうだったので気付いた。生き残っているから、よい点があるのだろうね。2であることがわかった。Matrixのドキュメントに、SDKやSoftDeviceのバージョンも含めた表が載っていた。それによると、SoftDeviceのS130がハイフンになってる。SDKが6.1.0までしか入っていないように見える。うそ・・・私のnRF51822、古すぎ?Nordicのところでは、これが一番近いのか。Zone今のところ大丈夫だ、みたいなところかな?でも、Nordicの人からの見解じゃなさそうなので、気になる。「動くとは思うけど、動かなかったとしても文句言わないでね」といところか。チップのリビジョンを上げられればよいのだが、そういうもんじゃないだろう。変化が早いとユーザが付いていかなくなる気がするから、そろそろ落ち着いてくれないかなぁ。F411REというボードがある。ARMで、開発環境がオンラインにあって、くらいの知識で購入。ついでに、こんなのも買った。スイッチサイエンスLANとかは得意ではないのだが、この時代で好き嫌いもいってられない。つなげてから考えよう、とNUCLEOのピンを見たのだが、イーサネットっぽいピンがない。あ、あれ、mbedって名前だったらピン配置とかに互換が合ったりするものじゃないの?じゃないのだ。mbedのPlatformページで検索できるのだが、Ethernetがそのままつながる基板というのは今(2015/3/23)のところ6種類しかなかった。mbed安いので、そんなに何でも載ってるはずないよな。W5200というシールドを使えばつなげられるらしい。mbedもうちょっと調べると、W5200というのはWIZnet社のチップで、シールドの名前ではないようだ。いうのでもよいかもしれん。スイッチサイエンスしかし、ここまで来ると、私ってそんなにネットにつなぎたい人だったっけ、と自問してしまう。今回は「あの葡萄はきっと酸っぱいんだ」ということで、見送ることにした。mbed2015/03/22[nrf51]HWIDの取得方法nRF51822は、チップのリビジョンによってドキュメントを読み分ける場合がある。3というリビジョンがある。チップの外観からもわかるようではあるが、ものによってはカバーがあったりして見えないかもしれない(うちのがそう)。するかというと、メモリを読むことでわかるそうだ。Zoneうちのは、こうだった。AAで、Dx0で、WLCSPで、FLASHが256kB、RAMが16kBとのこと。リファレンスマニュアルを見ると、読んだアドレスはCONFIGIDというレジスタのようだ。どのリファレンスマニュアルを読むとよいかを調べるためにHWIDを知りたかったのだが、たぶんこのアドレスはリビジョンが変わっても共通なんだろう。Linkを扱いだしている。Lite-Sモードとか、Plugモードとか、いろいろある。インターフェースがI2Cになったこともあり、扱いはやりやすい。その中で、というか、以前からというか、NFCの中で扱いに迷っているのが、NFC-DEPだ。大ざっぱに言えば、以前からある大きめのデータ転送がISO-DEPで、そこからちょっと新しく加わったのがNFC-DEP。いや、それも大ざっぱに表現できてないな。いま流行り(?)のHCE、特にAndroidのHCEは、Type-Aベースだ。Type-Aのうち、ISO/IEC-7816を使っていて、そのDEPがISO-DEP(名称をまちまちで書いているのは我慢しておくれ)。DESFireとかはISO/IEC-7816ベース(メモリの使い方)、かつISO/IEC-14443のType-Aベース(無線)。14443、というところだろう。端末同士でInitiatorとTargetの役割が確定していない場合は、DEPのように役割を動的に決めるしくみがいるだろう。paymentの場合、お金を要求する方がInitiator、お金を払う方がTargetという役割は変わらないだろう。DEPを拡張させるのではなく、CardEmulationを拡張させる方向になったのだろう。今のNFC-DEP(=LLCP=SNEP)でやってるところも、「お金」を「コンテンツ」と言い換えれば、別にDEPでやらなくても対応できそうに思う。NFC-DEPはやることの内容からすると、実装コストが高いように思っている。そんなわけで、NFC-DEPの実装はやめておこうかと思っていたけど、気になるレジスタがあったので、ちょっと迷っている。Linkで遊んでいる人がいるといいんだけどなぁ。nfc2015/03/21[c/c++]enumの符号mbedでソースを書いているのだが、引数がenumで、一応範囲チェックをしようとした。-1;}・・・そうすると、「kumaは0より小さくなることはない」みたいな警告が出てくる。Overflow整数型ではあるが、符号についてはコンパイラ依存とのこと。ほほぅ、そうだったのか。ARMのコンパイラ(armccかな?)では、一番小さい符号型にあわせられるらしい。Boxにインストールしてみた。エクスプローラと設定で、アクティブなウィンドウバーの色が違うんだな。エクスプローラというか、普通のアプリが色つきか。設定というか、ストアアプリだっけ、あのタイプもウィンドウで表示されるようだけど、あれには色がないようだ。スタートボタンを押すとこんな画面になる。右側の広いところには、もともとWindows8のスタート画面みたいなタイルが出てた(全部消したが)。Shellみたいなのを使うことになるんだろうな。Linkの件をいろいろ考えたが、現状でよいような気がしている。現状でどうやっているかの記録を残しておこう。Linkの回路LIBはここに置いてみました。見えるかな?mbedのライブラリはこんな感じで作った。ロジアナで記録したのは、これらの関数。「RETRY_NUM」は5だ。プログラムは、ByteWrite()→RandamRead()の順で呼んだだけ。メモリアドレスは0x01、書込む値は0x41だ。ret;}まず、書く。何回か波形を取ったが、1回だけリトライ4回目で成功、それ以外は3回目で成功だった。書いた直後に読もうとしているので、書き込み完了までの間はACKポーリングになってる。いうわけで、初回アクセスできるまでのところ以外は、意図した通りに動作しているようだ。稼動になるまでのNACKも、もうACKポーリングの一環とみなしてしまおうか、という気になっている。I2Cでアクセスしたいのは、通常はメモリを読み書きしたいときか、ホストスルーでのアクセス時くらいしかない。メモリをホストから読み書きするのは、リトライでカバーする。ホストスルーの場合は無線経由で稼動状態になるので、ホスト側でカバーする必要が無い。ホストからメモリアクセスするのは、そうそう頻繁にやるものではない(用途に因るだろうけど)ので、時間にシビアなシーンが発生しにくいとみなすと、まあ、困るものでもないんじゃないだろうか。Linkが出たりしたら、また考えましょうかね。nfc[mbed]NUCLEOにバニラシールドを載せるSTMのNUCLEOは、Arduino互換のピン配置になっているとのこと。バニラシールドが載せられるかも、と思い、スイッチサイエンスさんから買って載せてみた。足の長いコネクタもセットで購入している。横から見ると、こんな具合(まだ基板とコネクタはハンダ付けしていない)。ハンダ付けしてないので、基板とスイッチが当たってるけど、基板とコネクタを密着させてからハンダ付けすれば当たらないくらいのスペースがある。気になるなら、スイッチのキャップを取るのもよいだろう。基板の前後をひっくり返したらよいのでは?と思ってやってみたが、コネクタの配置間隔が右と左で違うので、全部のピンを有効にしつつひっくり返すのは無理そうだ。そこまでしてボタンが使いたいなら、基板を切ってしまう方がよいかも。ユニバーサル基板って、切るのが大変だったから、私はそこまでやらない。LinkとのI2C通信がうまくいかず、スレーブアドレス書き込み後にACKが返ってきていない。待ち時間がどこか足りていないのではないかということで情報を集めていると「リトライするとよいのでは」ということで試し、書き込みができた。SDA="L"の時間を長くしてもうまくいかないことに対して納得がいっていない私であった。チップを使う立場からすると、リトライするにせよ時間を長く取るにせよ、根拠がいる。その根拠から外れた動作をする場合は「異常系」の処理を行うだけなのだが、その判断ができないのだ。Plugなんかは時間のことがきっちり書いてあったので使いやすかったのだけど、今回はうーん・・・。今気にしているのは、チップがI2C通信を受け付けるようになるまでのやり方を、ドキュメント通りにやっているつもりなのにうまくいっていない、というところだ。Linkのドキュメントには時間のことが書かれていないのだろう?ここの仮説4で、SDA=Lにしてから~、と書いている箇所だ。電源オフ→(VDD投入)→スタンバイ→(SDA=L)→初期化→(時間??)→稼動となっていると私は仕様を読んだ。(知りたかった時間というのは、初期化から稼動に至るまでの時間だ。)SDA=Lを長くしてもダメで、リトライするとよかった。そこだけ見ると、仕様書の記載が間違っているんじゃないか?と思ってしまうのだが、もう少し落ち着いてみよう。本当に私はSDA=Lにできていたのだろうか?ロジアナ上ではLに見えている。Linkがその電圧をLと見ているかどうかは別の問題だ。そこを調べるにはオシロスコープくらいしか思いつかない。マルチメーター、特にうちにあるような安物だと無理そうな気がする(オシロもないけど)。SDA=Lにできていないなら、リトライでうまくいくということの説明が付かないのだけど、スタートコンディションのためにLにしたのと、ストップなり異常検知などでLにするのは別なのかもしれない。mbedベースの基板で試すには重たい内容だったか・・・。嘆いても仕方ないので、どうやるとリトライせずにきれいにアクセスできるかを調べますかね。Linkの電源状態が稼働状態にまだなっていないのではないか、という感じになってきた。SDA=Lにしてから10msecも待ったのに・・・。んじゃあ、20msecにしてやってみるか。リトライもしてみよう。んあ??ACKが返ってきた??その後の書込みがおかしいのは、まあソフト要因だからよいとして、ACKが返ってきたのだ!でも、20msecで一度スレーブアドレスを書き込み、そこで失敗して815usecくらい待ってからリトライして成功したのか。初期化状態から稼働状態までの待ち時間が20msecでも足りないってこと???気になったので、時間を10msecにだけしたアプリにしてみた。前回失敗したときとの違いはリトライをするかどうかだけだ。1回目に失敗して、やっぱり815usecくらい後で成功している。このロジアナ波形は、A2がSDAで、開始トリガはA2の立ち下がりエッジだ。スタンバイから初期化になるトリガは、本当にSDA="L"だけなのだろうか?いや、もちろんVDDが供給されるとかあるんだろうけど、SDA="L"だけだったら待ち時間を10msecにした場合には815usecがもっと長くなってから成功しないとつじつまが合わないように思う。私のハードウェア構成がよろしくないか。SDA="L"になっている時間を延ばす作戦はやめて、リトライ回数を増やすことにした。増やす、といってもどのくらいの時間が妥当かわからないので、無限繰り返しにした。・・・これだと、2msec以内にはうまくいったことになる。やって見ると、SDA="L"だけじゃなくて、SDAとかSCLがある程度ぱたぱた動くというところにも条件がありそうに見えた。なんか、私が知っているI2Cデバイスとは異なる動きをするので、正直なところどうしてよいかわからない。時間について記載が無いチップというのは、ちょっと使うのには厳しいなあ。5)やWindows環境のMakefileから焼けるようになったそうだ。Windows環境なのは、nrfjprog.exeというツールを使っているかららしい。Studioを今後はメンテしなくなる方針ということだろうか?まあ、今のところSoftDeviceを焼くか、UUIDを生成してもらうのにしか使ってないのだけど。LinkのNACKから抜け出せない。1bitが立ち下がらないだけなのに、うぅ・・・。あてずっぽうにやるのも疲れてきたので、いくつか仮説を立てることにした。ハンダ付けがうまくいってなくて、チップまで届いていないピンが実は逆順になっていたロジアナに吸い取られている時間が足りてないチップが壊れている仮説1テスターでチェックしたが、大丈夫そうだ。仮説2RFDETは思っていたピンで応答していたので、大丈夫そうだ。仮説3ロジアナを外してやってみたが、変わらず。R/Wで読み取れば動いたかどうかわかるのだ。仮説4VDDが供給されてからチップが動くまでに時間がかかるのでは?と5秒くらい待たせてみたが、変わらず。SDA=Lになってから初期化が始まり、初期化が完了して稼働状態にならないと有線インターフェースからのコマンドは受信できないそうだ。誤記修正)の状態を10msecほど作り出すようにしたけど、変わらない。Linkが1枚しかないので、先ほどスイッチサイエンスさんに注文しました・・・。無駄になりませぬよう。ユーザーズマニュアルにもスターターマニュアルにも時間の情報が見つけられない。これ以外で関係しそうなのは「RC-S967/1Vデータシート」というドキュメントなのだが、これは特約店から提供されるタイプらしい。スイッチサイエンスさんに、ご提供いただけるかどうか確認してみよう。LinkからACKが来ないmbedが来て、早2週間。うちに新しいマイコンが来たら、何かFeliCa関係のデバイスを動かすのがルールになっている。・・・というわけではないのだが、それなりに通信させる確認ができるので、RC-S620/SとかRC-S802とかを動かしていた。LinkであるRC-S730を動かすことに決めた。LinkはI2Cでの接続になっている。変形じゃないので、mbedのI2Cをそのまま使えばよいだろう。LCDのST7032iが動いたから、そんなに難しくないはず。はずだったのだが、スレーブアドレス書込み後のACKが返ってこない。以前の反省を元に、プルアップ抵抗の値をいくつか変えてみたのだが、変わらず。心配なのが、しばらくプルアップするピンを間違えてて、GNDに接続していたこと。RFDETは反応するんだけど、これは搬送波に合わせて脊髄反射的に動いているだけのような気がする。Linkに載っているチップ)が生きているかの判断ができそうにない。なんとなく大丈夫な気はするんだけど、私のハードウェアに関する判断は当てにならないしなぁ。Linkを買うことにした。この前は、どうにもわからずにロジアナを注文したら来る前に解決したのだが、今回はどうなることやら。Linkはもう1枚あってもよいかと思っていたので、割り切ろう。nfc[win8]ロジアナZeroplusのドライバインストールうちには、ロジアナとしてZeroplusのLAP-C(16064)がある。Windows7で使っていて問題ないのだが、Windows8だとインストール時にドライバが入らないという問題がある。Windows8ではあまり使っていないとはいえ、使えるに越したことはないのでバージョンアップで対応されないかな-、と思っていたのだが、最近FAQを見ると「こうやってね」と書いてあることに気付いた。Analyzers-Zeroplus手動でやってくれ、ということらしい。above)」とあるから、今後も対応する気はなさそうだ。windows2015/03/14[mbed]ST7032iを動かすせっかくNUCLEO-F411REを買ったので、mbedっぽく使ってみたい。I2Cデバイスを動かそう、ということで、以前買っていたST7032iをつなぐことにした。I2CのドライバはAPIがあるのはわかっていたので、uITRONで作っていた初期化とかを移植するか。思っていたら、mbed用のライブラリが既に作られていた。mbedこれが・・・mbedの威力か。結果的に、1時間程度で動かすことができた。その1時間も、程よい抵抗器を探したり、ブレッドボードにどうやって配置しようか悩んだり、SDAとSCLを逆にしててロジアナで波形取ったりとかいう時間がほとんどだ。記念なので、接続したときの写真を載せておこう(動かしたときの写真じゃない)。今回のプルアップ抵抗は、4.7kΩにした。I2Cの最初のアクセスも載せておこう。I2Cの仕様としては、アドレスは7bitだ。I2Cマスターが送信するときは、アドレス7bitに続けて、1bitのRead(1)/Write(0)情報を載せる。ライブラリで提供されているとき、指定するアドレスが7bitのものにするのか、Read/Write情報まで含めた8bitのものにするのか、あるいはRead/Write情報をライブラリ側でORすればいいように8bitのものにするのかは、調べた方がよいだろう。mbedの場合は2番目のパターンになるようだ。私はストロベリーリナックスさんから購入したのだが、今はスイッチサイエンスさんからも出てるみたいだ。スイッチサイエンスArduinoは直接挿せるようだけど、ピンとしてはアナログのA1~A5に挿す想定のようだ。NUCLEOで同じことができるかわからない。ストロベリーリナックスさんのHW構成(コンデンサ内蔵)に加えて、スイッチサイエンスさんのはI2Cのプルアップ抵抗も取り付けてあるので、そのまま接続するだけで使えそうなのが良いですな。toolchainmbedのプロジェクトはオンラインでやれるようなのだが、オフラインでもビルドできる、というのを読んだことがあった。これはオフライン版SDKをインストールして、使われているコンパイラを引っこ抜くとARM純正の環境が作れるのでは、ふふふふ、と思っていた。そんなことはなく、オンラインで作ったプロジェクトをエクスポートできるということだった。残念だが、まあそうだろう。いうエクスポートができるのか見てみたら、こんな感じだった。はて、グレーアウトされているのは何だろう?私のPC環境を読み取って、インストールされているものだけを選んでいる、というわけでもないし。Sourceryができないってこともなさそうなんだけどなぁ。mbedこちらを見ると、大きく4タイプのエクスポートができるとみなしているようだ。SourceryもMakefileタイプだろうから、できないわけではないんだろうけど。有償な環境は除外しているのかと思ったけど、それならIARが残っている理由にならない。すると、Nucleoだから、という制約があったりするのかもしれん。今のところMakefileでやるつもりだし、なるべくオンラインでやった方がよさそうなことが書いてあったから、こだわるのはやめておこう。v2からUSBPcapが取り込まれたので、もうちょっと使いやすいです。http://hiro99ma.blogspot.com/2015/11/wireshark20usbpcapti.htmlPaSoRiを自分で制御したい、ということから使い始めたlibusbだが、世の中にはUSB機器が多いのであれこれ応用が効く。デバッグがしたいとなるとUSBパケットそのものを見たくなる。お遊びでやっているのでお金をかけたくはないのだが、はてどうしたものか・・・ということでUSBPcapを使うことにした。USBPcapのよいところは、pcap形式になっているのでWireSharkが使えるところだ。WireSharkではUSBのパケットキャプチャとしてUSBPcapの説明を書いているくらいなのだ。標準でUSBのパケットをある程度解析してくれるようになっている。使ったときはライブキャプチャ、すなわちUSBのパケットをリアルタイムでWireSharkに表示する機能が使えていたのだが、最近はうまくいってなかった。Linuxとかのパイプでつなぐようなバッチファイルを作っていたのだけど、USBPcapが標準出力に吐き出すところと、標準出力からWireSharkで吸い取るところが別々に動いてしまってダメだったのだ。動いていたときからWireSharkのバージョンが上がったからかな?とか思っていたのだが、検索すると以下のサイトで解決されていた。きょうはなに色?コマンドプロンプト自体を管理者権限で起動する、だ。バッチファイルを管理者権限で起動すれば済むんだろうと思っていたのだが、まさにこの方が書かれていた内容が私にもあてはまったのだ。おかげで、作ろうとしていたものが何とかできた。普段だったら、それまでの過程とか調べたことをここに書くのだけど、今回はちょっと毛色が違うので書けないのだ。これでまたBLEの調査に戻れるので、よしとしましょう。Studioだが、前回は「12分まで」と書いたが、もう1つ制約があった。1日5セッションまで、という制限だ。うーん・・・、この制限はちときつい。いまはデバイスのつなぎ初めとかを見たいので、しょっちゅう入り切りしていたのだ。タイミング悪いとPCがブルースクリーンになってしまい、再起動という・・・。そんなわけで、USBPcapとWireSharkで進めることにした。お仕事だったらツールを購入するところなのだけど、お遊びでやってることだし。それに、キーボードのカスタマイズをするのと同じようなもので、どこでも同じ環境を作りやすい方が優先されてしまう。場合によりけりってとこですかね。windows[win]休止状態にならないのはアクティブパーティションがないためだった私はWindows7を主に使っている。週に一回くらいはシャットダウンするが、通常は休止状態で電源を切っている。SSDだと負担がかかってよろしくないような記事を見たことがあるが、うちは普通のHDDだし、まあそこまで目くじらを立てることはなかろう。その休止状態が急に動作しなくなった。いつも寝る前に休止状態にしているのだが、朝起きてもまだ電源が入っていたままだったのだ。なんというか、スリープっぽい状態になっていただけというか。休止状態に入ると復帰するには電源ボタンを押すしかないのだが、今回の状態だとマウスとかキーボードを触ると復帰してしまうのだ。私のイメージでは、休止状態というのは現在動作しているアプリなどのプロセスが使っているRAMをディスクに退避させる技術だ。ほら、RAMが少なかったらディスクにスワップさせるではないか。あれのRAMが0バイトになってしまった版。プラス、プロセスの管理情報とかも一緒に保存して、とにかくRAMのものを全部消してしまっても復元できるようにしてしまう技なんだろうと思っている。私のイメージがどうだろうと、休止状態にならないことには変わりがないが・・・。急にならなくなったのだが、なんとなく思い当たりがあった。週末からUSBのスニファをあれこれ試したりしていたので、そこら辺じゃないか、というものだ。検索すると、USBキーボードが・・・とかでよく出てくるし。今回はそれではなかった。インストールしたスニファもアンインストールし、USBデバイスも外し、スリープから復帰させることができるようにする設定も外したが、現象変わらず。次にそれっぽい情報として、パーティションがアクティブになっていないのがダメだった、というのがあった。いえば、「システム」の「既定のオペレーティングシステム」が何も表示されなくなっているな・・・。いうことで、ディスクの管理からCドライブの先頭パーティションをアクティブ設定にした。したら、休止できるようになった!アクティブなパーティションがなくなったから休止状態になれなくなったのか、というのはわからない。次回、似たようなことが発生した場合の対処として残しておこう。