[nfc]NfcPcdをAndroidStudio用に作り直す

コメントで、NfcPcdがビルドできない、というご連絡をいただく。
うーん、もう4年も前なのか・・・。

当時はEclipseだったし、Java6だったし、とりあえず今の私には記憶がないので、AndroidStudioにインポートすることにした。
そのAndroidStudioもいつの間にかバージョンが上がってて、今は1.2とかなんですかね。
1.3のベータがあるよという通知も来ていたけど、もうよくわからないので1.2のzipを落としてきて、上書き。
そうすると「バージョンが複数あるけん起動せん」とか言われたので、元のを消して新規に解凍。

ここでまた、JARだのAARだのとわからないことだらけになってきた。
AndroidStudioでつらいのは、build.gradleというファイルを手で書き直す場合があることだ。
たぶん、普通にアプリを作る分には何もしなくてよいのだろうけど、過去の資産を持ってきたりするとつらそうな感じがある。
特に今回みたいに「ビルドできるかどうか確認したいだけ」というときなんかは、腹が立ってしまう。
年寄りは前頭葉が弱ってくることで怒りっぽくなるというが、もしかしたらそのせいかもしれない。

今回は、こんな感じのことをやってビルドできた。

• 新規でアプリプロジェクトを作る
• New Moduleで、インポートを選び、NfcPcdのライブラリプロジェクトをインポート
• NfcPcdでproguardを使っていたためか、proguardにJARがいるとか何とかいわれているので、proguard設定ファイルを削除
• Project StructureでアプリのプロジェクトのDependenciesにNfcPcdをModule Dependencyとして追加。ScopeはCompileのままでよいみたい
• アプリの方に、以前作っていたサンプルソースを移植。元々はこれもインポートで済ませたかったのだが、ファイルの置き方が変だったのかうまくいかなかったので、手で移植した。

どうも、以前作ったものからのインポートがよくわかってない。
あれこれ試しているとき、「ライブラリにアプリケーションIDが付いている」と怒られたり、JARとして使おうとしたとき、apply pluginがlibraryじゃなくてapplicationになっていたり。

 

とりあえず、うちのNexus5で動いたので、githubに置いた。
もう、ライブラリ化はやめた。。。
死蔵するくらいなら、誰かに使ってもらった方がよいだろう。
git@github.com:hirokuma/NfcPcdStudio.git

[git]rebaseがよくわかっていない

もう一度、新規featureをつくって、commitやpushを何回か行って、feature完了処理をした。
今度は期待通りになった。

featureブランチの削除をしたので、ローカルでは消えている。
だが、remoteにpushしたブランチまでは削除しないようで、残っている。

 

よしよし期待通り、と思い、githubの方を見てみた。

あれ、developブランチを見てるのに、featureブランチの方のコミットも出てきている？？
なして？？？

---

うん、rebaseを理解できていないことがわかった。
いくつかのサイトを見たけど、mergeだと「く」の字型に履歴が残るけど、rebaseだと一本線になる、というような説明だったので、そういうものだと思っていたのだが、たぶんもう少し理解しないといかんのだろう。

Gitを使いこなすための20のコマンド 5ページ | OSDN Magazine

これの「コマンド18」がrebaseの説明になっている。
ここの図は、今まで見てきたサイトとは違うな・・・。
一本線になるというよりも、ベースラインが変更になるという感じだ。
だからrebaseという名前なのか。
私のrebaseのイメージは「時間がふっとばされて結果だけが残る」だったけど、そうじゃないんだ。。。

しかし、rebaseした場合、それより以前にブランチしていた人達は大丈夫なんだろうか？
何本か接ぎ木したうちの1本が幹として成長したことになるので、なんか変な気がするけど。。。
でも、それを言うなら「接ぎ木したうちの1本を折って、先っちょに挿した」みたいなことになるのか。
ならば、別に関係ないのか。

---

ただ、「rebaseで複数のcommitをまとめる」という記事がたくさん出てくる。
それと「pushしたものをrebaseするのはよくない」という記事も出てきた。

まだ内容は読めていないのだが、「何度もcommitしたくて、でも最後のコミットだけ見せればいいような場合は、pushせずにローカルでcommitする生活をして、最後にrebaseでまとめてからpushしよう」ということなのかな。

あとはプロジェクトとして、ファイルと担当者がなるべく一意になるようにして、自分の作業はファイル内で収まるように割り振るのがよいだろう。
他のファイルをいじりたくなったら、開発中はその人に依頼をかけるようにするとか。
ホームページとかだとよくわからないけど、組込み系だと機能ごとにファイルを分けることが多いので、そんな感じでもいいんじゃないかね。

[git]一人でやってるのに混乱する

nRF51822にTOPPERS/SSPを載せて遊ぼうとしているので、せっかくなのでこれにGit Flowを使ってみることにしている。
githubを使ってるので、私の混乱ぶりがわかるかもしれない。
https://github.com/hirokuma/nrf51822_uitron_ssp

あんまりまじめにやるつもりはなかったので、Git Flowのことはさらっとしか読んでない。
私の中では、こんな感じだと思っていた。

• とりあえず、masterとdevelopのブランチができ、基本はdevelopで作業
• 新しいことをするときは、developからブランチを切る(feature)
• featureのブランチが終わったら、developにマージなりリベースなりをする
• developでほどよくなったら、masterにマージする

SourceTreeにはGit Flowのアイコンがあって、それをクリックするとある程度は上記をやってくれる。
そう、私もfeatureのブランチを切って、作業をやっている間は混乱しなかったのだよ。

Advertisingができて満足したので、developにリベースしようとした。
と偉そうに書いてみたが、リベースってのはやったことがない。
Git Flowアイコンを押すとダイアログが出てきて、リベースするかどうかのチェックボックスがあったので、今までやったことがないのでチェックしてみた。
もう、このfeatureブランチはいらないので削除もチェックした。
そして実行してからの記憶が曖昧なのだが、pushしようとしてエラーが出たり、なんだかわけがわからなくなった。。。

これが、ようやくさっきエラーとかがなくなったので、スクリーンショットを撮ったところである。

左から2番目のが、featureブランチだろう。
私の思っていた完了形は、

• featureブランチがdevelopブランチにマージされるのだが、featureブランチでやっていた履歴は残らない
• featureブランチは消える

だったのだ。
が、スクリーンショットを見るとわかるように、featureの内容がそのままdevelopに入ってしまった。
featureブランチの削除はやらなくてよいとしても、developへマージするときにはその1点だけの情報で済ませたいのだ。
リベースの説明を読んでもそんな印象を受けていたのだが・・・。
non-fast-forwardのチェックをつけたりはずしたりしたような気がするので、それがよくなかったのか？

 

あと、SourceTreeの樹形図の見方を私は勘違いしていたようだ。
一番左の直線に並ぶのが現在checkoutしているものになると思っていたのだが、そうはなっていない。
いろいろうまくいかないと、細かいところから自信が崩れてきますな。

