2015/03/31

[nrf51][memo]nRF51 SDKドキュメントのシーケンス

いつも探してしまうので、メモを残す。

nRF51 SDKドキュメントにアプリとSoftDeviceのシーケンス図がある。
場所は「API Reference > S110(BLE peripheral) > xxx > Message Sequence Charts」の中。
たとえば、ここ、とか、ここ、とか。

以前は、ページだけでシーケンス図が載ってない時代もあったんだけど、さっき見た限りでは大丈夫そうだ。


アプリとSoftDeviceの図ではあるのだが、PEERというライフラインが出てきているので、これで無線のシーケンスもある程度は意識できるかもしれん。

まあ、まだまだ普通の勉強をしてからですな。

2015/03/30

[nrf51]SDK v8.0になって、また仕様が変わる

久々にnRF51822を触ろうと思い、まずはSoftDeviceをv8にした。
そしてSDKもv8.0にしたのだが、以前作っていたアプリにmakeが通らない。
まあ、いつものことだ。

今見つけたエラーは、APP_TIMER_INIT()というマクロ。
引数が4つあるんだけど、4番目の仕様が変更になったみたいでね。
以前まではboolで、スケジューラを使うかどうかという選択だったものが、今回からスケジューラのイベントハンドラを指定するようになったのだ。
どうも、スケジューラを使う場合は、includeするのがapp_timer_appsh.hになって、APP_TIMER_APPSH_INIT()というマクロになるっぽい。

ボタンの初期化はAPP_BUTTON_INIT()だったけど、こっちは定義すらない。
app_button_init()のコメントにはマクロを使えって書いてあるのに・・・。
サンプルではbspにあるものを使っていて、見るとapp_button_init()を呼び出していた。

 

うん、なるべく最新を追っていこうと思っていたけど、もう限界だ。
うちのチップではSDKがv6.1.0まで(SoftDeviceはv7.0.0)ってなってることもあるし、今回は見送ろう。
SDKはv7.2.0、SoftDeviceはv7.1.0にしておこう。

最新版を見送るって、なんか勇気がいるのよね。

2015/03/29

[mbed]Publishしてみた

mbedにLCDを挿したとき、ライブラリがあったのでimportし、すぐに使えた。
だから私も、RC-S730のライブラリをimportできるようにしておこうと考えた。

これは「Publish」というメニューからできるようだ。
まだコミットしてなければ、commitを求められる。
次にPublishのダイアログが出てくるので、適当に埋めればおしまい。

http://developer.mbed.org/users/hiro99ma/code/RCS730/

 

Publicも2種類あって、Activityの欄に出てくるPublicと、出てこないPublic(unlist)。
なるべく英語で書いてみたんだけど、まあ、単語が並んでたらわかるだろうレベルでやっている。

 

APIドキュメントが最初出なかったんだけど、Compileボタンをプルダウンすると「Update Docs」というのがあって、それやると出てきた。
出てきたけど、中身が空っぽで・・・。
Doxygen形式にするんだけど、classに対してbriefに相当するものを書かないとまったく出てこないようだ。

こうやって見ると、コールバックが不親切だな。
FeliCa Linkが返すデータ形式を呼び出し側でわかってないとうまくいかないようになっている。
改良の余地はあるけど、ドキュメント見ながらじゃないと使わないだろう、とか思ってしまい、このままになっている。
まあ、いいか。

[mbed]NUCLEO-F411REのデバッグ

FeliCa Linkのライブラリをmbedで作っていたのだけど、ちょっとバグっていた。
はて、mbedのデバッグってどうやるんだろう?

あまり深く考えず、ProgramをKeil形式でエクスポートし、Keil5で開いた。
Keil4形式のプロジェクトだったためか警告が出たが、開ける。
ビルドするとヘッダでエラーが出たが(SPI関係のマクロがないとか)、使ってないのでコメントアウト。
そのままデバッグモードにすると、あっさりデバッグできた。
ブレークポイントにも止まるし、ウォッチもできる。

そんなわけで、特にデバッグについて注意するようなことはなかった。
便利なもんだねぇ。

[felica]FeliCa Linkの読み書き時I2Cパケット

前回「動いた」と記事にはしたのだが、それだけだと味気がないので波形を取った。
が、それを全部載せるとわかりにくくなるので、ロジアナにパケットだけを抜き出してくれる機能があったから、それを使ってみた。
なお、うちのロジアナはZeroPlusのLAP-Cだ。

今回は、Plugモードで動かし、R/WからはPage0へRead without Encryptionを行っている。

image

image

以下で、簡単に説明をしていく。
ユーザマニュアルの「7.2.2 FT転送設定」を参照しながら読んでいただくとよろしいか。

IRQの立ち下がりをトリガにしてキャプチャしている。
なお、FeliCa Linkのデフォルト状態ではIRQ割込設定(割込マスクレジスタ)は全部マスクしてあるので、どこかで許可させる必要がある。
マスク設定はNon-Volatileで保持されるので、一度変更しておけばよい。
外すマスクは、ユーザマニュアルの推奨に合わせてint_tag_rw_rx_done2にした。

