2015/01/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/01/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/01/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/01/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/01/23

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

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

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

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

2015/01/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/01/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が変わったわけでもないので、基本的にやれることは同じだ。
そう恐れることはないんじゃなかろうかね。

2015/01/20

[nrf51]nRF51 SDKがv6からv7になってつらいこと

さて、nRF51 SDKが新しくなった。
昔の私は新しもの好きで、どんどん新しいものを取り入れていったものだが、もう歳だ。
歳のせいにはしたくないのだが、変化に対応するのがちとつらくなってきた。

今回は、そういう愚痴を軽めに書いてみよう。
まあ、コンピュータ関係の仕事をする人が変化に対応できないなんて、能力を露呈しているようなもんだから寂しくはあるのだが、あまり変化が早すぎるとユーザがついて行けないってのもあるしね。


フォルダ構成が変わった

まずは、これですな。
SDK v5から見ているのだけど、v5, v6まではIncludeフォルダとライブラリのソースファイルが別フォルダになっていたのだけど、今回は「greatly flatten」らしい。
フォルダ構成が浅くなったのかと思ったけど、そうでもない気がする。
Includeフォルダ/Sourceフォルダがまとまって、componentsフォルダになったような感じか。

まあ、フォルダが増えて、timerやbuttonがそれぞれ別のフォルダに入っているから、1つのフォルダにごちゃごちゃ入っているという感じがしないところは評価しよう。

 

サンプルソースからnRF51822がなくなった

以前は、nrf51822/Boardの下にサンプルがあった。
しかし、今回は"nrf51422"や"nrf51822"というフォルダ自体がない。
componentsフォルダと同階層にexamplesフォルダがあり、そこにサンプルがまとめられている。
そこにreadme.txtがあるのだが、ボードとサンプルの対応表が載っている。
pca10028はほぼ対応。
pca10031はちょこちょこ対応。
wt51822は1つだけ対応。

書き換えるところはそんなに多くはないのだと思うが、nRF51822よりもnRF51422の方がメジャーなのかしら?
なんとなくnRF51822の方がメジャーとばかり思い込んでいたので、多少ショックだった。

 

makefileが変わった

フォルダ構成が変われば、そりゃ当然なのだが、makefileが変更になった。
Keilとか使っていればそこまで大変じゃないのかもしれないが、私はgcc+makeでビルドしているので、憂鬱だ。
v5, v6まではそんなに変わっていなかったので、自分で使う環境用にmakefileを仕立てていた直後だけに精神的なショックが大きい。
ああ、またやり直しか・・・。

そう、新しくなって憂鬱に感じるのは、それに対応するための時間がもったいないと思うようになってきたからだろう。
そんなに人生は長くないのだよ。


まあ、ごにょごにょ言っても仕方ないので、対応はするんだけどね。

一人でやってると愚痴を言う機会が無いので、こういう場を借りて吐き出させてもらった次第だ。
さあ、やろうかね。

2015/01/19

[nrf51]nRF51 SDK v7から提供方法が変わった!

久々にNordicのnRF51822ページを見ると、IoT SDKなるものが入っていた。
IPv6どうのと書いてあるが、とりあえずダウンロードしておこう。
(まだ、そういうレベルまで追いついていない。。)

ついでに、インストールしているSDKが新しくなっていないかを、My pageで確認した。
うん、6.1.0が最新のようだ。

新しいSDKは、BLEのシーケンス図とかが載っていないのでつらいんだよなー、とNordicのドキュメントページを見ると、なんと図が付いているではないか!
URLを見ると、v7.2.0になっている。
v7.2.0 ??

URLを上までたどっていくと、nRF51 SDKのページにたどりついた。
こんなページは知らなかった・・・。
よくよくnRF51822ページを見ると、HowToDownload_nRF51_SDK.txtというテキストファイルも加わっていた。
そこに、このページのことが書かれていた。


なんか、いろいろと変わったようだ。
SDKが変わったというよりも、とにかく提供方法が変わったみたい。
今までのMSIインストーラはやめて、CMSIS packにするとのこと。
KEILで使われているパッケージ形式なのかな。

gccのようにKEILを使わない人用にもSDKは用意されていた。
よかったよかった。
・・・と言いたいところだが、まだ先があった。
SDKのフォルダ構成が変わっているのだ!

image

こんな感じだ。
ソースファイルとインクルードファイルが同じフォルダに置かれるようになったみたいなのと、examplesなどからgccのMakefileが消えた(armccはあるが)ことから、今回のSDKをgccに置き換えるのは一苦労しそうだ。
あ、"armcc"じゃなくて"armgcc"というフォルダ名だった。
armccだとARM社が出してるコンパイラだけど、armgccは単にARM版のgccじゃないかな?
そう期待しておこう。


