2015年1月31日

[cdt]トップディレクトリだけ指定して再帰的にincludeパスとみなす設定はあるのか?

私は見つけられなかったシリーズ。

eclipseでCDTを使うと、いろいろとソースの解析をエディタ上でしてくれる。
一番わかりやすいのは、includeファイルが見つからないとか、そういうdefineはないとか、そんなのだろう。

makefileでビルドするので、そういう警告が出ていても問題ではないのだが、気持ちは悪い。
プロジェクトの設定で、#includeに書いてあるファイルの上位パスまでを登録しておけば解決してくれるのだが、パスが増えてくると設定するのがめんどくさい。

nRF51 SDK v6の環境で設定したプロジェクトを用意していたのだが、v7が出て見事に使えなくなった。
ついでにarm-gccのパスも変更したので、もう、なにもかも、見えない・・・。

見えなくなったのは仕方ないとして、パスを1つ1つ登録するのではなく、最上位のパスだけ設定しておいたら、勝手に下側にあるファイルを検索して名前が一致したら見てくれる、みたいな設定がCDTにないのだろうか?というのがタイトルの意味だ。

ええ、わがままだってのはわかってますよ・・・。
だって、同じファイル名がパス上にあったらどうするんだ、とかいう問題があるからだ。
#include_nextみたいなわけにもいかないだろうし、そうなったら面倒だ。
だから、ないような気はしているのだが・・・。

stackoverflowなんかにもいくつか出ていたのだが、どれもそれっぽくない。
今日のところは「できないんだ」で終わらせるが、できそうなできなさそうなの境界線にあるので、どっちであっても気になる。

[nrf51]I/OサンプルをnRF51 SDK7対応

以前作っていたnRF51822 S110 SoftDevice v7.1.0向けのInput/Output Serviceサンプルを、nRF51 SDK7.2.0でビルドできるように変更した。

https://github.com/hirokuma/nrf51822_templete

変更点にあんまり「これ」というのはないのだが、こんなところか。

  • #includeの中にパスを書くのはやめ、gccのオプションで解決するようにした
  • makefileはexamplesのまねをした
  • "make debug"、"make release"ができるようにした
  • device_manager_peripheral.cとpstorage.cは外した

どうも、device_manager_peripheral.cがpstorageを呼んでいるようでリンクしてしまうのだ。
device_manager_peripheralなんて以前は使っていないし、

CFLAGS += -ffunction-sections -fdata-sections -fno-strict-aliasing
CFLAGS += -flto -fno-builtin

とか付けてるから、リンクで読まれるだけで最後は消されるんだろうと思ったけど、mapファイルを見ると残っていたのだ。
うーん、なんでだろう?

あ! releaseのビルドをしたら消えた!!
そうか、そういうしくみだったのか・・・。

2015年1月27日

Bluetooth 4.2とLE Privacy 1.2

今さらだが、Bluetooth 4.2の仕様が出ていることを知った。
まだ最新の動向を追いかけられるほど知識が溜まっていないが、概要は知りたい。

検索すると日本語でもいくつか出てくるのだが、その中に「ビーコンが安全になる」みたいなのがあった。
よくわからなかったので、なるべく理解してみよう。


とりあえず勘違いしていたのは、ビーコンが安全になるというのではなく、機器の追跡についてプライバシーが強化された、みたいな感じらしい。デバイスを追跡から保護する、と。
"Bluetooth Small devices"とあるから、スマホみたいなやつじゃなくて、ビーコン端末みたいなちっこいのを指してるのかな。

"LE Privacy 1.2"という名前(feature)で、

Bluetoothによる狭い範囲の追跡(Small location tracker)は、所有者か省電力動作中でも信頼されたグループ(trusted group all while consuming less power)のみ行うことができる(only be followed)

とある(Bluetooth4-2FAQ[pdf]より)。
まあ、私の訳だと不安だろうから、短いFAQなので読んでいただきたい(1ページ目にある)。

 

さて、勘違いしていたことに気付いたのはよいが、所有者だとかグループだとかはどこで出てくるんだろうか?
また、"Bluetooth Small location tracker"というのがAdvertisingを使ったビーコンみたいなところでできるかどうかまではFAQに書かれていない。
AM3 - Bluetooth Technology Overview Part2(pdf)の最後の方には、LE Privacy 1.2を実現するのはハードウェアだと書いてある。

ようやく情報が見つかったのが、こちらのページ。
Bluetooth LEが2.5倍に増速 - KONURE
ホワイトリスト方式での接続に限定できるとのこと。
これをキーワードにCore_V4.2を検索すると、Device Filterling Procedureという言葉が出てくる。
ただ・・・ホワイトリストにデバイスを追加するようなコマンドは、4.0のときからあるようなのだ。
上記のサイトでも、4.1ではホスト側でアドレス解決する方式があって、それとは上位互換になっていると解説してある。
ということは、コマンドがどうこうではなく、もっと、なにか、こう・・・。