作ったソフトでは、mbedの起動時にPlugモードへの変更(動作モード設定レジスタ)とマスクの設定を行い、IRQ待ちにしている。
そして、R/WのPaSoRiからRead without Encryptionを行っている。
Androidとかで試すと準備がいらなくてよいのだが、どういうアクセスの仕方をされるかわからないので、Windowsで作ったアプリを使ってアクセスさせた。

 

IRQ割込が来たときには、既にメモリの0x0C00から読み込んだデータが入っているので、それを読込む。
のだが、まずは割込み要因を調べるため、割込ステータスレジスタ(0x0B28)を4byte読込んでいる。
なおレジスタアクセスは、アドレスはビッグエンディアンで書込み、レジスタ値はリトルエンディアン(4byte)になっている。
よってここでは、0x00000008が読み込めたことになる。

int_tag_rw_rx_done2での割込だったことがわかるので、ようやく0x0C00のデータを読みにいく。
ここでは、まず12byte読込み、まだ読込む必要があれば再度読込みにいっている。
が・・・なんだこの12byteって・・・。
返信するときのデータ長が最短でも12byteになるから、それと間違えているな。
R/Wから来るデータの最短は16byteになるので、あとで修正しておこう。
mbedの汎用I2C APIを使っているからこういう書き方にしたが、自分でI2C含めて書くのだったら、最初の1byteでLENを取って、あとはLEN-1回回すような作りにするだろうな。

image

ブロックリストは、本来2byteタイプと3byteタイプがあるのだが、R/W側のアプリは2byteタイプでしかアクセスしに来ないので、割り切って作っている。

 

レスポンスデータも、同じく0x0C00に書込むことになっている。
ただ、いくつかのデータについてはFeliCa Linkが自動で作成することになっているので、ここでは変更が必要なところしか書き換えていない。
上の図でいえば、白い部分(ST1, ST2, ブロックデータ)が必要な箇所になる。
レスポンスデータの書き込みが終わったら、FeliCa Linkにそのことを通知(タグモード送信制御レジスタ)のtag_rf_send_enableに1を立てて書込む。
そうすることで、FeliCa LinkはR/Wにレスポンスを返してくれる。

最後に、割込クリアレジスタに書込んで、割り込み要因を消している。
この動作が必要かどうかは調べてないのだが、わざわざ用意しているくらいだからやるんだろう。
IRQ端子の説明としても、マスクされていない割込が1つ以上発生している場合、となっている。
このレジスタに書込んでから25usecくらい後にIRQ=Hになっているから、やるのかな。

 

Write without Encryptionの場合は、こんな感じ。
スレーブアドレス0x3Eはデバッグで使っているLCDなので、気にしないでおくれ。

image


なお、ここには出てこないが、RFDETは特に使っていない。
割込はさせてるけど、それでLEDを点灯させている程度だ。

2015/03/25

[nfc][mbed]FeliCa LinkのPlugモードでRead w/o Encが通った

昨日で完成させるはずが、ずるずると延びているFeliCa Linkをmbed(NUCLEO F411RE)で動かす件。
先ほどようやく、PlugモードでPaSoRiから1ブロックだけ読み出すことができた。

FeliCa Linkの部分は、自分の実装ミス以外は悩むところがなかった。
なんというか、仕様書通りに作ったら、仕様書通りに動いた、というところ。

動かなかったのは、自分の実装ミスだ。
なんだけど、mbedのI2Cインターフェースも反省すべき点はあると思う、うん。

FeliCa Linkには"Page Write"というのがあり、書込み先のアドレスを指定したら、あとは書込みたい分だけ書く、という使い方だ。
mbedのI2Cインターフェースは書き込みについては2つあって、1つはスレーブアドレスとバッファとサイズを指定して、一気に書込むAPI(API1と呼ぶ)。もう1つは、最後に書いた続きから1byte書込むAPI(API2と呼ぶ)。
私はメモリ確保を端折るため、書込み先アドレス指定をAPI1、書き込むデータをAPI2でぐるぐる回すような実装にしていた。
それはよいのだけど、API1とAPI2で戻り値が異なることに気付いてなかった。
API1は成功すると0、API2はACKが返ってくると1。
・・・想像がついたと思うけど、私はAPI2も成功が0と思って実装し、うまく書き込めてなかったのだ。
でも、API2の戻りはACK受信時に0でもよかったと思うのだ。

 

まあ、そういうこまごましたことはともかく、FeliCa Linkの扱いは思ったよりも楽だということがわかった。
FeliCa PlugだとFeliCa Throughモードしかないのでホスト側でデータを全部考えないといけないけど、FeliCa LinkにはLite-S/FTモードがあるので、既存のメモリを生かしつつ、拡張したいところだけThroughでやる、なんてことも考えられそうだ。

