[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番以外が使われていないので、未使用なんじゃないかなあ。

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