2019/08/31

[nordic][zephyr]Advertisingするチャネルを制御したいが、わからんかった

わからんかったシリーズだ。

 

ZephyrでBLEの簡単なことはできるようになったのだが、どんな感じで無線が飛んでいるのか見てみたいときもあるだろう。

そういうときはパケットスニファが便利だ。
私はTIのスニファを使っているのだが、接続後の無線を見たい場合は、チャネルを選んでAdvertisingから接続を待ち受けている。
そして、別のチャネルで接続開始された場合は切断して、またやり直す。

と、非常に効率が悪い。
もっといいやり方もあるのかもしれんのだが、使いこなせていない。

 

それで、私はAdvertisingするチャネルを制限させる、という方法を使っていた。

hiro99ma blog: [nrf51]特定CHへのAdvertisingを止める(デバッグ)
https://hiro99ma.blogspot.com/2015/11/nrf51chadvertising.html

ZephyrとはいえNordicの部分はNordicがサポートしているようなので、同じような手法が使えるんではなかろうか。


上記の記事は、S110 SoftDevice v8.0.0のときだった。
もう4年も前のことで、手元にあったS132(SDK15)を見てみると、ch_37_off、みたいなメンバがいなくなっていた。

今は配列になっているようだ。

typedef uint8_t ble_gap_ch_mask_t[5];

8bit * 5 = 40ということで、1bitが1chを指しているようである。
[0]のbit0がch0と同じなのかな?

 

 

zephyrのv2.0.0-rc1をchannel_maskでgrepすると、残念ながらたくさん出てきた。
さらに残念なことに、たぶん全部PPI関係のようだ。

あきらめて「37」で検索すると、これはこれでたくさん出てくる。。。
が、ようやくそれっぽいものを見つけた。

modules/lib/openthread/third_party/NordicSemiconductor/softdevice/s140/headers/ble_gap.h

なんだ、nRF SDKと同じファイル名ではないか。。。
そしてchannel_maskだったので、単にさっき見逃しただけのようである。


しかし・・・もともとnRF SDKでもchannel_maskはユーザアプリから触れる変数ではなかった。
ble_advertising_start()ならアクセスできるので、そこを書き換えていたのだ。

そして、もっと根本的な問題として、このファイルは使われているのだろうか?というものがある。
openthreadとなっているけど、zephyrのGitHubではなく、west updateで取得したものなのだ。

channel_maskを持っているble_gap_adv_params_tでgrepしたが、そのヘッダファイルしか出てこなかった。
残念だ。。。

 

ならば、advertisingの開始辺りを見てみればよいかと思ったが、よくわからん。
nRF SDKだとGAPだったのだが、subsys/bluetooth/host/hci_core.cあたりにあるようだ。
たぶんset_advertise_enable()だと思っている。あるいは手前のbt_le_adv_start_internal()か。

 

だが、ソースをぱっと見ても追えそうな気がしなかった。
残念だが、今回はあきらめよう。

[win10]WSLをexplorer.exeでアクセスできるのは1903からか?

ZephyrのビルドなどはWSLでも大丈夫だし、そのまま焼くこともできる、と安心していた。

しかし・・・別の環境でやってみると、そうはいかなかった。
explorer.exeで\\wsl$が開かないのだ。

名前がUNCで隠しフォルダなんかにアクセスする時みたいな名前なので「そんな機能知らなかった~」くらいに思っていたのだが、実は新機能だったのか。。。

 

ちなみに、explorerを使うとこう見える。

image

ユーザ名がhirokumaだから、それが/homeの下に見えている。
ネットワーク経由でアクセスするから、WSLとかそういうのは関係ないんだなー、賢いなー、とちょっと感激した私であった。

2019/08/25

nrfjprog.exeをWSLから実行できそうだ

いま、zephyrでビルドしたHEXファイルをnRF51822に焼くとき、west flashを使っている。
jlink用に設定しているので、nrfjprog.exeが呼ばれているのだと思う。

Windowsでzephyrをやっているのは、ほぼこのwest flashのためだ。
試していないが、WSLだとUSBが使えなかったと思うので、nRF Command Line ToolsのLinux版をインストールしても動かんだろう。
nrfjprogだけWindowsでやればいいんだろうけど、それは敗北だろう。

幸い、westをたたくくらいしかやることはないので、WindowsだろうとWSLだろうとそんなに問題は無く、毎回lsなどと打ってしまってエラーになるのがしゃくに障るだけだ。

 

そこで思いついたのが、WSLからWindowsのnrfjprog.exeをたたく、という方法だ。
これだとコマンドはWindows側で実行されるだろうから、USBも動くはずだ。

nrfjprog.exeのシンボリックリンクを作ってnrfjprogという名前を付けたのだけど、うまくいかなかった。
代わりにbashのシェルスクリプトの中でnrfjprog.exeを実行するようにして、ファイル名をnrfjprogにするとよさそうだった。

 

最初は、HEXファイルが見つからないと怒られた。
Windows風のパスじゃないとダメなのかとwslpathでやってみたが、それでもダメ。
試していて分かったが、実際にファイルのある場所がWindows側だったためか、そのディレクトリにシンボリックリンクした先のファイルを指定したからかわからないが、ともかくそんな理由で見つからなかったようだ。

作業ディレクトリをWSL側にしたところ、wsl flashがそのまま動いた。


Windows側のフォルダに置いておくと、他の開発作業と同じ管理ができるから楽だったのだが、WSL側にあったとしても最近はUNCの\\WSL$でアクセスできるようになっていたので、クイックアクセスか何かでピン留めしておけばよかろう。

2019/08/24

[zephyr][ble]serviceを作る (3)

LEDサービスを作った。

https://github.com/hirokuma/zephyr_ble_led/tree/135c5c0c40e53450e402f4b42bccc39a6ef8d63c

characteristicは1つで、0以外を書き込むとLEDオン、0だったらLEDオフ。
これだけだ。

 

main.cはsamplesのperipheral_hrなどとほとんど同じだろう。
接続したときにLEDサービスのinitを呼び出している。あと、notifyがなくなった。

 

LEDサービスのinitでGPIOの初期化をしている。
これは今ひとつだな。接続し直すたびに呼び出されてしまう。

write_ct()でWRITE時の処理をさせている。
関数名はそのまま使ったのだけど、この_ctはたぶんCurrent Timeの略だな。。。
readがないので値は保存しなくても良いのだけど、一応やっておいた。

 

サービスの登録だが、特に関数を呼び出している様子が無い。
これはたぶん、BT_GATT_SERVICE_DEFINEマクロがうまいことやっているのだろう。
staticが付けられないのが残念だが、それによって簡略化できているのだろう。

 

実装はこんな感じで、難しいところがない。
SRAMもそんなに消費していない。

Memory region         Used Size  Region Size  %age Used
           FLASH:       84851 B       256 KB     32.37%
            SRAM:       15120 B        16 KB     92.29%
        IDT_LIST:         136 B         2 KB      6.64%

 

どっちかといえば、UUIDってどういう決め方だったかとか、そういう調査の方に時間がかかった。
nRFgo Studioで作ったときの習慣で、場所でいえば0000xxxx-0000-1000-8000-00805F9B34FBのxxxxだけをServiceとCharacteristicで変更しているのだけど、それぞれ新規でUUIDを生成した方がいいんだろうか?

まあ、要調査だな。

[zephyr][ble]serviceを作る (2)

menuconfigの続き。

 

menuconfigでSaveすると、ファイルはbuildの下に.configとして保存されるようだ。
このファイルは、—prestineすると消えてしまうようである。

なので、これをprj.confとして保存してしまえばいいや、と思ったが、CONFIGがずらずら並んでいると気が滅入る。
どうやって減らそうかと思ったら、advancedということでminimal configをSaveするメニューがあった。

