組込 1 年目のエンジニアが開発環境を整備した話

Web から組込の世界に来てそろそろ 1 年になろうとしています。前回の [組込の開発でも CI/CD を構築してみた](https://qiita.com/utisam/items/25f7cbb73a65126f4c00) の続編として、その後のいくつかの取り組みについて紹介していきます。

## コードフォーマッタの導入

[ClangFormat](https://clang.llvm.org/docs/ClangFormat.html) は VSCode の C/C++ Extension とも連携できて良いですね。設定はこんな感じです。

```yaml:.clang-format
BasedOnStyle: LLVM

AccessModifierOffset: -4
AllowShortIfStatementsOnASingleLine: false
BreakBeforeBraces: Attach
ColumnLimit: 0
Cpp11BracedListStyle: false
IncludeCategories:
  - Regex:           '^<.*\.h>'
    Priority:        1
  - Regex:           '^<.*'
    Priority:        2
  - Regex:           '.*'
    Priority:        3
IndentCaseLabels: false
IndentWidth: 4
PointerAlignment: Left
SpaceAfterCStyleCast: true
TabWidth: 4
UseTab: Never
```

導入の注意点としては `#include` がソートされるので、マナーの悪いヘッダがいると挙動が変わってしまう点です。そのような場合は、途中に空行を入れれば塊ごとにソートされるので、特別に対応が必要なら順番を調整できます。段階的に導入したりしていくと良いと思います。

CI では、フォーマットに従っていないソースがあったら落とすようにしています。最初は警告のみにして、覚悟がキマったらエラーにするようにします。

```sh
log_error() {
    echo -e "\033[1;41m ERROR \033[00m $*" 1>&2
}

# ライブラリ以外を find して clang-format をかける
find . -path ./lib -prune \
    -o \( -name '*.c' -o -name '*.h' -o -name '*.cpp' -o -name '*.hpp' \) \
    -exec clang-format -i {} \;
# diff が発生していたら落とす
if ! git diff --quiet; then
    log_error "Code must be formatted by clang-format"
    exit 1
fi
```

## 循環的複雑度をチェックする

[lizard](https://github.com/terryyin/lizard) は、循環的複雑度 (CCN, cyclomatic complexity number) を計算したり、コードの重複を検出してくれたりするツールです。

CI に組み込むところまではできていませんが、時々見ると重複部分や長すぎる関数を警告してくれます。こちらも、最終的には CI でエラーにしていくところまで整備したいと思っています。

## 単体テストの強化

### C++ を利用

テストや実験用プロジェクトに限って C++ を解禁しました。 `extern "C"` で混ぜて利用します。

名前空間や `class` 、オーバーロード（同じ名前で異なる引数）、テンプレートあたりを利用できるようになります。 `std::array` あたりも利用できます。例外やヒープ領域を利用するような STL （`vector` など） を利用するには。 かなりの苦労が必要そうなので一旦見送っています。

さらに C++17 の `constexpr` ラムダ式で関数がその場で作れるのはとても便利です。コールバックがその場で書けるようになることで、処理の続きを近接して記述できるようになるため、可読性が向上します。

```c++
auto addOne = [](int n){
    return n + 1;
};
// コンパイル時に関数ポインタにすることができます。
constexpr int (*addOneFp)(int) = addOne;
static_assert(addOneFp(3) == addOne(3), "");
```

コンパイルオプションとしては `-fno-exceptions -fno-use-cxa-atexit -fno-threadsafe-statics` あたりがついていれば十分かと思います。

### 単体テストフレームワークを開発

Unity Test はとりあえずは使えたのですが、割り込みなどを含むもう少し複雑なテストをしようとすると不便を感じてきました。

* 実行部分と結果を出力する部分は疎になっていた方が良さそう
    * テスト結果のレポートは自分で出力するので結果の情報だけ欲しい
* テストしたい処理の中に割り込みが含まれると、テストケースが関数 1 つに収まらない
    * テストの開始と終了を自分で呼び出すテストフレームワークが欲しい
* Assert 失敗したら即 `setjmp`, `longjmp` で終わると困るときもある
    * 共通じゃない `tearDown` 的なやつ (`try-finally` とか Go の `defer` 的なやつ) が欲しいときとか

というあたりを解消するために、 [ecunit](https://github.com/utisam/ecunit) という小さなテストフレームワークを作りました。

### ショートカットでテスト実行までできるようにする

実際のところ実行が面倒だと活用されない問題があります。そこで、 VSCode の `tasks.json` で、 test 用バイナリをビルド、書き込み、実行を一気に行えるようにしました。

```json-doc:.vscode/tasks.json
        {
            "label": "make test flash run",
            "type": "shell",
            "command": "make -j4 test && make flash && python3 ../../../scripts/run-test.py",
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "options": {
                // SDK の examples のプロジェクトと同じ構成ならおおよそこんな感じ
                "cwd": "${workspaceRoot}/ボード/SoftDeviceの名前/armgcc"
            },
            // その他いろいろ
        }
```

これで `Tasks: Run Build Task` (デフォルトだと Ctrl+Shift+B) から実行できるようなります。

`run-test.py` は、 [pylink](https://github.com/square/pylink) を使ったスクリプトで、特定の文字列がログに出力されるまで実行します。このとき、ログが省略されてしまわないように `SEGGER_RTT_CONFIG_DEFAULT_MODE` を BLOCK に設定します。

## 開発者個人用 Makefile

一時的にマクロを変えたいとき用の設定を書く場所です。特定のテストだけを実行したり、特定の部分のみログを出力したりしたいときに利用します。

```Makefile:Makefile
# local.mk があれば include
-include local.mk
```

```Makefile:local.template.mk
# 個別で変えたくなる設定をまとめておく

## Watchdog Timer
# CFLAGS += -DWDT_ENABLED=0

## Log
# CFLAGS += -DNRF_LOG_ENABLED=0
# CFLAGS += -DNRF_LOG_DEFERRED=0
# CFLAGS += -DNRF_LOG_DEFAULT_LEVEL=4
```

一時的にコンパイルオプションを変えたくなったら、  `local.template.mk` をコピーして `local.mk` を作成します。 また、 `local.mk` をバージョン管理に含まれないようにします。このようにすることで、一時的に変えた設定を共有してしまうことを防げます。

```txt:.gitignore
# Local configuration
local.mk
```

## Natvis の利用

例えばデバッガでポインタを表示したりすると、そのままではアドレスとその値が示す場所の値だけが表示されてしまいます。本当はそこから隣の `size_t lenght;` 分見たいんだけどなぁというときは、通常は GCC を手で操作したりメモリダンプなどを利用したりすることになります。

Natvis は、 VS Code （元々 Visual Studio の機能らしいですが） で、デバッガ上の見え方をカスタマイズするツールで、データ構造を視覚化することができます。

例えば、メモリ上の区間を表す `brange_t` があったとして、

```c
typedef struct {
    uint8_t* ptr;
    const uint8_t* end;
} brange_t;
```

通常では、 `*ptr` と `*end` ぐらいしか見ることができません （一応気を利かせて `uint8_t*` を文字列として表示してくれてはいますが）。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15627/8b31216c-f1e5-7ffa-fea4-850abd36ccaa.png)

下記のように natvis を設定することで、 `ptr` から始まる長さ `end - ptr` の配列として認識させることができます。

```xml:.vscode/default.natvis
<?xml version="1.0" encoding="utf-8"?>
<AutoVisualizer xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010">
    <Type Name="brange_t">
        <DisplayString>{{size = {end - ptr}}}</DisplayString>
        <Expand>
            <Item Name="[size]">end - ptr</Item>
            <ArrayItems>
                <Size>end - ptr</Size>
                <ValuePointer>ptr</ValuePointer>
            </ArrayItems>
        </Expand>
    </Type>
</AutoVisualizer>
```

```json-doc:.vscode/launch.json
    "configurations": [
        {
            "name": "GDB",
            "type": "cppdbg",
            "request": "launch",

            // その他デバッグ起動用のいろいろ

            // .vscode/default.natvis を利用するように設定
            "visualizerFile": "${workspaceRoot}/.vscode/default.natvis",
        }
    ]
```

`[Visualized View]` の表示が新しく追加されています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15627/116a8d0a-744e-ac01-70a5-b99b0f53f752.png)

16 進数や 2 進数で表記したり、 Linked List や HashMap を表現する方法も想定されていて、データ構造を視覚的に確認することができます。　Git の管理対象にすることで、互いの Natvis の定義を共有することができるようになります。

## MkDocs の利用

ドキュメントを Word や Pages ではなく、 [MkDocs](https://www.mkdocs.org/) で管理するようにしました。

さらに CSS/JavaScript を利用することで、視覚的な情報を効率的に表現できます。例えば LED の点灯パターンを解説するドキュメントは、 `div` タグと `data` 属性で表現されており、  CSS と JavaScript で見た目を作っています。

```Markdown
## LED Blinking Pattern

本製品は以下の各状況に応じたパターンで LED を点滅させます。

<div class="blink-pattern">
    <div data-duration-ms="900"></div>
    <div data-duration-ms="100"></div>
</div>

<div class="blink-pattern">
    <div data-duration-ms="100"></div>
    <div data-duration-ms="400"></div>
    <div data-duration-ms="100"></div>
    <div data-duration-ms="400"></div>
</div>
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/15627/ee3fceb0-2dfc-d69e-70d6-8707d019da47.png)

## まとめ

広く応用できそうな部分を前回より具体的に書いてみました。

個人的には、 [GTAC 2014: Move Fast & Don't Break Things](https://youtu.be/j_JviA5nvS0?t=1357) の 22:37 あたりで話しているような Pyramid の状態に近づけたいと考えています。 UI テストに相当する部分は、組込で言うところの実際に動かしてテストする部分です。その前段階を厚くしていくことで、ビジネスの期待に素早く答えながら開発を進めていくことができると考えています。

このような取り組みに興味がございましたら[ぜひ一緒にやっていきましょう](https://qiita.com/organizations/bitkey)！

ちなみにタイトルですが、「組込 1 年目」であって「1 年目のエンジニア」ではないです。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">これだけ長くコード書いてると、もう「一年目」みたいなキーワードを使える機会は滅多に無いわけで、今なら使える！と思ってちょっと嬉しくなった勢いで書きました。</p>&mdash; Masatoshi Tsushima (@utisam) <a href="https://twitter.com/utisam/status/1270717099179032578?ref_src=twsrc%5Etfw">June 10, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>