BlueTooth Low Energyを使ってみる。nRF51822 (BVMCN5103)

ＳＤＫ　Ｖ６．０ nRF51822 RAM 16kB
使用するBluetooth Low Energy評価基板
Nordic の ＳＤＫのサンプルソフト
サンプルソフトを改造
ＵＡＲＴを使ってモニタを移植
タイマーを実装し、割り込み処理
１ｍｓ精度でタイマー同期
Soft Device ( s110 ) を使ってスマートフォンとＵＡＲＴ通信
Soft Device ( s110, s120 ) を使って nRF51822 相互にＵＡＲＴ通信 セントラル側は　こちらを元に変更しています
nRF51822 を使って相互にＵＡＲＴ通信。 ペリフェラルの名前とＭＡＣアドレス表示　 2016.6.10 追加
nRF51822 を使って相互にＵＡＲＴ通信。通信インターバル変更　 2016.6.12 追加
nRF51822 を使って相互にＵＡＲＴ通信。２台のペリフェラルとペアリング　 2016.6.24 　追加
nRF51822 を使って相互にＵＡＲＴ通信。２台のペリフェラルと相互通信　プロジェクトソース一式追加 2016.7.10
２台のペリフェラルと相互通信をテストする環境をＦＰＧＡで作成　 2016.7.19 　 修正　追加
Micro Blaze のＧＣＣコンパイラで、-Os オプションでバグ発生 2016.7.19 　 修正　追加

ＳＤＫ　Ｖ１０．０ nRF51822 RAM 32kB
SDK v10.0.0 を試す。使用デバイスは、BVMCN5103-CFAC-BK (nRF51822 CFAC ROM256k, RAM32k) ２０１７．１．２５　追加





使用するBluetooth Low Energy評価基板
現在簡単に入手できるＢＬＥ（Bluetooth Low Energy）評価基板は、Nordic の、nRF51822 を使ったモジュール、BVMCN5103-BK だろうと思う。 テキサスインスツルメンツにもあるが、開発環境が、ＩＡＲのようなので、無償で開発環境が使える、nRF51822 を使ったものにした。こちらだと、ＫＥＩＬの評価版開発環境で、３２ｋｂまで使えます（デバッガーが３２ｋｂまで）。ＧＣＣだと、制限がなくなりますが、環境の構築に、ＧＣＣの専門知識が必要なので、当面、ＫＥＩＬのお世話になります。


写真は、BVMCN5103-BK KIT PLUS　で、左の２枚のBVMCN5103 と、右はプログラマー。BVMCN5103 には、Nordic の、nRF51822 が使われていて、アンテナ付きのモジュールになっており、日本国内で使うことができます。

これらの基板のほか、あると重宝するのが、Nordic 社からでている、nRF51-DK という評価基板です。

nRF51-DK のメーカーＵＲＬ：nRF51-DK

ライターの用意
アプリケーションプログラムの書き換えには、トランジスタ技術の付録基板がライターとして使えますが、これでは、Nordic のソフトデバイスを書けないので、ソフトデバイス（ SoftDevice s110,s120 etc.) を書き換えるには、BVMCN5103-BK KIT PLUS のライターを使います。


まず、Nordic 社のＵＲＬからファイルをダウンロード

まずはユーザー登録から。

Nordic で検索すると、Nordic 社のＵＲＬが筆頭にでるはずで、その右側の上の方に、MyPage というプルダウンメニューがあり、Create a Nordic MyPage account を選択して、登録します。


登録した後、nRF51 SDK をたどると、以下のような　ＦＴＰでダウンロードするようなＵＲＬが現れます。

SDK には、V4 から、V9 までありますが、古いものも含め全部ダウンロードしといた方がいいでしょう。このＵＲＬでの解説で使うのは、主に　V6 です。

ここから、SDK のほか、pieces/ をたどると、SoftDevice なるもののダウンロードができますが、用途に合わせて、使い分けが必要になります。BVMCN5103 を、無線の端末として使うのなら（つまり通信相手のホストがスマートフォンで、出来合いのアプリで操作する）通常　SoftDevice　の書き換えは必要ないようです。


Nordic の ＳＤＫのサンプルソフト

pca10000 という評価基板でそのまま動作するものとして、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）に含まれるサンプルの、ビーコン、心拍数センサー、ＵＡＲＴ送受信端末などがあります。しかし、pca10000 という評価基板は入手困難なので、BVMCN5103 で動作させるには、押しボタンスイッチや、ＬＥＤを追加する必要があります。使っているチップが、nRF51822 と、同じなので、ポートの設定などを書き換えるかすれば、サンプルソフトが動作します。動作するにしても、通信相手は、スマートフォンなどになるものが多いためため、スマートフォン側に、受信ソフトが無いと、動いたか否かの確認をする手段がありません。

サンプルソフトの多くは、nRF51822 を通信端末、スマートフォンなどを通信センターにしたものですが、これらはすべて、ノルディックが用意したソフトデバイス（ Soft Device ）を、ＡＰＩで呼び出すことで通信をおこなうようになっています。Soft Device　は、ＲＯＭの０番地から９０ｋＢほどの領域にあり、割り込み処理なども管理下に置きます。このため、通信を行いながらタイマー割り込みなどを使う場合は、正確なインターバルにならない場合があります。というのは、Soft Device の通信処理が精密な時間管理のもとで行われるため、ユーザーが使う割り込み処理が後回しにされるからです。タイマー割り込みのインターバルが短いと（　たとえば１０ｍｓぐらい　）、後回しにされるだけでなく、１秒で１００回割り込みがあるはずのところ、９５回とかになってしまうこともあります。ですから、正確な短い割り込み処理が必須のアプリケーションを、 nRF51822 で兼用することはできません。

サンプルソフトを動かしてみる

サンプルソフトには、Soft Device　を使うものと、そうでないものがあり、多くは Soft Device　を使うものですが、２個の nRF51822 間で通信するには、Soft Device　を使わないサンプルソフトの方が簡便で、すぐに動作確認ができます。ただ、こちらは、照明器のリモコンのような単純な通信を想定したもので、数ビットの情報を伝えるためだけのもので、通信相手が情報を受け取れたか否かの確認は、照明が点灯したかどうか、人間の判断にゆだねるものです。つまり、無線通信のデータが確実に相手に送れたかどうかは、サンプルソフトでは確認しません。操作側は、データを送りっぱなしなのです。

ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）のインストールフォルダの中に、下図の様に、pca10001 フォルダに、button_radio_example　と、led_radio_example があって、これらが、送信( button_radio_example )と受信( led_radio_example )です。送信側は押しボタンの状態を読んでＯＮ，ＯＦＦのデータを受信側に送り、受信側では、送られてきたデータに基づいてＬＥＤを、ＯＮ，ＯＦＦするサンプルソフトです。

これらサンプルソフトでは、双方が、nRF51822 なので、スマートフォンなどは使いません。
このフォルダには、ほかに blinky_example（ いわゆるＬチカ ）や、uart_example ( ターミナルソフトでエコーバックなど )などがあり、無線を使わずＣＰＵの動作確認ができます。

いづれも、pca10001 と呼ばれている評価基板ではそのまま動作するもののようですが、今回入手した、BVMCN5103-BK KIT 評価基板では、ユニバーサル基板に取り付けるか、ブレッドボードに差し込んで、押しボタンスイッチなり、ＬＥＤなりを付けて動作させます。


サンプルソフトを改造
　サンプルソフト、button_radio_example　フォルダの、main_tx.c を見ると、押しボタンポートの設定が２か所（ BUTTON_0, BUTTON_1 ）ありますが、これを、１個の押しボタンだけにします。というのは、BUTTON_1 で送信データを２にしているにも関わらず、受信側ソースを見ても、送られてきたデータの判定で、ＬＥＤの点灯状態を切り替える処理が無いからです。
BUTTON_0で示されているポートは、このフォルダのファイルを見ても設定らしきものが無いので、探すと nrf51_sdk_v6_0_0_43681\nRF51822\Include\bords\pca10001.h に　#define BUTTON_0 16 と、１６番ピンということが判ります。

サンプルソフト、main_tx.c のオリジナルは以下です。押しボタンポートは入力なので、ポート設定はプルアップを有効にしているだけです。


　上記ソースを、BUTTON_0 が押されているか、否かだけの処理に変更し、さらに、BUTTON_0 の設定や、プルアップ設定を固定値にします。設定値を、インクルードするファイルに書くと、同じボードを使ってソフトを書く場合、共通に使えるので便利なのですが、ソースを別のパソコン上でも同じように使って同じ結果を出そうとすると、インクルードファイルを含めた開発環境のツリー構造もろともコピーしなければならず、バックアップファイルも大きくなってしまうので、できるだけ、ソースファイルを置くフォルダに、すべてを含むようにします。ボード依存の部分は、アプリケーションのソースと一体にしておくほうが、後で見てわかりやすいし、インクルードファイルのコピー漏れの事故を防ぎます。

以下は、改造後の動作テストしたソースです。


改造箇所は、以下ですが、無線関連の設定は、一切変更なしです。
  1. #include "boards.h" をコメントアウトし、#include "bvmcn5103.h"　に変更。bvmcn5103.h は、pca10001.h からコピーしてこれも改造。
  2. while (true)　のすぐあと、uint8_t btns = 0; を
    uint8_t btns = '0';　に変更。これは、受信側で、データの判定を、0 ではなく、'0' となっているため。
    これは、ノルディックのサンプルソフトのバグです。
  3. btn1_nstate = nrf_gpio_pin_read(BUTTON_1);　をコメントアウトするなど、BUTTON_0 のみで操作し、受信側では、BUTTON_0 が押されている間、ＬＥＤが点灯するように改造。
  4. 送信側で、BUTTON_0 が押されている間、送信側にもＬＥＤを付けて点灯するように改造。
    　これには、init(void) 関数に、nrf_gpio_range_cfg_output(LED_START, LED_STOP);　を追加。LED_1 で示されるポートを出力ポートにしています。
  5. ＬＥＤの点灯には工夫を凝らし、BUTTON_0 が押されている間、ＬＥＤは点灯しますが、一瞬消灯しています。反対にBUTTON_0 が離されているときは、一瞬点灯しています。これは、オシロで、送信開始タイミングを見るためです。

次に、受信側の改造をしますが、オリジナルのソースは以下です。



以下は、改造後の受信側の、main_rx.c です。


こちらも、ＬＥＤの点灯の部分で、受信判定直後に、Ｌｏｗか、Ｈｉｇｈのパルスがでるようにしています。

送信側の、main_tx.c と、受信側の、main_rx.c で、共通に使っているボード依存のヘッダーファイル、BVMCN5103.h は以下です。