# Generated by Kconfiglib (https://github.com/ulfalizer/Kconfiglib)
CONFIG_GPIO=y
CONFIG_SOC_SERIES_NRF51X=y
CONFIG_ARM=y
CONFIG_SERIAL=y
CONFIG_UART_0_NRF_UART=y
CONFIG_ENTROPY_NRF5_THR_THRESHOLD=4
CONFIG_ENTROPY_NRF5_ISR_THRESHOLD=12
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y
CONFIG_BT=y

今の設定で出力させたのだが、THRESHOLDの設定を変更したかどうか記憶にない。。まあいいや。

 

samples/bluetooth/peripheral_hrと比べて、いくつか追加した。

# Generated by Kconfiglib (https://github.com/ulfalizer/Kconfiglib)
CONFIG_GPIO=y
CONFIG_SOC_SERIES_NRF51X=y
CONFIG_ARM=y
CONFIG_SERIAL=y
CONFIG_UART_0_NRF_UART=y
CONFIG_ENTROPY_NRF5_THR_THRESHOLD=4
CONFIG_ENTROPY_NRF5_ISR_THRESHOLD=12
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_GATT_DIS=y
CONFIG_BT_GATT_DIS_MODEL="LED control"
CONFIG_BT_GATT_DIS_MANUF="hiro99ma"
CONFIG_BT_SMP=y
CONFIG_BT_DEVICE_NAME="BLE Test"

標準の項目については大半がCONFIGの設定だけで済ませられそうだ。
こりゃ、便利だわ。

Memory region         Used Size  Region Size  %age Used
           FLASH:       76267 B       256 KB     29.09%
            SRAM:       12988 B        16 KB     79.27%
        IDT_LIST:         136 B         2 KB      6.64%

まだまだ大丈夫だ。


Device Information Serviceを組み込んだので、これだけでも何か動いていいはずだ。
samples/bluetooth/peripheral_hrからBASとHRSを削除すればいいだろう。

 

main.cを見て気付いたが、BASとHRSっぽいのって、ほぼnotify()だけではないか。。。
こんなにコードが少なくて済むのか。
まあ、自分でserviceを作ってないからだとはいえ、助かるな。

 

Advertisingする設定が気になる。
peripheral_hrではこんな設定になっていた。

static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	BT_DATA_BYTES(BT_DATA_UUID16_ALL, 0x0d, 0x18, 0x0f, 0x18, 0x05, 0x18),
};

UUIDはいつも128bitだったような気がするが、ここは16bitなのか。
じゃあ、16bitの設定はどこで? 128bitはどうやって??

 

やはりコードだけじゃ無理だな。

https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-dev.html#initialization

説明はないが、ここではadが2byte分しかないのでわかりやすい。
0xaa, 0xfeはGoogleだろう。

https://www.bluetooth.com/ja-jp/specifications/assigned-numbers/16-bit-uuids-for-members/

image

BT_DATA_UUID16_ALLは、ALLとついているから列挙しているのだろう。
serviceなんかで、こういう値があった気がするのだが。。。

https://www.bluetooth.com/ja-jp/specifications/gatt/services/

そういえば、GenericだかGeneralだかがあったな。Device Information Serviceもそうだし。

 

Core仕様書が出てきた。
ここではv4.2を見ている。たぶんv5.1でも同じ章番号だろう。

Vol 3 – Part B – 2.5.1 UUID

https://www.bluetooth.com/specifications/assigned-numbers/service-discovery/

Serviceはここから探せそうだ。

https://www.bluetooth.com/specifications/gatt/services/

0x18があるのでGenericなServiceの番号かと思ったのだけど、なんか違う気がする。
Current Time Serviceは使って無さそうだから。
あまり深く考えず、AdvertisingだからAdvertisingのところを調べるべきだろう。


Advertisingは、GAP(Generic Access Profile)だ。
GAPは、Vol.3 – Part Cだ。

https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/

BT_DATA_UUID16_ALLは0x03なので、«Complete List of 16-bit Service Class UUIDs»を表しているのだろう。
0x09の«Complete Local Name»はBT_DATA_NAME_COMPLETEだから、COMPLETEを使ってくれれば悩まなかったのに。。。

ともかく、Service Classの16bit UUIDを列挙しているということだろう。
あれ、じゃあさっきの考えは間違ってなかったのか?

0x180d = Heart Rate
0x180f = Battery
0x1805 = Current Time

普通はこういう情報に現在時刻が必要よね?ということで付けたのだろうか。
じゃあ、最初に「Googleだろう」って書いたのは間違っているのかな。

 

まあいい。
今回は、Device Information Serviceだけだから、0x180Aでよかろう。
ビルドして焼いてみる。

image

image

むう、あっさり動いた。


さて、ここで出てきたUUIDのF1:76:C0:98:07:47はなんだろう?
MACなんだろうけど、どうやって指定するんだっけ。

6 byte mac address oft nrf52832 - Nordic DevZone
https://devzone.nordicsemi.com/f/nordic-q-a/31062/6-byte-mac-address-oft-nrf52832

ああ、FICRか。
nRF52832のデータだけど、こんな感じでDEVICEADDR[]が入っているようだ。

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fficr.html

nRF51822だと少し違うのかな?

nRF51822 - ID - Nordic DevZone
https://devzone.nordicsemi.com/f/nordic-q-a/6452/nrf51822---id

たぶん書き換えられないんだろう。

2019/08/20

[zephyr][ble]serviceを作る (1)

nRF51822(FLASH: 256kB, SRAM: 16kB)に、Zephyr OSを載せて、BLEのPeripheral serviceを作って動かしたい。

もちろん、characteristicなんかも作るが、とにかくZephyrでBLEを動かしたいのだ。


師匠(?)の記事を読もう。

Zephyr RTOS Programming - Qiita
https://qiita.com/deden/items/c7e6fddf7dffb3af5f06#mpu6050

最初は、LEDをON/OFFするだけのserviceでよいだろう。
service類の作り方が分かれば、あとはデバイスを動かすだけになるはず。

 

ソースコードの前に、prj.confだ。

https://github.com/github-deden/zephyr_ble_mpu6050/blob/a97351f3165452286fb4b4a265eb879906db57ae/peripheral_mpu6050/prj.conf

CONFIGの種類が分からないと、削れるかどうかも分からんな。

Configuration Options — Zephyr Project Documentation
https://docs.zephyrproject.org/latest/reference/kconfig/index.html

やめてー! おおすぎー!

 

・・・まずは、新規プロジェクトを作るところからやろう。


適当なところに作業ディレクトリを作り、CMakeLists.txtとかmain.cとかを置いていけば良いらしい。

https://docs.zephyrproject.org/latest/application/index.html#overview

RustだとHello Worldを自動的に作ってくれるが、そこまではやってくれないらしい。
なので、ここはsamplesのhello_worldをコピーする。
ビルドも確認。

Memory region         Used Size  Region Size  %age Used
            FLASH:       10756 B       256 KB      4.10%
             SRAM:        2356 B        16 KB     14.38%
         IDT_LIST:          56 B         2 KB      2.73%

むう、これだけで15%消費するのか。。。まあ、ほぼOSのみと思っておこう。


では、あきらめてCONFIGを見ようかと思ったが、そういえばLinux Kernelならmenuconfigがあった。
似たようなものがあるんじゃなかろうか?

Zephyr News, 14 May 2018 | Foundries.io
https://foundries.io/insights/2018/05/14/zephyr-news-20180514/

pip3でscripts/requirements.txtをインストールすると使えるのか?

やってみたのだが、hub==2.0がないとかでエラーになってしまった。。。
masterにはhubがなかったので、v2.0.0-rc1で入っていただけなのか。
その行を削除するとインストールは正常に終わった。

 

だが、menuconfig的なものが無い。
”python menuconfig”で探すと、kconfiglibというものがでてきた。

https://pypi.org/project/kconfiglib/

Zephyrという文字も出てきているので、これを使っているのだろう。
が、これはライブラリであって、ツールではないよな。。

https://docs.zephyrproject.org/latest/application/index.html?highlight=menuconfig#overriding-the-default-configuration

ああ・・・westなのか。

west build –t menuconfig

