diagram-js 検討

とあるものが必要なきがしてので、どのように作るのがいいか検討していた。
GUIが欲しかったので
表が得意そうなライブラリが豊富なjavascriptで書くことにして、
javascriptで書くのがつらそうなコアのバックグラウンド処理は
webassemblyとか使おうかなという方針になった。

まずはライブラリを探していた。
作図系ツール・ライブラリまとめ · GitHub
10+ JavaScript libraries to draw your own diagrams (2019 edition)
自分のイメージするGUI操作感からすると、シーケンス図やフローチャート、ブロックダイアグラムといった類

最終的に操作感がよさそうなのとデモの完成度に惹かれて以下のライブラリを使うことにした。
github.com
これ自体は描写部分のシンプルなライブラリで、
描写をもっと拡張したり、オリジナルの要素を追加したいときは
ライブラリのクラス(クラスのようなもの)を継承して実装する。

例として以下のbpmn-jsがdiagram-jsを利用したツール
demo.bpmn.io

f:id:katakanan:20190522140449p:plain
この要素をクリックした右上にContextPadPaletteがあるのがとてもよい。

公式にはdiagram-jsじゃなくてbpmn-jsを使うことを推している気がするが
Walkthrough | bpmn.io

bpmn-jsには
ライセンスが独自でめんどくさい。
読む限りは、基本的に?ロゴを右下に表示しておけばいいきがするが。。
また、bpnm-jsのGUIがすこしだけ自分のイメージとは違うので
diagram-jsから拡張していくことにした。

nodejs Webpack-dev-server js html ウェブブラウザ更新

webpack dev serverの設定メモ

  • エディタでjsをいじるとブラウザで自動リロードされる
  • htmlをいじると自動リロード
  • bundleも更新される(webpack-dev-serverはbundleしたものをメモリ上に置くので実態のファイル自体は更新されない?
  • その他

ファイル構成
f:id:katakanan:20190511101222p:plain
app/app.jsがあり、topファイル
publicにindex,jsがあり、bundle-app.jsも生成される。
package.json

{
・・・・
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "./node_modules/.bin/webpack",
    "start": "./node_modules/.bin/webpack --watch & ./node_modules/.bin/webpack-dev-server --hot --inline --progress --colors"
  },
・・・・
  "devDependencies": {
・・・・
    "html-webpack-plugin": "^3.2.0",
    "webpack": "^4.30.0",
    "webpack-cli": "^3.3.1",
    "webpack-dev-server": "^3.3.1"
  }
}

webpack.config.js

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'development',
  entry: './app/app.js',
  output: {
    path: path.join(__dirname, 'public/js'),
    filename: 'bundle-app.js'
  },
  devServer:{
    contentBase:'./public',
    publicPath: '/',
    watchContentBase: true,
    openPage: 'index.html',
    open: true,
  },
  plugins:[
    new HtmlWebpackPlugin({
      template : "./public/index.html"
    })
  ]
};

webpack-pluginとか要らないかもしれないが
いつまでも開発環境にこだわってると始まらないのでこれで

mbed ethernet UDPSocket

すこし確かめたいことがあったので
mbed(LPC1768)でEthernetを用いてUDP通信を行った。

プログラム

mbed osのバージョンによっていろいろと違うらしいので
最新のサンプルをImportする
os.mbed.com

f:id:katakanan:20190407005904p:plain

しかしすでに、exampleにあるような
UDPSocketのコンストラクタでEthernetInterfaceのインスタンスを渡すのは
deprecatedらしい。

    UDPSocket sock(&net);
    SocketAddress sockAddr;


openで渡す。

動作確認

connectでDHCPでIPを取ってくる。
f:id:katakanan:20190407005645p:plain

netcatでUDPパケットを受信できる。
f:id:katakanan:20190407002728p:plain

mbed NXP LPC1768

mbed NXP LPC1768

mbed LPC1768用イーサネット接続キット

mbed LPC1768用イーサネット接続キット

VScode STM32 WSL J-Link arm-none-eabi-gdb

VScode上で、JLinkGDBServerを起動して、
WSLのarm-none-eabi-gdbデバッグできるようにする。

WSL

make
arm-none-eabi-gcc
arm-none-eabi-gdb
は入れておく。

VScode

をインストールする。
ポータブル版でもよい。

VScode拡張機能

f:id:katakanan:20190331171209p:plain
上から
IntelliSencse
Cortex-Debug
日本語化

設定

VScodeでCubeMXのプロジェクトファイルがあるところを
RootFolderとする。
ファイル→フォルダを開くで指定すると、.vscodeフォルダができる。
この中にいろいろなVScodeの設定が保存されている。
f:id:katakanan:20190331170832p:plain

VScodeでCube MXのパスを設定する。

Ctrl + Shift + P

c/c++ : editconfigurationsとする
f:id:katakanan:20190331171537p:plain


includeフォルダを追加しておかないとintellisenseのハイライトがエラーを出して
うざいのでパスを網羅しておく。

Tasks

,vscode内に

tasks.json

をつくる。

makeに必要な操作を列挙する。

GDBServer Path

.vscodeにsetteings.jsonがあるはずで、
cortex-debugはGDBserverの場所を知らないので書いておく、

Debug settings

Ctrl + Shift + D

で左側にデバッグのカラムができるので、
f:id:katakanan:20190331172833p:plain
構成の追加をする。
環境選択ではCortex Debugを選ぶ
f:id:katakanan:20190331173017p:plain
launch.jsonが生成されるのでelfファイルや、その他を設定する。


新しいフィールド値を設定しなければならないときは、
その場所で