さあ、みんなもFeliCa Linkを使ってみよう!
・・・使ってみようよぅ、みんな。。。。。

やはり、あれか。
R/Wが使える2Vモジュールが出てきて、Android Payとかと絡めないと触手が伸びないのか。
なんとなく、少々のR/Wだと読めそうな気がしないのだが、iPhone6は持ってないからわからんな。

ちょうど、15年くらい使っていた腕時計が動かなくなったので、買い替えたいとは思っている。
思っているんだけど、せめて10年くらいは電池交換とか無しで動いてくれないとなぁ。


どうでもよいことだが、mbedのプロジェクトをZIP形式で落としてくると、.hgフォルダがある。
gitとかじゃなくて、mercurialなんだな。
launchpadにあったnfcpyを落としてきたときがそうだったので気付いた。
生き残っているから、よい点があるのだろうね。

2015/03/24

[nrf51]うちのnRF51822ではS130を動かせないのか?

前回、HWIDを読むことで、うちのnRF51822がrevision 2であることがわかった。
hiro99ma blog: [nrf51]HWIDの取得方法

ふーん、くらいで終わらせていたのだが、Compatibility Matrixのドキュメントに、SDKやSoftDeviceのバージョンも含めた表が載っていた。
それによると、SoftDeviceのS130がハイフンになってる。
動かせないの??


いや、そんなことより、nRF51 SDKが6.1.0までしか入っていないように見える。
うそ・・・私のnRF51822、古すぎ?
Nordicのところでは、これが一番近いのか。
nRF51822 w/s110 7.1.0 supports revision 2 or no? [closed] - Nordic Developer Zone
今のところ大丈夫だ、みたいなところかな?
でも、Nordicの人からの見解じゃなさそうなので、気になる。

「動くとは思うけど、動かなかったとしても文句言わないでね」といところか。
チップのリビジョンを上げられればよいのだが、そういうもんじゃないだろう。
変化が早いとユーザが付いていかなくなる気がするから、そろそろ落ち着いてくれないかなぁ。

2015/03/23

[mbed]NUCLEO F411REにはRJ45が直結できない

うちに、1枚だけNUCLEO F411REというボードがある。
ARMで、開発環境がオンラインにあって、くらいの知識で購入。
ついでに、こんなのも買った。
mbed用イーサネット接続キット - スイッチサイエンス

LANとかは得意ではないのだが、この時代で好き嫌いもいってられない。
まずはつなげてから考えよう、とNUCLEOのピンを見たのだが、イーサネットっぽいピンがない。
あ、あれ、mbedって名前だったらピン配置とかに互換が合ったりするものじゃないの?

じゃないのだ。
mbedのPlatformページで検索できるのだが、Ethernetがそのままつながる基板というのは今(2015/3/23)のところ6種類しかなかった。
Platforms | mbed

安いので、そんなに何でも載ってるはずないよな。
なお、W5200というシールドを使えばつなげられるらしい。
NUCLEO-F411RE | mbed

もうちょっと調べると、W5200というのはWIZnet社のチップで、シールドの名前ではないようだ。
なので、こういうのでもよいかもしれん。
WIZ820io - スイッチサイエンス

しかし、ここまで来ると、私ってそんなにネットにつなぎたい人だったっけ、と自問してしまう。
そして今回は「あの葡萄はきっと酸っぱいんだ」ということで、見送ることにした。

2015/03/22

[nrf51]HWIDの取得方法

nRF51822は、チップのリビジョンによってドキュメントを読み分ける場合がある。
今のところ、1, 2, 3というリビジョンがある。
チップの外観からもわかるようではあるが、ものによってはカバーがあったりして見えないかもしれない(うちのがそう)。

ではどうするかというと、メモリを読むことでわかるそうだ。
How to get nRF51822 serial number and HW ID through SEGGER? - Nordic Developer Zone

うちのは、こうだった。
FFFF004D

これをCompatibility_MatrixのPDFで調べると、revision 2で、CE AAで、Dx0で、WLCSPで、FLASHが256kB、RAMが16kBとのこと。

 

リファレンスマニュアルを見ると、読んだアドレスはCONFIGIDというレジスタのようだ。
まあ、どのリファレンスマニュアルを読むとよいかを調べるためにHWIDを知りたかったのだが、たぶんこのアドレスはリビジョンが変わっても共通なんだろう。

NFC-DEPしなくてもよいのでは

先週くらいからFeliCa Linkを扱いだしている。
Lite-Sモードとか、Plugモードとか、いろいろある。
インターフェースがI2Cになったこともあり、扱いはやりやすい。
よいことだ。

その中で、というか、以前からというか、NFCの中で扱いに迷っているのが、NFC-DEPだ。
大ざっぱに言えば、以前からある大きめのデータ転送がISO-DEPで、そこからちょっと新しく加わったのがNFC-DEP。
いや、それも大ざっぱに表現できてないな。