---

軽いので試してみよう。
sample/Makefileの削除、というだけのfeatureを切ってやってみる。

削除して、コミットして、今回はpushせずにGit Flowアイコンをクリック。

完了をクリック。

デフォルトではリベースしないようになっているので、チェックしてOK。
そうすると、けっこうな長い時間プログレスが流れる。

あら、今回はうまくいった？

Summary of actions:
- The feature branch 'feature/delete_sample' was merged into 'develop'
- Feature branch 'feature/delete_sample' has been removed
- You are now on branch 'develop'

現在のブランチがdevelopになって、未pushとなっている。
pushすると、pushされる。
githubを見ると、「Compare & pull request」、というのが出てきた。
いかん・・・名前はよく見るのだが、なんだかわからない・・・。

それに、1回コミットしたものでしか試していないので、期待する「1回だけコミットしたように見える」が実現できたかどうか判断できない。
もうちょっと試してみます。

[nrf52]サンプルを動かす

買ったまま放置されていたnRF52 Preview Developer Kit(以下、nRF52 DK)だが、まずは書いてある通りに動かしてみよう。

こちらは、SoftDeviceがない、LEDを光らせるサンプルだ。
Getting Started

書いてある通りにやるだけ。
Keilのプロジェクトを開いて、リビルドして、ダウンロード。
ダウンロード前に、PCとnRF52 DKをUSBで接続しておかないといかん。
初めてダウンロードってのを使ったときだけかもしれないが、Firmwareをアップデートしますか？と聞かれた。
Strong recommandとか書いてあったのでOKすると、J-Linkの画面とかプログレスバーとかが出てきて、勝手に何かやってくれた。
そして、光り出した。順番に光って消えるというのを繰り返している。

 

次は、SoftDeviceありのサンプルを動かす。
まず、SoftDeviceを焼く(今はs132_nrf52_1.0.0-3.alpha)。
私はnRFgo Studioを使った。
焼くと、こんな感じ。

あとは同じ要領でKeilのプロジェクトを開き、RebuildしてDownloadするだけ。
BLE Snifferで見ると、ちゃんとAdvertisingした。
さすがCortex-M4だけあって、Advertisingも速いぜ(違います)。

 

そんな感じで、ボードはBLE含めて動いているようだ。
さて、次はnRF51822で作ってたサンプルを移植することですかね。

gitのGUIツールを選択するのに悩む

あんまり、gitに慣れていない。
自分一人でやるときはよいのだけど、プロジェクトで使うとなると不安がある。
なので、他のメンバーでも不安に思っている人もあろう。

そう思うと、GUIツールで「こうやればとりあえず大丈夫」というルールを用意しておきたい。
作るのがメインなので、履歴管理で失敗したりして時間がかかるというのは避けたいのだ。

以前は、WindowsはGit Extension、MacはSourceTreeでやっていた。
Linuxはコマンドラインだけど、ソースファイルの編集はSamba経由のWindowsでやっていた。
ソースファイルは、新規で作るものもあれば既存のものもあり、文字コードや改行コードは統一したいけど提供物も含まれていたりして勝手ができない感じ。

ありがちなのが、テキストエディタで保存するときに以前と異なるエンコード/改行コードで保存してしまった、というもの。
WinMergeで差分を見るようにしていたとしても、ちょうど設定が「改行コードを見ない」になっているのを忘れてて気付かずにコミットしてしまうとか。
差分ツールとしてWinMergeはかなりよいと思うのだが「一時的に設定を変更する」がないので、やらかしてしまうのだ・・・(そういうのできるのかしら？)。

ツールは、その人のスキルうんぬんよりも、使ったことのあるなしが大きいので、「今までプロジェクトがSVNだけだったので、gitは初めて」という人も多い。
なので、目線としては「えー、git使ったことないんですか－」ではなく「うんうん、git使ったことないですよね」で行きたい。
環境を強制するのだから、それくらいはしないといかんだろう。

---

と、前置きが長くなったが、gitのGUIツールについてだ。

私は今のところ、SourceTreeをWindowsで使っている。
無料だし、いざとなればMacでも使えるし。
ただ、重たい・・・。
gitのGUIツールは、グラフィカルに表示させようとするためか、基本的に重たい気がする。

あとですね、Git Flowを使いたいと思っているのだ。
前回gitで初めてプロジェクト管理をして、機能を依頼するごとにブランチ切ったり、リリースするとタグ切ったりってのをやっていたのだが、Git Flowの説明を見てるとだいたい同じことをやってくれるみたいだ。
SourceTreeにはアイコンもあるくらいだし、いいんじゃなかろうかね、と思っている。

会社だったら「Git Flowでやってみたいから、ちょっと試してみて－」とかできるんだけど、今は一人でやってるし、まだプロジェクトが始まる前なので誰もやってくれない。。。
なので、今のうちにいろいろ想定して、試せるものは試している段階だ。

---

git とGit Flowの位置関係がよくわかってなかったのだけど、Git Flowはあくまでローカル側のツールなのだな。
Git Flowでリポジトリを作っておけばよいというものじゃなくて、各人に「このリポジトリはGit Flowでやってるからね」と話をして、やり方まで決めておかないといかん。

まあ、プロジェクトを始める前にコミットルールとかも通知しないといけないので、「Git Flowに従います」とやっておくと、やり方がわからなくてもネットで調べてくれるだろう。
プロジェクト管理してると「こういうときはどうしたらよい？」という、実装とかじゃなくて運用について聞かれることが多いので、その辺が省略できるのはありがたい。

Git Flowはローカル側なので、リポジトリをcloneしたあと、自分の環境をGit Flow用にせんといかん。
SourceTreeだとアイコンを押すだけなので、そこが楽ですな。

 

ただ、重たい・・・。
うちのPCが、最後にCPUを変更して4年半くらい経つので、もう一般的なスペックより低いのかしら。

[nrf52]mbed Enabled ?

nRF52 DKのピン情報を見ていた。
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52.v1.0.0%2Fdevelopment%2Fhw_power_sup.html&cp=1_0_6_2

ん？

えっ？

うちの子には、そんなマークないよ！

 

ちなみに、反対側の隅にはSEGGERのマークが入っている。
P19がそれっぽい数で、溝もぴったりなんだけど、うちのJ-Link LITEには嵌め殺しというか、逆指し防止で1ピン埋まってるのですよ。
あれ・・・P18にも似たようなのがあって、こっちは「Debug Input」。P19は「Debug Output」。
どうやら、Debug Inputはデバッガを挿すところ、Debug Outputは自分がデバッグとなって相手に挿すところ、という違いのようだ。
だから、私がJ-Link LITEを挿したいとしたらP18のほうだった。
あぶないあぶない。