以下は、動作させて、ＬＥＤの部分と、無線電波の様子をオシロで観察したものです。
黄色：送信側ＬＥＤ　ボタンを押していないとき。TASKS_START = 1U にしてから、Ｈｉｇｈ、送信終了でＬｏｗ。
水色：受信側ＬＥＤ　受信完了で、Ｈｉｇｈのパルス
桃色：２．４ＧＨｚの電波が出ている状況。この画面キャプチャーは取引会社のオシロを借りて撮ったものです。
　帯域２．５ＧＨｚというスペックです。４５０万ほどしたそうな。




ＵＡＲＴを使ってモニタを移植


まず、ＵＡＲＴの動作を確かめる

当ＵＲＬでは、使用するマイコンなどには、ＵＡＲＴで操作できるモニタを移植して、動作確認するだけでなく、動作中のマイコンのメモリやポートを参照できるようにしていますが、nRF51822 にも移植してみます。制御マイコンは Cortex-M0 なので、ＵＡＲＴの入出力ができれば移植は簡単に行えます。ただ、モニタを移植すると、押しボタンスイッチの状態を監視するには、それなりの工夫が必要です。というのは、サンプルソフトの送信プログラムでは、押しボタンの状態を読んですぐに送信という、永久ループになっているので、ＵＡＲＴからのコマンドが読めなくなってしまいます。

そこで、モニタプログラムでＵＡＲＴの受信チェックをポーリングするところで （ getcon() 関数 )、押しボタンスイッチを監視する処理も入れ、ＵＡＲＴから受信が無い間は、押しボタンの状態に応じて無線で送信する処理をするという流れにします。モニタの処理のほとんどの時間は、ＵＡＲＴからの受信待ちになるので、この間で無線処理をすませます。

ＵＡＲＴを操作するには、nRF51822 のマニュアルを頼りに、ポートをたたくという作業になるのですが、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中には、uart_example フォルダに、main.c という名のサンプルソフトがあるので、これを利用します。
　uart_example フォルダの、main.c を見ると、ＵＡＲＴの初期設定と思われる関数を呼び出しています。１０６行に、

simple_uart_config(RTS_PIN_NUMBER, TX_PIN_NUMBER, CTS_PIN_NUMBER, RX_PIN_NUMBER, HWFC);

　の記述があります。シンボル名から、どうやらＵＡＲＴのピンを指定しているのが推測できますが、いわゆるボーレートとか、ビット数、パリティーなどの設定は、main.c の中には、見当たりません。この simple_uart_config のあと、uart_start();　を呼び出して、その中で、simple_uart_putstring を実行して、文字列を出力しています。では、simple_uart_config とか、simple_uart_putstring はどこに記述されているのか、uart_example フォルダを見ても無いので、main.c のインクルードファイル、"simple_uart.h"　を探して中身を見ても手がかりはありません。そこで、uart と名の付くファイルを探すと、nrf51_sdk_v6_0_0_43681\nRF51822\Source\simple_uart というフォルダがあって、そこに simple_uart.c というソースファイルがあります。ここに、simple_uart_config と、simple_uart_putstring の関数がありました。この、simple_uart.c には、ほかにも、１文字出力とか、１文字入力待ちなどがあり、それらは、直接ＵＡＲＴデバイスのレジスタを直接操作しているので、これらを、ＵＡＲＴのＢＩＯＳとして使えそうです。

送信テストプログラム、main_tx.c に、simple_uart_config と、simple_uart_putstring を、main() の起動時に実行させ、指定ポートから、ＵＡＲＴ信号が出るか、確認します。ここで、TX_PIN_NUMBER　とかを、ヘッダーから参照するのではなく、以下のように、直接数値で書いてみます。

simple_uart_config( 16, 12, 1, 13, 0);// HWFC は１だと、ＲＴＳ，ＣＴＳが有効になるので、０にして無効にします。
　送信：１２ ( P0_12 )、　受信：１３ ( P0_13 )

また、simple_uart.c を、main_tx.c のあるフォルダにコピーし、１０７行の、UART_BAUDRATE_BAUDRATE_Baud38400 を UART_BAUDRATE_BAUDRATE_Baud115200　に変更して、ボーレートを１１５２００に変えます。コピーした、simple_uart.c は、ＫＥＩＬのプロジェクトファイル管理の( Project タブ ) app を右クリックして、add Existing Files to Group 'app' を選択してソースとして有効化します。


改造して、ＵＡＲＴを有効化し、起動時に、Start: と出力し，その後、ＵＡＲＴターミナルソフトから１文字送信すると、エコーバックします。
simple_uart.c には、ＵＡＲＴから受信があったか、否かを判定する関数がないので、simple_uart_rxready()　なるものを追加します。ＵＡＲＴから受信が無いと０をリターンし、あれば１をリターンします。


改造した、main_tx.c


ＵＡＲＴの動作を確かめられたら、モニタを追加

モニタでは、ＵＡＲＴの入力チェックで、コマンド待ちでループしてしまうので、無線の受信待ちでのループと両方の待ち状態を維持するには、ちょっとした工夫が必要になります。
  1. 無線の受信待ち中、もし無線を受信できない場合、ＵＡＲＴの受信チェックができなくなるので、無線受信待ちのループの中に、ＵＡＲＴの受信チェックを入れ、もしＵＡＲＴからの受信があると、無線の受信待ちのループから抜け出るようにする。
  2. 無線の受信待ち中に抜け出る場合、再開できるように、フラグを１にし、ＵＡＲＴの受信処理が済んだ後、再びＵＡＲＴ受信待ちに来た場合、フラグが１だと、無線受信待ちループの場所にジャンプする。
  3. 上記のジャンプの前に、フラグを消しておき、無線受信ループを再開する。

以上の処理をする、モニタのＵＡＲＴ受信部分は以下です。



送信側は、ＵＡＲＴ受信待ちの間、送信を行うだけなので、フラグを設けなくても送信しながらモニタのＵＡＲＴ受信の両方を処理できます。
以下は、送信側での、getcon() です。



送信側のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
送信側ソース button_radio_moni.lzh
受信側のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
受信側ソース led_radio_moni.lzh

タイマーを実装し、割り込み処理
モニタを実装したあと、タイマーで割り込みを発生させて、１００ｍｓのインターバルで、送信を行ってみます。モニタを実装した段階では、無線の送信は、ＵＡＲＴの受信待ちの間、最短時間のループで送信するため、チャンネルを占有するようになってしまいます。ＢＬＥでは、できるだけチャンネルを占有しないように、チャンネルを切り替えて通信するようにしているので、今までのプログラムでは、その定石に違反してしまいます。ノルディックが提供しているソフトデバイスも、チャンネルを占有しないような、周波数ホッピングと呼ばれる方法で操作されています。周波数ホッピングの実装は簡単ではないので、せめて送信インターバルを長くして、他のＢＬＥ機器への電波妨害を低減します。

１００ｍｓのインターバルで送信する機能を追加するにあたり、以下の機能も入れます。
  1. １ｍｓで割り込みを発生させ、ｍｓ単位の正確なカウンタを実装。１０００でクリアし、秒カウンタを更新。
  2. １００ｍｓで送信タイムフラグを立て、１ｍｓ間隔で８回送信するような、カウンタを設定する。
  3. １００ｍｓ毎に、８回送信するという動作にする。これは、次の機能、「１ｍｓ精度でタイマー同期」を実現するための準備。
  4. 通信内容（ペイロード）を８バイトまで増やす。これは、送信側と受信側と、同時に変更しないと、通信できない。
  5. 増やした通信内容（ペイロード）にはまだ何も入れませんが、後に１ｍｓカウンタの値を入れる。
  6. 通信内容（ペイロード）の増加設定は、radio_config.c の、#define PACKET1_STATIC_LENGTH　と、PACKET1_PAYLOAD_SIZE　を８にする。
以上のような機能を入れたものが、以下のソースです。実行ファイル（ＨＥＸ）も同梱しています。
送信側のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
送信側ソース button_radio_moni_timer.lzh
受信側のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
受信側ソース led_radio_moni_timer.lzh

以下は、button_radio_moni_timer.lzh を走らせて、ＰＣとターミナルソフトで接続し、ワークメモリ部分の先頭から、１２８バイトをダンプしたものです。メモリダンプのあと、０ｘ２０００２０１Ｃ番地を、ロングワードで表示しています。( コマンドは、 sl20002000(enter) ) この番地は、タイマー割り込み処理　void TIMER2_IRQHandler(void)　で、１ｍｓでカウントアップしている変数、timer2intcount　の番地です。
ＵＡＲＴは、ＴＴＬレベルのシリアル信号を、ＵＳＢでＰＣと接続しています。
USB-serial と BVMCN5103 との接続
信号名
　BVMCN5103　ピン　
　nRF51822 port　
　USB-serial ピン（　秋月電子通商　）　
TXD ( nRF51822 )
　６　
　P0_12　
　５ ( RXD )　
RXD ( nRF51822 )
　４　
　P0_13　
　４ ( TXD )　
LED_1 ( nRF51822 )
　１　
　P0_19　
-　
BUTTON_0 ( nRF51822 )
　２　
　P0_16　
　-　





１ｍｓ精度でタイマー同期

送信側と、受信側の１ｍｓカウンタの値を、無線を使ってほぼ同じ値に維持するテストです。まず１ｍｓカウンタの値を使って、１秒周期で点滅するＬＥＤを追加します。カウンタが５００になると点灯し、１０００になるとカウンタをクリアすると同時に、ＬＥＤも消灯するようにすると、両方同時に電源を入れた場合は、ほぼ同期して点滅しますが、長時間そのままにしておくと、同期がずれてきます。双方に周波数精度の高い水晶発振器があっても、数時間もすれば肉眼でもずれがわかります。BVMCN5103 のスペックを見ると、最大３０ｐｐｍの精度の水晶が使われているみたいですが、３０ｐｐｍだとすると、約３万秒で最大１秒の差があるということなので１日８６４００秒では３秒近いずれが生じます。約８時間で１秒、つまり４時間で、点滅の状態が反転状態になるほどずれることになります。３０ｐｐｍというのは、温度変化を考慮した最大値なので、双方が同じ温度なら、もっと精度が高くなります。

