前回Mbed Online Complierが終了なのでKeil Studio Cloudへ移る以外にオフラインに逃げる方法もあるということでMake-GCC-ARMへのイクスポートをOS2とOS6の両方試したもののコケてました。今回はMbed OS6のプロジェクトのビルドに成功。でも依然としてOS2はダメなのよ～
※「モダンOSのお砂場」投稿順Indexはこちら
Make-GCC-ARMへのイクスポートとその問題、そして解決策
Online Compiler上で、Mbed OS6向けに作成した（勿論動いているもの）プロジェクトを冒頭のアイキャッチ画像のようにExportメニューから Make-GCC-ARMへイクスポート後、make中にコケたのは以下のようでした。
発生個所は、ビルドも結構終わりの方、except.Sなるアセンブラソースをアセンブル始めるという以下のメッセージの後です。
Assemble: except.S
そこで発生したエラーと対策ですが、同じような問題に遭遇した人は以前にもいるようで以下のページで語られてました。エラーメッセージもクリソツ。
Export to GCC missing mbed_config.h #9816
私の方は自作のソースですが、上記は典型的なLチカで起こったみたいです。みんな苦労しているのね。。。
先に解決策を書いておきます。ダウンロードしてきたプロジェクトに含まれているMakefileを１行書き換えてしまうという力技です。以下の#でコメントアウトしてある /filter～プロジェクトにより異なるパス～/mbed_config.h の行を、その下の簡単なものにしてしまう、というだけ。
#ASM_FLAGS += /filer/workspace_data/exports/8/854210f985ae0baffdfe757d6b3df9e2/queueSample/mbed_config.h ASM_FLAGS += ../mbed_config.h
これでビルドが通りました。念のため作成されたオブジェクトを実機(Nucleo-F401RE）に書き込んだところ動作もOK。
ただし、成功したケースには以下条件がつきます。
-
- Windows11上
- arm-none-eabi-チョメチョメの「クロス」ツールチェーンはArm社のサイトからダウンロードした古いバージョン
- makeなどのビルドツールは MSYS2 上のもの
同じプロジェクトファイルでも以下条件では今のところまだ失敗してます。
-
- WSL2上のUbuntu 20.04
- arm-none-eabi-チョメチョメの「クロス」ツールチェーンは apt で入れた上記よりは多少新しいもの
- makeなども apt でいれたもの
MSYS2をインストールしたわけ
一か月くらい前に新しいPCに変えてから、実はMSYS2は入れないで済むならそうしようと考えてきました。理由はWSL2上で「ホンモノ」のUbuntuが動いているしので、Linux系のツールはそちらを呼べばよい、というもの。しかし、今回で気が変わりました。
Windows側のファイルシステムに載っているソースをWSL2側のツールで処理しようとすると、遅い、とっても遅い、という一点。
WSL2の側のファイルシステムにコピーして処理する分にはサクサク動く処理が、/mnt/c/チョメチョメ なるWindows側のファイルシステムへcdして処理してみると、とんでもなく遅かったです。なんやらオーバヘッドがあって遅いという話をどこかで読んだ気がしましたが、１桁以上遅いんじゃないかと感じました。たまにイレギュラーな処理で１ファイル、２ファイル処理する分にはWindows側のファイルシステムを直接Linux側から操作するのは便利ですが、小なりとはいえOSをビルドするのは辛いっす。そこで MSYS2 入れてしまいました。MSYS2は以下に。
これもね、Git for Windows入れるとMSYSついてくるので、そちら一本でできないかと思ったのですが、GitのMSYSはpacmanもついてないみたいなので環境整備が辛そう（やられている方はいるみたいです。）重複でMSYS入れてしまう方がお楽、というだけであります。なんだかな～増え続けるDISKの肥やし。
ツールチェーン
WSL２上にはArmマイコン用のクロスツールを別シリーズMicroPythonのビルドのために整備済です。Windows側には入れてなかったです。今回入れることにしたのは、Mbed CLI 1という、Mbed OS用のコマンドラインツール用のものです。すでにCLI 2という新しいバージョンもあるのですが、OS2などの古いソースに対応できるのはCLI 1 だということで、CLI 1を選択いたしました。しかしCLI 1のインストール、インストーラの「お任せ」でやって大失敗であります。
Python2.7 をインストールされたうえに、システム側のPathの先頭に2.7がいる
いわゆるPathの汚染というやつ？ いまどきPython2.7はやめてくれ。大混乱のもとなので、Pathから外したり余計な手間がかかりました。DISKの肥やし。
なお、arm-none-eabi-チョメチョメのMbedお墨付き版各種バージョンは以下のサイトからダウンロード可能であります。
GNU Arm Embedded Toolchain Downloads
今回当方がWindows上で使っているのは、以下の版（2017年なのでかなり古い）です。
6 2017-q2-update
なお、上記のパッケージのarm-none-eabi-gccのバージョンも古いです。
6.3.1
一方、WSL2上にインストールしてある arm-none-eabi-gccのバージョンは
9.2.1
です。最新版じゃありませんが、CLI 1用よりはかなり新しいです。上記の9.2.1版でMicroPython処理系のクロスビルド(ターゲットは同じF401RE）は成功してますが、online-compilerからダウンロードしたプロジェクトのビルドは失敗してます（最初に説明した問題とはまた異なる理由。）
ビルドして実行
ビルドがうまくいった末尾のところが以下に。
作成された queueSample.hex ファイルをターゲットのNucleo F401REボードに書き込み、仮想シリアル端末を接続したところが以下に。
動作しておりますな。オンライン・コンパイラからの脱走？成功（OS２プロジェクトはまだ失敗中だな。）