2019年8月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年8月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年8月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年8月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年8月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年8月9日

[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年8月6日

[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年8月4日

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

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

 

image

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

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

 

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

 

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