で・・・これはピンを折ってもよいのかな？
そこらへんは書かれていないようなのだ。
そういえば、On-BoardのJ-LINKもあるとかだったから、折る前に調べてみよう。

[nrf52][nfc]NFCでできそうなこと

nRF52832のドキュメントに、NFCTという章があった。
ざっと見た感じでは、NFCIP-1の106kbpsっぽい。
搬送波検知で起きたり、NFC-A形式のフレームデータをデコード/エンコードできるようなことも書かれている。

NFCIDは1で、サイズは4byte, 7byte, 10byteの全部をサポートしているようだ。
FICR(Factory Information Configuration Register)で定義できるらしい(NFCID1 partというレジスタもあるので、使い分けがあるのかな)。
全部の桁をユーザが定義できるかどうかまでは調べてない。。

あとはEasyDMAだのなんだのと書かれていた。
ちょっと詳細はきついな。

ただ、チップがサポートするのはあくまで「NFC-A」という無線の部分なので、タグとしてどう動かしたいかはアプリでサポートすることになるだろう。
TaskとかEventとかはnRF51と同じようにあるから、あとはがんばってゴリゴリと作るか、nRF52 SDKがType2 Tagとかをサポートするまで待つしかなかろう。
搬送波検知ぐらいだったら、割込と同じような感じで使えるのかもね(見てないけど)。

 

しかし、だ。
もし私が思ってるようにゴリゴリ作らんといかんのだったら、ゴリゴリ作りさえすればNFC-Aのタグを実装できるということになる。
そう、Type2だろうとType4だろうと、あるいは自分の好きなタグを作ろうとも。
まあ、自前タグを作ってもR/W側が対応できないと意味はないだろうがね。

 

そういえば、nRF52の説明で「ペアリングが～」と書かれていたが、別にペアリング専用の機能っぽいことは書かれていない。
そういう心配はしなくてよさそうだ。

[nrf52]届いたボード

BeagleBoardを頼んだときはかなり待ったのだが、nRF52のPreview DKは数日で届いた。

上側のコネクタはMicroUSBで、その裏側にはCR2032が付いていた。
白く延びているのは、電池を浮かせるための紙だ。

 

気になっているであろうNFCアンテナだが、これは本当にアンテナだけのようだ。
ぺらぺらで柔らかい。

ドキュメントを見ると、NFC-A Listen Modeをサポートしているとのこと。
Listenってどっちだっけ？と思ったら、自分の記事が見つかった。
タグは、Listen Modeだ。

で、このアンテナに付いてる赤と黒をどう挿せばよいのか？
1ピンマークが赤側になってるから、赤い方がR25のある方、黒い方がR26のある方だろう。
なお、NFCアンテナはGPIOと兼用？らしく、GPIOとして使いたい場合は0Ω抵抗をR25→R27、R26→R28と移動させるそうだ。
うーん、私には厳しい半田付けだ・・・。
まあ、NFCはデフォルトで有効だし、私もNFCは外さないつもりだからいいんだけどね。

ためしに電源を入れない状態でアンテナを挿し、Androidにかざして見たが、特に反応はしなかった。
そういえば、NFC-Aは無線方式だけなのだが、Tagの種類はどうなってるのだろうか？
うちのNexus7 2013は確かBroadcomのチップで、Mifare 1KのようなClassic系には反応しなかったと思う。

 

さて、USBケーブルを挿して、左側にあるSWをONにすると、LEDが光った。
そして、なんか知らないけどドライバがインストールされた。
BLE Snifferで見てみたが、何か出しているわけではない。
Androidをかざして見たが、やはり反応はない。

なお、Setting up the development kitによると、光ったのはStatus Lightらしい。
そしてインストールされたドライバは、MassStorageのようだ。

今日はここまで。

[nrf51]SSPをちょっとだけ動かす

BluetoothにSPPというプロファイルがあるが、それではない。
TOPPERS/SSPだ。

ちょうどarmv6_m_gcc – Contributed Softwareがあったので、ちょいちょいと変更できるかと思ったのだけど、Cortex-M0+だったのでベクタオフセットを変更できるレジスタが使われていたし、SysTickも使われていた。
nRF51822にはその辺がないので、ベクタテーブルは今と同じくRegion1の先頭に置き、タイマはそのうち載せることにした。
UARTのログ出力も対応方針を決めていないので、引き抜いた。
とりあえずタスクが起動するだけ、というものを動かすことにした。

その状態でビルドすると、このくらいだ。
.exeという拡張子になっているが、ELF。
TOPPERSはなぜか.exeなのだ。

arm-none-eabi-size ssp.exe
   text    data     bss     dec     hex filename
   2434       4     424    2862     b2e ssp.exe

えっと、

text : コード
data : 初期値あり変数
bss : 初期値なし変数

だそうだ。
あれ、初期値ありはいいとして、初期値なし変数もELFの中に入っているのか？
あるいは単に情報として表示しているだけで、ROM化したときには残らないのか？

---

気になったので、objdump -h で見た。

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000077e  00018000  00018000  00008000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000204  00018780  00018780  00008780  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000004  20002000  00018984  0000a000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          000001a8  20002008  00018990  0000a008  2**3
                  ALLOC
  4 .ARM.attributes 0000002d  00000000  00000000  0000a004  2**0
                  CONTENTS, READONLY
  5 .comment      00000070  00000000  00000000  0000a031  2**0
                  CONTENTS, READONLY
  6 .debug_line   000012a5  00000000  00000000  0000a0a1  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_info   00002755  00000000  00000000  0000b346  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_abbrev 00000e19  00000000  00000000  0000da9b  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_aranges 00000180  00000000  00000000  0000e8b8  2**3
                  CONTENTS, READONLY, DEBUGGING
10 .debug_loc    00000b7a  00000000  00000000  0000ea38  2**0
                  CONTENTS, READONLY, DEBUGGING
11 .debug_str    00000dd1  00000000  00000000  0000f5b2  2**0
                  CONTENTS, READONLY, DEBUGGING
12 .debug_frame  00000350  00000000  00000000  00010384  2**2
                  CONTENTS, READONLY, DEBUGGING
13 .debug_ranges 00000180  00000000  00000000  000106d4  2**0
                  CONTENTS, READONLY, DEBUGGING

sizeコマンドがtextで表示しているのは、text + rodataだ。
なので、純粋にROMとしてはこのサイズになるはず。
dataやbssはアドレスがRAMになっているから、ROMからは除外されるだろう。

---

これをnRF51822に焼いて、サンプルのhello_worldのログ無し版のタスク呼び出しまでは確認できた。
元々はログにHello Worldを出すだけのサンプルなので、それのログ無し版となると中身がないのだ・・・。

さて、これにnRF51 SDKを組み合わせないと意味がない。
Advertisingくらいまで動けばよいのだが、まずはベクタテーブルを解決せんといかん。
nRF51 SDK v8.1.0を見る限りでは、components/drivers_nrfがハンドラを持っている。
それをSSPで置き換えないと、OSが割込を管理できないのではないかと思う。