ではどれほどずれるのか、まず１ｍｓカウンタの値でＬＥＤを点滅させ、テストしてみると、１時間で、ＬＥＤ点灯開始に、２０ｍｓの差ができました。これは、１日ではほぼ０．５秒の差になり、約５ｐｐｍの相互精度でした。
  1. 測定は、２台同時に電源ＯＮし、ほぼ同期している状態で点滅ＬＥＤの出力ポートをオシロで時間差を確認します。
  2. 次に、ＬＥＤの点灯時刻が早い方に USB-serial でターミナルで操作できるようにします。
  3. NRF51822-Bug>sl4000a540 ( enter )　で、
  4. 4000A540 00003E80 と表示されるので、ここを、3E90 に変更します。
  5. すると、カウンタがマッチする時間が、1/1000　ほど伸び、１秒が、１．０００１秒になり、オシロで観察すると、点灯開始が遅れてゆき、やがて点灯開始がぴったり一致するところまで来ます。
  6. ここで、0x4000A540 を、3E80 に戻すと、そこで１秒に戻り、しばらく同期したままになります。
  7. １時間ほど放置していると、２０ｍｓほどずれ、送信側と受信側の水晶の精度差が確認できます。
ここで、０ｘ４０００Ａ５４０番地ですが、TIMER2 のコンペアレジスタのアドレスで、カウンタがこの値になると、０クリアされ、１ｍｓ割り込みが発生しします。

１ｍｓでカウントするカウンタを実装し、ＬＥＤを点滅させる送信側と、受信側のスースです。
このソースから、いままでのものから、無線部分の設定（ radio_config.c ）を変更しています。
  1. NRF_RADIO->MODE = (RADIO_MODE_MODE_Nrf_2Mbit << RADIO_MODE_MODE_Pos); から、
    　NRF_RADIO->MODE = (RADIO_MODE_MODE_Ble_1Mbit << RADIO_MODE_MODE_Pos); に変更。ＢＬＥで普通に使われているビットレート。
  2. NRF_RADIO->FREQUENCY = 7UL;　から、NRF_RADIO->FREQUENCY = 4UL;　4 で、２４０４ＭＨｚになり、ＢＬＥのｃｈ１になります。
送信側のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
送信側ソース button_radio_1msdata.lzh
受信側のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
受信側ソース led_radio_1msdata.lzh

１ｍｓでカウントするタイマーでＬＥＤの点滅ができたところでさらに改造

受信した送信側の１ｍｓカウンタの値で、ＬＥＤを点灯するタイミング付近（　５００〜５０８　）の受信データのとき、受信側の１ｍｓカウンタの値と比較すると、５０Ｘ以下と、５０Ｘ以上の場合があります。送信側は、５００，５０１，５０２，５０３，５０４，５０５，５０６，５０７，５０８のとき送信するので、これと比較して、小さいと、受信側が遅れているので、１ｍｓのインターバルを少しだけ小さくして、ＬＥＤ点灯を早めます。逆に、大きいと受信側が進んでいるので、インターバルを１ｍｓより長くして、ＬＥＤの点灯を遅らせます。
  1. これらの処理をするにあたり、送信側で、押しボタンを押したとき、packet[0] が、'1' になっているので、このとき受信側で、インターバルの設定を変えてタイマーを調整します。大きな差があれば、タイマーの調整値を大きくして、早く点灯タイミングがずれるようにします。
  2. どれくらいずらせるかは、ずれの大きさによって変化させ、ＬＥＤ点灯タイミングが近づいてくると、タイマーの調整値を小さくします。
  3. ２ｍｓ以内になると、１ｍｓのインターバルを、１．００００６２５ｍｓか、０．９９９９３７５ｍｓにして、ゆっくり変化するようにします。
  4. ちょうど一致している場合、１ｍｓのインターバルを１ｍｓちょうどにします。
  5. 送信側の押しボタンが離されると、１ｍｓのインターバルは、１ｍｓに戻します。

受信側のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
受信側ソース led_radio_adjust.lzh


Soft Device ( s110 ) を使ってスマートフォンとＵＡＲＴ通信

　ここまでの例では、 Soft Device　を使わない通信でしたが、今度は、 Soft Device　のプロトコルスタックを使って、信頼性の高い通信のサンプルを動かしてみます。
ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）のフォルダをたどると、

　nrf51_sdk_v6_0_0_43681\nRF51822\Board\pca10001\s110\experimental\ble_app_uart

というフォルダがあり、ここにＵＡＲＴで、スマートフォンと通信できるサンプルがあります。experimental というフォルダ名があるので、サンプルとしては、まだ確定して提供していないということですが、正常に動作するようです。nRF51822 はペリフェラルの設定です。スマートフォン側のアプリは、ノルディックからダウンロードできます。

スマートフォン側のアプリ android nRF Toolbox for BLE

このソフトを起動すると、以下のような操作画面になります。 ( android )

nRF51822 側では、以下の s110_ble_app_uart.lzh を実装して電源を入れ、一番下の、９ピンのＤＳＵＢコネクタのアイコンをタップすると、スマートフォンの画面は以下のようになります。画面の中央の、AVALABLE DEVICES: の、Nordic_UAR1 は、ソースの、main.c に記述しています。また、その下の、CA:A1:EB:B6:E3:69　は、nRF51822 のフラッシュメモリの中に書かれている、ＭＡＣアドレスです。（ＭＡＣアドレスは、フラッシュメモリに書かれていてライターでも書き換えることはできません。アプリケーションから読み出しは可能です。）

ここで、Nordic_UAR1 をタップしてしばらくすると、Connected to CA:A1:EB:B6:E3:69 と、接続完了のメッセージが出て、ＵＡＲＴの送受信できることが報告されます。


ここで、パソコンのターミナルソフトから、"abcdefg" (enter) と入力すると、"abcdefg " received となって、スマートフォンで受信したことがわかります。

ここで、"abcdefg "　と、"g" の右がスペースのように見えますが、実は、( enter ) の、0x0D です。ソースの、main.c を見ると、送信するとき、( enter ) の、0x0D も含めて送信しているからです。


送信側 ( peripheral ) のソースです。すべてを含んでいませんが、残りは、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）の中にあります。
送信側ソース s110_ble_app_uart.lzh
このソースファイルは、ＴＯＰフォルダが s110 になっており、nrf51_sdk_v6_0_0_43681\nRF51822\Board\pca10001\s110\( ここ )に置きます。KEIL のプロジェクトファイルには、ファイルの存在場所のツリー構造も含んでいるので、ソースとプロジェクトファイルの設置場所を合わせておかないと、起動時に「ファイルが無い」というマークが付いてしまい、新たにファイルの存在場所を指定しないと、build できません。

ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）のサンプルソフトから、少し変更しています。
  1. ＵＡＲＴのポートは、いままで解説してきたソースに合わせています。
  2. ＵＡＲＴポートは、USB-serial 変換で接続し、パソコンのターミナルソフトで送受信を確認します。
  3. 通信相手は、上述の　スマートフォン用アプリを立ち上げ、接続しますが、ＣＯＮＮＥＣＴＩＯＮ開始画面で、Nordic_UAR1 になるように、機器名を、Nordic_UART から、Nordic_UAR1 に変更しています。( main.c の ５２行 )



Soft Device ( s110, s120 ) を使って nRF51822 相互にＵＡＲＴ通信
通信相手がスマートフォンではなく、２台の nRF51822 間で、ＵＡＲＴの通信を行います。ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）には、nRF51822 相互のＵＡＲＴ通信例がなく、ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）に HRM セントラルの例を見つけたので、それと、HRM ペリフェラル（心拍数計測のペリフェラル）とで通信します。通信プロトコルは、HRM なのですが、ペイロードとして使える２０バイトのパケットに、ＵＡＲＴで送りたい文字を乗せると、通信できます。最新のＳＤＫ（ nRF51_SDK_10.0.0_dc26b5e ）には、ble_app_uart_c なるフォルダに、ＵＡＲＴセントラルのサンプルがあるようですが、これはまたあとでテストしたいと思います。

心拍数計測のセントラルのサンプルは、

nrf51_sdk_v6_0_0_43681\nRF51822\Board\nrf6310\s120\experimental\ble_app_hrs_c\ フォルダにあります。

これを改造して、心拍数のデータではなく、ＵＡＲＴのデータを送受信しますが、普通のＵＡＲＴの１バイト単位の通信を行うとパフォーマンスが２０分の１に低下してしまいます。これは、心拍数のデータを送る場合でも、ユーザーが使えるペイロードは２０バイトあるので、ここに、心拍数のデータを載せても、せいぜい２バイトに収まり、残り１８バイトはごみになります。ＵＡＲＴの場合、送りたいデータが１バイト単位なので、１バイトの送信要求があると、直ちに送る必要があり、残り１９バイトの空きが、無駄になってしまうからです。

そこでＡＤコンバータから読んだデータを、定期的に送るような場合を想定し、１サンプル毎に送るのではなく、２０バイト分溜まった時点で送るようにします。ＢＬＥの無線伝送能力の上限に近い２０パケット／秒で送信し、４００バイト／秒の無線伝送ができる雛形を作ってみました。

以下が、２０バイト単位で、ＵＡＲＴで相互伝送できる、nRF51822 を使った、ペリフェラルと、セントラルのプロジェクト一式です。
セントラル側のソースは、 こちらを元に変更しています

送受信ソース BVMCN5103_uart_peri_cent.lzh ＵＡＲＴのポート送信：P0_12, 受信：P0_13
以下は、ＵＡＲＴのポートを、送信：P0_13, 受信：P0_12 に変更したもの。基板を作成するとき、以下の割り当てになってしまった。
送受信ソース BVMCN5103_uartx_peri_cent.lzh

このファイルは、解凍して以下の位置に置きます。場所を間違えると、ＫＥＩＬでプロジェクトを開いても、ファイルの所在が判らないマークが付き、コンパイルができません。
nrf51_sdk_v6_0_0_43681\nRF51822\Board\( ここに、BVMCN5103 フォルダを置く )

ＵＡＲＴからのデータを伝送中の、送信側と、受信側の消費電流

消費電流を測定するには、電流プローブが必要ですが、ここでは、BVMCN5103 の電源供給ピンに、３．３Ｖ電源を直接つなぐのではなく、９Ωの抵抗を間に入れて、その間の電圧をオシロで観察します。BVMCN5103 は、電波を使っている間、１８ｍＡほどの電流が流れるので、９Ωだと、１６０ｍＶほどの電圧になり、様子を観察できます。

以下は、４ｃｈのオシロを借りて測定したスクリーンショットです。かなりノイズが重畳していますが、様子は判ります。
黄色：送信側の９Ωの両端電圧
桃色：送信するデータを受け取るＵＡＲＴ信号
水色：受信側の９Ωの両端電圧
緑色：受信して出力したＵＡＲＴ信号