で出てきた。

image

あとは、ここからじわじわ眺めていくか。

とりあえずBluetoothだけ有効にしてビルドした。

Memory region         Used Size  Region Size  %age Used
           FLASH:       33632 B       256 KB     12.83%
            SRAM:        9496 B        16 KB     57.96%
        IDT_LIST:         136 B         2 KB      6.64%

ははは、もう半分以上使われてしまった。
でも、まだ余裕があるな。
リンクも何もしていないので、これからということか。

2019/08/19

[vscode]Cortex-M disassembly

昨日、nRF51822をvscodeのCortex Debugでデバッグし、ブレークポイント位置がソースコードと微妙に違うという話になった。

inlineとかあるから、アセンブラのコードも見えると良いのだがやり方が分からん、というところで終わった。

 

が、Cortex Debugの機能にあった。

image

たぶんデフォルトがAutoになっているので、Forceを選択。

image

出た!

出たんだが、

  • mixed表示じゃないので、読み解くのがめんどくさい。
  • Cソース側で打ったブレークポイントが見えない。Disassembly側でぶれーくポイントの設定はできるし、止まる。
  • CソースとDisassemblyを両方表示しても、Disassembly側しかステップカーソルが移動しない。

など、ちょっと微妙だ。
まあ、gcc/gdbの範囲でしか対応できないとは思うが、もうちょっと表示が豊かになるとうれしい。

 

レジスタの表示もできるのだが、16進数で表示してくれないのもちょっと困る。
あからさまにアドレスが入るようなレジスタは16進数になっているのだが、汎用レジスタは10進数のようだ。

これからに期待ですな。

2019/08/18

Zephyr (10)

夏休みが終わる・・・集中Zephyr学習もたぶん今回が最後だろう。
あとは、動かしながら試すまでだ。

 

最後に、デバッグの仕方を調べておこう。

Eclipse Debugging
https://docs.zephyrproject.org/latest/application/index.html#eclipse-debugging

えー、eclipseなのかー。
いや、eclipseが悪いわけではないのだけど、最近はvscodeをよく使っているので、これもvscodeでやりたいのだが。

 

まあ、eclipseを使えるということは、vscodeも使えるはずだ。
つまり、vscodeでCortex-M0のデバッグができればよいというだけのことだ。


こういうextensionがあった。

Cortex-Debug - Visual Studio Marketplace
https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug

インストールして、settings.jsonにJLinkのGDB ServerCLの実行パスを設定しておくとよさそうだ。
8.3形式じゃないとダメな気がするので、短くしておこう。というか、スペースがない名前にしたいだけなんだけどね。

"cortex-debug.JLinkGDBServerPath": "c:\\PROGRA~2\\SEGGER\\JLINK\\JLINKG~2.EXE"

launch.jsonはこうした。

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Cortex Debug",
            "cwd": "${workspaceRoot}",
            "executable": "./build/zephyr/zephyr.elf",
            "request": "launch",
            "type": "cortex-debug",
            "servertype": "jlink",
            "device": "nrf51",
            "interface": "swd",
            "ipAddress": null,
            "serialNumber": null,
            "armToolchainPath": "c:\\Winappli\\gcc-arm-none-eabi-8-2019-q3-update-win32\\bin"
        }
    ]
}

 

これで、blinkyを動かしたのだが、一応デバッグできているようだ。
「一応」がつくのは、ブレークポイントの位置に止まってくれないからだ。

image

ずれているわけではなく、gpio_pin_write()には止まってくれないようだ。
最適化の関係か?

だったらアセンブラコードとあわせて見るとわかるのだけど、出し方が分からん。
残念だが、今回はこれで終わろう。

Zephyr (9)

Zephyrで、自分用のボード設定を作ろう!

私が使っているのはnRF51822のrevision 2。CEAAなので、FLASHが256kB、SRAMが16kBだ。
GPIOは開放されているので、こっちで好きに使ってよい。

HR serviceを使ったサンプルですらSRAMの使用量は93%近くあるので、余裕を持って作りたいなら32kB以上はSRAMがほしいところだ。


新しいボードをサポートしたい場合はテンプレートを使ってくれ、と書いてある。が、これはドキュメントのテンプレートであってボード設定のテンプレートではない。

https://docs.zephyrproject.org/latest/boards/index.html

今回は、BLE Nanoに近い構成で、J-LINKだけPCA10028の設定を使いたいというだけなので、BLE Nanoをコピーして作れば良かろう。

Linuxの場合は、defconfigをコピーして.configにしてからmenuconfigでカスタマイズしていたのだが、Zephyrも似たようなツールがあるのだろうか?
・・・いかんいかん、先走っちゃいかんな。
まずはボードの設定を作ろう。

 

ファイルは6つ。

board.cmake
Kconfig.board
Kconfig.defconfig
XXX.dts
XXX.yaml
XXX_defconfig

XXXはボード名のようだ。
他にもファイルが置けるようだが、まあ今回はよかろう。

https://docs.zephyrproject.org/latest/application/index.html#boards

 

ファイルの中身を見ただけだが、だいたいこんなところだろうか。

board.cmake : west flashなどで使いそうな設定
Kconfig.board : menuconfigで使いそうな設定
Kconfig.defconfig : 自分のボードが有効なときにmenuconfigで使いそうな設定
XXX.dts : Device Tree Script、だったか。ボード/デバイスの設定。
XXX.yaml : マイコンの種別、RAMのサイズのような設定
XXX_defconfig : CONFIGのデフォルト値

 

今回のnRF51822はBVMCN5102を使っているので、XXXはnrf51_bvmcn51にしよう。
QFAAとかQFACとか設定があるのだが、dtsiを見るとFLASHとRAMのサイズで分けているだけのように見える。

51822_QFAA : FLASH=256, SRAM=16
51822_QFAB : FLASH=128, SRAM=16
51822_QFAC : FLASH=256, SRAM=32

となると、yamlファイルに書いてあるRAMサイズは人間用なのだろうか?
まあいいや。

そして、board.cmakeはPCA10028の設定を使う。
内蔵RCを使うようにもしておこう。
これくらいしか変更点が思いつかない。


peripheral_hrをビルドした。

Memory region         Used Size  Region Size  %age Used
           FLASH:      109535 B       256 KB     41.78%
            SRAM:       17712 B        16 KB    108.11%
        IDT_LIST:         152 B         2 KB      7.42%

あれー。
nrf51_blenanoを変更しただけなのに。。。
念のためボードをnrf51_blenanoにしてビルドすると、こっちもRAMオーバーした。
なんだこりゃ?
昨日はなんだったのだ??

WSL版でも同じようになったから、そうなんだろう。
CONFIG_SERIALやCONFIG_CONSOLEをnoにしていったが、さほど効果無し。
zephyrがmasterブランチだったので、v2.0.0-rc1タグにしたが、変わらん。

 

うーん、今日、west build系がなぜかうまくいかなかったのでbuild/ごと削除したのだが、それが原因だろうか。原因というか、昨日はキャッシュが効いたままになってて、なんか外れた状態になっていたのか?

 

zephr_prebuilt.mapを見てみる。大きいのはこの辺か。

bss        0x1810
noinit     0x2551
datas     0x05cb

なんか、ちょこちょこlogという名前が出てくる。
そういえば、prj.confから削った気がする。

CONFIG_BT_DEBUG_LOG=n

CONFIG_PRINTKなんかがnだったので消えるんだろうと思っていたが、prj.confに入っているからリンクされるのか。
prj.confを書き換え、buildディレクトリごと削除して、west build。

>west build -b nrf51_blenano samples\bluetooth\peripheral_hr –pristine

Memory region         Used Size  Region Size  %age Used
            FLASH:       86591 B       256 KB     33.03%
             SRAM:       15364 B        16 KB     93.77%
         IDT_LIST:         152 B         2 KB      7.42%

効くねぇ。

では、BVMCN51でビルドし直す。