Ctrl + Space

を押すとどのような値を設定できるかが表示される。
f:id:katakanan:20190331173304p:plain

preLaunchTaskはgdbServerが起動する前に実行するタスクで
先ほど定義したtasks.jsonから選ぶ。

preLaunchCommandsはgdbが起動した後に実行されるべきコマンドのリストで、
ここでは例として
・ファイルを書き込む。
・mainにbreak pointを打つ
・実行
としている。

デバッグ

main.cを開いて、

F5

を押せばデバッグが開始される。
f:id:katakanan:20190331174500p:plain

デバッグコンソールのログから、
プログラムが書き込まれていて、
ブレークポイントが設定されているのがわかる。
ここからgdbにコマンドを叩ける。

Eclipseを使いたくなかったのでVScodeで頑張ってみたが、
意外と使いやすそうだった。

実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング

実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング

Nucleo J-Link化

STM32の開発でJ-Linkというデバッガーがよさそうらしいので
手元のNucleoで試してみる。

準備

今回試すのはNucleo-F401、
ST-Linkの基板が隣にくっついているので
このST-Link部分をJ-Linkにして、
STM32F401REに書き込み、デバッグしてみる。

メインループ
STM32Cube MXのmain.cにあるメインループに書き足す。

while (1)
{
  /* USER CODE END WHILE */
  HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);
  HAL_Delay(1000);
  /* USER CODE BEGIN 3 */
}

J-Link化

何はともあれNucleoのST-Link部分をJ-Linkにすることが必要。
https://www.segger.com/downloads/jlink/#STLink_Reflash
f:id:katakanan:20190330010542p:plain

ST-Link書き換え用のソフトウェアを手に入れる。

Nucleoをつなげるとデバイスマネージャーには
ST-Link V2などが認識されている。

STLinkReflash.exeを起動していくつかの同意事項を確認した後、
書き込みを行う。

f:id:katakanan:20190330011002p:plain
バイスマネージャーには以下のようになる。
f:id:katakanan:20190330011340p:plain

J-Linkソフトウェアをインストール

https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack
J-Link Software and Documentation Packを入れた。
f:id:katakanan:20190330013445p:plain

J-Link GDB Server Config

f:id:katakanan:20190330013339p:plain
Nuckleoベースだったので、USBでつなげている。
MCUを選択。
SWDでつながっている(SWDIOとSWCLK)

J-Link GDB Server起動

f:id:katakanan:20190330013936p:plain
起動すると、GDBからの接続待機になる。

arm-none-eabi-gdb

WSLから

arm-none-eabi-gdb test.elf
target remote localhost:2331

GDBの”waiting for connection”が緑になる。
f:id:katakanan:20190331115300p:plain
あとは

load
continue

でelfが書き込まれた後に、
実行が始まる。
continue前に

b HAL_GPIO_TogglePin

とすれば、ここで実行が停止する。
f:id:katakanan:20190331115820p:plain

Amazonでj-linkのデバッガーを探したが
そのものはなかった。
代わりに以下のモジュールにはj-Link Lite SEGGERがついてくるらしい。

STM32Cube MXプロジェクト生成

自分の使いたいMCUを検索して右上のStart Projectする。
f:id:katakanan:20190324190425p:plain

Pin Configuration

を適当に
f:id:katakanan:20190328004928p:plain
FPGAならQuartus 13とかProject Navigatorとか
かなり昔からこんな画面のPINコンフィギュレーションソフトウェアがあったのに
代表的なMCUにはなぜないんだろうと思っていた。(PICとかAVRとかSTMも)(あったのかもしれないが)

外部クロックなどSystemに関係する機能はここでオンにしておく。
例として外部クリスタルを使う場合は以下を設定する。
f:id:katakanan:20190329220845p:plain

Clock Configuration

f:id:katakanan:20190328005143p:plain
データシートで見るようなクロックツリーがGUIで操作できる。
ユーザーが本当に求めていたものという感じだ。
外部クロックを使にはHSEをオンにする必要がある。

f:id:katakanan:20190329221042p:plain

Project Manager

ではコード生成するばしょや
Toolchainによってその形を適当にしてくれる。
f:id:katakanan:20190328010040p:plain
今回はWSLでmake + arm-none-eabi-gccでビルドしようと思うので
Makefileを選択。

Tools

ではいろいろな環境を設定できるらしいが今回は無視
f:id:katakanan:20190328010306p:plain

Code generation

を押すと指定した場所に必要なヘッダーファイルとともに
main関数の存在するファイル群が生成される。

f:id:katakanan:20190328010744p:plain
これがいわゆるStdPeriph_Libraryと比較されるHALライブラリか

mainまで作られてるので

sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt update
sudo apt install gcc-arm-embedded

だが、リンカスクリプトが空なので自分で書かなければならない?
→生成しなおしたら空じゃなかった。

とりあえず
makeはできる。

STM32Cube MXを導入

MXCubeはStdLibの代替になれるぐらいには洗練されたと聞いたので
ようやくSTM32Cubeを利用するためにインストールする。

インストーラーをダウンロードする。
www.st.com

f:id:katakanan:20190324173737p:plain
登録しなければならないらしい。
メールに送られてくるリンクからダウンロードする。

f:id:katakanan:20190324174813p:plain

f:id:katakanan:20190324174958p:plain

MCU選択・ボード選択からできるようだ
f:id:katakanan:20190324183058p:plain

次からプログラムをしてみる。

STM32マイコン徹底入門 (TECH I Processor)

STM32マイコン徹底入門 (TECH I Processor)