このスクリーンショットは、パソコンからＵＡＲＴで、１パケット２０バイトを、送信側に１秒に２０回送っているときのものです。インターバルは５０ｍｓなのですが、パソコン側での時間管理が正確には行えないので、インターバルは、３０ｍｓから６６ｍｓの間で変動しています。総計では１秒に約２０回になるはずで、長時間（１時間）でのずれは起らないようにしています。（　MFC の、OnTimer 関数を２０ｍｓで起動し、処理は、timeGetTime();を使って、５０ｍｓインターバルにしている）

無線を使うインターバルが３０ｍｓで一定で、送信側、受信側ともに同期しているのを観察できます。つまり、ノルディックの　SoftDevice を使うと、ＢＬＥの通信は、３０ｍｓインターバルで行われ、お互いにそのタイミングから外れないことです。ＵＡＲＴで通信データを送信側に送らなくても、無線通信は常に３０ｍｓインターバルで行われており、その場合、受信側はＵＡＲＴに何も出力しません。

電波を使っているときは、１８ｍＡほど流れますが、平均すると、送信側で約１．３ｍＡ、受信側で約２ｍＡとなり、この電流は１秒に４００バイトのデータを伝送してもあまり増加しません。受信側が大きいのは、ＵＡＲＴで出す処理を、ここではポーリングで行っているからと思われます。送信側ではＵＡＲＴを割り込み処理にしているので、受け取ればＣＰＵが低消費電力モードに移行するからと推測されます。（power_manage();　関数を呼び出している　）


nRF51822 を使って相互にＵＡＲＴ通信 ペリフェラルの名前とＭＡＣアドレス表示

nRF51822 で相互通信する場合、いままでの例では、複数のペリフェラルの中、特定のペリフェラルだけ選択して、ペアリングするという機能が無いので、どのペリフェラルとつながるか予測できません。特定のペリフェラルだけとペアリングするには、ＭＡＣアドレスか、ペリフェラルの名前で区別する方法があります。ＭＡＣアドレスで区別する場合、あらかじめＭＡＣアドレスを、セントラル側が知っておく必要があります。ペリフェラルの名前で区別する場合は、ペリフェラル側のソフトで個別に名前を設定できなければなりません。

ペリフェラルの名前は、スマートフォンでは、ペリフェラルの名前とＭＡＣアドレスの表示で確認　のように表示されるのですが、これを、nRF51822 のセントラル側で確認できるようにします。
スマートフォンでは、以下のように、接続（ペアリング）のまえに選択、確認画面が出る。


ペリフェラルで、名前を設定しているところ。main.c の設定している部分。

このソースでは固定ですが、static 変数で作成し、nRF51822 以外の装置から、何らかの情報を読んで、起動（ gap_params_init(); )前に 名前を変更すれば、"Nordic_UAR1"　以外の名前にすることができるようです。

　さてここで、この名前を、セントラル側で読む例ですが、サンプルソフトではそれらしいところが無く、あるのは、ペアリングが成立した後、以下のようにＭＡＣアドレスを報告する部分です。


　ペアリング後の報告では、スマートフォンみたいに特定のペリフェラルを選択することができません。ＭＡＣアドレスと名前は、アドバタイジングの時にペリフェラルから送られているので、どこで読みだせるのか、いろいろ調べていると、以下の部分でできることが判りました。 BLE_GAP_EVT_ADV_REPORT　とある部分です。名前から想像できるように、ペリフェラルからのアドバタイジングパケットを受信した時の報告です。

BLE_GAP_EVT_ADV_REPORT　で、いきなりＵＵＩＤをチェックしていますが、ＵＵＩＤ以外に、ＭＡＣアドレスや、デバイス名も送られてきていることが、params.adv_report.data　をヘキサダンプすると確認できます。
  1. params.adv_report.data　には、ＵＵＩＤか、又はデバイス名。.data[1] に、ＵＵＩＤか、デバイス名かを区別するコードが書かれています。
    　data[0] には、（コード＋有効データ）のバイト数、data[1] が 0x09 の場合、デバイス名になります。
    　data[1] が 0x07 の場合、ＵＵＩＤになります。
  2. params.adv_report.peer_addr　には、ＭＡＣアドレス。peer_addr[0] --- peer_addr[5] の６バイト。
  3. ＭＡＣアドレスは、アドバタイジングパケットに常に含まれますが、ＵＵＩＤと、デバイス名は、１度には送られず、別のパケットに分けて、最低２回送られるようです。
このことを確認する、セントラルのソースで、ヘキサダンプする部分が以下です。


上記のセントラルソース一式 BVMCN5103_uartx_cent_s120.lzh
上記のセントラルソース一式 こちらが、ＭＡＣ表示付 BVMCN5103_uartx_cent_s120_v2.lzh
実行させて、ペアリングが確立するまでターミナルに表示させたものです。この例では、ＭＡＣは表示されていません。

この図から、３行目に、
adv_report.data = 0C,09,4E,6F,72,64,69,63,5F,55,41,52,31,02,01,05,len = 16　とありますが、これは、"Nordic_UAR1" であるのが確認できます。
さらに、５行目に、
adv_report.data = 11,07,9E,CA,DC,24,0E,E5,A9,E0,93,F3,A3,B5,01,00,40,6E,len = 18　とありますが、
これは、ペリフェラルのソース、ble_nus.c　に、以下のように設定されている、ＵＵＩＤです。（一部異なっています。0xB5 の次が 0x01）



nRF51822 を使って相互にＵＡＲＴ通信。 通信インターバル変更

　今までの通信では、サンプルソフトのデフォルト３０ｍｓ設定で、通信インターバルが設定されていましたが、このインターバルは、１．２５ｍｓ単位で変更できます。設定しているところは、セントラル、ペリフェラル共に、main.c の冒頭近くにあります。
セントラルの main.c の設定


ペリフェラルの main.c の設定


　これらは、デフォルトで設定されていて、意味するところは、最短は、両方とも条件を満たす長い方、最長は、両方とも条件を満たす短い方で、最短は２０ｍｓ、最長は７５０ｍｓ（コメントの７５ｍｓはコメントの間違い）になります。そして、実際に通信インターバルが落ち着くところは、ＢＬＥのコンセプトである、できるだけ消費電力を少なくするように、両方の条件を満たす３０ｍｓになります。

　通信インターバルは、セントラル側が、ペリフェラルからのアドバタイジングにＯＫを出すときに行われ、それを行っているところが、main.c の以下の部分です。
関数、static void on_ble_evt(ble_evt_t * p_ble_evt)　の中ほど、sd_ble_gap_connect() の引数、&m_connection_param で、で通信インターバルを設定しています。


　ペアリングを始める前に、上記のように、インターバルを設定していますが、関数、static void on_ble_evt(ble_evt_t * p_ble_evt)　の最後に、
case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST:　
の場合の処理に、sd_ble_gap_conn_param_update() というＡＰＩを呼び出しています。ここに来るのは、たぶん、ペリフェラルから通信インターバルの変更要求があった場合に、応答する処理と思われ、ペリフェラル側でその要求を出さない限り、この処理は行われないみたいです。
　ともあれ、この sd_ble_gap_conn_param_update() というＡＰＩで、ペアリングした後でも、通信インターバルを変更できそうです。

　ＡＰＩを呼び出しているところは、main.c の、関数、static void on_ble_evt(ble_evt_t * p_ble_evt)　の中の以下です。コメントには、 Accepting parameters requested by peer.　とありますが、通信インターバルを変更できる権利は、セントラル側だけにあるようです。このＡＰＩの引数を見ると、p_gap_evt->conn_handle　が、ペリフェラルを操作するハンドル、そして、&p_gap_evt->params.conn_param_update_request.conn_params　が、インターバルの数値を格納したパラメターテーブルですが、どのような数値なのかは、SoftDevice のマニュアルをたよりに探すと、include\ble\120\ble_gap.h　で定義されているのが判ります。


　そこで、p_gap_evt->conn_handle　を記憶しておき、ble_gap_conn_params_t　で定義テーブルを作成しておき、このＡＰＩを呼び出せば、通信インターバルを変更できるのか、確認してみます。定義テーブルは、main.c では、初期化のときにはＲＯＭになっているので、これを変数にして初期化時と、ペアリング後の変更時とで共有します。
こちらが通信インターバルを変更できる、BVMCN5103_uartx_cent_speed_s120.lzh セントラルのソースです。
こちらが通信インターバルを変更できる（ＭＡＣ表示付）、BVMCN5103_uartx_cent_speed_s120_a.lzh セントラルのソースです。
通信インターバルは、コントロールＤ１文字で、短くし、コントロールＵ１文字で長くします。変更するインターバルの値は、ソースにテーブルで定義し、それへのインデックスで指定します。コントロールＤでインデックスを下げ、コントロールＵでインデックスを上げます。初期値は、３０ｍｓとし、コントロールコードを１文字、ＵＡＲＴで BVMVN5103 に送ると、コードに従ってインデックスの内容で、通信インターバルを変更します。なお、コントロールコードは、無線で送信しません。

コントロールコードで変更している部分は以下。conn_handle は、コネクションが成立したとき、記録した値。


以下は、このセントラルのプログラムで、通信インターバルを短くしたときのターミナルの表示と、オシロの波形です。


青色が、ＵＡＲＴのコントロールＤでトリガ（黄色の菱形）をかけた波形、赤色が、BVMCN5103 の電源電圧のドロップ。１０オームを介してで電源と接続しており、無線電波を使っているとき、電流が増加するので、下がります。コントロールＤを受けた後、８回ほどペリフェラルと通信している部分は、３０ｍｓですが、その後１５ｍｓになっています。しかし、何秒か経つと、ターミナルで２行目に表示しているように、６００（７５０ｍｓに相当）になってしまいます。というのは、ペリフェラルでの最短インターバルが、１６（２０ｍｓに相当）なので、範囲外となり、最長のインターバルにするように、ペリフェラルから、通信インターバルの変更要求が来て、それに応答した結果です。



通信インターバルが、７５０ｍｓになった波形





nRF51822 を使って相互にＵＡＲＴ通信。２台のペリフェラルとペアリング

　ＳＤＫ（ nrf51_sdk_v6_0_0_43681 ）には、複数のペリフェラルと接続するサンプルとして、
nrf51_sdk_v6_0_0_43681\nrf51822\Board\nrf6310\s120\experimental\ble_app_multilink_central　と
nrf51_sdk_v6_0_0_43681\nrf51822\Board\nrf6310\s120\experimental\ble_app_multilink_peripheral　が　ありますが、
ble_app_multilink_central　のフォルダに、device_manager_cnfg.h　があり、このファイルの５２行に、

