2015/07/30

[win10]T61にWindows10 Proを入れた

まあ、こういうのは早めがよかろう、ということで、うちのThinkPad T61にWindows10 Proを入れた。

初日は、ずっとマシンを立ち上げておけばダウンロードが始まるかも、と待ってみたのだが、だめだった。
だめだったので忘れようとしたのだが、窓の杜に記事があった。
サイトからダウンロードできるし、DVDにも焼けるとのこと。

ツールをダウンロードして立ち上げると、まあ、記事に書いてあるように進んでいく。
私はDVDを作りたかったので進めていくと、32bit版か、64bit版か、あるいは両方か、という選択が出てきた。
まるで金の斧の罠のようだが、うちには32bitも64bitもマシンがあるので、両方を選んだ。

無事、ISOファイルはできたのだが・・・サイズが大きすぎてDVDに焼けず・・・。
やはり罠だったか・・・。
なお、USBメモリでもやれるそうなので、両方を選びたい人はUSBメモリにするとよいかも。
うちのマシンはUSBメモリで起動できるかどうかわからんし、なによりUSBメモリがそんなにないのだ。

作っている間、念のためにT61のバックアップを取っていた。
Windows8.1が入っていたのだが、あまり開発用で使っていないので、とりあえずバックアップだけした感じだ。
OSに付いていたバックアップ機能を使った(名前が「履歴のなんとか」でわかりづらい)。
バックアップは別HDDに取ったのだが、回復ディスクも作っておきたい。
で、Windows8.1はこれがUSBメモリだけだと・・・。
サイズは小さくてよいだろうと、私が最初に買った128MBのUSBメモリを挿したのだが、512MB以上必要とか何とかで、結局USBメモリをここで1つ消費することになった。
なんだよー。
普段はParagonの無料版バックアップを使っているのだが、そっちにすればよかったか。

 

T61への載せ替えは、特に何もなくできた。
ほぼそのまま残っている(CtrlキーとCapsLockキーの入替は戻されていた)。
ClassicShellを入れていたためか、違いがほとんどわからんかった。
ゴミ箱が四角くなったな、とか、タスクバーの左下にアイコンが2つくらい出てるな、とか。
それらのアイコンは非表示にできるので、そうすると、Windows8.1と見分けが付かないくらいだ。
そうそう、T61には指紋でロック解除する機能があるのだけど、それもそのまま動いている。

前も書いたが、Windows10からはストアアプリもウィンドウで動くようだ。
ただ、それはTrackPointが動かなかった。
設定アプリなんかもストアアプリになったっぽいから、ちょっと嫌だなあ。
(TrackPointの設定でいけるかもしれんが、まあ追々でいいや)

 

メインマシンには、まだまだ先となるだろう。
1年間は無償でアップグレードできるらしいので、まあまだよかろう。

2015/07/29

[お知らせ]欧州連合の法律関係

最近、忙しくて更新できてないのだが、このブログ(Blogger)のお知らせが来ていた。

image

https://support.google.com/blogger/answer/6253244?p=eu_cookies_notice&hl=ja&rd=1

そんなわけで、何か通知が出るかもしれませんが、あしからず。
たぶん、うちのサイトはCookieを有効にしなくても困らないだろうと思います。
Adsenseとかも入れてますが、収入源になってるわけでもないですし。

 

9月末くらいまで忙しく、ほとんど更新できない気がします。
普段だったら、仕事が忙しくても家でやってることで更新したりするのだけど、今は家でも仕事しているので、書くに書けぬのです。
まあ、順調になれば元に戻るでしょう。

2015/07/18

[ble]AndroidのEddystoneValicatorを動かしてみる

 

https://github.com/google/eddystone/tree/master/tools/eddystone-validator

AndroidStudioでビルドさせようとすると「Protocol family unavailable」と出てきた。。。
http://stackoverflow.com/questions/25603439/solved-gradle-project-refresh-failed-protocol-family-unavailable
こちらを見ると、.gradleフォルダを削除して、ファイアウォールの設定を切った、とある。
確かに、プロジェクトを開いたときか何かに、ファイアウォールが接続していいかどうか聞きに来たな。