思うのだが、そもそもSoftDevice自体がかなりOSっぽいことをしているので、その流れは変えたくない。
じゃあ、RTOSを入れなくてもいいやん、となってしまい、頭の中がぐるぐるしている。

まあ、もう少し粘ってみますかね。

ARMのSVC

ARMのSVCは、旧名SWIらしい。
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204ij/Cihidabi.html

Thumbの場合は8bitで、ハンドラとしては引数に番号が載っているだけのようだ。
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0203gj/Cihdhefa.html

で、その番号でswitch-caseして処理を呼ぶ、と。
それなら、nRF51の番号とOSの番号が重ならなければよいはず。

ただ、ARMのベクタテーブルは0x0000から始まっていて、そこはSoftDeviceが握っている。
SVCのベクタテーブルは11番目なので、アドレスとしては0x2C。
SoftDeviceのHEXファイルを見ると、51070000。リトルエンディアンでThumbなので、0x0x0000_0750。
うーん、まだSoftDeviceの中だ。

STM32にはベクタテーブルのアドレスを移動させるような機能があったけど、あれはSTMだけなのかなぁ。
いや、そういうレジスタがあるらしい。
http://www.aps-web.jp/academy/cortex-m/18/
が！　Cortex-M0にはなさそうだ・・・。

M0+だと、System Control Blockの中にVector Table Offset Registerという項目があるのだ。
ってことは、M0にはないんだろう。

リセットしたときの動作しか見ていないが、一度SoftDevice側のハンドラが動いて、そこから自分でビルドしたリセットハンドラが呼び出されているようだ。
ということは、SVCも同じで、nRF51 SDKに従って素直にSVC_Handlerを作っておけば、SoftDeviceが自分でやりたいことをやった後でこちらのハンドラを呼んでくれるんじゃないかな。
であれば、OS側のソースが全部こっちにあるなら、処理番号だけ重ならないようにしておくだけで済みそうだ。

SoftDeviceの処理番号は、nfc_soc.hにある。
SOC_SVC_BASE(0x20)～SVC_SOC_LASTが使われるようだから、そこだけ避ければよいかな？
・・・いや、ble_ranges.hを見ると、0x60以降も使っているようだ。
じゃあ0x20以前ならよいかというと、nrf_mbr.hだと0x18を使っているみたい。
nrf_sdm.hだと0x10がベースになってるし。。。
うーーん、どこが空いてるんだ？？？

 

SSPのARM-v6M依存部分を見ていたが、SVCが使われていないように見える。
exc_entryが呼ばれるようなのだけど、exc_tbl[]に従って飛ぶだけのような感じがする。
そして、exc_tbl[]の11番はデフォルトのハンドラっぽい。
そもそも、このテーブルは15番と19番以外が使われていないので、未使用なんじゃないかなあ。

まあ、動いても動かなくても、締め切りがあるわけでもないからいいか。

[nrf51]RTOSを載せるのはひどく面倒そうだ

お仕事で、uITRONを使いそうな気配がある。
私、OSありの仕事ってやったことがほとんどないのよね・・・。
ちょっとは慣れておいた方がよいだろうと思い、家でTOPPERSでお勉強をしようと思った。

ただ、どのプラットフォームでやるかが悩みどころだ。
どうせなら、nRF51822で動かせた方が面白いだろう、と思い、SSPの情報を探した。
https://dev.toppers.jp/trac_user/contrib/wiki/armv6_m_gcc
ここに、Cortex-M0+に移植したものがあるから、これをベースに持ってきてみよう。

と思って調べていたのだが、ネックが出てきた。
SVCだ。
OSだから、何かするときはSVCで飛ばすようになっている。
しかし、nRF51ではSoftDeviceがSVCを使っている。
やりたいなら、単に移植するだけじゃなくて、SVCハンドラをうまいことやってやらないとダメそうだ。
nRF51のリファレンスマニュアルを見ると、割込み優先度もひっくるめて設計してあるようなので、ハンドラを移植できたとしてもBLEが正しく動かせるかどうか心許ない。

 

OSを使ってる人がいないか検索すると、uCXpresso.NRFというものがあるらしい。
https://devzone.nordicsemi.com/blogs/344/now-ucxpressonrf-provides-the-free-evaluation-lice/
でも、他のモジュールで使うのは難しいらしく、インストール自体めんどくさいらしい。
Hobby Electronics: もう１つのNRF51822 オフラインコンパイラ(uCXpresso.NRFを試してみる：インストール編)

FreeRTOSってのもあるらしい。
https://github.com/nocko/FreeRTOS8.0.1-nrf51-softdevice
へー、nRF51ってSysTickがないんだ。

nRF51822は別によいのだけど、nRF52だと大きいプログラムを載せることもありそうだから、そろそろRTOSなんかがないとつらい気がしている。
SSP自体はSysTickもオプション扱いだから、SVCだけうまいことやれば移植できるのかな？
まあ、SVC自体よくわかってないので(SW割込というイメージだけど)、そこからですな。

[tech]ドライバ以上、ミドルウェア以下

組込みだけかもしれないが、ドライバから見ると「おまえアプリだろう」で、アプリからすると「おまえドライバだろう」みたいな立ち位置の部分がある。
一般的には「ミドルウェア」と呼ぶ気がする。

レジスタをたたくようなところはドライバでよいだろうし、機能を動かすならアプリでよいだろう。
じゃあミドルってどうよ？と思う。
私のイメージだと、ドライバが提供するものをアプリが使いやすいように加工する階層なんだけど、どちらかといえばアプリ寄りで、かつおしゃれな感じがしている。

たとえば「ファイルシステム」とか。
ファイルシステムがおしゃれかって言われると困るのだが、ドライバをよく作る立場からするとなんとなくおしゃれ感がある。
たぶん「データベース」なんかもそうだ。
中で何やってるのかわからないけど、とりあえずインターフェースを提供してくれるという秘匿な感じをおしゃれと思ってしまうのかもしれない。

まあ、私のおしゃれ感はどうでもよいとして。
そういうものよりも、もうちょっと地面に近い階層があると思う。
たとえば「LED制御」とか。
LEDはGPIOと直結してて、PWMとかは抜きとして、ONとOFFだけなら1行で書けるくらいだ。
でも、アプリでそういうのを持ちたくないので、別関数にしてしまいたい。
「ドライバ」と分類してもよさそうな気はするのだが、GPIOのドライバがいたり、点滅でタイマを使ったりすることを考えると、ドライバよりも少し上の層の方がしっくりくる。
くるんだけど、ほどよい階層の名前が思いつかない。。。

ラッパー(wrapper)といえばラッパーだけど、純粋なラッパーでもないし。