と設定されており、最大８台のペリフェラルと接続できることが判ります。
サンプルソフトでは、セントラルにＬＥＤを複数個設置し、対応したペリフェラルの押しボタンの操作で、ＯＮ，ＯＦＦする機能があります。この例を参考に、ＵＡＲＴでの相互通信で、複数のペリフェラルと通信できるように改造しようとしましたが、ＵＡＲＴ相互通信と、このサンプルとでは違いが多すぎて、改造を進めることができず、途中であきらめました。

そこで、先ほどの、#define DEVICE_MANAGER_MAX_CONNECTIONS　に注目し、１対１のＵＡＲＴ相互通信のソースにある、device_manager_cnfg.h　で　１　に設定されているところを、２に変更して、どのようになるのか、試してみることにしました。セントラル側のソースは、DEVICE_MANAGER_MAX_CONNECTIONS　を２にするだけでコンパイルし、ペリフェラルは（ ＵＡＲＴ相互通信 ）を２台用意し、セントラルを先に電源を入れ、１台目のペリフェラルの電源を入れます。そして通信が確立したところで、２台目の電源をいれると、
ペアリングの過程が表示され、エラーらしきものもありません。これはもしかして、２台と通信できるということなのかも！！
以下が、２台のペリフェラルとペアリングする過程のセントラル側の記録です。
[APPL]: << DM_EVT_SECURITY_SETUP_COMPLETE conn_handle = 0 で、１台目のペアリングが確立。
そして最後から２行目の
[APPL]: << DM_EVT_SECURITY_SETUP_COMPLETE conn_handle = 1 で、２台目のペアリングが確立。

　ためしに、各ペリフェラルに、２０バイトの文字をＵＡＲＴで送ると、それぞれが無線で送信し、セントラル側に表示されます。


nRF51822 を使って相互にＵＡＲＴ通信。２台のペリフェラルと相互通信

　２台のペリフェラルから送られたデータを表示できたものの、どちらからのデータなのかは、このままではデータの内容で区別するしかありません。また、セントラルからデータを送る場合、２台のペリフェラルのうち、送信先を指定するのはどうするのか、このままのソースでは行えません。
　ためしに、２台とペアリングできた時点で、セントラルにＵＡＲＴで２０バイト送ると、先にペアリングした方ではなく、あとからペアリングした方に送信されます。このことは、送り先を指定する方法のヒントになります。

　さて、今までは、２台のペリフェラルの起動は同時ではなく、１台目のペアリングが確定してから、２台目を起動していましたが、これを２台同時に起動するとどうなるのかを試すと、途中でエラーで止まってしまいます。サンプルソフトでは、app_error_handler　で、永久ループするようになっています。なぜエラーになるのかは、サンプルソフトの、ble_app_uart_c が、元々１台のペリフェラルだけを想定していて、ペアリング確立過程で、相手を区別することなく進んでいくからです。

　では、同時に２台のペリフェラルからのアドバタイジングが有る場合はどうするのか、以下の方法を考えてみました。
  1. ペアリング確立過程で、 Softdevice からのメッセージで送られてくる情報の記憶場所を２台分用意する。
    　具体的には、m_ble_db_discovery　をもう一つ、m_ble_db_discovery2
    　と、m_dm_device_handle　をもう一つ、m_dm_device_handle2
  2. アドバタイジングのデータのデバイス名で２台のペリフェラルを区別し（０と１）、それぞれＭＡＣアドレスを対応して記録しておく。
  3. DM_EVT_CONNECTION　で、ＭＡＣアドレスを読んで、記憶しておいたＭＡＣアドレスのどれと一致しているのか探す。このとき、デバイス名で区別した、０か１かが判明する。
  4. DM_EVT_CONNECTION　では、コネクションハンドル情報も通知されているので（０か１になる）、ハンドル番号を、デバイス名（番号）に対応させて記録する。
  5. DM_EVT_CONNECTION　での処理は、ble_db_discovery_start　で次のペアリング処理に移るが、このときハンドル番号に対応した、m_ble_db_discovery　か、m_ble_db_discovery2 を（アドレスで渡す）引数にする
  6. ＵＡＲＴのセントラル側では、コネクションの最終手続きで、uart_c_evt_handler が呼び出され、ここで、write_dummy() 関数を使っていますが、この先は、ble_uart_c.c の中にあり、そこでは、write_char(mp_ble_uart_c->conn_handle, mp_ble_uart_c->TX_handle, (uint8_t *) "dummy", 5); をさらに実行します。ここで、mp_ble_uart_c なるポインタを引数にしているので、そこのハンドル値を要求されている、０か１にする。このハンドル値は、db_discover_evt_handler　関数が、uart_c_evt_handler　を呼び出す前に、ハンドル値をその都度書き換えているので、最後に呼び出したハンドル値になり、write_dummy() 関数では０か１か、特定することができない。ここで、特定できる、write_dummy() を用意する。write_dummy0() と、write_dummy1() 。
  7. 上記の０か１かの区別のため、ble_uart_c.h で定義している、ble_uart_c_evt_t　に、uint8_t handle; を追加し、db_discover_evt_handler　関数が、uart_c_evt_handler　を呼び出す前に、このハンドル値を、evt.handle = p_evt->conn_handle;　で書く。これで、uart_c_evt_handler　関数内で、ハンドル値を確認して、write_dummy0() と、write_dummy1() を振り分ける。
  8. セントラル側は、どちらにＵＡＲＴデータを送るかを区別できるように、ホストマイコンとのＵＡＲＴプロトコルを策定する。
  9. ペリフェラルから無線で送られたデータを区別できるように、セントラル側は、uart_c_evt_handler　内でハンドル値で区別し、プロトコルに反映する。
  10. ペアリング確立過程では、１台単位で処理が進むようにする。この為に、ペアリング進行状態を示す、シーケンス管理フラグを２台分確保して、１台目のペアリング処理が終わるまで、２台目からのアドバタイジングには応答しないようにする。
　まあ、ざっとこんな具合ですが、ここまでたどり着くのに、ずいぶんと試行錯誤がありました。

２台のペリフェラルとの接続で、接続の順番が変わると、それぞれのペリフェラルを特定するコネクションハンドルも変わる

　下図のように、ペリフェラルとの接続順番の違いで、ハンドル番号も変わる。


　複数のペリフェラルとの接続では、ソフトデバイスによってコネクションハンドルが、０と１に割り振られますが、ハンドル番号だけではペリフェラルを特定することができません。この為、２台のペリフェラルを特定して、セントラルからデータを送りたいとき、ハンドル番号と、ペリフェラルとの関係を知っておく必要があります。
　しかし、この関連付けは簡単ではありません。事前に、各ペリフェラルのＭＡＣアドレスが判っている場合は、比較的簡単で、device_manager_event_handler　の、DM_EVT_CONNECTION　の時、ＭＡＣと、ハンドル番号が同時に参照できるので、このとき、指定したいペリフェラルのハンドル番号が特定できます。
　通常、ＭＡＣアドレスを事前に知っておいてペリフェラルを特定することはほとんどなく、このことは、イーサネットのＭＡＣアドレスと、ＩＰアドレスの 関係付けと似ています。ＩＰアドレスに相当するのが、ＢＬＥではＵＵＩＤになりますが、ＵＵＩＤは、勝手に値を変えて使えるものではないので、デバイス名を使うようにします。無論このデバイス名は、任意に設定できるので、全く関係の無いペリフェラルで同じデバイス名になることも想定されるので、イーサネットのＩＰアドレスのようには扱えませんが、ＵＵＩＤの不一致で排除することになります。

　こちらがデバイス名を設定できるペリフェラルと、セントラルのソースです。BVMCN5103_setdev_s110_s120.lzh

以下は、セントラル、ぺリフェラル共用の回路図。図の右で、「デバイス番号(P) ショートで２番」とありますが、セントラル側では、ショートでデバッグ情報をＵＡＲＴに出力します。オープンだとＵＡＲＴ通信で受信したデータだけＵＡＲＴに出力します。


セントラル側では、アドバタイジングパケットで、ペリフェラルのデバイス名を表示する機能を追加しています。
　ペリフェラル側では、P0_02 ピンを入力ピンとしてプルアップ設定し、ジャンパーでショートすると、Ｌｏｗになるので、起動時に、デバイス名の最後の文字を、 '2' に変更しています。ショートしなければ、１となります。デバイス名は、それぞれ、Peripheral_1 と、Peripheral_2 となります。
　以下は、最初にペリフェラル２を起動し、あとからペリフェラル１を起動したときの、セントラルのログ情報です。
４行目から、
[APPL]:[1A 21 4C 54 9A EE]: ADV EVT
[APPL]:device name = Peripheral_2
とあり、ペリフェラル２からのアドバタイジングパケットを示し、
３６行目から、
[APPL]:[69 E3 B6 EB A1 C3]: ADV EVT
[APPL]:device name = Peripheral_1
ペリフェラル１と報告されています。それぞれのＭＡＣアドレスも報告しています。

ここで、３行目にRSSI = -68 ,09　とありますが、これは、ペリフェラル２からの、電波強度の報告です。マイナス表記ですが、下がるほど弱いことを示します。09 は、パケットデータ種別の９番ということで、デバイス名が送られてきたということです。３５行目では、RSSI = -51　とあり、Peripheral_1 の方からの電波が強いことが判ります。

　２台のペリフェラルと相互通信できる、 セントラルとペリフェラルの KEIL プロジェクトソース一式です。
nrf51_sdk_v6_0_0_43681\nrf51822\Board\ フォルダに、解凍したフォルダ、BVMCN5103_2peripheral　を配置すると、KEIL のプロジェクトを開けます。
各モジュールのＵＡＲＴ通信のフォーマットは以下の説明図を参照。

２台のペリフェラルと通信させるテスト環境

　２台のペリフェラルと接続ができることは判りましたが、ペリフェラルを指定してデータを送るには、ＵＡＲＴで指示するか、Ｉ／ＯピンのＬｏｗ、Ｈｉｇｈでペリフェラルの区別をする必要があります。また、ペリフェラルから送られてきたデータがどちらからのものか、これもＵＡＲＴで知らせるか、Ｉ／ＯピンのＬｏｗ，Ｈｉｇｈで区別する必要があります。Ｉ／Ｏピンで行う方法では、セントラルとＵＡＲＴで接続する相手がパソコンなどの場合は、Ｉ／Ｏを制御しなければならず、そう簡単ではないので、ＵＡＲＴで指定することとします。３台のＢＬＥモジュールの３ポートのＵＡＲＴを一元管理するには、ＵＳＢ−ＵＡＲＴ変換ケーブルを３本使うことになりますが、これも、ソフトが複雑になりそうなので、一元管理できる方法を考えてみました。
　以下が、ＦＰＧＡを制御マイコンとして、３ポートのＵＡＲＴ一元管理する構成と、ＵＡＲＴフォーマットです。


