2015/04/18

[nrf51]GPIOとGPIOTE

GPIOはよいとして、GPIOTEというのはあまり他のマイコンでは見られない周辺機能だと思う。
nRF51822には、そのGPIOTEがある。


まず、GPIO。
General Purpose Input/Outputで、これは他のマイコンでもおなじみだ。
nRF51822には32本のGPIOがある。
それぞれのピンは独立していて、設定もそれぞれにできる(PIN_CNF[n]レジスタ)。

  • DIR(InputかOutputかの方向)
  • INPUT(inputバッファに接続するかどうか。使わんなら切断しとくと省電力に貢献)
  • PULL(プルアップ/プルダウン/なし)
  • DRIVE(他周辺機器用?)
  • SENSE(入力の1/0検出レベル)

リファレンスマニュアルの図を見ないと、意味がわかりづらいと思う。

ビットをセットするだけのレジスタとクリアするだけのレジスタがあるので、自分で読んで論理演算操作しなくてもよい。
これができないと、アトミックな操作ができなくて面倒なことがあるのよね。

SENSEは、次のGPIOTEに関係していると思う。
あるいは、WFI/WFEの解除トリガになってくれるのかもしれないが、Peripheral interfaceの図を見ると、NVICにつながっているのはEVENTになっているので、DETECTがアサートされただけでは解除されないと思う。
DETECT線へ通知するとは書いてあるんだけど、これがどうなるかまでは書いてないのだ。


GPIOTEは、GPIO Task and Eventの略。
だから、TaskとかEventとかの概念があるnRF51822くらいしか持ってないんじゃないかと思う。

Taskはアプリ→周辺機器方向への要求で、こんなのができる。

  • SET
  • CLEAR
  • TOGGLE

まあ、こんなもんでしょうな。

Eventは周辺機器→アプリ方向への通知で、こんなのが来る。

  • 立ち上がりエッジ
  • 立ち下がりエッジ
  • 変化あり

まあ、こんなもんでしょうな。
CONFIGで設定ができるが、2bit分あるのに設定値が0, 1(Event mode), 3(Task mode)だ。
なんとなく、2がTask modeで、3がTask and Event modeみたいになりそうだけど、そうじゃないんだ。

これはCONFIGが4つ分しかないので、4ピン分しか使えないはずだ。
ではnRF51 SDKがどうしているかというと、特にそういう制約は書かれていない。
むしろ、初期化時に「最大いくつのセットを使うか」みたいな指定ができるくらいだ。
割込テーブルを見ると、GPIOTE_IRQHandlerと1つ分しか登録していない。
どうやってるんだろう?

ちなみに、app_gpiote_fast_detect.cという方もあり、こちらはCONFIGを設定している。
引数がchannelになってて、0~3までのようだから、こっちはGPIOTEを使ってる感じがする。
SDKをgrepすると、SPIスレーブがTASKS_OUT[]を使っているので、SPIスレーブを使うとGPIOTE fastは使えない、という制約があるのかもしれん。

じゃあfastじゃない方のGPIOTEはどうやってハンドラが呼ばれているのかというと、これはINTENレジスタによるもののようだ。
Port eventの説明を読むと、ようやくGPIOのDETECT線が出てきた。
つまり、わざわざTaskの設定をしなくても、割込を有効にしておけばDETECT線のアサートによってNVICに通知が来て割り込みハンドラが呼ばれるしくみになっているんだろう。

 

あれ、じゃあGPIOTEユニットを止めたりすると割込が発生しなくなるんだろうか?
そもそも、GPIOTEは有効/無効の設定があるんだろうか?
推測だが、UARTとかの周辺機能にはTaskとしてSTART/STOPがある。
これがユニットへの電源供給制御も兼ねてるんじゃなかろうか。
GPIOTEにはそういうのがないから、常に有効なんだろう。

正規表現は難しいと思うが面白くもある

長年、勉強せんといかんと思っていた正規表現を、最近やり始めた。
だいたい何かツールを作ったりするときはC/C++でやってるのだけど、少なくとも文字列の操作だけが目的だったら別の言語がよいだろうと思っている。
文字列には文字列を、というわけではないが、スクリプトを書いてやろうとしている。

しかしまあ、初心者には正規表現はつらい。
書いているときはまだわかるんだけど、それを後から見直したとき「何がやりたかったんだっけ?」となることがしばしだ。
コメントを書かないとさっぱり思い出せん(記憶力の問題?)。