そういえば、この辺ってOSがいる階層だな。
nRF51だとあまりOSを載せる気はないのだが、nRF52だと余裕があるから載せるかもしれない。
というわけで、OSとかフレームワークの層ということにしよう。

LEDがフレームワークかよ、と思われそうだが、よかろうなのだ。

[excel]Excel2013でエクスプローラでの新規作成を変更したい

※注意※
私の環境でのパスは、Click to RunでExcelをインストールした場合のようです。
C:\WINDOWS\ShellNewになるパターンもあるようなので、コメントをご参照ください。

もう、Excelってカテゴリを作ってしまった。
自分で忘れてしまうのでね。

Excel2013を使っているのだが、エクスプローラの「新規作成」としてファイルを作ったとき、自分の作ったファイルで新規作成できていないのだ。
検索するといろいろ出てくるのだが、なんかうまくいかないので調べつつやってみる。

ShellNewHandlerというツールで見てみると、以下のレジストリが新規作成で使われている。

C:\Program Files\Microsoft Office 15\Root\VFS\Windows\ShellNew\excel12.xlsx
なので、このファイルを変更するとよい。
管理者権限がいるので、うまいことやること。

このファイルに、よく使うテーマを反映させ、既定のテキストボックスなどの設定を済ませておくと、エクスプローラで新規作成したExcelファイルにもそれが最初から反映される。

それはよいのだが、Excel内で「空白のブック」を選んで新規作成した場合は微妙に違うようだ。
セルの方は反映されるのだが、テキストボックスの設定は反映されていないように見える。
なんだかよくわからないが、自分用のカスタムテンプレートを作って新規作成させた方が無難なようだ。

[excel]「既定のテキストボックスに設定する」はファイル単位のようだ

Microsoft Officeシリーズの中で、Excel2013だけは買った私。
文字と絵が貼り付けられて広さが固定されていないとなると、なんかExcelくらいしか思いつかなかったのだ。
Libre Officeも使っていたのだけど、なんかこう直感的じゃなくて。

そのExcelだが、テキストボックスや図形に「既定に設定する」という選択がある。
既定っていうからには、デフォルトの動作が変わるのだろう。
このファイルだけこうしたいのだけど、普通はそれだと困るからなあ、と思い、あまり使っていなかった。

が、さっき試すと、既定の範囲はファイルのようなのだ。
シートが変わっても維持されるが、別のファイルだとまた元に戻る。
なんだ、そういう仕様だったんだ！

既に作っているテキストボックスには影響がなく、新しく作ったものに反映される。
フォントとフォントサイズも既定として設定ができる。
フォントを変更して既定とした場合は、テーマを変更しても影響を受けない。
逆に言えば、フォントを変更して既定としないと、テーマの影響を受ける。
今のテーマと同じフォントで固定したいは、フォント選択で「テーマのフォント」になってないところから選ぶとよさそうだ。

今までなんとなくで使っていたので、たまには仕事と関係ないところでこういうのを調べておかんとね。

[nrf]nRF52シリーズが発表された

いま私が使っているのはnRF51822で、nRF51みたいなシリーズになっている。
昨日、nRF52シリーズが発表されていた。

nRF52832 - Bluetooth Smart - Products - Nordic Semiconductor

まだ私もBLEでは若輩者に過ぎないので(歳は食ってるが)、nRF51がどのくらい経っているのかとか、市場での立ち位置とかは知らない。
nRF51822は、Cortex-M0が載っていて、16MHzくらいで動く。
16MHzっていうと、私がPC98のノートPCでWindows3.1を使っていたときも16MHzだったような。
クロック数が同じだけとはいえ、しみじみしてしまう。

さてnRF52だが、まずはnRF52832というチップが出るようだ。
今度は、Cortex-M4F。
「F」が何かは調べてないけど、Cortex-M4は信号処理系が強いイメージがある。

そして、FLASHが512KB、RAMも64KBある。
これもSoftDeviceが載るというところは同じなようだ。
そのサイズがどれだけかはわからないけど、512KBというのは広い。
Keil MDKの制限が32KBだったと思うから、製品版を買ってしまうか、GCCにするのがよいかもしれんな。

で、興味深いのは、OOB(Out of Band)のペアリングとして、NFCタグが標準装備になっている。
標準装備というか、NFC-Aと書いてあるから7byteのUIDが異なるように発行されるのかいな？

どんな感じなのか、ちょっと興味が湧いてしまった。

おや、nRF52 Preview DKという評価ボードがあるらしい。
チップの発売はまだ先だったと思うから、評価ボードという位置づけなんだろう。
じゃあ、手に入るのはまだまだ先・・・・

あれ、BUYってボタンがある。
ほほう、DigiKeyでも取り扱ってるんだ。
そういえばアカウント持ってたな。
どんなのか見てみよう・・・・

ふーん、そんなに高くないんだ。

あれ、買ったの、わたし？？

夜って怖いな、そう思った私であった。

ExcelでSmartArtな階層図を作りたい(が、できてない)

たまに、こんな感じの図を作りたいことがある。

詳細なわけでもなんでもないけど、それとなく全体がわかったような気にならなくもない図だ。
とりあえず、わかりやすいパーツを並べて、それを秩序だったように見せるのだ。
私はソフト屋さんだから、ハードに来るものさえ全部列挙できてしまえば満足なのだ。
「新しく増えたら、再見積もりするよ？」みたいな防御ですかね。
それだけではなく、開発ドキュメントの最初の方に載せておくと、後から入った人がイメージがつかみやすいかもしれない。
始まる前でも、意識が合いやすいかもしれない。
最近は開発サイクルが早くなって、ドキュメントなんて書いてないかもしれない。
まあ、私も同じような仕事しかやっていないので一般論は書けないのだけど、組込み関係だと製品寿命が長くなりがちなので、ドキュメントがないと「これを開発していた人は誰もいません」ということが、しばしばある。
開発サイクルっていうより、人のサイクルが早くなったのか？
それに「このタイミングで割込が入ると、まだこの機能が使えないかもしれないのでもう1回だけスリープさせて」みたいな、特定のハードウェアなどに依存した実装があると、ソースファイルだけ見ても、またそこに詳しいコメントがある程度書いてあったとしても、タイミングチャートとかと一緒に説明しないとわからんだろう。

---

いかん、脱線した。
とにかく、上のような図を描きたい。
そういいつつも、これもExcelで描いたのだけど、単にテキストボックスなどに色を付けただけだ。
そうじゃなくて、自動的にやってほしいのだ。
SmartArtで。
イメージしたのは、Androidの階層図。
あれ、今は図が変わったのかな・・・。

---

程よさそうなのは、「カード型リスト」だったのだが・・・
これは、2行分作ってみた例。

私の理想は、「取りあえず横幅はいっぱいに使う」なのだ。
ああ、近いのはAndroidで横にボタンとかを並べたときだ(LinearLayout?)。
これだと、ちょっと寂しいなあl。
「グループリスト」もよさそうだったけど、これは縦方向だけしかなくて。