上のフォーマットでは、ペリフェラルのＵＡＲＴ受信で受信バッファーのポインタを初期化する機能が無いので、パワーＯＮなどのごみが残ることがあるので、ＳＴＸで初期化をする機能を追加したものが以下。


テスト環境に使った、ＦＰＧＡ基板。Digilent の、ＡＲＴＹ。コネクタ Pmod JA に接続しているのが、３ｃｈのＵＡＲＴ。ピン配置は、ＵＳＢ−ＵＡＲＴ変換ケーブル（秋月電子通商製のピン配置に合わせている）

UART コネクタ、１：セントラル、２：ペリフェラル１、３：ペリフェラル２
ＦＰＧＡのソースと、.bit .bin ファイル。ソース、bin, bitこれには、Custom MicroBlase RTL ソース、プログラムソース、GCC makefile など含みます。開発は、Vivado 15.3。モニタにバグあり 　どのようなバグなのか、調査 Vivado 15.3 SDK の使い方でコンパイルオプションにバグあり

ＦＰＧＡのソースと、.bit .bin ファイル。ソース、bin, bitこれには、Custom MicroBlase RTL ソース、プログラムソース、GCC makefile など含みます。開発は、Vivado 15.3。とISE 14.4 の、ＧＣＣツールチェーンを使ったもの

カスタムマイクロブレーズのソースの説明はこちら→外部メモリでも動作できる、新たなカスタム設計の MicroBlaze　５クロック／１命令
Custom MicroBlaze は、Xilinx の MicroBlaze のサブセットですが、ＧＣＣコンパイラが生成する命令を実行できるものです。（ネイティブな乗除算命令を使わないコードに限る。乗除算命令は、加減算でエミュレートされるので、三角関数など、超越関数も演算可能）

以下の　Vivado のＳＤＫでは、一部不具合が見られたので、（　どのようなバグなのか、調査 Vivado 15.3 SDK の使い方でコンパイルオプションにバグあり　）ISE 14.4 の、ＧＣＣでの開発を後述します。
Vivado は、ＳＤＫをインストールすると、MicroBlaze の開発ツールチェーンを使えるようになりますが、そのためのパスの設定を以下のようにします。
マイクロブレーズ用コンパイラのツールチェーンパスを、C:\Xilinx\SDK\2015.3\gnu\microblaze\nt\bin
ＧＣＣツールのパスを、C:\Xilinx\SDK\2015.3\gnuwin\bin
とすると、コマンドプロンプトで、
set path=c:\Xilinx\SDK\2015.3\gnu\microblaze\nt\bin;c:\Xilinx\SDK\2015.3\gnuwin\bin;%PATH%　を実行します。

上記、src_bit.lzh　を解凍すると、src_bit\sources_1\new\artycmb　フォルダができますが、このフォルダにコマンドプロンプトを移動し、 make ( enter ) で、Custom MicroBlaze の０番地からの実行ファイル（ヘキサ表現）、cmbiofint.mot　が生成されます。このデータを０番地からアクセスできるブロックＲＡＭなどに書いておくと、０番地から実行できます。

　ISE 14.4 をインストールすると、( c:\xilinx\14.4\ フォルダとする )
マイクロブレーズ用コンパイラのツールチェーンパスを、C:\xilinx\14.4\ISE_DS\EDK\gnu\microblaze\nt\bin
ＧＣＣツールのパスを、C:\xilinx\14.4\ISE_DS\EDK\gnuwin\bin;
とすると、コマンドプロンプトで、
set path=C:\xilinx\14.4\ISE_DS\EDK\gnu\microblaze\nt\bin;C:\xilinx\14.4\ISE_DS\EDK\gnuwin\bin;%PATH%
上記、src_bit_ise14_4gcc.lzh　を解凍すると、src_bit_ise14_4gcc\sources_1\new\14artycmb　フォルダができますが、このフォルダにコマンドプロンプトを移動し、 make ( enter ) で、Custom MicroBlaze の０番地からの実行ファイル（ヘキサ表現）、cmbiofint.mot　が生成されます。このデータを０番地からアクセスできるブロックＲＡＭなどに書いておくと、０番地から実行できます。
では、ブロックＲＡＭに書くのはどうするのか、ですが、ＲＴＬソースの中で、defparam で宣言します。しかし、これが一筋縄ではできず、専用の変換ツールを使います。
ヘキサファイル（ cmbiofint.mot ）から、Custom MicroBlaze のメインメモリ mainmem.v を作成する専用変換ツール、binutils.exe　binutils_018.lzh

　ＢＬＥモジュールのＵＡＲＴと接続して、ＰＣから制御する MicroBlaze の機能として以下のものがあります。CMB-BUG> は、ＦＰＧＡ内の操作ソフトのコマンドプロンプト。115200 bps のターミナルソフトで、ＵＡＲＴ経由で操作します。
  1. セントラルから、ペリフェラル１にデータを送信し、返答を待ってから再度送るのを繰り返す。( CMB-BUG>rl2 (enter ) )
  2. セントラルから、ペリフェラル１とペリフェラル２にデータを送り、各ペリフェラルで受信したら、各ペリフェラルからセントラルにデータを送り、それをセントラルで受信するとＵＡＲＴで受け取る。両方のペリフェラルからの返答データが揃うと、またセントラルからペリフェラル１とペリフェラル２にデータを送る。これを繰り返す。( CMB-BUG>rl3 (enter ) )
  3. 指定したインターバルで、上記のような、２個のペリフェラルにデータを送信し、返答を待つが、指定時間まで返答がなければ、やり直す。( CMB-BUG>rl7,300 (enter ) 300ms のインターバルの場合)
ＢＬＥモジュール操作のコマンドは以上ですが、メモリの内容を表示したり、変更したりできる簡単なモニタ機能もあります。また、任意のアドレスから実行できる g コマンドがあり、0x8000000 番地から３２ｋＢのメモリを実装しているので、コンパイラで生成するＭＡＰを変えたソフトをロードして実行でき、Vivado を走らせなくても操作プログラムのテストができます。同梱した、artycmb フォルダ以下の、makefile には、0x8000000 番地から実行できるヘキサデータを生成するスクリプトを含んでいます。
モニタの操作と機能はこちら→　Custom MicroBlaze モニタの操作
以下は、ＢＬＥテストで使ったＣＰＵのレジスタ、メモリマップ
Custom MicroBlaze のレジスタ、メモリマップ
名称
　アドレス　
　アクセスサイズ　
　機能１　
　機能２　
　装備　
mainmem
　0x0 ---- 0x7FFF　
　１，２，４バイト　
　プログラム、データ３２ｋＢ　
　５クロックで１命令　
　標準装備　
mainmem2
　0x8000000 ---- 0x8007FFF　
　１，２，４バイト　
　プログラム、データ３２ｋＢ　
　プログラムデバッグ用　
　BLE test　装備　
SIOC
　0xFFFF0003　
　1 バイト　
　ＵＡＲＴステータス　
　b2:1で送信中 b1:１で送信バッファー１バイトあり　b0:受信バイトあり　
　標準装備　
SIOD
　0xFFFF0007　
　1 バイト　
　ＵＡＲＴデータレジスタ　
　ライトで送信データ　リードで受信データ　
　標準装備　
TIMER0BASE + 4
　0xFFFF0014　
　フリーカウンタ　
　100MHz でカウントアップ　
　ＣＰＵクロックでカウント 100 MHz　
　標準装備　
TIMER0BASE + 8
　0xFFFF0018　
　フリーカウンタ　
　上記カウンタオーバーでカウント　
　42.949 秒でカウント　
　標準装備　
SIOC1
　0xFFF00003　
　1 バイト　
　ＵＡＲＴ１ステータス　
　b2:1で送信中 b1:１で送信バッファー１バイトあり　b0:受信バイトあり　
　BLE test 装備　
SIOD1
　0xFFF00007　
　1 バイト　
　ＵＡＲＴ１データレジスタ　
　ライトで送信データ　リードで受信データ　
　BLE test 装備　
SIOC2
　0xFFF00013　
　1 バイト　
　ＵＡＲＴ２ステータス　
　b2:1で送信中 b1:１で送信バッファー１バイトあり　b0:受信バイトあり　
　BLE test 装備　
SIOD2
　0xFFF00017　
　1 バイト　
　ＵＡＲＴ２データレジスタ　
　ライトで送信データ　リードで受信データ　
　BLE test 装備　
SIOC3
　0xFFF00023　
　1 バイト　
　ＵＡＲＴ３ステータス　
　b2:1で送信中 b1:１で送信バッファー１バイトあり　b0:受信バイトあり　
　BLE test 装備　
SIOD3
　0xFFF00027　
　1 バイト　
　ＵＡＲＴ３データレジスタ　
　ライトで送信データ　リードで受信データ　
　BLE test 装備　
LED1
　0xFFF00043　
　1 バイト　
　ＢＬＥテストでセントラル送信開始で点灯　
　ＢＬＥテストでペリフェラル受信で消灯　
　BLE test 装備　
MICROTIMER0BASE
　0xFFFF0014　
　32 bit １μsec カウンタ　
　何かを書くと０になる　
　１ＭＨｚでカウントアップ　
　BLE test 装備　

以下は、BLE test で使っている　Digilent の、ARTY 基板の使用ピン
ARTIX-35T ピン割り当て
名称
　ARTY コネクタ　
　XC7A35TICSG324−1L　ピン番号　
　機能　
RXD ( SIO )
USB-UART FT2232H　
　D10　
　ＣＰＵ操作ＵＡＲＴ受信ポート　
TXD ( SIO )
USB-UART FT2232H　
　A9　
　ＣＰＵ操作ＵＡＲＴ送信ポート　
RXD1 ( SIO1 )
Pmod JA　
　D12　
　セントラル操作ＵＡＲＴ受信ポート　
TXD1 ( SIO1 )
Pmod JA　
　K16　
　セントラル操作ＵＡＲＴ送信ポート　
RXD2 ( SIO2 )
Pmod JA　
　A11　
　ペリフェラル１操作ＵＡＲＴ受信ポート　
TXD2 ( SIO2 )
Pmod JA　
　A18　
　ペリフェラル１操作ＵＡＲＴ送信ポート　
RXD3 ( SIO3 )
Pmod JA　
　B11　
　ペリフェラル２操作ＵＡＲＴ受信ポート　
TXD3 ( SIO3 )
Pmod JA　
　B18　
　ペリフェラル２操作ＵＡＲＴ送信ポート　
LED1
ARTY LED4　
　J5　
　ＢＬＥテストで１巡で点滅　
LED
ARTY LED5　
　H5　
１００ＭＨｚカウンタ　Ｄ２４で点滅　