いま流行り(?)のHCE、特にAndroidのHCEは、Type-Aベースだ。
Type-Aのうち、ISO/IEC-7816を使っていて、そのDEPがISO-DEP(名称をまちまちで書いているのは我慢しておくれ)。
海外のMIFARE DESFireとかはISO/IEC-7816ベース(メモリの使い方)、かつISO/IEC-14443のType-Aベース(無線)。
AndroidのHCEは、ISO/IEC7816 + 14443、というところだろう。

 

端末同士でInitiatorとTargetの役割が確定していない場合は、DEPのように役割を動的に決めるしくみがいるだろう。
しかしpaymentの場合、お金を要求する方がInitiator、お金を払う方がTargetという役割は変わらないだろう。
だから、DEPを拡張させるのではなく、CardEmulationを拡張させる方向になったのだろう。

じゃあ、今のNFC-DEP(=LLCP=SNEP)でやってるところも、「お金」を「コンテンツ」と言い換えれば、別にDEPでやらなくても対応できそうに思う。
NFC-DEPはやることの内容からすると、実装コストが高いように思っている。

 

そんなわけで、NFC-DEPの実装はやめておこうかと思っていたけど、気になるレジスタがあったので、ちょっと迷っている。
誰か、もうちょっとFeliCa Linkで遊んでいる人がいるといいんだけどなぁ。

2015/03/21

[c/c++]enumの符号

mbedでソースを書いているのだが、引数がenumで、一応範囲チェックをしようとした。
こんな感じ。

enum EnumKuma {
  FIRST,
  SECOND,
  THIRD
};