ドライバはみんなに使ってもらうものだ！と思うと、縦割りにされると哀しい。
なお、「左右交代積み上げ画像ブロック」は、3列があって、1行目は1列：2列、2行目は2列：1列、3行目は1列：2列、・・・というようｒに、交互に並ぶだけだった。
「積み木型の階層」はよさそうだったけど、階層になってしまう。
ちょっと、イメージと違うな。


そんなわけで、いろいろ試したが、Excelでソフトの階層図を作りたかったら、自前で描くのがよさそうだ。
まあ、階層といっても意味的な上か下かしかないので、しかたないか。

[nrf51]pstorageがいくつもある

nRF51 SDKは、いろいろとAPIやライブラリがある。
把握しようとしても、数ヶ月ごとに新しくなり、しかも内容が変わっているので、把握する気になれない。
とりあえずBLEに直接関係あるところだけ、とも思っていたのだが、それですらざくざくと変更が入っていく。
正気を保てているのは、仕事でやっていないから、というだけじゃなかろうかとすら思ってしまう。

最近、アドバタイジングするチャネルを選択できるという餌に吊られてSoftDevice v8.1.0系に対応しようとしている。
とりあえずの移植だけは出来たのだが、気になることがある。
アドバタイジングするとき、pstorageのAPIを呼ぶようになってしまったのだ。

 

pstorageは「Persistent Storage Manager」の略のようで、日本語に直訳すると「永続的なストレージ管理」だろう。
字面から受けとるイメージとしては、Non-Volatileなメモリ、例えばE2PとかFLASHとかに、ファイルシステムとまではいかないにしても、なんらかの管理用メモリを持つということじゃなかろうか。
複数のデバイスからCONNECTされる前提だったり、そうでなくても前と同じデバイスから接続されたら続きから始めたいということもあるだろうから、Peripheral側でも何らかの管理情報を持ちたいことはあるだろう。

そういう事情があったとしても、接続相手の情報がどうのこうのというのはアプリで管理するものであって、BLEの下回りが自動的にやるようなものじゃないんじゃなかろうか・・・。
あるいは、無線の法律的な関係で、最後に無線を送信してからある程度の休止期間が必要、ということを考慮したものであろうか・・・(BLEじゃないお仕事では、そういう考慮もしてた)。

---

まあ、細かい考察は置くとして、今回はpstorageだけについて考えたい。
何を考えるかというと、「どのpstorageを使えばよいのか？」だ。

何を言っているのかわからないと思うので、ファイル構成を載せよう。

私はnRF51822をGCC+Makefileで使っているのだが、他のIDEを使っていたとしても同じだろう。
nRF51822でアプリを作る場合、構成としては、

自分のアプリ＋nRF51 SDK＋SoftDevice

とする場合がほとんどだと思う。
SoftDeviceは事前にnRF51822に焼き込むからよいとして、nRF51 SDKはソースファイルで提供されている。
だから、その機能を使いたい場合、自分でビルドしなくてはならない。

そして、nRF51 SDK v8.1.0のcomponents/ble/ble_advertising/ble_advertising.cにあるble_advertising_start()ではこうなっている。

このファイル内で"pstorage"がついているのはこれだけなので、このためだけにpstorageをリンクせねばならない。
どこに定義があるのだろうとgrepした結果が、これ。

pstorage.cと、pstorage.nosd.cにあるのだ。
さて、どっちをリンクするように設定したらよいのだろうか？

---

検索して、唯一出てきたのが、これ。
https://developer.nordicsemi.com/nRF51_SDK/nRF51_SDK_v7.x.x/doc/7.0.1/s110/html/a00086.html

表の3行目に出てくる。

無線系のチップなので、アプリ側で処理を占有してしまったりすると、きっと通信エラーなどが発生するだろう。
優先度は無線側に強く割り当ててあるとは思うが、OSを使っているわけでも無いのでやろうと思えば何でも出来るはず。

そもそも、「nosd」は、「NO SD」という意味なのだろうか？
NO Storage Device ?
NO SD card ??
解釈はいろいろと出来てしまう。

でも、nosdの方にも、flashなんちゃらというAPIが使われているので、なんだかもう、探るのが嫌になってしまった。
pstorageを使うつもりがなければ、適当にpstorage_access_status_get()を実装してしまって、無条件でSUCCESSを返してしまえばよいのではなかろうか、と思った。

こういう不透明なところが、扱うのが難しいところですな。

[nrf51]構成に悩む

nRF51822で、InputとOutputだけのサービスを持つ自分用テンプレートを、SoftDevice v8.1.0に対応した。

https://github.com/hirokuma/nrf51822_templete_v810

 

まだほとんど動かしていないが、アドバタイジングするのと、CONNECT/DISCONNECTでLEDが変わるところだけ見た。
つまり、サービスの動作はまったく見てないのだ・・・。

個人的な課題としてずっと残っているのだが、あまり構成に関する設計が得意じゃなくてですな。。。
「これはドライバだからこう」とか「アプリだからこう」みたいなのが、ぐちゃぐちゃになっている。
なるべく分けるようにしているのだけど、今回だとSoftDeviceとBLEのところをどう切り分けるか、とか、BLEからのコールバックをさらにアプリへコールバックするとき、アプリから登録してもらうようにするか、あらかじめ名前を決めておいてアプリに実装してもらうようにするか、とか。

特に、コールバックについては、登録制にするとお互いが独立して汎用性は高くなるんだろうけど、その分の実装サイズも増えるし、保持しておくRAMも増えてしまう。
それくらいだったら、名前決め決めでやってしまった方がやさしいのでは・・・、などと考えてしまう。
この辺がダメなのかしら。。。

ひとまず今回のコミット#2では、ドライバ類をラップしたものをdrivers.c,hに、BLE関係をapp_ble.c,hにまとめることにした。

---

以下は、愚痴だ。

nRF51 SDKには、BLE関係のAPIなどがある。
これの名前が「ble_」で始まる。
こんなありがちな名前を付けられたら、アプリ側は名前が付けにくいじゃないか！

Bluetooth Low Energyの略で、BLE。
それはわかるのだが、頭に「nrf_」をつけるなどして、これはnRF51 SDKのAPIなんだ、とわかるようにしてほしかった。。。

じゃあ、とアプリで使う方に「app_」とつけるようにしたんだけど、これはこれでlibrariesに「app_button」なんかがあるので、紛らわしくなってしまった。
librariesなら「lib_button」とかにしてくれよ！

悩める私であった。

[nfc]Broadcom ?

久しぶりに、NFC関係で目を引いたニュースがあった。

Broadcom licenses Mifare • NFC World+

 

ちょっと、企業の位置関係がわからなくなっているので、整理してみよう。