Memory region         Used Size  Region Size  %age Used
           FLASH:       85667 B       256 KB     32.68%
            SRAM:       15328 B        16 KB     93.55%
        IDT_LIST:         152 B         2 KB      7.42%

微妙な差は、CONFIG_SERIALやCONFIG_CONSOLEをnoにしているからか?
BLE Nanoと同じ設定にしてビルドし直す。

Memory region         Used Size  Region Size  %age Used
            FLASH:       86591 B       256 KB     33.03%
             SRAM:       15364 B        16 KB     93.77%
         IDT_LIST:         152 B         2 KB      7.42%

同じになった。
内蔵RCを使ったとしても引数が変わるだけだから、その差は無いみたいだ。

CONFIG_COMPILER_OPT=”-O3”を設定するとこうなった。

Memory region         Used Size  Region Size  %age Used
            FLASH:      134582 B       256 KB     51.34%
             SRAM:       15380 B        16 KB     93.87%
        IDT_LIST:         152 B         2 KB      7.42%

CONFIG_SIZE_OPTIMIZATIONS=yでは変わらず。デフォルトがそうなのか。

 

consoleは使わないがUARTは使いたいので、CONFIG_SERIAL=yにしておこう。

Memory region         Used Size  Region Size  %age Used
            FLASH:       86383 B       256 KB     32.95%
             SRAM:       15348 B        16 KB     93.68%
         IDT_LIST:         152 B         2 KB      7.42%

ちなみに、LOG_BACKEND_RTTとUSE_SEGGER_RTTをyesにするとRAMがあふれてしまった。


動いてそうなので、GitHubに置いておこう。

https://github.com/hirokuma/zephyr_boards_arm_nrf51_bvmcn51/tree/89f64c97200c7477008342182a447dfbb1e8cc7c

west flashで焼けるのが便利ですな。

2019/08/17

Zephyr (8)

では、BOARDはble nanoにしたまま、prj.confで内蔵RCを使うように設定してビルドする。

Memory region         Used Size  Region Size  %age Used
            FLASH:       85823 B       256 KB     32.74%
             SRAM:       15108 B        16 KB     92.21%
         IDT_LIST:         152 B         2 KB      7.42%

ちょっと増えたが、まあよかろう。44byteだし、そのくらいは何かあるんだろう。
nrfjprogで焼くと、動いた。
あの苦労は何だったのか。。。


west flashだが、runnerを選択してjlinkを使うことができるらしい。

https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#choosing-a-runner

やってみたのだが、BLE NanoはDAPなのでサポートしてない、みたいなメッセージが出てきた。
ということは、自分用のボード設定を作ってしまえばできるんじゃなかろうか。

次回はそれだな。

Zephyr (7)

そろそろ、BLEのサンプルを動かそう。


その前に。。

NordicSemiconductorのGitHubに何かないか見ていたら、nrfxというリポジトリがあった。

Standalone drivers for peripherals present in Nordic SoCs

もしかしてSoftDeviceの部分をオープンソースにしたのか??と思ったけど、Peripheral部分だけのようだ。
nRF5 SDKから切り出したというところか。
MDKのことも書いてあるので、自分のところで出したSDKだけだと利用者が増えないので、切り出しやすいところを出して、他の環境でも使えるようにしているのだろうか。


あと、ログも。
RTTが使えるかどうかで効率はずいぶん変わってくる。

https://docs.zephyrproject.org/latest/samples/subsys/logging/logger/README.html

loggerのサンプルを動かしたが、RTT Viewerには出てくれない。
ファイルを見てみると、prj.confの他にprj_rtt.confというものもあった。

CONFIG_LOG_BACKEND_RTT=y
CONFIG_USE_SEGGER_RTT=y

差分はこの2行の追加だけ。

CMakeLists.txtに

set(CONF_FILE "prj_rtt.conf")

を追加(末尾ではダメだったので、minimumの次くらいに追加)してビルドして焼き直すと、RTT Viewerに現れた。

image

printk()はそのまま、時間が出ているところはログ関数、というところだろうか。

ログ出力するだけのサンプルかと思ったけど、スレッド使ったりして、簡単に読めるものではなかった。
main()ないし。

ともかく、RTTを有効にすればRTTに出力できることは分かった。

 

違うCONFファイルを使いたい場合は、CMakeLists.txtに書かずとも、westのオプションでよいようだ。

https://docs.zephyrproject.org/latest/application/index.html#basics


では、BLEのサンプルを動かそう。
自分で書くのは、ずいぶん後になるだろう。

Bluetooth: Peripheral HR
https://docs.zephyrproject.org/latest/samples/bluetooth/peripheral_hr/README.html

私が使っているnRF51822のボードには外部RCがないので、RTT Viewerを使いたいのもひっくるめてprj.confに追記した。

CONFIG_LOG_BACKEND_RTT=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF5_K32SRC_250PPM=y

 

>west build samples\bluetooth\peripheral_hr --pristine

うーん、CLOCK_CONTROL_NRF5_K32SRC_RCなど知らない、といわれてしまった。
Nordicのブログに書いてあったのだが、時代が変わったのだろうか。

今はNRF5ではなくNRFだけでになったようだ。

https://github.com/zephyrproject-rtos/zephyr/blob/v2.0.0-rc1/drivers/clock_control/Kconfig.nrf#L30

では、修正を。

CONFIG_LOG_BACKEND_RTT=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_250PPM=y

ビルドはできたが、焼いても動かない。
blinkyの点滅を先頭に組み込んだが、それも動いていなさそうだ。
うーん。

 

あれ。

Memory region         Used Size  Region Size  %age Used
           FLASH:      110415 B       256 KB     42.12%
             SRAM:       20144 B        32 KB     61.47%
         IDT_LIST:         152 B         2 KB      7.42%

SRAMが61.47%の使用率・・・。
私が使っているnRF51822はrevision 2なのだが、revision 2のSRAMは16kB・・・。

image

嘘・・・私のnRF51822、SRAM少なすぎ?

 

main.cを削っていったが、16kB以内にすることができなかった。
あとちょっとなのだけど、これで動いたとしてもアプリがほとんど書けないということになるので、やる気が出ない。。

 

nRF52を使おうとしたら、BLE Nanoが出てきた。
うちにあるのは古いやつなので、これもたぶん16kBだろう。
こっちはSupport Boardなので、一応試しておこう。

Memory region         Used Size  Region Size  %age Used
           FLASH:       84495 B       256 KB     32.23%
            SRAM:       15064 B        16 KB     91.94%
        IDT_LIST:         152 B         2 KB      7.42%

入るんだ・・・。
私のCONFIGの削り具合が足りてなかったということだろうか。

そして、BLE NanoはMbedっぽくなっていて、DAP対応?しているため、west flashで焼くことができる。
焼き終わると立ち上がって、Advertisingしだした。

image

nRF ToolboxでHRMを使うと、ちゃんとバッテリーとHRが見える。

 

ということは、私が使ってるnRF51822だってできるはずだ。
次はそれを試そう。

Zephyr (6)

ここまでエミュレータで動かしただけだったので、そろそろ実機で動かしたいところだ。

動かしたいところなのだが・・・夏休みを終えて作業場に戻ってきてしまった。
となると、作業場のPCにもZephyrの環境を作りたい。
今までのPCは何だったかというと、移動用のPCだったのだ。

作業用PCもWindowsなのだが、同じようにWSLにインストールするのも面白味がない。
それに、WSLだとUSBが使えないので、ウェストフラッシュ!(west flushのこと)が使えないのだ。
だからWindows Nativeのインストールをしよう。

 

というわけで、今回はまたZephyr v2.0.0-rc1をインストールする話だ。 

https://docs.zephyrproject.org/latest/getting_started/index.html

pythonのことはスルーして、required toolsのインストールを行う。

https://docs.zephyrproject.org/latest/getting_started/installation_win.html

前回は、ここのOption 2になるはずだ。
今回はOption 1。recommendedだから、すんなりいくだろう。