それと、ツールによって動きが若干違うことがあるのが、困る。
sedで、コンマで区切られた一番最初の部分、という抜き出しをしたかったのだけど、どうやっても最長一致した文字列しか取ってくれなかったのだ。
秀丸でやるとできるのに、sedだとできない・・・・。
さんざん調べると、sedでは最長一致にしかならないよ、という情報を見つけた。
正規表現の書き方が悪いんだと思って、そっちばかり調べていたのだが、ツールによって違いがあるのに気付いたのはそのときだった。

置換結果の末尾に「0」がつき始めたので「これを勝手につけたのは誰だ!」と思った。
しかし、sedでは「$10」みたいなのは2桁は認識してくれないので「$1」に0がついた結果になっていただけだった、とか。

ちなみにやりたかったのは、C言語のプロトタイプ宣言から戻り値と関数名と引数の型をコンマで区切る、だ。
いろんなことができないのはわかっているから、1行で書かれている、とか、仮引数は必ず書かれている、とかの条件ありありにしたんだけど、それでもかなりかかってしまった。
まだツールの選択肢と使える正規表現の数が少ないせいかもしれんが、どうやるのが一番速かったんだろう?

 

ただ、文字列のとらえ方が違う観点からできるようになったのは、よいことだった。
繰り返しが0回以上/1回以上とか、この文字に当てはまる/当てはまらないとか、そういうのをつなぎ合わせて文字列は構成されてるんだなー、という、当たり前といえば当たり前なんだけど、そういうとらえ方。
他の言語もたまにはやってみらんといかんですな。

2015/04/16

[nrf51]PPI、あるいはTaskとEvent

自分の記憶が薄れていくのは、もう仕方が無い。
nRF51822のGPIOTEのことも調べていたのだけど、もう記憶に残っていない。
お仕事だと資料ファイルを作ってまとめるんだけど、家だと実装して満足してしまっているようだ。
つまりまあ、何も残ってない。
これじゃいかんので、とりあえずネットに残しておこう。


nRF51822は、周辺機器機能を"Task"という扱いにしているようだ。
何かの機能を使おうと思ってリファレンスマニュアルのレジスタ仕様を見ると、

  • TASKS
  • EVENTS
  • REGISTERS

の3つに分かれている。
この辺のことは「Peripheral interface」に書かれている。
大ざっぱに言えば、Taskはアプリ→周辺機器への要求、Eventは周辺機器→アプリへの通知、のようだ。

 

Event、という言葉を聞くと、ARMの命令であるWFIとWFEとの関係が気になってくる。
ARM Information Center
ようわからん。。
10.2. WFIとWFE
Iは割り込みハンドラを経由して、Eは経由しない、という違いのようだが、そもそもnRF51822のEventと関係あるかがわからん。
ほとんどSoftDeviceとSDKで吸収しているから、知らなくても何とかなるのだけど、知らずに使うよりは知っていて使いたい。

わかってる、わかってるんだ!
そんな内部のことをせっかく隠してるんだから、もっと違うところに力を入れるべきだというのは。
でも、そういう意味では、私は大きくなれないんだよなぁ。

2015/04/15

実験用の回路図を引いてみる

でん。

image

水魚堂さんの回路図エディタを使って、作ってみようと思っている実験用回路図を引いてみた。
LEDを抵抗器とか無しで接続してるけど、よいのかいな?
保護抵抗とかなんとかいう言葉をよく聞くけど、まあ、壊れてから考えればいいや。
・・・回路図を引く仕事じゃなくてよかった。

 

まだまだ初心者の域を脱しないので、実際にブレッドボードなどでつないだ後で引いたので、間違いがあるかも。
なんというか、単体テストがある程度終わってから詳細設計書を書いているようなもんだから、順番としては入れ替わったことになるだろうが、まあ、ね。
それに、詳細設計書だって実装を少しやって雰囲気をつかんでから書くことだってあるから、悪いもんでもないと思う。
少なくとも、動くはずがない設計書を書くよりはよいはずだ。

私が今までやってきてるお仕事では、開発工程をきっちり進めるのがほとんどだ。
ウォーターフォール型、といえるだろう。
昔は「ウォーターフォール型なんて古いし遅いし、よいことない!」と思ってたんだけど、最近は丸くなったというか、業種が変わったからか、気持ちが変わってきた。

なんというか、身を守る必要があるのよね。
「こういう指示だったから、こう設計した」とか「こういう話だったから、こうした」とか。
エビデンス、ってやつですか。
そこを守ってくれるのが、ドキュメントと議事録くらいしかないのですわ。
あとはもう、言った言わないになるのがわかっているから、必要以上のことは言いたくないし、言われることは文字に全部表してもらう。