BVMCN5103-CFAC が新しく入手できたので、これでＳＤＫ　v10.0 を試す

ここまでは、ＳＤＫ　ｖ６．０．０という古いものでしたが、nRF51822 の、ＲＡＭが３２ｋＢになった、ＣＦＡＣというデバイスで、簡単に、ＵＡＲＴ相互通信ができることを確認できたので、それの解説をします。解説と言っても、ＳＤＫのサンプルをすこし改造するだけで、ＵＡＲＴ相互通信を行えるので、その備忘録です。

ここでは、以下の動作確認をしたものの説明します。
  1. ペリフェラル側で、アドバタイジング時や、接続中の、出力電波の強さを可変にする。
  2. ペリフェラル側で、アドバタイジング時の、デバイスアドレス（通称ＭＡＣアドレスと呼ばれる）を任意に設定する。
  3. セントラル側にタイマーを実装し、時間で処理を管理できるようにする。
  4. セントラル側で、アドバタイジングしているペリフェラルのＭＡＣアドレス、電波強度、デバイス名などをＵＡＲＴで出力する。
  5. セントラル側で、特定のペリフェラルを指定して接続し、ＵＡＲＴの相互通信をする。
  6. ・・・・

最初にＵＡＲＴの相互通信を、スマートフォンとできるようにする。

サンプルソースは、ＳＤＫ　ｖ１０．０　をインストールしたフォルダを、nRF51_SDK_10.0.0_dc26b5e　とすると、
nRF51_SDK_10.0.0_dc26b5e\examples\ble_central\ble_app_uart_c　フォルダが、セントラル、
nRF51_SDK_10.0.0_dc26b5e\examples\ble_peripheral\ble_app_uart　フォルダが、ペリフェラルです。このフォルダの main.c をまず変更します。

　修正するのは、ＵＡＲＴのポートと、ＬＥＤのポート設定です。ボーレートは、デフォルトの３８４００のままとします。また、ＢＶＭＣＮ５１０３では、ＲＴＣ（３２７６８Ｈｚの水晶）が実装されていないので、その変更も必要です。
　ＵＡＲＴポートは、main.c で直接設定変更可能ですが、ＬＥＤのポートに関しては、define で設定されたポートの設定値が main.c にはないので 、ポートの数値を直接使う関数を使います。

　ＬＥＤのポートは、各種ノルディックの評価ボードに対応するため、どのボードかを設定すれば、ＬＥＤポートの番号が特定できるような設定ファイル（xxx.h )に基づいて設定されるようになっていて、main.c を見る限り、そのポートが物理的に何番なのか、判りづらくなっています。無論、この方法は、同じmain.c のソースを使っても、ボードの種別に左右されることなく、ＬＥＤの点灯、消灯を行えるので、評価ボードのメーカーにとっては手間が省けるのですが、いざ、カスタム設計のボードでＬＥＤを操作するには、手間のかかるソースの体系です。

　評価ボードでテストするにはいいですが、カスタムなボードでは、ＬＥＤを点灯するポートがどこなのか、ソースを見てすぐに判るようになっている方が、ボードの回路を含めたデバッグの手間がかかりません。そこで、main.c から直接ポート指定できるように変更します。
　また、ble_app_uart フォルダ以下を、別のＰＣへコピーする場合、変更した部分は、すべて　ble_app_uart フォルダ以下に含まれていないと、コピー先のＰＣでコンパイルしたとき、同じ　hex ファイルが作成されなくなるので、このような変更方法とします。

ＵＡＲＴポートの変更は、main.c の、
static void uart_init(void)　関数内を、 以下のように変更します。

　ＬＥＤポートを設定、点灯、消灯の関数は以下です。これらは、ＳＤＫの中で宣言され、使えるものです。ＬＥＤは、p0.19 ポートから抵抗を通してアノードに接続、ＬＥＤのカソードはＧＮＤへ接続するとして、
nrf_gpio_cfg_output(19);　ポートを出力に設定。
nrf_gpio_pin_clear(19);　ポートをＬｏｗで消灯。
nrf_gpio_pin_set(19);　ポートをＨｉｇｈで点灯。
上記のポート設定は、以下の回路図では、「接続」のＬＥＤが点灯となります。


そして、ＲＴＣが実装されていないので、main.c の、
static void ble_stack_init(void)　という関数内で、
SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, NULL);　をコメントアウトし、代わりに
SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION , false);　に置き換えます。

以上で、オリジナルの、ble_app_uart.c の main.c の変更で、上図の回路で、スマートフォンと、ＰＣのＵＡＲＴ間でＵＡＲＴ相互通信ができるようになります。

さて、ソースを変更しても、サンプルソフトのプロジェクトファイル（ ble_app_uart_s110_pca10028.uvproj ）を開いただけでは、コンパイルエラーが出てしまいます。

ＫＥＩＬで、プロジェクトファイル、ble_app_uart_s110_pca10028.uvproj　を開き、Project --> Options for Target 'nRF51422_xxac_s110' を選択して、
C/C++ タブを開くと、


Include Paths 欄の右のボタンを押し、図のように、..\..\..\..\..\..\components\toolchain への Path を追加し、


さらに　..\..\..\..\..\..\components\toolchain\gcc への Path を追加する。


　パスの設定を追加したあと、メモリマップの確認をしておきます。Options for Target 'nRF51422_xxac_s110' ウィンドウの、Target タブを選択すると、以下のようなメモリのアドレス設定の表などが出てきますが、
IROM1: Start 0x18000 Size 0x28000
IRAM1: Start 0x20002000 Size 0x6000
を確認します。


コンパイルして実行形式　nrf51422_xxac_s110.hex　を生成する
　実行形式は（ nrf51422_xxac_s110.hex ）、以下のフォルダに作成されます。 nRF51_SDK_10.0.0_dc26b5e\examples\ble_peripheral\ble_app_uart\pca10028\s110\arm4\_build\nrf51422_xxac_s110.hex
　ここで、ファイル名が、nRF51422 となっています。最近のノルディックの評価基板には、nRF51822 が実装されたものが見当たらないですが、nRF51822 でも実行できます。nRF51422 と nRF51822 の違いは、ＡＮＴというプロトコルを実行できる機能を入れるか否かです。nRF51822 にはその機能が実装されていないだけで、他の機能は同じです。以下は、ノルディックの、NORDIC DEVELOPER ZONE にある、Ｑ＆Ａに説明があります。
What is the difference between nRF51822 and nRF51422?
　だから、サンプルソフトは、nRF51422 用に作成されていても、ＡＮＴプロトコルを使わないサンプルであれば、nRF51822 でも実行可能みたいです。

　コンパイルして、実行形式を作成したプロジェクトファイル一式
　解凍して、ble_app_uart　フォルダ以下を、nRF51_SDK_10.0.0_dc26b5e\examples\ble_peripheral\ フォルダの、ble_app_uart　に上書きすると使えるようになります。この例では、上記回路図　で、スマートフォンと接続できると、ＬＥＤが点灯します。

注意：ここで、BVMCN5103 にはあらかじめソフトデバイスが書かれていますが、バージョンが一致していても、一度全部消して、nRF51_SDK_10.0.0_dc26b5e\components\softdevice\s110\hex\s110_nrf51_8.0.0_softdevice.hex を書いたほうが無難です。

通信の電波強度を変更する

　無線の電波強度を下げると消費電力を下げられますが、ソフトデバイスには、そのためのシステムコールが用意されていて、アドバタイジング中や、ペアリング確立の後でも、いつでも変更できるようです。システムコールの名称は、sd_ble_gap_tx_power_set(n) です。n に数値を設定しますが、ble_advertising_start　関数ではデフォルトの０になります。変更するには、アドバタイジングを開始した後、sd_ble_gap_tx_power_set(n)で変更します。n は、
-40, -30, -20, -16, -12, -8, -4, 0, 4 のみです。これ以外の数値は設定できません。マイナスが大きい方が、電波が弱くなります。

アドバタイジング時のＭＡＣアドレスを変更する

　ＢＬＥのＭＡＣアドレスは、イーサネットのＭＡＣアドレスとは異なり、メーカーに割り振られている３バイトの値を使っていないものもあります。ノルディックがその例で、ノルディックで重複しないような値を、チップに書き込んでいて、アドバタイジング時にその値を使うようになっています。http://standards.ieee.org/regauth/oui/oui.txt（このサイトはダウンロード時間がかかる） でＭＡＣアドレスを調べてみると、ノルディックには割付が無いみたいです。ちなみに、ＢＬＥモジュールのメーカーである、Silicon Laboratories の、Blue Gecko BGM113 Bluetooth Smart Module 　のＢＬＥのＭＡＣには、Silicon Laboratories に割り当てられた、0x00, 0x0B, 0x57 で始まるＭＡＣの値で、アドバタイジングをしています。

　アドバタイジング時のＭＡＣアドレスを変更するソフトデバイスのシステムコールは、sd_ble_gap_address_set(0,&caddr);　で、caddr　は、ble_gap_addr_t　で定義される構造体です。第一引数の０は、BLE_GAP_ADDR_CYCLE_MODE_NONE　で　ここに解説があります。 この　sd_ble_gap_address_set　を、ble_advertising_start　を実行する前に呼び出します。

　ここで、ble_gap_addr_t addr 構造体ですが、以下のように初期化すると、ＭＡＣが、0x00, 0x11, 0x22, 0x33, 0x44, 0x55 になります。

　ところで、チップに書かれている工場出荷時のＭＡＣの値ですが、

で、caddr 構造体に読むことができます。


セントラルのサンプルを改造してＵＡＲＴで相互通信できるようにする

nRF51_SDK_10.0.0_dc26b5e\examples\ble_central\ble_app_uart_c　フォルダが、セントラルのサンプルになっているので、これを改造します。

　改造箇所は、ＵＡＲＴのポートと、３２７６８の水晶が無いので、その設定です。main.c には、APP_LOG というマクロで、デバッグ情報を出すようになっていますが、APP_LOG は、app_trace_log　に置き換えられており、これを有効にするには、KEIL のＩＤＥの、Options for Target 'nRF51422_xxac_s120' のダイアログで、Define 欄に、ENABLE_DEBUG_LOG_SUPPORT　を追加する必要があります。これを行わずに、
#define APP_LOG app_trace_log　を、
#define APP_LOG printf に書き換えます。
　こうすると、デバッグ情報がＵＡＲＴに出力されます。ただ、このままでは、いつも出力されてしまうので、コントロール 'L' で、有効、無効を切り替える機能を入れるため、endgbout 変数を用意して、ＵＡＲＴからの、コントロール　'L ' で、endbgout を操作します。そして、APP_LOG を使ってる行に、if(endbgout) を追加します。