PowerShellでもよいらしいが、私はcmdしか知らん。
そして、chocolateyというツールを使うらしい。思い出せないが、他の環境を作るときにこの手のツールを使ったことがある。Windows用のパッケージマネージャーの1つだ。
sudo …じゃなくてAdministratorでインストールする方を選択。そうじゃない方はめんどくさそうだったから。

何も考えずにchocoを使ってインストールしたのだけど、Noteを見ると、別に手動でインストールしてもよいらしい。
だが、やってしまったのだ。Option1の5と6を実行すると、WindowsのPATHに追加されていた。

image

まあ、インストールの説明って、どうしてもそうなるよな。
私も最近までインストールの資料を作っていて、細かい説明を書くのが面倒・・というか無理になってきたので、Ubuntuのaptを使った説明しか書かない、みたいなことをやっていたのだ。

image

binの中を見てみたけれど、gitなんかはコマンドが入ってないな。pythonもない。
ただ、pythonをcmd.exeで実行すると、Microsoft Storeのアプリが立ち上がってPythonアプリのインストールが出てくる。
いや、gitもpythonも、もうインストールされているのよ?
そこは考慮してくれないの??
いま気付いたけど、cmakeはProgram Filesにインストールしたの???

再起動して分かったが、cmakeもgitもProgram Filesにインストールされていて、コントロールパネルの「プログラムと機能」にも出ていた。 
「プログラムと機能」にCMakeが出ていたので「昔インストールしてたやつだろう」と思って削除したら消えていたので分かった。。。


あれこれやって、gitにもPATHを通して、west initからやり直す。
そして、”Zephyr (2)”の要領でZEPHYR_TOOLCHAIN_VARIANT=hostにして、ボードはqemu_x86にする。

そうすると、「指定されたファイルがが見つかりません」になった。
おそらくdts.cmakeの${CMAKE_C_COMPILER}だろう。
Windowsの場合、標準のコンパイラなどないから、gccなどをインストールするのだろう。

 

でも、そうするとWSLでいいやん、という気分になるので、QEMUを使うのは止めよう。

set ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
set BOARD=reel_board
set GNUARMEMB_TOOLCHAIN_PATH=C:\Winappli\gcc-arm-none-eabi-8-2019-q3-update-win32

こんなのをzephyrrc.cmdというファイルに保存して、c:\Users\xxxxの直下に置いた。west initなどしてダウンロードしたzephyr-env.cmdは、%userprofile%\zephyrrc.cmdを読み込むようになっているのだ。
west buildは、通った。

 

そして!
ようやくwest flashところまでやってきた。

D:\Prog\Zephyr\zephyr>west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner pyocd
-- runners.pyocd: Flashing file: D:/Prog/Zephyr/zephyr/build/zephyr/zephyr.hex
0000405:WARNING:common:STLink and CMSIS-DAPv2 probes are not supported because no libusb library was found.
No connected debug probes
0000417:CRITICAL:__main__:uncaught exception:
Traceback (most recent call last):
  File "c:\python37\lib\site-packages\pyocd\__main__.py", line 338, in run
    self._COMMANDS[self._args.cmd](self)
  File "c:\python37\lib\site-packages\pyocd\__main__.py", line 468, in do_flash
    with session:
  File "c:\python37\lib\site-packages\pyocd\core\session.py", line 284, in __enter__
    assert self._probe is not None
AssertionError
ERROR: command exited with status 1: pyocd flash -e sector -t nrf52 -f 4000000 D:/Prog/Zephyr/zephyr/build/zephyr/zephyr.hex

私としてはpyocdじゃなくてJ-Linkを使ってやりたいのだがね。

Nordic nRF5x Segger J-Link
https://docs.zephyrproject.org/latest/guides/tools/nordic_segger.html

残念ながら、west flashではできないようだ。
あれ・・・私がWSLを使わないでセットアップした理由はなんだったっけ。。。


ともかく、実機に焼いて動かす。
書いてあるとおりにHEXを焼いて、RTT Viewerを起動。
何も出ない。

 

そもそも、printk()が自動的にRTTを使ってくれるのかどうかわかっていない。
単にUARTに吐き出すだけかもしれない。
もう少しわかりやすく、LEDの点滅をさせよう。

https://docs.zephyrproject.org/latest/samples/basic/blinky/README.html

west build samples\basic\blinky --pristine
nrfjprog --eraseall -f nrf51
nrfjprog --program build\zephyr\zephyr.hex -f nrf51
nrfjprog --reset -f nrf51

なんか出た。
使ったボードはPCA10028じゃないけど、LED0のポートはGPIOとして使えるようになっていたので、そこにつなげた。

image

 

せっかくなので、オシロで間隔を測った。
若干、1秒よりも短いが、まあ仕方ないか。

image

 

あっさり動いたように書いたが、最初は別のGPIOを使おうとして動かなかったのだ。
ポート番号さえあってりゃいいんだろう、と思っていたけど、nRF51はGPIO0.xxという割り当てなので、GPIO0のところをdevice_get_binding()でやってやらんといかんらしい。

ここら辺になると、そろそろZephyrでの書き方というものを調べねばならぬだろう。

2019/08/16

UMLエディタを探し始めた (6)

まだやってたのか?と自分でも思っていたのだが、まだ探していたUMLエディタ。

 

Visual Paradigm Community Edition
https://www.visual-paradigm.com/editions/community/

これを書いている時点では、v16.0だ。

 

image

 

なんとなくだが、この子とはうまくやっていけそうな気がしている。
私がやっていないUML2らしい。

なんか線の種類が多いのだけど、線を引いた後に出てくるクイックメニューのようなところからReplyも引くことができた。
始点とActivationの結びつきは強く、矢印を移動させると始点の方のActivationは伸びる。
Activationは自動で縮まないが、自動調整アイコンが出てくるので、クイックするとほどほどのところまで縮む。
上の図の右端のReplyはそうやって縮めたものである。矢印の始点よりも少し下に伸びているのは、これは矢印の設計がそうなっているためなのだろう。

というのも、Activationと終点の結びつきはほとんどなくて、例えばReplyの矢印を下に移動させて終点がActivationから外れると、元のActivationが伸びるのではなく、その終点用のActivationができるからだ。

image

この状態で矢印線を上に移動させると、終点側の緑Activationは黄色Activationに吸収される。
また下に移動させると、またActivationが現れる。このときのActivationの色は、ライフラインに設定していた背景色が採用される。
だから、上下関係でActivationが見えなくなるのではなく、吸収されるのだろうと思ったのだ。

 

もし購入するとしたら、私の場合は買い切りのModelerコースになるだろう。

https://www.visual-paradigm.com/shop/vp.jsp?license=perpetual

コード生成とかUXとかはやらないだろうしなぁ。

 


とはいえ、astahの財産が使えなくなる(Viewerは提供されているので、見るだけ)のも、哀しい。
あれだけお世話になったし、1回くらいは購入してもよいかもしれない、という気分になってきた。

これだけ時間を掛けて探しておいて今さら!と思わなくもないが、代替になりそうなツールが見つかったことで心に余裕ができたのだろう、きっと。

 

買い切りであるユーザーライセンスの場合、1年分のサポートは付いてくる。
つまり、1年以内なら最新バージョンを使うことができるというわけだ。
過去の履歴を見てみると・・・

image

よし、急いでないから10月でいいな。
それまではVisual Paradigm CEの練習をしておこう。

2019/08/15

Zephyr (5)

そろそろ、ZephyrのBLEについて見ていこう。
BLEというか、もうnRF51関係だけでいいや。

 

この辺か?

https://github.com/zephyrproject-rtos/zephyr/tree/master/soc/arm/nordic_nrf
https://github.com/zephyrproject-rtos/zephyr/tree/master/boards/arm/nrf51_pca10028
https://github.com/zephyrproject-rtos/zephyr/tree/master/dts/arm/nordic
https://github.com/zephyrproject-rtos/zephyr/tree/master/subsys/bluetooth