まず、MIFAREのNXP社。
Mifare
NXPはオランダのフィリップス社の半導体部門が分かれたもののようだ。
HP社のAgilentみたいなものか。
まあ、説明はいらんだろう。

そしてBroadcom社。
無線に強いチップメーカー、というイメージだ(私の中では)。
Raspberry-Piの初代もBroadcom社のチップが使われているし、確かNexus7 2013もBroadcom社のNFCチップが使われていたんじゃなかったっけ。
そうそう、NFC Forum分類でのTag Type 1のTopazも、今ではBroadcomが持ってたはずだ。

そこで、こんなニュースが上がっていた。
これは、2015/5/29のものだ。
ニュース - 整理統合が進む半導体業界、AvagoがBroadcomを370億ドルで買収へ：ITpro
Avago社なんて知らんなぁ、と思ったが、Agilent社からスピンオフした会社らしい。
なんだかもう、訳がわかりませんな。。。

[nrf51]特定CHでのAdvertising OFF

SoftDevice v8に対応して、まずやりたかったこれを試した。
hiro99ma blog: [ble][nRF51]selectable advertising channel ?

やり方は簡単で、Advertisingのパラメータとしてメンバが増えているので、そのメンバのフラグを立てるだけ。
Githubにさっきコミットしたので、差分を見るとわかるだろう。

今回は、38CHと39CHのフラグを立て、37CHだけAdvertisingが出てるかを確認した。
うん、ちゃんと38CHと39CHは抑止されていた。
これで、BLEモニタで接続後も安定してパケットが取得できるというものだ。

 

なんとなくだけど、スマホアプリでCONNECTしようとすると、時間がかかるようになった気がする。
ただ、単にAdvertisingを1秒周期でしかやってないから捉まえられなかっただけかもしれない。
実装中しかそういうことはしない予定なので、気にしないけどね。

[nrf51]sd_ble_gap_ppcp_set()でパラメータエラー

わからん・・・。

v8でリンクが通るようにまでできたのだが、sd_ble_gap_ppcp_set()でINVALID_PARAMが返ってきてしまう。
SoftDeviceの中でエラーを返しているようなので、何がどう悪いのかがわからんのだ。

v7で動いていたところで、v8になってパラメータが変わったわけでもない。
ということは、v8になったことでやってやらないかんことがあるのか？
でも、sd_ble_gap_ppcp_set()なんて最初の方で呼ぶものだから、特になさそうだしなぁ。

 

実はここに至るまでも、SoftDeviceのサイズが変わったことでリンクのアドレスが変えないといけないことに気付かずに時間がかかっていた。
あとはすんなりいってくれることを期待したのだが・・・。

---

いろいろやってみたが、結果としては値がよくなかったようだ。

connIntervalのminとmaxを、それぞれ1秒と4秒にしていたのだが、これが原因らしい。
hrsサンプルでは400と650だったので、それにすると通った。

が、だ。
connIntervalの仕様としては、7.5msec～4secだ。
Core_V4.2を参照し直したが、変わっていない。

1.25msecの倍数で、最小値は6=>7.5msec、最大値は0xc80=3200=>4000msec。

以前はこの値で動いていたから、SoftDevice v8.0.0のバグか？と疑ったが、だいたいこういうのは自分が間違えている。

"Vol.6 Part B - 4.5.2 Supervision Timeout"に、値の範囲は100msec～32secで、(1 + connSlaveLatency) * connInterval *2より大きいこと、とある。
このconnIntervalをminの方と思っていたのだが、どうもmaxのようだ。
私はconnSlaveLatencyを0、Supervision Timeoutを4秒にしていたので、この条件に引っかかっていたようだ。

 

はあ、疲れた・・・。
nRF51 SDK v8.1.0対応したFelicaLinkアプリをGitHubに置いた。
https://github.com/hirokuma/nrf51822_felicalink_v810

リポジトリ名にSDKのバージョンまで書いておかないと、管理できんな。
ブランチで分けるって手もあるんだろうけど、ぐしゃぐしゃになってしまいそうだ。

---

Supervision Timeoutの範囲チェックはもう1つあって、これもconnSlaveLatencyとconnIntervalMaxを使う。
私はこの判定式を、

connSupervisionTimeout * 8 > connIntervalMax * (connSlaveLatency + 1)

としていたのだけど、nRF51 SDKでは

connSupervisionTimeout * 4 > connIntervalMax * (connSlaveLatency + 1)

と書いてあった。
GitHubにアップした方は4にあわせたんだけど、そもそもこの式はどこから出てきたんだっけ？
Core_v4.2を探しているけど、見つけられない・・・。

[nrf51]GPIOTE再び

前回、たぶんSDK v6かv7のときに、これを書いた。
hiro99ma blog: [nrf51]GPIOとGPIOTE

v8になって、ふと心配になり、もう一度調べ直した。
nRF51 GPIOTE

当たり前だけど、nRF51 SDKとは関係なく、nRF51系のチップ仕様に関わることなので、v7だろうとv8だろうと書く内容に変わりは無い。

だから、次はv8に特化したことを調べることになるか。

---

ピンの変化に対するサンプルコードは、2つある。

• gpiote
• pin_change_int

clockとかqdecでも使ってはいるが、機能説明として使っているのは上記2つだろう。

 

pin_change_intサンプル

• nrf_drv_gpiote_init()
• nrf_drv_gpiote_out_init()
• nrf_drv_gpiote_in_init()
• nrf_drv_gpiote_in_event_enable()
• イベントループ

TaskとかEventとかが出てこない。
あまり中は読んでないが、nrf_drv_gpiote_init()でnrf_gpiote_int_enable(GPIOTE_INTENSET_PORT_Msk)を呼んでいるので、ここでPORTの割込を有効にしているのだろう。
そしてGPIOTE_IRQHandler()でPORTレジスタを見ているので、指定したポートからの割込かどうかを判定しているのだろう。

INとかOUTとかも見ていないので、TaskやEventの制約である「4つまで」には関係なく使えそうだ。

 

gpioteサンプル

こちらは、pin_change_intサンプルと比べるとわかりづらい。
LEDを点滅させたい感じはするのだが・・・。

• nrf_drv_ppi_init()
• nrf_drv_gpiote_init()
• nrf_drv_timer_init()
• nrf_drv_gpiote_out_init()
• nrf_drv_timer_extended_compare()
• nrf_drv_ppi_channel_alloc()
• nrf_drv_timer_event_address_get()
• nrf_drv_gpiote_out_task_addr_get()
• nrf_drv_ppi_channel_assign()
• nrf_drv_ppi_channel_enable()
• nrf_drv_gpiote_out_task_enable()
• nrf_drv_timer_enable()

あきらかにタイマのAPIもあるのだが、PPIがよくわからないので全部書き出した。
点滅させるからタイマを使うのはわかるとして、PPIはなんだろう？