ファイアウォールを切ると、進んだ。
が、Build Toolの22.0.1がいるよ、ということで、ダウンロードを要求された。
これは自動的にダイアログが出てダウンロードまで進めてくれたので、指示に従った。
そして、正常にビルドできたようだ。

よし、実行だ!

image

えっ・・・。
実物が動いてないとダメなの・・・。
私の期待としては、パケットを入力する画面が出てきて、それに16進数でぺこぺこ入力して「チェック!」みたいなボタンを押すと、そのパケットがEddystoneとして正しいかどうかチェックするツールだったのだが・・・。


ええい、ならばAdvertisingするソフトを作るだけよ!

幸い、nRF52832のサンプルでBeaconを出すものがある。
それを改造しよう。

image

出してみたものの、アプリに反応がない・・・。

あれ?
2番目のAD Typeが0x03じゃなくて、0x14になってる??
Eddystoneの説明では「Service Soliciation」と「Service Data」と書いてあったけど、表の方は「Service UUID」と「Service Data」になってるな。
nRF52 SDK(nRF51もだけど)では、Advertisingするデータはバイナリで詰めるのではなく、構造体のメンバを埋めるようになっている。
なので、メンバのuuids_soliciatedに設定していたのだ。
そうじゃなくて、uuids_completeの方なのか・・・?

image

image

出た!!

なんだよー、本文の方が間違ってるのかよー。

まあ、私の解釈が間違っている可能性もあるので、ここで責めてブーメランのように戻ってくるのは嫌だから、「soliciationじゃなくてcompleteみたいな気がする」にとどめておこう。

 

改造したのが、こちらのソースファイル
Googleドライブだけど、見えなかったらごめんなさい。

[ble?]Eddystone-URL

前回は、Eddystoneの概略を見たので、今回はEddystone-URLのことを調べておこう。

Eddystoneは、Bluetooth SIGの仕様書を参照しているところからもBLEのAdvertisingで使うのがほとんどだと思う。
とはいえ、単なるプロトコルなので、他で使ってもよいのだと思う。
最初に思いついたのは、やはりNFCだ。
NDEFにもURIの仕様があるのだけど、Eddystoneは30byteくらいのデータで表現できるので、もうこれでもいいんじゃないかという気がする。
NDEF-URIも圧縮して小さくするところがあるので、実はEddystoneも同じ構成だったりするのでは?などと興味を抱きつつ、仕様を見てみよう。


うちのサイトは、Googleの短縮URLだとこうなった。

http://hiro99ma.blogspot.com/
   ↓
http://goo.gl/qe8bzJ

これをEddystoneプロトコルにすると、こうなるはず。
「はず」で止まっているのは、確認方法がわかってないからだ。
Varidatorがあるから、こういうので確認するとよいのでしょうな。

image

面白いことに、".com"とか".net/"みたいなものは、0x00~0x0dまでの数字で短縮できるようになっている。
なので、短縮URLにしなくても、短い名前のところならいけるかも(うちのサイトはダメだった)。

 

まだ調べてないけど、Eddystone-URL Configuration Serviceという説明がある。
これは接続するタイプ、つまりBroadcasterじゃなくてPeripheralでだけ使えるものらしい。
Characteristicとか出てきているから、Connectしてから読み出すのだろう。
Advertisingだけじゃないってところが、また特長なのでしょうな。

2015/07/15

[ble?]EddystoneというBeacon

GoogleがEddystoneなるBeacon規格を出したということで、ざっと見てみよう。

https://github.com/google/eddystone/blob/master/protocol-specification.md

 

共通要素

Eddystoneは以下のPDUを持ってないといかん。

  • Service Solicitation(サービス勧誘?)
    • Bluetooth規格書のSupplement(CSSv5):1.10参照
      "Service Solicitation"というのはEddystone専用の言葉じゃなくて、Bluetooth規格に出ている。
      UUIDとして16bit、32bit、128bitがあるのだが、Eddystoneでは0xFEAAという値とのこと。
  • Service UUIDs
    • Bluetooth規格書のSupplement(CSSv5):1.1参照
      本文は"Solicitation"なのだが、表のバイナリ値(AD Type)を見ると0x03なので"«Complete List of 16-bit Service Class UUIDs»"のはず(githubのところにも書いてあった。)。0xFEAAなのは同じ。
  • Service Data(サービスデータ)
    • Bluetooth規格書のSupplement(CSSv5):1.11参照
      サービスと関連したUUIDで、これも16bit、32bit、128bitがある。
      Eddystoneではこれも0xFEAAという値とのこと。
      ただ、この後にURLとかのデータをつけるしくみがあるようだ。