SoftDeviceという文字が入ったファイル名はあるものの、SoftDeviceそのものは見つけられていない。
cmakeしているときにダウンロードしているのだろうか?

https://lists.zephyrproject.org/g/devel/topic/28266081

なんでも、subsys/bluetoothの部分がSoftDeviceと同じ立ち位置になるらしい。
ということは、今までSoftDeviceとしてバイナリ提供していた部分が公開されている?
あるいは、cmakeするときにダウンロードしているとか??

謎は深まるばかりだが、まあそこはやってみればわかるんじゃないだろうか。
ビルド後にSoftDeviceのhexファイルなんかが残っていればわかりやすいんだけどね。


あと心配するのは、NordicのZephyrに対する思い入れだ。

nRF51はもうデバイスとして枯れているとは思うが、Zephyrへの対応がどのくらい進んでいるのか分からない。
nRF51822のIC revision 2はnRF SDKのサポートはv10.0で終わっているようなので、よほどのことがないとアップデートされないだろう。

そうなると、Zephyrを使った方がよさそうな気がするのだが、しばらくして「やっぱりやめた」という心配がある。特に、プロプライエタリな部分を含んでいる場合には、メーカーが対応してくれなくなったら身動きが取れなくなってしまう。

 

commit履歴を見たけれど、少なくともここ数日は毎日Bluetooth関連の変更が入っていた。
うん、何の根拠もないけど、v.2.x.xはサポートしてくれそうな気がする。

というわけで、このままいってみよう。

Zephyr (3)

別のディレクトリにhello_worldをコピーしてやってみよう。

$ cp -r ~/zephyrproject/zephyr/samples/hello_world ~/prog/zephyr/
$ source ~/zephyrproject/zephyr/zephyr-env.sh
$ cd ~/prog/zephyr
$ mv hello_world hello_zephyr
(hello_zephyr/src/main.cを編集)

$ west build -b qemu_x86 hello_zephyr
$ west build -t run

-- west build: build configuration:
       source directory: /home/xxxx/prog/zephyr/hello_zephyr
       build directory: /mnt/c/Prog/zephyr/build
       BOARD: qemu_x86 (origin: CMakeCache.txt)