PPIはてっきり「PeriPheral Interface」の略だと思っていたが、Programmable Peripheral Interconnectのことらしい。
あぶないあぶない(SlideShareはさっき修正した)。
これはEventとTaskを接続する機能のようだ。
ここでは、TIMERのEventとGPIOTEのTask(TOGGLE)を接続している。
こうしておくと、タイマのイベントハンドラを書かなくても、タイマが満了したら勝手にGPIOのピンをトグルするようになる。
へー。
すぐに用途は思いつかないが、覚えておいて損はあるまい。

GPIOTEのTaskは何に使うんだろうと思っていたが、こういう感じで使えるという例なのだろう。
なので、単に割込として使いたい場合はpin_change_intサンプルを参考にするのがよさそうだ。

---

さて、gpioteサンプルで謎だったのが、これ。

*(uint32_t *)0x40008C0C = 1;

TIMER0のアドレスは0x40008000からなのでタイマ関係のレジスタだとは思うが、リファレンスマニュアルにはオフセットが0x54Cまでしか割り振られていないので、何だかわからない。

ネットで検索すると、Product Anomaly Noticeのドキュメントが出てきた。
PAN ID 73で、どうもバグっぽい。
「GPIOTEかRTCのTASKをトリガとしてTIMERモジュールのEVENTを使おうとするとうまくいかん」みたいなもののようだ。
TIMERモジュールの0, 1, 2でそれぞれ0x40008C0C、0x40009C0C、0x4000AC0Cがあって、タイマを使うときに1、いらなくなったら0にするようだ。
サンプルを見たから気付いたけど、知らなかったらすごく悩んで、最後にPANを読んで知る、みたいなパターンになりそうだ。

PAN v3.0になって追加されてるっぽいが、IC revに関係なく起きるってことだろうか？
そう思ったときに調べるのが、Compatibility Matrixだ。
PAN v3.0はIC revが3だから、私が持っているIC rev2では起きない現象なんだろう。

[nrf51]SDK v8のGPIOTE

nRF51 SDK v7で作っていたサンプルをv8で動くように移植しているが、なかなか進まない。

APIの引数に増減があったり、定義名に変更があったりはコンパイルレベルでわかるからまだいい。
困っているのが、やり方が変わったタイプだ。

今直面しているのは、GPIOTEだ。
nRF51822は割込の検出として、TaskとEventというしくみを使っている。
GPIOの割込機構がGPIOTEというわけだ。

v7まではこれを、app_gpioteというライブラリでやっていた。
nRF51 SDK - S110 SoftDevice: GPIOTE handling library

v8にもapp_gpioteはあるのだが、サンプルソースをgrepすると消え去っていた。
その代わり、nrf_drv_gpioteというドライバに移行しようとしているようなのだ。
nRF51 SDK - S110 SoftDevice: GPIOTE

GPIOなんかはドライバでやるのがよいとは思うのだが、なんでまた急に。。。
リリースノートを見ると、v8でも、v8.1.0からそうなったようだ。
https://developer.nordicsemi.com/nRF51_SDK/nRF51_SDK_v8.x.x/doc/8.1.1/release_notes.txt

ドライバが出来て、サンプルもできたってことは、ライブラリは将来的に消えるのだろう。
黙って従うのがよいか。

 

もう1つ、ライブラリだったものでドライバが追加されたものがある。
TWI、つまりI2Cだ。
FeliCa Link使うときに、TWIも使ってしまったのよね。
まだまだ移植には時間がかかりそうだ・・・。

Windowsで`pwd`したいときは%CD%

普段、Windowsで作業している。
いまはnRF51 SDK v8に対応しようとしているのだが、ちょくちょく構造体のメンバがわからずに確認している。

grepでも探せるのだが、めんどくさいのでタグジャンプで対応したい。
でも、タグを付けたいのはcomponents以下だけで、examplesなどはいらない。
じゃあ、絶対パスでタグファイルを作って、それを移動させればよかろう。

 

絶対パスでctagsのタグを作るのは、こんな感じらしい。
ctags絶対パスで作成 - Webエンジニアの技術メモ　～PHP、SQL、Linuxなど～

何度もやってる作業なんだが、毎回忘れてしまう・・・。
まあそれはよいとして、問題は`pwd`。
Linuxだとそれでいけるのだが、Windowsだとどうやるんだろう？

調べると、%CD%で見えるようだった。
> ctags -R %CD%

よかったよかった。
Windows Live Writerでアップできるようになったのも、よかった。

[nrf51]すべてを疑う

以前も、悩んだ。
そして当時は、もうバージョンを上げない、という選択をした。
hiro99ma blog: [nrf51]SDK v8.0になって、また仕様が変わる


しかし、また私は「バージョンを上げる」という宣言をしてしまった。
当時の記憶はないのだが、音を上げるくらいには大変だったのだろう。
もう一度やっているが、やっぱり音を上げそうだ。
　・フォルダ構成が違う
　・ファイル名が違う
　・APIの引数が違う
　・マクロ名が違う
　・構造体メンバが違う
v7.2.0からv8.1.0なのだが、もう別物と思えるくらいに違うのだ。

なんとか残り2ファイルくらいまでになったところで、はたと不安になった。
もしかすると、 APIの使い方も変わってきているのでは・・・？
これだけ変わってるのだから、その可能性は否定できない。

しかし、そこを疑うということは、今まで積み上げてきたものが崩壊しかねない。
しかねないのだが、疑ったまま作業するのも嫌だ。

すべてを疑う・・・刑事の哀しい性だ。
明日は、疑うところから始めよう。

[ble][nRF51]selectable advertising channel ?

SlideShare用に資料を作っている。
Bloggerのエディタで画像を貼るのが面倒なら、そういう資料を作ってアップロードするだけにすればいいんじゃないの、ということで、しばらくこのスタイルでやってみることにした。
手元にファイルとして情報が残るという利点もある。

その際、どうしても「SoftDevice / nRF51 SDKのバージョンが変わるとめんどう」ということを書きたかったので、そもそもバージョンアップで何が変わったのかを見てみることにした。
私はv7までで止まっているので、v8の内容を見てみよう。

https://www.nordicsemi.com/eng/Products/S110-SoftDevice-v8.0

ふんふん、と読んでいたのだが、その中に「Selecting which advertising channels will be used」という項目を見つけた。
これはもしかして、私が探し続けていた機能では・・・。

https://developer.nordicsemi.com/nRF51_SDK/nRF51_SDK_v8.x.x/doc/8.1.0/s110/html/a00253.html

37ch, 38ch, 39chをOFFにする指定ができるように見える。
これがあれば、BLEモニタで悩まずに済む！

悩むのは、今のSDK v7用に作ったMakefileをまたいじる気力があるかどうかだ。
でも、モニタできずに苦労するくらいだったら、今のうちにやっておくか・・・。