IoT SDKのドキュメントをちょっと見たら、nRF51 SDK v7.1.0をベースにしているとのこと。
やはり、v6系は捨ててv7系に行くのがよいのか。

v7.2.0のリリースノートを見ると、gccはgcc-arm-embedded 4.7 2013q1で確認しているとのこと。
SoftDeviceはS110 7.1.0をサポートしているようなので、現状でよさそうだ。
サポートしているボードは、PCA10028, PCA10031, WT51822(S110)で、それ以外はドキュメントを読むかSDK V6.x.xを使え、とある。
まったく、悩ませるやつだ・・・。

今日はこれだけ調べるだけで疲れ果てたので、また後日。

2015/01/17

[win]ソース埋め込み用NDEFバイナリ出力アプリ

ソースファイルに、NDEFを埋め込みたいことがときどきある。
書込む値が最初から決まっている場合とか。
Excelとかでも作れそうなのだが、Windowsアプリで作った。

https://sites.google.com/site/hiro99ma/nfc/files/windows/NdefBinary.zip?attredirects=0&d=1

image

まあ、あまり需要はないと思うが。

[android]未フォーマットのFeliCa LiteをNDEFとして検出してしまう

あまり調査できてないのだが、Android 5.0.1でFeliCa Lite未フォーマットのカードをかざすと、intentをgetTag()して取得したTagがNDEFとして見られているような感じがする。

public void onNewIntent(Intent intent) {
    super.onNewIntent(intent);
    Tag tag = getTag(intent);
    if (Ndef.get(tag) != null) {
        //NDEFの処理
    }
}

こんな感じのコードにしていたのだが、if文の中に入ってしまったのだ。
でもNDEFじゃないので、何かするとTag Lostで例外に飛んでしまう。
以前はそうじゃなかったような気がするんだけど・・・。

NdefFormatterがうまく動かないので、NDEFかどうかの判定よりも先に、NFC-Fかどうかの判定をして、NFC-FだったらNDEFフォーマットだろうと未フォーマットだろうと、とにかく未フォーマット時の処理をするようにした。
バグかな?という気もするけど、Androidアプリに慣れていないので単なる実装ミスのような気もしてしまう。

それと、Nexus7(2013)でFeliCa Liteカードの読み込みがあまりよろしくない。
昔からそうだったのかもしれないけど、TagInfoですぐエラーになってしまう。
調子がよいときもあるので、単にかざし方がよくないだけのようにも思うが、もうちょっとがんばってくれてもよいような気がする。

なんか、技術的に弱みがあると「気がする」が多くなってしまうな。。。

[android]HCEの動作確認を今さら行った

HCEのサンプルを作っておいたまま、Androidでの動作確認をしないままでいた。
hiro99ma blog: [nfc]HCEのサンプルを作った

NXP TagInfoアプリのことを調べた際に、このアプリはNFC Reader Modeでの動作ができることがわかった。
なので、Nexus5にHCEサンプルを、Nexus7(2013)にTagInfoを入れてタップした。
うん、URIのNDEFとして認識してくれたようだ。
ロック画面が表示されたときにも読めたので、期待通りに動いているようだ。

まあ、HCEでNDEF動作をエミュレーションしてもあまり意味はないんだけどね。

2015/01/15

[n7]Nexus7 2012(Android 5.0.2)で、TagInfoがタグを読まない

Nexus7 2012がいつの間にかAndroid 5.0.2になった。
それと関連しているのかどうかわからないが、NXPのTagInfoアプリ(NFCのタグを読むアプリ)がタグを読んでくれない。

読まずにどうなるかというと、通常時にタグを読んだのと同じ動作をしてしまうのだ。
Nexus7 2013(5.0.1)とNexus5(5.0.1)では同じアプリでもタグを読んでくれるのに。
うーむ。

考えられるのは、ForegroundDispatchがうまく動作していない、なんだけど、そんなことってあるのかい?
私が以前作ったNDEFフォーマットアプリは動作しているようだから、そうではなさそうだ。

 

TagInfoアプリの設定で「NFC reader mode」のチェックを外すと、動くようになった。
NFC reader modeは最近付いたモードだったと思うが、Nexus7 2012はNFC周りがNXPでNCIに対応しておらず、さらに言えばHCEにも対応していないので、NFC reader modeが動作しないということだろうか?