-- west build: running target run
[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: qemu32,+nx,+pae
Optimal CONFIG_X86_MMU_PAGE_POOL_PAGES 9
***** Booting Zephyr OS build v2.0.0-rc1-10-g10ffef93e639 *****
Hello Zephyr! qemu_x86

 

なお、ZEPHYR_TOOLCHAIN_VARIANTとかPATHの設定は済ませているものとする。
環境変数BOARDにqemu_x86を設定しておくと、もう少し楽になる。


では、qemuのArm版をインストールして動かしてみよう。

sudo apt install qemu-system-arm

~/.zepherrcも編集

01: #BOARD=reel_board
02: BOARD=qemu_cortex_m3
03: export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
04: export GNUARMEMB_TOOLCHAIN_PATH=/home/xxxx/gcc-arm-none-eabi-8-2019-q3-update
  

 

$ west build hello_zephyr --pristine
$ west build -t run

[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: cortex-m3
qemu-system-arm: warning: nic stellaris_enet.0 has no peer
***** Booting Zephyr OS build v2.0.0-rc1-10-g10ffef93e639 *****
Hello Zephyr! qemu_cortex_m3

動いたんだと思う。

2019/08/14

Zephyr (2)

未だに、"Zephyr"の綴りを見ながらじゃないと書けない。。。

さて、QEMUでHello Worldだけは動いたので、もう少し本体のことを見ておこう。


まず、BLE部分。

Nordic Blog(2016/12/22)によると、Link Layer + HCIを移植したそうだ。
ソースファイルを見てみると、Nordicの名前が入っている。
もう少し上のディレクトリになると、NordicだけでなくIntelの名前も入っていた。
shellやmeshなんかはIntelのようだ。

今のところこの部分はNordicだけしか入っていないので、Nordicで使いやすくポーティングされているのだろう。highly optimizedと書いているのは、そういった理由からだろうか。
いや、nRF5x SDKで作っていたコードを移植しやすいということか。"you can clone, build and run"ってのがよくわかってない。が、まあ、ZepherがサポートするIPv6 over BLEなんかの機能と組み合わせられるとか恩恵を受けるとか、そんなことをいいたいんじゃなかろうか。
あるいは、git cloneとかで好きかって改造したらいいやん、みたいなところもあるのか・・・。

考えても分からんので、そのうち考えよう。


Blogの手順を見ると、beaconを動かす手順が書かれていた。
3年前の記事だから、手順が多少違うかもしれない。

なんとなくZephyr SDKを展開したものの、これっていらないんじゃなかろうか・・・。

image

zephyr-sdk-0.10.2/arm-zephyr-eabi/bin$ ./arm-zephyr-eabi-gcc --version
arm-zephyr-eabi-gcc (crosstool-NG 1.24.0-rc2-dirty) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

うーん?
ZEPHYR_SDK_INSTALL_DIRを設定しなければいいだけのような気もするが、そういえばdtcのバージョンがあったな。。。

dtcのソースコードを取ってきてビルドしよう。

https://git.kernel.org/pub/scm/utils/dtc/dtc.git

$ sudo apt install flex bison
$ make
$ make install

うーん、/home/xxxx/bin/dtcにインストールされたようだ。

$ sudo make PREFIX=/usr install

無理やりな感じもするが、これでパスが通るところに最新dtcが置かれた。

 

$ west build -b qemu_x86 samples/hello_world

...

  ZEPHYR_SDK_INSTALL_DIR must be set

ああ、ZEPHYR_TOOLCHAIN_VARIANT=zephyrが設定されていたままだった。
しかし、未設定にするとZEPHYR_TOOLCHAIN_VARIANTの設定を要求された。
GCCのprefixみたいなイメージだったのだが、何を指定すれば良いのだろうか。。。

どうも、zephyrproject/zephyr/cmake/toolchainの下にあるディレクトリ名として使っているようだ。

image

host、でいいのかな?

$ file build/zephyr/zephyr.elf
build/zephyr/zephyr.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, with debug_info, not stripped

まあ、いいのかな。

しかし、 west build -t runは動かなかった。

/bin/sh: 1: QEMU-NOTFOUND: not found
FAILED: zephyr/CMakeFiles/run

QEMUがインストールされていないのか?

$ sudo apt install qemu-system-x86

ダメか。

どうも、CMakeCache.txtに載ってるらしい。

https://github.com/zephyrproject-rtos/zephyr/issues/6911#issuecomment-378770605

確かに、QEMUはnotfoundだった。

//Path to a program.
QEMU:FILEPATH=QEMU-NOTFOUND

CMakeCache.txtの更新方法が分からんかったので、build/ごと削除してwest buildからやり直した。
そしたら、動いた。

qemuって、動いたらCtrl+Cでは止められないのね。。。


というわけで、SDKディレクトリは削除をしてよいだろう。
数GBあって、うちのSSDの空き容量を圧迫していたのよねぇ。

2019/08/13

Zephyr (1)

SEGGER Embedded Studioを使って、nRF51822を久々に動かしてみようとした。
nRF51822は3年ぶりくらいでまったく記憶にない上、eclipseで作っていた環境もSESにはインポートできなさそうで、新たにやり直すことになりそうだ。

 

じゃあ、せっかくだし、別のを試すか。

nRF5x support within the Zephyr Project RTOS - Nordic Blog - Nordic Blog - Nordic DevZone
https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/nrf5x-support-within-the-zephyr-project-rtos

まあ、SESの方が前の知識を生かしやすいとは思うが(知識が残っていたら)、少しかじっておくとどこかで使えるかもしれん。


インストール

今回は、Windows10のWSLにインストールしてみよう。
Windowsのネイティブ側でもよいそうなのだけど、まあ、なるべくLinuxに近い環境の方がやりやすい。

https://docs.zephyrproject.org/latest/getting_started/installation_linux.html

この中でつまづいたのが、dtc。
バージョンが1.4.6以上を要求されているのだが、持っているのは1.4.5。
ソースからビルドするか、Zephyr SDKに入ってるやつを使うか。
本物のUbuntu18.04だったらsnapが使えそうな気配があったのだが、WSLではsnapが使えないようだ。

まあいい。SDKのを使おう。
今の時点では、v0.10.2がリリースされている最新なのか。

 

Zephyr SDKはツールチェーンなど一式が入っているのだが、それ無しでもビルドできるようにはできているらしい。
まあ、まだそこまで考えなくてよいか。


最初に見つけたのがOSごとのインストールだったのだが、OS共通でいろいろインストールするものがあった。

https://docs.zephyrproject.org/latest/getting_started/index.html

 

こんな感じだろうか。

mkdir ~/.local/bin
(.bashrcなどでPATHに通す)

pip3 install --user -U west

west init zephyrproject
cd zephyrproject
west update

pip3 install --user -r zephyr/scripts/requirements.txt

.local/binはどこかで使うのだろうか?

 

ツールチェーンはどうしたものか。
私は、たぶんnRF51822向けに使うだろうから、Cortex-M0か。
Xtensaもあるから、ESP8266でもいけるのかな?
手元にArm環境は無いのだが、8-2019-q3-updateのLinux 64bit版をインストールしておく。

~/.zephyrrcにcmakeのPATHは追加されていたので、Armの分を追加しておこう。
個々でいいのかどう亜走らんが。

export PATH=/home/xxxx/bin/cmake/cmake-3.13.1-Linux-x86_64/bin:$PATH
export ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
export GNUARMEMB_TOOLCHAIN_PATH=/home/xxxx/gcc-arm-none-eabi-8-2019-q3-update

 

あとは、ninja?とかいうのもインストールした。
いるのかどうか、よくわかってない。


https://docs.zephyrproject.org/latest/getting_started/index.html#build-hello-world

zephyr-env.shを読み込むと、~/.zephyerrcも読み込むようだ。

ビルドは、westかcmakeとninjaでできるようだ。
ninjaの代わりにmakeでもいいらしいが、まあ、せっかくインストールしたのでそのままやろう。

 

実行すると、ELFファイルができたっぽい。
コンソールには zephyr/zephyr.elfと出ていたが、ビルドを開始したディレクトリ基準にするとbuildの下らしい。

$ file build/zephyr/zephyr.elf
build/zephyr/zephyr.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

むう、自分で設定したとはいえ、Armのバイナリだ。
westかninjaでflashコマンドを実行するとUSB経由で焼いてくれるらしい。

 

あ、USB ?
WSLって、USBに対応していなかったはず。。。

01: $ west flash
02: -- west flash: rebuilding
03: ninja: no work to do.
04: -- west flash: using runner pyocd
05: -- runners.pyocd: Flashing Target Device
06: No connected debug probes
07: 0003517:CRITICAL:__main__:uncaught exception:
08: Traceback (most recent call last):
09:   File "/home/xxxx/.local/lib/python3.6/site-packages/pyocd/__main__.py", line 338, in run
10:     self._COMMANDS[self._args.cmd](self)
11:   File "/home/xxxx/.local/lib/python3.6/site-packages/pyocd/__main__.py", line 468, in do_flash
12:     with session:
13:   File "/home/xxxx/.local/lib/python3.6/site-packages/pyocd/core/session.py", line 284, in __enter__
14:     assert self._probe is not None
15: AssertionError
16: ERROR: command exited with status 1: pyocd flash -e sector -t nrf52 -f 4000000 /home/xxxx/zephyrproject/zephyr/build/zephyr/zephyr.hex
  

デバイスはnRF52になっているようだ。
これがreel_boardというものらしい。

 

いまボードがないので、QEMUでやってみよう。
reel_boardと同じ要領でqemu_x86にしてみたのだが、既にreel_boardようになっているというエラーになった。
--pristineオプションを付けるとビルドが進んだ。。のだが、すぐこけた。
~/.zephyrrcにArm用の設定を追加していたので、そこをコメントアウトしてターミナルを立ち上げ直す。

$ west build -b qemu_x86 samples/hello_world --pristine 

$ file build/zephyr/zephyr_prebuilt.elf
build/zephyr/zephyr_prebuilt.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, with debug_info, not stripped

 

$ west build -t run
SeaBIOS (version rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org)
Booting from ROM..Optimal CONFIG_X86_MMU_PAGE_POOL_PAGES 9
***** Booting Zephyr OS build v2.0.0-rc1-10-g10ffef93e639 *****
Hello World! qemu_x86

 

Hello World!って出てきたので、動いたのだろうか?
まあ、そういうことにしておこう。

2019/08/11

[ses]SES v4.18

夏休みなので、SEGGER Embedded Studio for ARMを起動させてみたところ、v4.18がリリースされているということだった。
前回はv4.16だったので、大して変わっていないと思うがアップデートしておこう。

 

 

・・・ビルドが通らなくなった。
SEGGER_Flash.icfが変更になったようだ。

  1. プロジェクトツリーの”Project xxxx”にフォーカスを当てて、コンテキストメニューからOptions…を選択
  2. 検索ボックスに”seg”くらいまで入力すると、Memory Segmentsが出てくるので変更する

FLASH1 RX 0x00018000 0x00028000;RAM1 RWX 0x20002000 0x00002000

 

v4.16のときは「FLASH」「RAM」だったのだけど、これが「FLASH1」「RAM1」になった。
こんだけのことだが、動揺するのであまり変更してほしくないなぁ。。。

[vscode][rust]ビルド時にpermission deniedが出る

前回、WSL + vscodeにRustの環境を作った。
動いているのだが、cargo buildなどでビルドするとTERMINALにPermission Deniedが出る。
特に問題はなさそうなのだけど、あまり気持ちがいいものでもない。

https://code.visualstudio.com/docs/remote/wsl#_i-see-eaccess-permission-denied-error-trying-to-rename-a-folder-in-the-open-workspace

設定を追加するとよいそうだ。

"remote.WSL.fileWatcher.polling": true,

vscodeを再起動してcargo clean, cargo buildすると、きれいにビルドできた。
よかったよかった。

 

WSL2では解消されているらしいので、はやくWSL2を試してみたいものだよ。
lmdbが今のWSLで使えなくなってしまったのも一緒に解消されないかなぁ。。。

2019/08/09

[win10]Rust環境をインストールしたい

なんだか、周囲でRustの話をしている人がいた。
名前は知っているが、よくわからん。
まずい・・・。

というわけで、Windows10でRustの開発環境をインストールしたい。


ここで悩むのが、WSLでやるかどうかだ。
WSLだとコマンドのところで悩まずに済むし、LinuxやMacなどとも話がしやすい。
しかし、Windowsのネイティブ環境にインストールするとその恩恵を受けやすいだろう。

 

悩んだときは、WSLだ。
親切なことに、インストールのページにWSLでのやり方も書かれていた。

curl https://sh.rustup.rs -sSf | sh

meteorなんかもこんなインストール方法だったな。

$ cargo --version
cargo 1.36.0 (c4fcfb725 2019-05-15)

 

Hello Worldはコマンドだけでやれるようだ。

$ cargo new hello_cargo
     Created binary (application) `hello_cargo` package
$ cd hello_cargo
/hello_cargo$ cargo run
   Compiling hello_cargo v0.1.0 (hello_cargo)
    Finished dev [unoptimized + debuginfo] target(s) in 4.12s
      Running `target/debug/hello_cargo`
Hello, world!

 

とりあえず、環境だけはできた。


で、学習するからにはデバッグ環境がほしい。
しかし、私はgdbが苦手だ。。。覚えられない。。。

こういうときはVisual Studio Codeだろう。
拡張機能もあるし、WSLを使うかどうかという設定もある。

image

あるのだが、RSファイルを開くと「Rust Language Serverがない」「Rustup not available」などといわれてしまう。
rust-client.rlsPathで設定してみたが、それはそれでダメだった。
"Use WSL"は、一体何をしてくれるのだろうか?

 

・・・Use WSLのサポートは打ち切られて、代わりにRemote -WSLを使うようになったらしい。

https://github.com/rust-lang/rls-vscode/issues/585#issuecomment-507037318


ということは、どうなるかというと。。。

  • ExtensionのRemote-WSLをインストールする
  • Rust(RLS)もインストールする

どうも、Remote-WSLはディストリビューションを選択するらしい。
私はこうなった。

image

これを有効にすると、各ExtensionもWSL用にインストールするかどうかのボタンがそれぞれに出てきた。
取りあえず、C/C++のデバッガやRLSなどはインストールしておいた。
RSLの設定は、デフォルトのままでよさそうだ。

そしてvscodeを立ち上げ直すと、まずRemote-WSLが立ち上がるようで、今までより少し時間がかかった。
そしてmain.rsファイルを開くと、RLSが立ち上がってくれたようだ。

image

 

と、すんなり動いたように書いているが、ここに至るまでにかなりあれこれやったので、もしかしたら他に設定がいるかもしれん。


元々は、デバッグがやりたかったのだ。

01: {
02:     // Use IntelliSense to learn about possible attributes.
03:     // Hover to view descriptions of existing attributes.
04:     // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
05:     "version": "0.2.0",
06:     "configurations": [
07:         {
08:             "name": "(gdb) Launch",
09:             "type": "cppdbg",
10:             "request": "launch",
11:             "program": "${workspaceFolder}/target/debug/hello_cargo",
12:             "args": [],
13:             "stopAtEntry": false,
14:             "cwd": "${workspaceFolder}",
15:             "environment": [],
16:             "externalConsole": false,
17:             "MIMode": "gdb",
18:             "setupCommands": [
19:                 {
20:                     "description": "Enable pretty-printing for gdb",
21:                     "text": "-enable-pretty-printing",
22:                     "ignoreFailures": true
23:                 }
24:             ]
25:         }
26:     ]
27: }
  

こんな感じのlaunch.jsonを作ってprintln()のところにブレークポイントを設定すると、デバッガを起動させて止まってくれたように思う。

よくわかってないが、"debug.allowBreakpointsEverywhereをtrueにしないとブレークポイントが設定できなかった。
まあ、今回はこれで良かろう。

2019/08/06

[vscode]単語カーソル移動

vscodeで、Ctrlキーを押したまま左右矢印キーを押すと単語移動する。

あまり使ったことなかったのだが、今日使っていて違和感があった。
いつも使うテキストエディタと移動がなんか違う・・・。

 

設定を見ると、こうなっていた。

{
    "key": "ctrl+left",
    "command": "cursorWordStartLeft",
    "when": "textInputFocus"
},
{
    "key": "ctrl+right",
    "command": "cursorWordEndRight",
    "when": "textInputFocus"
},

cursorWordは共通で、StartLeftとEndRight。
つまり、Ctrl+左矢印だと単語の左先頭、Ctrl+右矢印だと単語の右末尾にカーソルが移動する。

私が普段使っているエディタでは、Ctrl+左矢印で左先頭なのは同じだが、Ctrl+右矢印は右先頭に移動するものが多かったのだと思う。

 

まあ、これはどっちが良い悪いではなく、慣れの問題だったり、どっちの方が自分の作業にとって便利かというところだろう。
そんなわけで、ctrl+rightを””cursorWordStartRight"に変更した。

2019/08/04

[hw]I2Cとレベルコンバータ (2)

昨日に引き続き、ArduinoとFeliCa Linkをレベルコンバータ経由で動かそうとしている。
経由というか、バイパスというか、なんて言うんでしょうね。

 

image

さっきまでソフトタイプのワイヤで接続していたのだが、どうも動作が安定しないので試しにハードタイプにしてみたところ、安定して動くようになったと思う。

経験則なのだけど、I2Cはノイズに弱いのか知らんが、短い線で観測などもせずにおくのが無難だと思っている。
プルアップ抵抗の大きさでなんとかなるのかもしれんが、うん、動けばよかろうなのだ。

 

I2Cの通信がダメだったのは、単純にAPIの使い方を間違えていただけだった。
まさかrequestFrom()みたいなAPIがあろうとは思ってもいなかった。。。

 

いまは、IRQが立ち下がらない原因を調査中である。
まあ、なんか設定を忘れているだけだろうが、I2Cとは関係ないので、これで終わりだ。

2019/08/03

[hw]I2Cとレベルコンバータ (1)

久々にハードウェアが絡んだ話だ。

 

夏休みが近いので、何か工作をしようと考えていた。
出てきたのは、ArduinoとFeliCa Link。
そういえば、この組み合わせはまだやったことがなかったな。


ネットで検索して出てきたのは4年以上前のライブラリだった。

https://os.mbed.com/users/hiro99ma/code/RCS730/

MbedのAPIを使っていたので、それをArduinoのAPIに置き換えればなんとかなるだろう。

 

それよりも問題は電圧だ。
FeliCa Linkは3.7Vまでなのだが、Arduinoは5Vだ。
そのままでは接続できない。

幸いなことに、スイッチサイエンスさんから購入したレベルコンバータが手元にあった。

https://www.switch-science.com/catalog/1466/

Arduinoからは3.3Vもとれるので、FeliCa Linkは3.3V、Arduinoは5Vで動かせば問題なかろう。


接続するだけなので、電圧を確認しつつもブレッドボードで配線した。
FeliCa Linkで一番簡単に確認できるのは、RFDETピン、つまり搬送波検出だ。
電源を入れて、スマホなりNFCのR/Wなりをかざすと立ち下がってくれる。
レベルコンバータを経由してRFDETをポーリングし、搬送波を検出したらArduinoのLEDを点灯させる、というところも動いた。

ならば、あとはI2Cのところだけだから簡単だろう。

 

 

・・・簡単じゃなかった。
そもそも、私はI2Cが苦手なのだ。
たった2本でデータをどちらからも読み書きできるし、なによりもオープンドレインだ。
オープンドレインだからどうのこうのというのはわからんのだが、私のイメージとしては「早い者勝ち」で、手を離すタイミングと相手がつかむタイミングがずれると泥沼にはまってしまうという恐怖感がある。

そして、プルアップ抵抗。
計算方法は分からんのだけど、ダメな値の抵抗値を使うとダメだ。
計算方法を理解すればいいのだろうが・・・そこは真面目にやる気が起きず、なんとなく5kΩ前後を選べばいいんじゃなかろうか、くらいの経験則でやっている。

 

自業自得とも言えるが、都合が悪いことは忘れよう。


どううまくいかないのか調べていったところ、スタートコンディションになってない、ということがわかった。
(一行で書いたけど、配線調べたり実装調べたり、そこに至るまでも大変だったのだ。)

ArduinoはI2Cのマスターだからスタートコンディションにすることくらいはできるだろうと考えていたのに、最初からうまくいっていないのだ。
以前、I2Cで失敗したときはプルアップ抵抗の大きさが問題だったので適当に変えてみたが、やはりダメ。

 

あれこれやって気付いたのだが、どうもレベルコンバータがあるとダメなようだ。
外すと(もちろんI2Cのデバイスも外れるが)、スタートコンディションなどはできていた。

 

そこでようやく、レベルコンバータというものの動作を理解できていなかったことに気付いた。
電圧のレベルをうまいこと変換してくれるもの、という程度の認識だったのだが、お互いが直結しているわけではないのだった。
お互いがHIGHになっていることが確認できないと、I2Cとしてはスタートコンディションしてよいかどうか判断できないので、Arduino側はArduino側でプルアップし、FeliCa Link側はFeliCa Link側でプルアップしないといかんのじゃなかろうか。

そして、ArduinoのI2Cライブラリ(Wire.h)を使った場合、内部でプルアップしているということだった。
ならば、FeliCa Link側だけプルアップしてやればよさそうだ。


ただ・・・まだi2cdetectができただけで、I2Cの通信はこれから出会った。。。