今度はアドレス解決という観点でCore_V4.2を検索すると、ようやくそれらしきものに出会った。
"Vol 6, Part D: Message Sequence Charts"の"4 Scanning State"だ。
Core_V4.1では「Passive Scanning」と「Active Scanning」しかないのだが、Core_V4.2では追加がある。

  • 4.3 Passive Scanning for Directed Advertisements with Privacy
  • 4.4 Active Scannig with Privacy
  • 4.5 Active Scanning with Privacy and Controller Based Resolvable Private Address Generation

図は、デバイスBがAdvertisiongして、デバイスAがそれを見つけるようになっている。
既存のはデバイスBだけでAdvertisingしているのだけど、この3つのシーケンスではホストBもなんかやってる。
やってるが、よくわからん・・・。

controller resolving listとかいう名前も出てくるが、これだったらハードウェアの変更じゃなくてファームウェアの変更で対応できそうな気がする。
違うのかなぁ・・・。


そうそう、もう1つ勘違いしていたのは、FIPSとかいうセキュリティのことだ。
FIPSが何かは知らんけど、これでビーコンみたいなAdvertisingのものを安全にできたりしないよなあ、と思ったのだ。
もちろんこれは私の勘違いで、FAQでも"during device pairing"と、ペアリングしたあとのことを言っているようだ。
ペアリングする前のAdvertisingには関係ないのだ。

2015年1月25日

[nrf51]今日のデバッグ設定

nRF51822 + J-Link LITE CortexMの環境を使っている。
gccは推奨バージョンじゃないが、まあよいだろう。

  • nRF51822 xxAA
  • J-Link LITE CortexM : 4.94j
  • SoftDevice : S110 v7.1.0
  • nRF51 SDK : v7.2.0
  • Eclipse : Luna Service Release 1a(4.4.1) C/C++ Developers
  • GNU ARM Eclipse Plug-ins : J-Link Debugging : 3.1.1.201412191510
  • arm-none-eabi-gcc : 4.8.4 20140526 (4_8-2014q2-20140609-win32)

 

"Startup"の"Run Commands"で、"Pre-run reset and halt"の設定をしたらmain()で止まった状態で開始できたので、メモがてら残しておこう。
gdbのパスが"CodeSourcery"になってるが、気にしないように。もう長いことフォルダ構成を変えていないから、ARMのコンパイラはここに置くようになってしまったのだ。

 

image

 

image


自分のプロジェクトだが、SDK v7からはSDKの中にフォルダを作って置くことにした。
以前は環境変数にSDKのパスを書いて、それを参照するようにしていたのだ。
でも、SDKが変わるたびに作りが変わっているので、なんかもう維持するのが面倒になってしまった。
makefileだけ書き換えればよいのだろうが、もう「nRF51 SDK v7.x用」と割り切ってしまいたい。

 

とまあ、こんな感じでようやく方針が決まったから、BLEの続きをやりましょうかね。

2015年1月24日

[ios]IoS Developer Programの年間参加費が¥11,800になった

下記のサイトで、年会費が上がったという記事があった。
Apple、iOS・Macデベロッパープログラムの年会費の値上げを実施 | 気になる、記になる…

うわぁ、本当だ!
iOS Developer Program - Apple Developer

 

経費にすることはできると思うんだけど、いかんせんiOSでの開発はやらない気がするからなぁ。
さっき久々にログインして、iOS8.2 beta4が出てるのを知ったくらいだ。
BLEだとiOSは大切なんだろうけど、MacのiOSシミュレータでBLEできるような記事もあったので、更新はしないでよさそうだ。

2015年1月23日

[nrf51sdkv7]デバッグがきれいに始まらない

これはnRF51 SDKがv7になったせいではないような気がする。
何かというと、デバッグ開始時がすんなり進まないのだ。

だいたい、HardFaultが発生している。
そこで"Restart"すると、今度はうまくいく。
以前、eclipseのプラグインを入れ込んでから、うまくいくようになったとばかり思っていたのだが・・・。

この辺をすっきりさせたいのだけど、まだ、今の私にはまだ力が足りていない。。。
他力にすがってもよいので、探しておきたいところだ。

2015年1月22日

VはViolationのV

Linuxやってるとよく見る、Segmentation Fault。
セグフォル、とか略したりするが、C言語で使うときは"SIGSEGV"だ。

今まで何も考えずに使っていたけど、Segmentation Faultなのに、なぜ「V」が??
そう思って調べた結果が、今回のタイトルだ。
Segmentation Fault Violationの略で、SEGVなのだった。

 