API仕様を見る限りでは、特にそういう制限はなさそうだ。
しかしアプリを作るのであれば、もしNFC reader modeが有効ならForegroundDispatchは使わないだろうし、NFC reader modeを使わないんだったらForegroundDispatchを有効にするように思う。

ここで深追いすると勉強になるんだろうけど、弱気なのでやめておこう。

[android]使うならせめてリフレクションにしよう

反省だ。
「@hideのAPIを使うのは避けるべきだが、使うのならせめてリフレクションで使おう」。

 

以前、EjectSDというAndroidウィジェットを作ってAndroid Market(今はGoogle Playか)に置いていた。
単にSDカードのマウント・アンマウントをウィジェットで行えるだけのアプリだ。
経緯は忘れたが、たぶんアンマウントするのにメニューが深くて嫌だったから作ったんだろう。

hiro99ma blog: [app]「Eject SD」を公開しました
hiro99ma blog: アプリからmount/umountさせる
hiro99ma blog: EjectSDをAndroid4でビルドし直す

当時の私はリフレクションなど知らなかったので、Androidのプラットフォームを落としてきて、その組込みアプリとしてビルドしてapkを作り、それに署名だけしてアップしていたようなのだ。
そのためか、このソースやapkが手元に残っていないのだ・・・。
私のことだから、「Windowsでソースを作る→Linuxにファイルを転送→Linuxでビルド→エラーが出たのでLinuxで編集&ビルド→その場でapkに署名→apkのアップもLinuxで行う」とやって、残っていないんだろう。
Linux側は、ごたごたして、ぜーんぶフォーマットしてしまったので、何も残っていない気がする。。。

もし私がリフレクションを知っていたら、こういうOSを行き来せずに済んだのに、という反省だ。
まあ、そうじゃなくてもソースをちゃんと管理していればよいだけの話ではあるが。

 

なんで急にこの話をしたかというと、"4.1.2にインストールしたけど動かないみたい"というメールが来たからだ。
Google Playを見ると、EjectSD4は4.1.1までの対応になっているらしい。
4.1.2まではAPI16で同じだと思ったんだけど・・・。

ん、よく読むと「インストールはできたけどアプリ一覧に出てこない」と言われているようだ。
Nexus5でアプリ一覧を見てみたが、スマホ系はアプリしか出てこないのだな(タブレット系はウィジェットも次のタブとして表示される)。
ウィジェットから探すようにお願いしてみるか。
こういうやりとりをもっと楽しめるようになれば、私の英語力ももう少し高まるかもしれんな。

2015/01/13

[N5]急に電池がなくなった

Nexus5 Android 5.0.1なのだが、昼に触ってみるとえらく温かく、電池は切れていた。
家に帰ってから確認すると、なぜか急激に消耗したみたいだ。

image

なんだろうね?

2015/01/11

[arm]DHCSR (1)

nRF51系というか、Cortex-M0系というか、ARMv6-MアーキテクチャにはDHCSRというレジスタがあることを知った。
ねむいさんのぶろぐ | Discovery系基板を中心とした小ネタいろいろ

世の中知らないことばかりですな。
PDFはこちらで、C1.6.3(p.331)から説明がある。
ARMv6-M Architecture Reference Manual - DDI0419C_arm_architecture_v6m_reference_manual.pdf

0x07は、(C_STEP | C_HALT | C_DEBUGEN)にビットを立てたことになる。

  • C_DEBUGENを1にすると、このレジスタの内容が意味を持つ。
  • C_HALTを1にすると、Debugステートを維持する(C_STEP, C_MASKINTSはN/A)。
  • C_STEPを1にすると、Debugステートを抜けて次の命令を実行し、HALTする。

ということからすると、Debugステートを維持したいのであれば0x05でよいようだ。

しかし、「Debugステートを維持」と「次の命令を実行してHALT」の違いは何だろう?
HALTすると、何か例外が発生するまで次に進めない
そもそも、Debugステートってのは何だろうか。
いつも「JTAGデバッガを使うとブレークポイントに止まってくれて助かる」くらいにしか思っていないが、なんか曖昧なことしか知らないのだった。

ARMv6-Mでデバッグ機能が使用できる場合、以下のようなことができる。

  • プロセッサのHALT
  • シングルステップ
  • プロセッサのコアレジスタへのアクセス
  • ResetおよびHardFaultベクタキャッチ
  • 無制限のソフトウェアブレークポイント
  • システムメモリへの完全なアクセス

また、デバッグオプションには以下が含まれることがあるとのこと。

  • ハードウェアブレークポイント(1~4)
  • ウォッチポイント(1~2)