これだけみたい。
そしてService Dataを0xFEAAに続けて書いていくことで、以下のどれかのデータを付加できるらしい。

  • 0x00:Eddystone-UID
  • 0x10:Eddystone-URL
  • 0x20:Eddystone-TLM

付加できるといっても、Advertisingできるデータサイズは小さい。
31byteくらいだったか・・・ちょっとすぐに出てこん。
付加するデータの種別までで12byte使うので、全部で31byteまでだったら残りは19byteだ。

Eddystone-UID

10byteのネームスペースID+6byteのインスタンスID=16byteのUUID。

 

Eddystone-URL

圧縮URL(というのか?)を載せるようだ。
例として「https://goo.gl/Aq18zF」。21byteある。。。
(ちなみに、上はhttps://en.wikipedia.org/wiki/Eddystone_Lighthouseになった)

ソースを見ると、べたっとしたURIじゃなくてエンコードされるような感じもする。
まあ、要確認ですな。
eddystone/UriBeacon.java at master · google/eddystone

 

Eddystone-TLM

なによTLMって!!
バッテリー電圧とか温度とからしい。

 

というところまで読んで、「データの中身はソース見ないとわからんのか・・・」と悲しんだのだが、そんなことはない。
タイトルからリンク先に飛べるようになっていた。
今は読む気力がないので、リンクだけ残しておこう。


iBeaconもそうだけど、データ長が短いのでそんなに難しい仕様ではない。
公の資料なので、誰でも使えるんだろう。
ちょろっと遊んでみたいものですな。

 

以上、よろしくお願いいたします。


後日の調査

2015/07/12

[git]Git Extensionsをインストールするだけではgitflowは使えない

gitの運用で、まだまだお悩み中。

SourceTreeでいいか、と思ったけど、やっぱり重たい。
重たいのはまだよいとして、チェックボックスを押したりしても、処理中を示すような動作をしてくれることが少ない。
なので、なんか余計に待たされ間が強まってしまう。

 

Git Extensionsでもgitflowが便利に使えるようになっているらしいので、そちらも試すことにした。
SourceTreeはgitコマンドとして内蔵かインストール済みのものかを選択できるのだが、Git Extensionsはインストール済みのものを使う。
Puttyなんかは入ってるけど、SourceTreeに入っている方を使うことにした。

動かしてみると、軽い。
このくらいであればストレスは感じないと思う。
プラグインにgitflowも入っているし、これでやろうかしらね。

そう思ってfeatureを開始させようとしたが「git flowなんてコマンドはないよ」と言われる。
そうか・・・Git Extensionsをインストールしても、git flowが自動的に使えるようになるわけじゃないんだ・・・。

なおSourceTreeも、コンソールを開いた場合にはgit flowが使えなかった(内蔵gitでも)。
なんかちょっと違うしくみを使ってるんでしょうな。


Windows · nvie/gitflow Wiki

この通りにやるとよいらしい。
cygwinではないので、MSysGitの方をやればよかった。

  • git://github.com/nvie/gitflow.git」をcloneする。
    インストールし終わったら削除してもよいと思うので、場所はどこでもよい。
  • getopt.exeと、libintl3.dllと、libiconv2.dllを、MSysGitのbinの中に置く。
    うちはWindows7 64bitなので「C:\Program Files (x86)\Git\bin」にコピーした。
    その3ファイルも、SourceTreeのインストールディレクトリの中に入っていたので、そのまま借りてきた。
  • Windowsのコマンドプロンプトを「管理者権限」で起動する。
    管理者権限でやらないと、いろいろ失敗する。
  • cloneしたgitflowのフォルダまでcdコマンドなどで移動する。
  • コマンドプロンプトで実行
    contrib\msysgit-install.cmd "c:\Program Files (x86)\Git"
  • おしまい

さて、再びGit ExtensionsのプラグインでGitFlowをやってみる。
Start branchでfeatureを選び、適当に名前を入れて「Start!」ボタンを押すと・・・うん、うまくいったようだ。
一番下のボタンがなんなのか化けてるか何かでわからないけど、マウスを当てると「exit code:0」になってるから成功したのだろう(英語ならちゃんと出るかと思ったが、そういうわけではなさそうだ)。


軽くてエクスプローラのコンテキストメニューからも使えるのでよさそうだけど、これをプロジェクト全員に周知できるだろうか・・・。
日本語で説明できるならまだ対応できるが、英語の人にうまく伝えられるか自信がない・・・。
それに、プロジェクト管理者ってわけでもないので、なんか強制して使ってもらうのには抵抗があるのだ。
高飛車に「gitくらい使えないと!」じゃなくて、なるべく低姿勢で「これを使ってください」だろうし、「こうこうすればうまくいきますよ」程度じゃないとうまくやっていけないだろう。

なので「SourceTreeもあるけど、重たいようであればGit Extensionsもあって、こうすればGit Flowが使えますよ」まで持っていかないといかんな。

2015/07/08

[nrf52]GCCでビルドし、eclipseで焼く

しばらく忙しくて、ブログはおろかBLEやらNFCもできなくなりそうなので、記憶が甦られるようにメモを残しておこう。

nRF52832+nRF52 SDKを、GCCでビルドするのだ。


まず、GCCコンパイラの場所を指定する。パスなどは自分の環境に合わせる。
components/toolchain/gcc/Makefile.windows

image

 

ビルドは、cygwinでやった。他のでもmakeが通れば使えるんじゃなかろうか。
make debugがなくて、リリース用のビルドしかなさそう。
eclipseでブレークポイントには止まるのだけど、ソースは見えなかった。

 

そのeclipse。
プロジェクトは、Importで読込ませた。

image

 

デバッグの設定は、nRF51822のと同じ感じでやった。
GDB SEGGER J-Link Debuggingを選んだ。これはプラグインだったと思う。

image

赤いところには、SEGGERなのか何なのかわからないけど、nRF52 Preview DKの白いシールが貼ってあるマイコンの下に書かれている数字。
Device nameは「nRF52」なのだが、新しいバージョンのJ-Linkじゃないとダメだった。
私は、5.00gが最新だったので、それを使った。

eclipseで、J-Linkの場所は環境変数に設定しているので、こんな感じでパスを指定。

image

 

そしてデバッグを開始すると、mainで止まったっぽい感じ(でもソース見えない)になって、緑三角で開始するとAdvertisingが始まった。

 

一度makeなりeclipseなりの環境を作ると、あとは複製するなりして動かせるから、覚えないですな。。

2015/07/04

[nrf51]RTX ? (2)

自分でRTXをビルドせずとも、nRF51 SDKのサンプルにRTXで動くものが入っていた。
nRF51422向けだが、まあ大丈夫だろう。

ビルドしてみる前に、ソースの差分を見てみる。
ble_app_hrsと、ble_app_hrs_rtxのmain.cだ。
だいたいこんな感じだ。

  • タイマは、OSのしくみを使う
  • SoftDeviceからのBLEイベント通知は、メッセージボックスに詰めて投げるだけ。
    処理はble_stack_thread()というスレッド(uITRONでいうところのタスク)で行う。
  • sd_app_evt_wait()は、osDelay(1000)に置き換えられている

sd_app_evt_wait()は、SoftDeviceなしだとWFEみたいだが、SoftDeviceありだとSVCALLしている。
何か秘密があるんじゃないかと思ったんだけど・・・。
なんか、ちょっと納得がいってない。

RTXのosDelay()をたどると、__svcDelay()を呼んでいた。
svcDelay()という関数はあるのだが・・・。
こんな記載があり、マクロマクロして、SVCに変換されるようだ。

SVC_1_1(svcDelay,・・・・)

この辺が、nRF51 SDKがRTXをサポートしているという意味なのか。
でも、それだったら1秒じゃなくて、もっと長くすればいいのにという気もするが・・・何か違うのか・・・。

SVCはSoftDeviceと共有と書いてある。
だから、上記リンク先の表でも、RTXよりもS110の方が動作までに多くクロック数がかかるようになっているのだろう。
しかし、Application SVC interruptはS110の方が速くなっていて、何か腑に落ちない。
私がSVCをまだ理解できてないせいかもしれないので、本を読んでみよう。

[nrf51]RTX ? (1)

「ふふ、nRF51822には標準で使われるRTOSはなさそうだ。ここは私がTOPPERS/SSPを移植して、マイナー技術サイトから脱却するぜ」と思っていたかどうかは知らないが、TOPPERS/SSP周りを調べていた。

今朝、SWI0~5について調べていると、RTOSのことが出てきた。
いくつかOSが移植されているのは知っていたが、有名なものはないはず・・・
ん、ARM??

RTX Real-Time Operating System

いや、ARMがサイコーとか、そういうつもりはないのだが、IPの本家が出してきたとなると無視できない。
CMSISって、最初は評判がよくなかったような記憶があったので、全然気にしていなかったのだ。
そういう間に、世の中って動いていくのだね。

 

まずは、動かしてみよう。
ネットで情報が見つからなかったので、適当にやってみる。

まず、Keil v5を立ち上げよう。
どこかでソースだけダウンロードできるのかと思ったのだが、上記リンクの一番下に「MDKの全editionにソースがある」となっていたから、他ではダウンロードできないのだろう。

新規でプロジェクトを作って、nRF51822を選択。
次に進めると、こういうダイアログが出てきた。

image

まず、Keil RTXにチェックを入れる。
そうすると、左下のValidation Outputに「これが足りない」みたいな警告が出てくる。
それに全部チェックし、s110にもチェックすると、また警告が出てきたので、全部にチェックする。
OKをすると、こういうプロジェクトができた。

image

何も考えず、そのままビルドすると、エラーが2つ出た。
お楽しみはこれからってところですかね。


nRF51822で検索していたから見つけられなかったのだが、ソースだけのダウンロードもできるようだ。
こちらにBSDライセンス版(無料)のダウンロード先があったので、ダウンロードしてみた。
ARM: 無料版 リアルタイムOS RTX OS : BSDライセンス: マイコン風雲録

CMSIS_RTOS_RTX_V4P70.ZIP (3,437K)
Monday, March 18, 2013

 

GCCでもビルドできるようなので、うまくいけば試すかも。
ただ、RTXがあまり情報に出てこなかったのが気になっている。
ARMのお仕事をしていないので気付いていなかっただけかもしれないが、状況は気になりますな。

2015/07/03

[nrf51][ssp]Advertisingのタイムアウト (3)

割り込みハンドラをどうするかは考えればよいとして、SoftDeviceがどの割り込みをどう使っているのかは把握しておきたい。
周辺機器などはよいとして、SWI0~SWI5というのがどう使われているかは、ソースまで見ないとわからない。
でも、資料があるなら見たいです。

それっぽい質問が上がっていた。
how the swi0~swi5 interrupts triggered by softdevice? - Nordic Developer Zone
一番最後の回答に「SoftDevice Specification 2.0を読むとよいよ」とあるので、読んでみた。

S110-SDS / nRF51822(ログインしなくても読めるのかはわからん)
p.37にSWIの用途が書かれていた。
ARMのSWI命令は途中でSVCになったが、このSWIはそれとは別で、内部要因で発生させることができる割込らしい。
よくわからんが、そういうことができるんだろう。

p.36には、それぞれの割込について、アプリにとって制限あり(Restricted)なのか、アプリまでやってこない(Blocked)なのか、自由に使ってよい(Open)なのかが書いてある。
SWI2はRestrictedなので、nRF51 SDKを呼び出すようにするのがよいだろう。

 

SWI0は、アプリが使ってよいことになっている。
SVCのベクタは14だったと思うが、それとは別に使えるのか?
親切なことに、さっきのQAの人が「nrf_svc.hを見るとよいよ」と書いてくれている。
見ると、SVCALLマクロがそれに当たるようだ。
んー、私のイメージでは、SVCALLマクロを使うとSVC割込(14)が発生して、そのハンドラの中でswitch-caseするのだったのだけど、その0~5についてはSoftDeviceがSWI0~5に変換し、それ以外は自分の中で処理してしまうということかな?
うーむ。

前に悩んでいたSVCの値だが、これはp.38に範囲が書いてあった。
それ以外にも、いろいろ情報が書いてあるので、OSを移植するつもりなら読まないといかんのだろうな。。。

[nrf51][ssp]Advertisingのタイムアウト (2)

さて、前回わかったのは、Advertisingのタイムアウト時間になるとSWI2の割込が発生しているようだ、ということだった。

どのようにして確認したかというと、

  1. BLEスニファを立ち上げる
  2. nRF51のアプリを立ち上げる
  3. スニファでAdvertisingが止まるのを待つ
  4. デバッガで止める

だ。
うちはGNU環境なので、EclipseでGDBを使っているのだが、まあ他でも同じだろう。
もしかすると、有償の環境はもっとすごいのかもしれない。
有償の開発環境でうらやましいのは、ビルド以上にデバッグですな。

 

SoftDeviceを使った環境では、割り込みベクタはSoftDeviceが握っている。
Cortex-M0ではベクタオフセットレジスタがオプション扱いで、nRF51822ではレジスタがないから、変更できない。
動的にベクタが変わらないのは、デバッグとしてはやりやすい。迷わなくて済むし。

それ故、アプリが割り込みベクタと思って定義しているものは、単にSoftDeviceが関数呼び出しをするのに使っているベーブルだろうと思う。
SoftDeviceの中身を知らないし、デバッガで追ったわけでもないが、一度SoftDeviceが割り込みベクタから呼び出されたのにアプリの方まで呼んでいるというのは、そういうしくみになっているとしか思えない。

gcc_startup_nrf51.sを見ると、ベクタテーブルが定義されている。
この場所は、SoftDeviceが固定で呼び出すアドレスになるので、順番などは変更できない。
これを今はTOPPERS/SSPが使うようにしていて、自分のデフォルト割り込みハンドラに飛ばしている。
だから、OS無しのときはAdvertisingのタイムアウトによって呼ばれていたハンドラが呼ばれないのだ。

 

では、どうすべきか。
ITRONにならって、TOPPERS標準割り込み処理モデルを定義してから既存のSWI割込を呼び出すようにすべきか。
あるいは、既存の流れにそのまま載せるために、標準割り込み処理モデルをそこだけ使わないようにするか。
うーむ。

2015/07/01

[nrf51][ssp]Advertisingのタイムアウト (1)

githubに置いている、nRF51822+TOPPERS/SSPだが、Advertisingが1分続くと止まっている。
なぜだ!?

という話を書こうとしてソースを確認したのだが、app_ble.cのAPP_ADV_TIMEOUT_IN_SECONDSに、60秒って自分で定義してた。
そして、Advertising間隔は1秒。
念のため、30秒にしてみたら、30回のAdvertisingで止まった。

てへっ。

ではなく、SoftDeviceに対してタイムアウト時間を指定していた場合、どういうことが起きているのかを考えてみたい。
これは、SoftDeviceというある種のOSの中にuITRONを載せたがために起きていると思う。
なぜなら、今まではAdvertisingのTimeoutという通知がコールバックされていたから。


TOPPERS/SSPでは、TOPPERS標準割り込み処理モデル、という実装を使っている。
内容とかは知らないのだが、とにかくマイコンの割り込みハンドラが直接使われるのではなく、TOPPERSが一度吸収してハンドラを呼ぶようになっている。
これによってパフォーマンスとサイズは多少犠牲になるが、ハンドラ自体の移植性は高くなる。

「パフォーマンスの犠牲」は、性能が十分に引き出せない程度の意味なので、「速度パフォーマンスが犠牲になる」であれば処理速度が十分に出せてないことになるし、「省電力パフォーマンスが犠牲になる」であれば電力消費が無駄になっていることになる。
省電力に関しては、製品の要求などに関わってくるので、一般的な指標は出せないだろう。
電池を使わないモデルであればそもそも気にしないだろうし、100日持つか101日持つかみたいなところだと1日は誤差範囲だろうし。


そんな感じで、省電力をシステム依存で目一杯削減したい場合、汎用OSは導入できないだろう。
その代わり、汎用OSで使いたい機能は自分で実装することになり、苦労が増える。
汎用OSを使うなら、省電力は多少犠牲になるが、自分で実装する量が減るので、バグも減るだろう。
悩ましい。

 

そんなことを考えながら、誰がAdvertisingのタイムアウト割り込みを発生させているのか探してみたが、どうもSWI2のようだ。
ソフトウェア割り込みだ。