Vが付くと、なんとなく東欧とかロシアとかの単語から来てるんじゃないかと想像していたのだ。
セマフォの上げたり下ろしたりのPとかVとかも、確かその辺だったはずだ。
逆ポーランド法とか。

[nrf51sdkv7]makefileの作りがv6と違う

以前作っていた、自作のI/O ServiceアプリをSDK v7.2.0でビルドすることにした。

やり方は簡単で、昨日ビルドできたexamplesのmakefileを持ってきて、パスやソースの場所を書き換えるだけ。
あ、nRF51422だったから、nRF51822 S110 QFAA用に変更するようなところもやった。

ビルドすると、意外にもするっと通った。
まだ実機には焼いてないけど、バイナリのサイズがSDK v6よりもかなり小さい。
どうやら、引数無しのビルドはリリース用になるらしく、-gなどがなかった。

SDK v6のときは、Makefile.commonにそういうのが書かれていたはず、と思って探したが、それ以前にSDK v7のexamplesにあるmakefileは、Makefile.commonをincludeせず、単にMakefile.windowsなりMakefile.posixなりをincludeするだけになっていたのだ。
SDK v7にもMakefile.commonは用意されていたのだが、ファイル比較するとSDK v6とまったく同じ内容だった。
今後はmakefileも平たい構造にするため、各プロジェクトのmakefileにほとんどの処理を書くようにしよう、という意思の表れだろうか。

ただ残念ながら、examplesのmakefileにはデバッグ版でビルドするような設定は入っていないようだ。
そういうのは、Makefile.commonから持ってくるとよいんではなかろうかね。

2015年1月21日

[n7]Nexus7(2013)にもAndroid5.0.2がやってきた

やってきたのだ。
これでうちにあるNexusシリーズのうち、Nexus7は両方ともAndroid 5.0.2になる。
Nexus5はまだだが、まあこれもそのうち来るのだろう。

 

こちらは、TagInfoで普通に読めた。
以下を試した。

  1. 片方のNexus7を、ホーム画面にする
  2. もう片方はTagInfoアプリを立ち上げる
  3. Android Beamさせる

Nexus7(2013)でTagInfoをNFC reader modeにしたときだけは、Android Beamもできないし、タグを認識した音もしなかった。
それ以外は、Beamできたり、音が鳴ったりした。

自分でNFC reader modeにだけするアプリを作って比較してみればよいのだろうが、まあ同じ結果だろう。
これはバグ扱いになりそうな気配がする。

[nrf51sdkv7]makefileを書き換えてサンプルをビルド

とりあえず、nRF51 SDK v7.2.0のexamplesを、自分の環境でビルドできるようにしよう。
なお、今回はWindows 7 Pro Sp1 (64bit)でやっている。
長年使っているので、あれこれインストールされている。少なくとも、SDK v6でビルドできるようなものはインストールされている。

ビルドするのは、examples/ble_peripheral/ble_app_hrsだ。
makefileは、pca10028のものを使おう。


まず、Makefile.windowsの書き換え。
SDKv7では、components/toolchain/gcc/Makefile.windowsにある。
中身は、SDKv6のときと同じ内容でよさそうだ。


これでmakeしてみると・・・完了した。
えっ、これだけ??
ま、まあ今回はnRF51422用だったから、うちでは動作確認させることができないしね。

・・・さすがにこれだけだとあんまりなので、v6とv7のble_app_hrsを比較した感想も書いておこう。


v6までは、エラーなどの状態をLEDで表すためにnrf_gpio_pin_xxx()を埋め込んでいたけど、v7ではbsp_indication_set()という関数を用意しているようだ。

v7には、DFUのことが実装されている。
Device Firmware Updateの略のようだ。
SoftDevice7から使えるようになったとは聞いていたが、まだ未確認なので動かしてみたいものだ。
やはり、無線の小物を仕事で作っていると、とにかく問題になるのがアップデートについてだ。
昔はmask ROMで安価にして、その代わりアップデートもできないというのが普通だった。
それじゃやっぱりねぇ、ということでFLASHになって有線で書き換えができるようになってきた。
でもカエサルのものは、というわけではないが、無線通信するものは無線で書き換えできた方がよいよね、ということでAIRでのDFUがサポートされてるんじゃないかと思っている。

あと、v7にはボタンの初期化がないね。
ble_stack_init()もなくなって、代わりにbsp_init()が呼ばれているようだ。
bsp(Board Support Package)は、examples/bsp/に入っている。
boards.hもここにあるので、自分のボード用に書き換えることになるだろう。


そんな感じで、ちょこちょこと変わってはいるものの、SoftDeviceが変わったわけでもないので、基本的にやれることは同じだ。
そう恐れることはないんじゃなかろうかね。