int Func(EnumKuma kuma)
{
  if ((kuma < FIRST) || (THIRD < kuma)) {
    return -1;
  }
・・・

 

そうすると、「kumaは0より小さくなることはない」みたいな警告が出てくる。
あれ、enumってint型扱いじゃないんだっけ?

Signedness of enum in C/C99/C++/C++x/GNU C/GNU C99 - Stack Overflow

整数型ではあるが、符号についてはコンパイラ依存とのこと。
ほほぅ、そうだったのか。
ARMのコンパイラ(armccかな?)では、一番小さい符号型にあわせられるらしい。

ARM Information Center

2015/03/20

Win10 Tech Previewを見てみた

Windows10のTechnical Preview版があったので、Virtual Boxにインストールしてみた。

image

image

エクスプローラと設定で、アクティブなウィンドウバーの色が違うんだな。
エクスプローラというか、普通のアプリが色つきか。
そして設定というか、ストアアプリだっけ、あのタイプもウィンドウで表示されるようだけど、あれには色がないようだ。

 

なお、スタートボタンを押すとこんな画面になる。

image

右側の広いところには、もともとWindows8のスタート画面みたいなタイルが出てた(全部消したが)。

 

今後はこういう画面になるから慣れた方がいいんだろうけど、きっとClassic Shellみたいなのを使うことになるんだろうな。

[felica]FeliCa Linkを動かす

FeliCa Linkの件をいろいろ考えたが、現状でよいような気がしている。
なので、現状でどうやっているかの記録を残しておこう。


配線は、こう。

image

回路図エディタ:水魚堂オンライン
Arduino UNO回路LIB(NUCLEOとして使った):bsch3v向けArduino UNO回路図作った - ねぎらぼ

FeliCa Linkの回路LIBはここに置いてみました。
見えるかな?


mbedのライブラリはこんな感じで作った。
ロジアナで記録したのは、これらの関数。
「RETRY_NUM」は5だ。
プログラムは、ByteWrite()→RandamRead()の順で呼んだだけ。メモリアドレスは0x01、書込む値は0x41だ。

 

書くほう

int RCS730::ByteWrite(uint16_t MemAddr, uint8_t Data)
{
    int ret;
    int retry = RETRY_NUM;
    char buf[3];
    buf[0] = (char)(MemAddr >> 8);
    buf[1] = (char)(MemAddr & 0xff);
    buf[2] = (char)Data;
    do {
        ret = mI2c.write(mSlvAddr, buf, (int)sizeof(buf));
    } while ((ret != 0) && (retry--));
    return ret;
}

 

読むほう

int RCS730::SequentialRead(uint16_t MemAddr, uint8_t *pData, int Length)
{
    int ret;
    int retry = RETRY_NUM;
    char buf[2];
    buf[0] = (char)(MemAddr >> 8);
    buf[1] = (char)(MemAddr & 0xff);
    do {
        ret = mI2c.write(mSlvAddr, buf, (int)sizeof(buf), true);
    } while ((ret != 0) && (retry--));
    if (ret == 0) {
        ret = mI2c.read(mSlvAddr | 1, reinterpret_cast<char*>(pData), Length);
    }
    return ret;
}


まず、書く。

image

image

何回か波形を取ったが、1回だけリトライ4回目で成功、それ以外は3回目で成功だった。

 

そして読む。

image

書いた直後に読もうとしているので、書き込み完了までの間はACKポーリングになってる。


そういうわけで、初回アクセスできるまでのところ以外は、意図した通りに動作しているようだ。

 

稼動になるまでのNACKも、もうACKポーリングの一環とみなしてしまおうか、という気になっている。
I2Cでアクセスしたいのは、通常はメモリを読み書きしたいときか、ホストスルーでのアクセス時くらいしかない。
メモリをホストから読み書きするのは、リトライでカバーする。
ホストスルーの場合は無線経由で稼動状態になるので、ホスト側でカバーする必要が無い。
ホストからメモリアクセスするのは、そうそう頻繁にやるものではない(用途に因るだろうけど)ので、時間にシビアなシーンが発生しにくいとみなすと、まあ、困るものでもないんじゃないだろうか。

リーダライタが使えるタイプのFeliCa Linkが出たりしたら、また考えましょうかね。

[mbed]NUCLEOにバニラシールドを載せる

STMのNUCLEOは、Arduino互換のピン配置になっているとのこと。
では、バニラシールドが載せられるかも、と思い、スイッチサイエンスさんから買って載せてみた。
足の長いコネクタもセットで購入している。

image

写真が暗いな・・・。
横から見ると、こんな具合(まだ基板とコネクタはハンダ付けしていない)。

image

ハンダ付けしてないので、基板とスイッチが当たってるけど、基板とコネクタを密着させてからハンダ付けすれば当たらないくらいのスペースがある。
気になるなら、スイッチのキャップを取るのもよいだろう。

基板の前後をひっくり返したらよいのでは?と思ってやってみたが、コネクタの配置間隔が右と左で違うので、全部のピンを有効にしつつひっくり返すのは無理そうだ。
まあ、そこまでしてボタンが使いたいなら、基板を切ってしまう方がよいかも。
ユニバーサル基板って、切るのが大変だったから、私はそこまでやらない。

2015/03/18

[felica]FeliCa Linkの続き (2)

前回までのあらすじ

FeliCa LinkとのI2C通信がうまくいかず、スレーブアドレス書き込み後にACKが返ってきていない。
待ち時間がどこか足りていないのではないかということで情報を集めていると「リトライするとよいのでは」ということで試し、書き込みができた。

ただ、SDA="L"の時間を長くしてもうまくいかないことに対して納得がいっていない私であった。

チップを使う立場からすると、リトライするにせよ時間を長く取るにせよ、根拠がいる。
その根拠から外れた動作をする場合は「異常系」の処理を行うだけなのだが、その判断ができないのだ。
FeliCa Plugなんかは時間のことがきっちり書いてあったので使いやすかったのだけど、今回はうーん・・・。

 

まあ、そこは忘れよう。
今気にしているのは、チップがI2C通信を受け付けるようになるまでのやり方を、ドキュメント通りにやっているつもりなのにうまくいっていない、というところだ。
hiro99ma blog: [felica]なぜにFeliCa Linkのドキュメントには時間のことが書かれていないのだろう?
ここの仮説4で、SDA=Lにしてから~、と書いている箇所だ。

FeliCa Linkのチップが初期化完了した状態を「稼動状態」と呼ぶのだが、電源オフ状態からそこに至るまでには、

電源オフ→(VDD投入)→スタンバイ→(SDA=L)→初期化→(時間??)→稼動

となっていると私は仕様を読んだ。
(知りたかった時間というのは、初期化から稼動に至るまでの時間だ。)

 

SDA=Lを長くしてもダメで、リトライするとよかった。
そこだけ見ると、仕様書の記載が間違っているんじゃないか?と思ってしまうのだが、もう少し落ち着いてみよう。
本当に私はSDA=Lにできていたのだろうか?

ロジアナ上ではLに見えている。
見えているのだけれども、FeliCa Linkがその電圧をLと見ているかどうかは別の問題だ。
そこを調べるにはオシロスコープくらいしか思いつかない。
マルチメーター、特にうちにあるような安物だと無理そうな気がする(オシロもないけど)。

SDA=Lにできていないなら、リトライでうまくいくということの説明が付かないのだけど、スタートコンディションのためにLにしたのと、ストップなり異常検知などでLにするのは別なのかもしれない。
いきなりmbedベースの基板で試すには重たい内容だったか・・・。

 

まあ、嘆いても仕方ないので、どうやるとリトライせずにきれいにアクセスできるかを調べますかね。

[felica]FeliCa Linkの続き

とある筋より情報をいただき(ありがとうございます)、FeliCa Linkの電源状態が稼働状態にまだなっていないのではないか、という感じになってきた。

でも、SDA=Lにしてから10msecも待ったのに・・・。
んじゃあ、20msecにしてやってみるか。リトライもしてみよう。

image

んあ??

image

ACKが返ってきた??
その後の書込みがおかしいのは、まあソフト要因だからよいとして、ACKが返ってきたのだ!

でも、20msecで一度スレーブアドレスを書き込み、そこで失敗して815usecくらい待ってからリトライして成功したのか。
初期化状態から稼働状態までの待ち時間が20msecでも足りないってこと???

 

気になったので、時間を10msecにだけしたアプリにしてみた。
つまり、前回失敗したときとの違いはリトライをするかどうかだけだ。

image

あれ・・・。

image

1回目に失敗して、やっぱり815usecくらい後で成功している。
このロジアナ波形は、A2がSDAで、開始トリガはA2の立ち下がりエッジだ。

スタンバイから初期化になるトリガは、本当にSDA="L"だけなのだろうか?
いや、もちろんVDDが供給されるとかあるんだろうけど、SDA="L"だけだったら待ち時間を10msecにした場合には815usecがもっと長くなってから成功しないとつじつまが合わないように思う。
あるいは、私のハードウェア構成がよろしくないか。。。

 

とりあえず、SDA="L"になっている時間を延ばす作戦はやめて、リトライ回数を増やすことにした。
増やす、といってもどのくらいの時間が妥当かわからないので、無限繰り返しにした。

image

・・・これだと、2msec以内にはうまくいったことになる。

こうやって見ると、SDA="L"だけじゃなくて、SDAとかSCLがある程度ぱたぱた動くというところにも条件がありそうに見えた。

なんか、私が知っているI2Cデバイスとは異なる動きをするので、正直なところどうしてよいかわからない。
時間について記載が無いチップというのは、ちょっと使うのには厳しいなあ。

2015/03/16

[nrf51]SoftDeviceがKeilやMakefileから焼けるようになったらしい

Flashing SoftDevice directly from ARM Keil uVision and Makefile (nRF51 SDK 8.0.0)

いつもSoftDeviceはnRFgo Studioから焼いていたのだが、どうやらKeil(4 or 5)やWindows環境のMakefileから焼けるようになったそうだ。
Windows環境なのは、nrfjprog.exeというツールを使っているかららしい。

 

試していないのだけど、nRFgo Studioを今後はメンテしなくなる方針ということだろうか?
まあ、今のところSoftDeviceを焼くか、UUIDを生成してもらうのにしか使ってないのだけど。

[felica]なぜにFeliCa Linkのドキュメントには時間のことが書かれていないのだろう?

まだ、FeliCa LinkのNACKから抜け出せない。
たった1bitが立ち下がらないだけなのに、うぅ・・・。


あてずっぽうにやるのも疲れてきたので、いくつか仮説を立てることにした。

  1. ハンダ付けがうまくいってなくて、チップまで届いていない
  2. ピンが実は逆順になっていた
  3. ロジアナに吸い取られている
  4. 時間が足りてない
  5. チップが壊れている

 

仮説1

テスターでチェックしたが、大丈夫そうだ。

 

仮説2

RFDETは思っていたピンで応答していたので、大丈夫そうだ。

 

仮説3

ロジアナを外してやってみたが、変わらず。
APIからエラーが返ってきたらLEDでわかるようにしたし、NFC R/Wで読み取れば動いたかどうかわかるのだ。

 

仮説4

VDDが供給されてからチップが動くまでに時間がかかるのでは?と5秒くらい待たせてみたが、変わらず。

SDA=Lになってから初期化が始まり、初期化が完了して稼働状態にならないと有線インターフェースからのコマンドは受信できないそうだ。
メモリアクセスをコマンドと解釈するのかどうかわからんが、ストップスタートコンディション(3/17 誤記修正)の状態を10msecほど作り出すようにしたけど、変わらない。

image

そもそも、どこにどのくらいの時間がかかるかって記載がPDFにないのだけど、なんでだろう?

 

仮説5

はい、うちにはFeliCa Linkが1枚しかないので、先ほどスイッチサイエンスさんに注文しました・・・。
無駄になりませぬよう。


ユーザーズマニュアルにもスターターマニュアルにも時間の情報が見つけられない。
これ以外で関係しそうなのは「RC-S967/1Vデータシート」というドキュメントなのだが、これは特約店から提供されるタイプらしい。
スイッチサイエンスさんに、ご提供いただけるかどうか確認してみよう。

2015/03/15

[felica][mbed]FeliCa LinkからACKが来ない

mbedが来て、早2週間。
うちに新しいマイコンが来たら、何かFeliCa関係のデバイスを動かすのがルールになっている。
・・・というわけではないのだが、それなりに通信させる確認ができるので、RC-S620/SとかRC-S802とかを動かしていた。

今回は、FeliCa LinkであるRC-S730を動かすことに決めた。


FeliCa Plugが変形SPIでの接続だったのに対して、FeliCa LinkはI2Cでの接続になっている。
変形じゃないので、mbedのI2Cをそのまま使えばよいだろう。
LCDのST7032iが動いたから、そんなに難しくないはず。

はずだったのだが、スレーブアドレス書込み後のACKが返ってこない。
うーむ。

image

以前の反省を元に、プルアップ抵抗の値をいくつか変えてみたのだが、変わらず。

ちょっと心配なのが、しばらくプルアップするピンを間違えてて、GNDに接続していたこと。
RFDETは反応するんだけど、これは搬送波に合わせて脊髄反射的に動いているだけのような気がする。
IRQはデフォルトでは全部無効みたいなので、RC-S967/1V(FeliCa Linkに載っているチップ)が生きているかの判断ができそうにない。
なんとなく大丈夫な気はするんだけど、私のハードウェアに関する判断は当てにならないしなぁ。

とりあえず、もう1枚FeliCa Linkを買うことにした。
この前は、どうにもわからずにロジアナを注文したら来る前に解決したのだが、今回はどうなることやら。
まあ、FeliCa Linkはもう1枚あってもよいかと思っていたので、割り切ろう。

[win8]ロジアナZeroplusのドライバインストール

うちには、ロジアナとしてZeroplusのLAP-C(16064)がある。
Windows7で使っていて問題ないのだが、Windows8だとインストール時にドライバが入らないという問題がある。
Windows8ではあまり使っていないとはいえ、使えるに越したことはないのでバージョンアップで対応されないかな-、と思っていたのだが、最近FAQを見ると「こうやってね」と書いてあることに気付いた。

Logic Analyzers-Zeroplus

手動でやってくれ、ということらしい。
「Win8(or above)」とあるから、今後も対応する気はなさそうだ。

2015/03/14

[mbed]ST7032iを動かす

せっかくNUCLEO-F411REを買ったので、mbedっぽく使ってみたい。
まずはI2Cデバイスを動かそう、ということで、以前買っていたST7032iをつなぐことにした。

I2CのドライバはAPIがあるのはわかっていたので、uITRONで作っていた初期化とかを移植するか。
と思っていたら、mbed用のライブラリが既に作られていた。
SB1602E (ST7032) | mbed
これが・・・mbedの威力か。

結果的に、1時間程度で動かすことができた。
その1時間も、程よい抵抗器を探したり、ブレッドボードにどうやって配置しようか悩んだり、SDAとSCLを逆にしててロジアナで波形取ったりとかいう時間がほとんどだ。

記念なので、接続したときの写真を載せておこう(動かしたときの写真じゃない)。
今回のプルアップ抵抗は、4.7kΩにした。

image

I2Cの最初のアクセスも載せておこう。

image

 

I2Cの仕様としては、アドレスは7bitだ。
I2Cマスターが送信するときは、アドレス7bitに続けて、1bitのRead(1)/Write(0)情報を載せる。
ライブラリで提供されているとき、指定するアドレスが7bitのものにするのか、Read/Write情報まで含めた8bitのものにするのか、あるいはRead/Write情報をライブラリ側でORすればいいように8bitのものにするのかは、調べた方がよいだろう。
mbedの場合は2番目のパターンになるようだ。


確か、私はストロベリーリナックスさんから購入したのだが、今はスイッチサイエンスさんからも出てるみたいだ。
I2C接続の小型LCD搭載ボード(3.3V版) - スイッチサイエンス
Arduinoは直接挿せるようだけど、ピンとしてはアナログのA1~A5に挿す想定のようだ。
NUCLEOで同じことができるかわからない。
ストロベリーリナックスさんのHW構成(コンデンサ内蔵)に加えて、スイッチサイエンスさんのはI2Cのプルアップ抵抗も取り付けてあるので、そのまま接続するだけで使えそうなのが良いですな。

2015/03/08

[mbed]export toolchain

mbedのプロジェクトはオンラインでやれるようなのだが、オフラインでもビルドできる、というのを読んだことがあった。
これはオフライン版SDKをインストールして、使われているコンパイラを引っこ抜くとARM純正の環境が作れるのでは、ふふふふ、と思っていた。

が、そんなことはなく、オンラインで作ったプロジェクトをエクスポートできるということだった。
残念だが、まあそうだろう。


どういうエクスポートができるのか見てみたら、こんな感じだった。

image

はて、グレーアウトされているのは何だろう?
私のPC環境を読み取って、インストールされているものだけを選んでいる、というわけでもないし。
GCCも、ARM EmbeddedができてCode Sourceryができないってこともなさそうなんだけどなぁ。

Exporting to offline toolchains - Handbook | mbed

こちらを見ると、大きく4タイプのエクスポートができるとみなしているようだ。
Code SourceryもMakefileタイプだろうから、できないわけではないんだろうけど。
有償な環境は除外しているのかと思ったけど、それならIARが残っている理由にならない。
もしかすると、Nucleoだから、という制約があったりするのかもしれん。

が、今のところMakefileでやるつもりだし、なるべくオンラインでやった方がよさそうなことが書いてあったから、こだわるのはやめておこう。

2015/03/07

[usb]USBPcapはコマンドプロンプト自体を管理者権限で立ち上げよ

追記:2015/12/15
WireShark v2からUSBPcapが取り込まれたので、もうちょっと使いやすいです。
http://hiro99ma.blogspot.com/2015/11/wireshark20usbpcapti.html

PaSoRiを自分で制御したい、ということから使い始めたlibusbだが、世の中にはUSB機器が多いのであれこれ応用が効く。
しかし、デバッグがしたいとなるとUSBパケットそのものを見たくなる。
お遊びでやっているのでお金をかけたくはないのだが、はてどうしたものか・・・ということでUSBPcapを使うことにした。
USBPcapのよいところは、pcap形式になっているのでWireSharkが使えるところだ。
しかも、WireSharkではUSBのパケットキャプチャとしてUSBPcapの説明を書いているくらいなのだ。
標準でUSBのパケットをある程度解析してくれるようになっている。
ただ、初めて使ったときはライブキャプチャ、すなわちUSBのパケットをリアルタイムでWireSharkに表示する機能が使えていたのだが、最近はうまくいってなかった。
Linuxとかのパイプでつなぐようなバッチファイルを作っていたのだけど、USBPcapが標準出力に吐き出すところと、標準出力からWireSharkで吸い取るところが別々に動いてしまってダメだったのだ。
動いていたときからWireSharkのバージョンが上がったからかな?とか思っていたのだが、検索すると以下のサイトで解決されていた。
USBの解析ソフト - きょうはなに色?
コマンドプロンプト自体を管理者権限で起動する、だ。
バッチファイルを管理者権限で起動すれば済むんだろうと思っていたのだが、まさにこの方が書かれていた内容が私にもあてはまったのだ。
助かりました。

おかげで、作ろうとしていたものが何とかできた。
普段だったら、それまでの過程とか調べたことをここに書くのだけど、今回はちょっと毛色が違うので書けないのだ。
うーん、残念。
まあ、これでまたBLEの調査に戻れるので、よしとしましょう。

2015/03/01

Free Device Monitoring Studioは1日5セッションまでだった

USBスニファとして使い始めたFree Device Monitoring Studioだが、前回は「12分まで」と書いたが、もう1つ制約があった。
1日5セッションまで、という制限だ。

image

うーん・・・、この制限はちときつい。
いまはデバイスのつなぎ初めとかを見たいので、しょっちゅう入り切りしていたのだ。
かつ、タイミング悪いとPCがブルースクリーンになってしまい、再起動という・・・。

 

そんなわけで、USBPcapとWireSharkで進めることにした。
お仕事だったらツールを購入するところなのだけど、お遊びでやってることだし。
それに、キーボードのカスタマイズをするのと同じようなもので、どこでも同じ環境を作りやすい方が優先されてしまう。
まあ、場合によりけりってとこですかね。

[win]休止状態にならないのはアクティブパーティションがないためだった

私はWindows7を主に使っている。
週に一回くらいはシャットダウンするが、通常は休止状態で電源を切っている。
SSDだと負担がかかってよろしくないような記事を見たことがあるが、うちは普通のHDDだし、まあそこまで目くじらを立てることはなかろう。

が、その休止状態が急に動作しなくなった。
いつも寝る前に休止状態にしているのだが、朝起きてもまだ電源が入っていたままだったのだ。
なんというか、スリープっぽい状態になっていただけというか。
休止状態に入ると復帰するには電源ボタンを押すしかないのだが、今回の状態だとマウスとかキーボードを触ると復帰してしまうのだ。

私のイメージでは、休止状態というのは現在動作しているアプリなどのプロセスが使っているRAMをディスクに退避させる技術だ。
ほら、RAMが少なかったらディスクにスワップさせるではないか。あれのRAMが0バイトになってしまった版。
プラス、プロセスの管理情報とかも一緒に保存して、とにかくRAMのものを全部消してしまっても復元できるようにしてしまう技なんだろうと思っている。

まあ、私のイメージがどうだろうと、休止状態にならないことには変わりがないが・・・。


急にならなくなったのだが、なんとなく思い当たりがあった。
週末からUSBのスニファをあれこれ試したりしていたので、そこら辺じゃないか、というものだ。
検索すると、USBキーボードが・・・とかでよく出てくるし。
しかし、今回はそれではなかった。
インストールしたスニファもアンインストールし、USBデバイスも外し、スリープから復帰させることができるようにする設定も外したが、現象変わらず。

次にそれっぽい情報として、パーティションがアクティブになっていないのがダメだった、というのがあった。
そういえば、「システム」の「既定のオペレーティングシステム」が何も表示されなくなっているな・・・。
ということで、ディスクの管理からCドライブの先頭パーティションをアクティブ設定にした。
そしたら、休止できるようになった!

 

アクティブなパーティションがなくなったから休止状態になれなくなったのか、というのはわからない。
次回、似たようなことが発生した場合の対処として残しておこう。