うーん、これはCorTex-M0のマニュアルを読んで書き写しているだけなのだが、それだけでも難解だ。
「より根源をたどれ!」という私と、「どうせそこまで理解してもデバッガでできる以上のことはやらんだろう」という私がせめぎ合っている。

とりあえず今回は「デバッグは奥が深い」という底の浅い言葉で終わろう。

2015/01/10

[ble]geckoタグが届いた

image

geckoタグという、BLEのタグが届いた。
Gecko - Make your Smartphone smarter

Indiegogoに出ていたものの1つで、Gigazineに記事があったので開発者向けので出資?していたのだ。
2014年の7月に出荷状態になったまま届かず、でもメールだけは届いていて「最終出荷が終わった」みたいなのがあったので、「うちはどうなってんの?」とメールしたら届いたのだ。
下手な英語メールでも、単語さえそれっぽく並んでいれば理解してくれるのだろう、うんうん。

大きさは上の画像を参照。
左から順に、単3電池、BVMCNDT52、gecko、SensorTagだ。
まあ、そんなに大きくはないですな。
厚みもなく、キーホルダーになるくらい。

アプリは、AndroidはGooglePlayに、iOSはAppStoreにそれぞれあがっている。
Android版は・・・今ひとつか。
うちがOS5.1のNexus5だからか、よくアプリ自体が死ぬ。それに、Nexus7(2013)だとインストールできない。
iOS版の方が動きはよいのだが、iPad miniではアイコンがデフォルトだし、なんだかなぁ。

そういう文句を言うなら自分で作りなさい、ということで開発者向けにはdeveloperサイトがあり、アカウントも案内されて用意があるのだけど、いつの間にかログインできなくなった。。。
パスワードを忘れたのかと思って「forgot password」したいのだが、gecko用に作ったYahooアカウントへはSMTP接続に失敗するというエラーが出てどうにもできない。

やむなく、また下手な英語メールを出したところだ。
ネットで探しても日本語で「買った」みたいなのが見つからないので、やはりマイナーなのか。。。

[nrf51]gcc+eclipseでの開発(2015/01/09)

nRF51822を無料の開発環境で使いたいとなったとき、Keil(制限有り)かgcc+gdbになるだろう。
私はgcc+gdbなのだが、環境を作る情報がはっきりしない。
Nordic社のPDFが正しいのだろうと思っていたけど、どうもそれではうまく行きにくい。

それを懸念したのかどうかわからないが、Nordic Developer Zoneのブログに記事が出ていた。
Documentation and Resources for Eclipse Development

ただ、この記事は現状のまとめみたいなもので、「ここにはこう書いてあるけど、最新の情報ではない」とか「こっちはこういう感じだ」と書かれているだけで、どうもはっきりしない。


nAN-29 Development with GCC and Eclipse

  • Windows向けに書かれているので、LinuxやOS Xの人は読み替えしていく必要あり
  • GNU ARM Eclipse Plug-insを使っていないし、SEGGER J-Link Eclipse pluginを使っていない。managed buildではなくmakefileを使っている
  • SDK 7.1.0向けにアップデートされていない

 

Tools for OS X Development

  • OS X上でEclipseを使うのであれば、ツールのリストは役に立つだろう

 

Development with Eclipse and GCC

  • nAN-29を参照しているが、多少アップデートされている。SEGGER J-Link pluginを使うようにしているところがよい。
  • managed buildではなくmakefileを使っている
  • SDK 7.1.0向けにアップデートされていない
  • Windows用のコマンド(“make flash”など)はOS Xでは使えない

 

Getting started with nRF51 development on Mac OS X

  • Eclipseについて書かれている記事ではないが、MacでGCC + makefileで開発する際のよい情報が書かれている
  • SDK7.0.0向けにアップデートされている
  • OS X上でSEGGER J-Link toolsを使ったFLASH書き込みについて書かれている

 

Software Development with nRF51 Series Bluetooth® Low Energy SoC

  • nRF51-DKではなく、IMM-NRF51822モジュールでの使用方法が書かれている
  • SEGGER J-LinkではなくOpenOCDを使うようになっている
  • サードパーティのEHALソースツリーを使っている(なぜそれが必要なのかわからない)


こんな感じで書かれているので「こうやるとよいのだよ」というのは出てこない。

うちは、こういう環境で使っている(2015/01/09)。

  • gccは、CodeBenchから最新版を取ってきた
  • eclipseは、LUNA
  • eclipse pluginなどはこちら