でも、設計書書いてると時間が経過して仕様変更がやってきて、それドキュメント反映に時間がかかる、となると先に実装して、ドキュメントは後回しで作業が全部終わり、ドキュメントに回す工数がなくておしまい、とか。
なんだかねぇ。

 

そんなわけで、ドキュメント的なものはほしいのだけど、何かもうちょっと力を入れずに役立つドキュメントが作れないかねぇ。
doxygenで作るようなやつじゃなくて、もうちょっと上の方だ。

そう思うと、回路図って適度に抽象化されてるよなぁ。
抵抗器とかコンデンサみたいなものは見ればわかるし、ICなどは型番があるから仕様書読めばよいし。
だからきっと、ソフトの設計書はハードの設計書を参考にして考えたらいかんのだろう。

以前は、建築工学が一番近いとかで、用語もビルドとか構築とか、そっち系の言葉がよく使われていたと思う。
最近の研究で「実は酔っぱらった親父のくだの巻き方が一番近い!」とかになってたら嫌だなぁ。
でも、開発し始め(飲み始め)は言ってることがまだわかるんだけど、進むにつれて何をやってるのかどんどんわからなくなるし、時に火を噴くし(省略)、終わってしまうと途中経過が残ってなかったりするし。

 

回路図1つ書くだけでここまで考えることになるとは思わんかった。

2015/04/09

[nfc]搬送波はどこへ行った

でん。

image

PaSoRi RC-S370と、左がFeliCa Plug RC-S802、右がFeliCa Link RC-S730。
モジュール全体としてはFeliCa Plugの方が小さいけど、チップ単体ではFeliCa Linkの方が小さいな。

写真はなんとなく撮ってみただけで、意味はない。


今回は何をしたかというと、FeliCa Linkに、電源3.3V、GND、それとLEDを付けて、搬送波が来たときにLEDを点灯させようとしたのだ。
これだけだと、ソフトを書いたりしなくてよいので手軽だ。
だいたい、PaSoRiから5cmのところくらいまでは検知してくれた。
これは「FeliCaを検知した」ではなく、「搬送波を検知した」だけである。
その差は大きい。

 

私が小学生の頃は電池と豆電球で、スイッチで点けたり消したりしてたけど、そのうち豆電球がLEDになって、スイッチがNFCの搬送波になったりするのかも。

そうなると、搬送波をどうやって出すか、というのが問題になる。
PaSoRiがあればよいのだが、FeliCa Linkは家にあってもPaSoRiは置いてないかもしれない。
しかし、そこで断念するのは早い!
NFCの搬送波は、(思っているよりも)けっこう身近にあるのだ。

例えば、nimocaとかSuicaをかざせるようなところは、搬送波が出ている。
JRの改札とかは、いつかざされるかわからないから、搬送波は出っぱなしじゃないだろうか。
お金をチャージするところは、チャージしてほしい人が来るまでは出てない気がする。
(※注意※ 搬送波目的で改札とかを使うのは迷惑になるからやめようね)

自動販売機も、可能性があるな。
ただ、あれも買う商品を決めてからじゃないと読み取る意味が無いので、それまでは出してない気がする。

それらだと外に行かないといけないが、家の中にもある。
NFCに対応した携帯電話だ。
ただ、これは私がよくしらないのだ。
うちにあるAndroidのNexus7、Nexus5はNFCに対応していて、ホーム画面などでは搬送波を出している。
少し古いが、P906iもi-appliでR/Wモードがあるので、搬送波を出しそうだ。

iPhone6は「NFC対応」というよりも、「Apple Payでの支払い対応」のような感じがしている(持ってない)。
ネットに出ていた記事を読む限りでは、ハードウェアとして搬送波を出す機能は持っていないように見える。
まあ、Androidだから搬送波が必ず出るというわけでもないと思うが。


ちなみに「搬送波」というのは、無線をやっているとよく出てくる言葉だ(というのを、無線を少しやって知った)。
英語だと「キャリア(carrier)」と呼んでたけど、Wikipediaでは「carrier wave」で出てきた(って、中にも書いてあった)。
まあ、運ぶ波、と直訳してもよさそうだ。
正直なところ、Wikipediaを読んでもよくわからなかった。。。

私のイメージでは、通信したいデータの周波数は±αみたいな、0を境目に上がり下がりしているデータ、それを空中に伝えるためにエネルギーがいるので、搬送波というエネルギーに載せている、という感じだ。
だから、搬送波が近いもの同士は混線しやすいとか、通信できないとか。

NFCの搬送波は、13.56MHzだ。
WiFiとかBluetoothが2.4GHzくらいだから、そこら辺とは重ならないと思う。
それ以外は、よく知らん。