static void uart_init(void)　関数内を、 ペリフェラルと同じように、以下のように変更します。


そして、ＲＴＣが実装されていないので、main.c の、
static void ble_stack_init(void)　という関数内で、
SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, NULL);　をコメントアウトし、代わりに
SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_250MS_CALIBRATION , false);　に置き換えます。

　改造した、プロジェクトファイル一式 ble_app_uart_c.lzh
解凍して、トップフォルダ　ble_app_uart_c を、nRF51_SDK_10.0.0_dc26b5e\examples\ble_central\　に置くとコンパイルできます。

ペリフェラルの電源を入れ、セントラルにＵＡＲＴを接続してターミナルで表示したもの。
Conecting to target ed24482927ea のメッセージは、ペリフェラルのＭＡＣアドレスを報告しています。
The device has the device RX characteristic は、ＵＡＲＴサービスの、受信キャラクタリスティックを確認したメッセージ、
The device has the device TX characteristic は、ＵＡＲＴサービスの、送信キャラクタリスティックを確認したメッセージ　で、以後、ＵＡＲＴで送受信できます。

　ペリフェラル、セントラル共に、接続できると、ＵＡＲＴから２０文字、または、文字列＋ＬＦコードで、無線送信を開始します。サンプルソフトでの無線送信開始が、このようになっているからであり、いわゆる、インタラクティブなＵＡＲＴのように、「１文字でもＵＡＲＴで受信すると送信する」という仕様ではありません。

セントラル側にタイマーを実装し、時間で処理を管理できるようにする

　タイマー機能を入れるには、app_simple_timer.c 内の関数を呼び出すのですが、所在は、nRF51_SDK_10.0.0_dc26b5e\components\libraries\simple_timer　フォルダにあるので、KEIL のＩＤＥで、そのパスの設定を行います。２箇所設定します。




　また、 Project 表示ウインドウで、以下のように、app_simple_timer.c と、nrf_drv_timer.c のソースファイルを追加します。
さらに、ＩＤＥの　main.c は、図のソース表示のように、simple_timer_init(), NRF_TIMER1->PRESCALER = 6, app_simple_timer_start(APP_SIMPLE_TIMER_MODE_REPEATED,timer_handler,50000,NULL) をソースに追加します。ここで、timer_handler は、タイマー割込みで実行される関数で、これも追加します。この関数の中で、定期的な割り込みで、目的の処理を記述します。


　timer_handler() では、以下のように、例として、ＬＥＤを点滅させて、タイマーが動作していることを確認します。


上記のタイマー追加で、図の　P0_05 に接続したテスト用のＬＥＤが点滅します。



ペリフェラルのＭＡＣアドレス、電波強度、デバイス名などをＵＡＲＴで出力する。
　ＭＡＣとデバイス名、そしてＲＳＳＩを報告する、プロジェクトファイル一式 ble_app_uart_c_ckADV.lzh
　ノルディックのスマートフォンのＢＬＥアプリ、ノルディックのスマートフォンのＢＬＥアプリのＵＡＲＴをタップして、connect を押すと、アドバタイジングしているペリフェラルの　デバイス名とＭＡＣがリストアップされ、電波強度は、アイコンで表示されます。

　この機能を、セントラル側に実装し、ＵＡＲＴで報告できるようにします。
　アドバタイジングで送られてくる情報には多くのものがあり、それらは、
nRF51_SDK_10.0.0_dc26b5e\components\softdevice\s120\headers\ble_gap.h
　で定義されています。この、ble_gap.h の、１７１行目から抜き出したのが以下です。


　ここで、デバイス名は、Complete local device name　と説明されている、0x09, なので、これをアドバタイジングで受信したデータからさがします。
　static void on_ble_evt(ble_evt_t * p_ble_evt)　関数でソフトデバイスからイベントとして呼び出されますが、アドバタイジングのデータは、p_ble_evt というポインタで渡されているので、このポインタから参照します。このポインタから、ble_gap_evt_t で定義される構造体へのポインタ、gap_evt を ble_gap_evt_t *p_gap_evt の、p_gap_evt にコピーしておきます。

　p_ble_evt　には、どういうデータかを示すＩＤが、p_ble_evt->header.evt_id　にあるので、これを調べて　BLE_GAP_EVT_ADV_REPORT　なのかを判定し、一致すると、ＭＡＣとか、デバイス名とか、サービスのＵＵＩＤとかを読み出せます。ここのところが、on_ble_evt　関数で、switch() されていて、case BLE_GAP_EVT_ADV_REPORT: の場合に、読み出します。読み出すとき、先にコピーしたポインタ、p_gap_evt　を使って辿っていきます。

　サンプルソフトでは、デバイス名とか、ＲＳＳＩを読み出すようにはなっておらず、これらを追加します。
　以下が、以上の機能を入れて、ＭＡＣ、デバイス名、ＵＵＩＤをＵＡＲＴで報告する、static void on_ble_evt(ble_evt_t * p_ble_evt)　関数の最初の部分です。

　以上の機能を入れて、ターミナルで、接続までの状態を、表示したものが以下です。

　上の記録で、ADVDATA =02 01 05 0C 09 4E 6F 72 64 69 63 5F 55 41 52 54　ですが、アドバタイジングで送られてきた、データです。
　データの意味は、02 は、続く２バイトのデータ区切りを示し、01 は、BLE_GAP_AD_TYPE_FLAGS　で、内容は 05　。意味は判りません。その次の、0C が、１２バイトのデータで、09 が、BLE_GAP_AD_TYPE_COMPLETE_LOCAL_NAME　で、デバイス名のデータという意味。これに続いて、デバイス名が、4E 6F 72 64 69 ・・・と続き、"Nordic_UART" です。このデータはこれで全部ですが、別のパケットで、ADVDATA =11 07 9E CA DC ・・・・と送られており、このデータは、Complete list of 128 bit service UUIDs. 　であることが、11 の次の 07　で判ります。このデータは１６バイトあり、ノルディックの、ＵＡＲＴサービスのユニークなＵＵＩＤです。セントラル側では、このＵＵＩＤをチェックして、相手が、ノルディックのＵＡＲＴサービスのＵＵＩＤなら、接続手続きに移行します。
　次の行の、Connecting to target ed24482927ea は、相手のＭＡＣを示して、接続シーケンスに移ることを報告したものです。

　さてここで、ＭＡＣ　アドレスはどう読み出すかですが、ＭＡＣは、アドバタイジングを受信したデータには、常に含まれていて、別の場所にあります。p_gap_evt->params.adv_report->data が、ＵＵＩＤや、デバイス名で、ＭＡＣは、p_gap_evt->params.adv_report.peer_addr.addr に記録されています。

　デバイス名が送られてくるアドバタイジングパケットにも、ＵＵＩＤが送られてくるアドバタイジングパケットにも、常に、ＭＡＣ情報がバンドルされています。ＲＳＳＩも同じく、どのアドバタイジングパケットにもバンドルされています。ＲＳＳＩは、p_gap_evt->params.adv_report.rssi の１バイトの情報です。

　p_gap_evt->params.adv_report.data　が、アドバタイジングデータですが、構造は以下のようになっています。
アドバタイジングデータの構造　２個の場合
バイト数 （データ種別１バイト＋データのバイト数）
　データ種別　
　データ　
バイト数 （データ種別１バイト＋データのバイト数）
　データ種別　
　データ　
02
　01　
　05　
　0C
　09　
　0C 09 4E 6F 72 64 69 63 5F 55 41 52 54 (Nordic_UART 11 バイト)

　ＭＡＣとデバイス名、そしてＲＳＳＩを報告する、プロジェクトファイル一式 ble_app_uart_c_ckADV.lzh

解凍して、トップフォルダ　ble_app_uart_c_ckADV を、nRF51_SDK_10.0.0_dc26b5e\examples\ble_central\　に置くと変更、再コンパイルできます。


セントラル側で、特定のペリフェラルを指定して接続し、ＵＡＲＴの相互通信をする。

　この機能を実現するには、ペリフェラルの、デバイス名か、ＭＡＣアドレスを指定するとできますが、そのデータをどこに置くかという違いでセントラルのＵＡＲＴの扱い方が異なってきます。nRF51822 のチップにＲＯＭとして書くと、常に通信相手は固定され、変更するには、ＲＯＭを書き換えないといけませんが、ＵＡＲＴの操作はそのままです。
　もう一つの方法は、nRF51822 の外部、つまり、セントラルとＵＡＲＴで接続するホストに設定しておき、ＵＡＲＴで通知するという方法です。

　まず、ペリフェラルのデバイス名とか、ＭＡＣをＲＯＭに書いておいて、特定の相手だにけ接続できるかを確認します。
　アドバタイジングのデータで得られたデバイス名などが、所定のものならば、接続に移行するのは、比較的簡単に行えます。
　on_ble_evt　関数の、case BLE_GAP_EVT_ADV_REPORT: のところで　ＵＵＩＤの判定をしているところがありますが、
if (is_uuid_present(&m_nus_uuid, p_adv_report))
　この判定条件に、デバイス名などの一致を条件として追加すればいいわけです。

　デバイス名が一致したか、否か　を区別するため、ペリフェラル側で、デバイス名を一部変更できる機能を先に実装します。デフォルトでは、"Nordic_UART" になっているので、中央付近の、'_' のところを、電源ＯＮ後に変更できるようにしてみます。変更する操作が済むまで、アドバタイジングに移行しないようにフラグで操作します。
　以上のような機能を入れた、ペリフェラルのプロジェクトファイル一式です。ble_app_uart3.lzh
　ble_app_uart3.lzh　では、電源ＯＮで、接続したときに点灯するようにしていたＬＥＤを点滅させ、ＵＡＲＴから何か１文字受信すると、ＬＥＤが消え、アドバタイジングを開始します。１文字として、' ' スペースなら、"Nordic_UART" とデフォルトのデバイス名、スペース以外なら、その文字、たとえば、'1' なら、"Nordic1UART" というデバイス名になります。

　セントラル側で、ペリフェラルのデバイス名として、"Nordic_UART" なら、接続を開始するように改造したものが以下です。
　ペリフェラルのデバイス名が"Nordic_UART"のみと接続できる。ble_app_uart_c_ckADV_dev.lzh







準備中


ホームに戻る

inserted by FC2 system