Armadillo-900 開発セット では基本的に ATDE という Armadillo 専用開発環境と、 Visual Studio Code (以降 VS Code と記載します) 向け Armadillo 開発用エクステンションを用いてアプリケーション開発を行っていきます。
この節では、アプリケーション開発のために、はじめに開発環境のセットアップを行います。
本節を完了すると、Armadillo を用いた製品の開発に即座に取り組むことができる状態になります。
開発環境のセットアップは、作業用 PC と Armadillo の両方に対して行います。
本節では初めに作業用 PC についてのセットアップを行い、その後に Armadillo についてのセットアップを行います。
そのため、新たに Armadillo を用意した場合や、Armadillo のセットアップをやり直したい方は本節の途中から行うことができます。
後半では Armadillo による開発方法の勝手を大まかに把握したい方を想定して、
Python アプリケーションによる LED 点滅の動作確認を行う項を用意しています。
不要な方はこの項をスキップしてください。
作業用 PC をセットアップします。
アットマークテクノでは、製品のソフトウェア開発や動作確認を簡単に行うために、Oracle VirtualBox 仮想マシンのデータイメージを提供しています。
このデータイメージを ATDE(Atmark Techno Development Environment) と呼びます。
ATDE の起動には仮想化ソフトウェアである VirtualBox を使用します。
![[ティップ]](images/tip.png) | |
---|
Oracle VirtualBoxには以下の特徴があります。 -
基本パッケージが GPLv3(GNU General Public License Version 3) で提供されている
-
VMware形式の仮想ディスク(.vmdk)ファイルに対応している
|
7.1.1.1. VirtualBox のインストール
ATDE を使用するために、作業用 PC に VirtualBox をインストールします。
VirtualBox の Web ページ(https://www.virtualbox.org/) を参照してインストールしてください。
また、ホスト OS が Linux の場合、デフォルトでは VirtualBox で USB デバイスを使用することができません。
ホスト OS(Linux)で以下のコマンドを実行後、ホスト OS を再起動してください。
[PC ~]$ sudo usermod -a -G vboxusers $USER
ホスト OS が Windows の場合はこの操作は必要ありません。
ATDE のアーカイブ(.ova
ファイル)を Armadillo サイト(https://armadillo.atmark-techno.com/resources/software/atde/atde-v9)から
ダウンロードします。
![[注記]](images/note.png) | |
---|
アットマークテクノ製品の種類ごとに対応している ATDE のバージョンが異なります。
本製品に対応している ATDE のバージョンは以下のとおりです。 -
VirtualBox
-
ATDE9 v20240925 以降
|
ATDE9 は Debian GNU/Linux 11 (コードネーム bullseye) をベースに、Armadillo-900 開発セット のソフトウェア開発を行うために必要なクロス開発ツールや、Armadillo-900 開発セット の動作確認を行うために必要なツールが事前にインストールされています。
![[警告]](images/warning.png) | |
---|
作業用 PC の動作環境(ハードウェア、VirtualBox、ATDE の対応アーキテクチャなど)により、 ATDE が正常に動作しない可能性があります。
VirtualBox の Web ページ(https://www.virtualbox.org/) から、
使用している VirtualBox のドキュメントなどを参照して動作環境を確認してください。 |
-
VirtualBox を起動し、[ファイル]-[仮想アプライアンスのインポート]を選択します。
-
[ソース]の項目で、ダウンロードした ATDE のアーカイブ(
.ova
ファイル)を選択します。
-
[設定]の項目で、[ハードドライブをVDIとしてインポート]のチェックを外します。
-
[完了]をクリックします。インポートの処理が完了するまで数分程要します。
-
インポートの処理が完了したら、ホスト OS の環境に合わせた設定に更新するため
仮想マシンを選択して[設定]をクリックした後に[OK]をクリックします。
![[ティップ]](images/tip.png) | |
---|
ATDE に割り当てるメモリおよびプロセッサ数を増やすことで、 ATDE をより快適に使用することができます。
仮想マシンのハードウェア設定の変更方法については、
VirtualBox の Web ページ(https://www.virtualbox.org/) から、
VirtualBox のドキュメントなどを参照してください。 |
-
仮想マシンを選択して[起動]をクリックしてください。
-
ATDE のログイン画面が表示されます。
ATDE にログイン可能なユーザーを、表7.1「ユーザー名とパスワード」に示します []。
表7.1 ユーザー名とパスワード
ユーザー名 | パスワード | 権限 |
---|
atmark
| atmark
| 一般ユーザー |
root
| root
| 特権ユーザー |
7.1.1.5. コマンドライン端末(GNOME端末)の起動
Armadillo を利用した開発では、 CUI (Character-based User Interface)環境を提供するコマンドライン端末を通じて、 Armadillo や ATDE に対して操作を行う場面が多々あります。
コマンドライン端末にはいくつかの種類がありますが、ここではGNOMEデスクトップ環境に標準インストールされているGNOME端末を起動します。
GNOME端末を起動するには、図7.1「GNOME端末の起動」のようにデスクトップ左上のアプリケーションの「ユーティリティ」カテゴリから「端末」を選択してください。
図7.2「GNOME端末のウィンドウ」のようにウィンドウが開きます。
コマンドライン端末から次の操作を行い、ソフトウェアを最新版へアップデートしてください。
VirtualBoxは、ゲストOS (ATDE)による取り外し可能デバイス(USBデバイスやDVDなど)の使用をサポートしています。
デバイスによっては、ホストOS (VirtualBoxを起動しているOS)と ATDE で同時に使用することができません。
そのようなデバイスを ATDE で使用するためには、ATDE にデバイスを接続する 図7.4「ATDE にデバイスを接続する」 の操作が必要になります。
7.1.1.8. VirtualBox Guest Additions の再インストール
ATDE は VirtualBox 仮想マシン用ソフトである VirtualBox Guest Additions があらかじめインストールされた状態で配布されています。
Guest Additions のバージョンは VirtualBox 自体のバージョンと連動しているため、
お使いの VirtualBox のバージョンと ATDE にインストール済みの Guest Additions のバージョンが異なる場合があります。
VirtualBox と Guest Additions のバージョンが異なることによって問題が起こる可能性は低いですが、
これに起因すると思われる不具合(ATDEの画面・共有フォルダー・クリップボード等の不調)が発生した場合は、
以下の手順を参考に Guest Additions を再インストールしてください。
(実行前に ATDE のスナップショットを作成しておくことを推奨します)
-
ATDE を起動後、上部バーの[デバイス]-[Guest Additions CD イメージの挿入]を選択してください。
-
お使いの VirtualBox と同じバージョンの
VBox_GAs_[VERSION]
が「ファイル」上に表示されます。
-
VBox_GAs_[VERSION]
をマウントするために、「ファイル」から VBox_GAs_[VERSION]
を押下してください。
インストールする前に、以下のコマンドで既にインストール済みの Guest Additions をアンインストールします。
sudo /opt/VBoxGuestAdditions-[VERSION]/uninstall.sh
以下のコマンドでお使いの VirtualBox のバージョンに合った Guest Additions がインストールされます。
cd /media/cdrom0
sudo sh ./autorun.sh
ホスト OS と ATDE 間でファイルを受け渡す手段として、共有フォルダーがあると大変便利です。
ここでは、ホスト OS と ATDE 間の共有フォルダを作成する手順を紹介しますが、
不要な方はこの手順をスキップしてください。
追加した共有フォルダーは、図7.8「「ファイル」に表示される共有フォルダー」のように「ファイル」からアクセスするか、
または /media/sf_share(共有フォルダー名)
からアクセスできます。
( share
というフォルダー名で作成すると、ATDE上では sf_share
として表示されます。)
作業用 PC のセットアップです。
Armadillo-900 開発セット の開発には、 VS Code を使用します。
ATDE のバージョン v20230123 以上には、 VS Code がインストール済みのため新規にインストールする必要はありませんが、
使用する前には図7.3「ソフトウェアをアップデートする」にしたがって最新版へのアップデートを行ってください。
以下の手順は全てATDE上で実施します。
VS Code を起動するために code
コマンドを実行するか、「アプリケーション」の中から「Visual Studio Code」を探して起動してください。
![[ティップ]](images/tip.png) | |
---|
VS Code を起動すると、日本語化エクステンションのインストールを提案してくることがあります。
その時に表示されるダイアログに従ってインストールを行うと VS Code を日本語化できます。 |
7.1.2.2. VS Code に開発用エクステンションをインストールする
VS Code 上でアプリケーションを開発するために、
ABOSDE (Armadillo Base OS Development Environment) というエクステンションをインストールします。
エクステンションはマーケットプレイスからインストールすることができます。
VS Code を起動し、左サイドバーのエクステンションを選択して、検索フォームに「abos」と入力してください。
表示された「Armadillo Base OS Development Environment」の 「Install」ボタンを押すとインストールは完了します。
7.1.3. Armadillo に初期設定をインストールする
次に、 Armadillo に初期設定( initial_setup.swu
)をインストールします。
initial_setup.swu
はログインパスワードやユーザー固有の証明書などの
初期設定を Armadillo にインストールするためのファイルです。
initial_setup.swu
でインストールされるユーザー固有の証明書がない場合、
ユーザーが開発したアプリケーションをインストール、またはアップデートすることができません。
このため開発前に、初期化された Armadillo に initial_setup.swu
をインストールする必要があります。
初期化された Armadillo に対してユーザーが開発したアプリケーションのインストール・アップデートを行うために必須の手順になりますので、
必ず行ってください。
ここでは、 initial_setup.swu
を VS Code で作成し、 ABOS Web で Armadillo にインストールします。
7.1.3.1. initial_setup.swu
の作成
図7.11「initial_setup.swu
を作成する」 に示すように、VS Code の左ペインの [COMMON PROJECT COMMAND] から [Generate Initial Setup Swu] を実行してください。
初回実行時には各種設定の入力を求められます。
入力する設定の内容を 図7.12「initial_setup.swu 初回生成時の各種設定」 に示します。
なお、この後の
Python アプリケーション
による動作確認では ABOS Web を使用した手順を記載しています。
この後の手順通りに動作確認を行いたい場合は、ABOS Web のパスワードを設定してください。
|
COMMON_NAME には証明鍵の「common name」として会社や製品が分かるような任意の名称を入力してください。
|
|
証明鍵を保護するパスフレーズを2回入力します。
|
|
SWUイメージ自体を暗号化する場合に「y」を入力します。
詳細は 「SWUpdate と暗号化について」 を参考にしてください。
|
|
アットマークテクノのアップデートをインストールしない場合は「n」を入力します。
|
|
rootのパスワードを2回入力します。
使用するパスワードは以下のルールに従ってください。
-
辞書に載っている言葉を使用しない
-
単調な文字列を使用しない
-
8文字以上のパスワード長にする
|
|
atmarkユーザーのパスワードを2回入力します。
何も入力しない場合はユーザーをロックします。
使用できるパスワードの制限はrootと同様です。
|
|
自動アップデートを無効のままで進みます。ここで「y」を入れると、定期的に
アットマークテクノのサーバーからアップデートの有無を確認し、自動的にインストールします。
|
|
abos-webを使用する場合はパスワードを設定してください。
ここで設定したパスワードは abos-web から変更できます。
使用できるパスワードの制限はrootと同様です。
詳細は 「ABOS Web のパスワード変更」 を参考にしてください。
|
|
作成したファイルを確認します。「swupdate.aes-key」は暗号化の場合にのみ作成されます。
|
ファイルは ~/mkswu/initial_setup.swu
に保存されます。
7.1.3.2. initial_setup.swu
を Armadillo にインストール
上の手順で作成した SWU イメージ(initial_setup.swu
)を Armadillo へインストールします。
インストール方法は様々ありますが(「SWU イメージのインストール」)、ここでは ABOS Web を使用した手動インストールを行います。
ABOS には ABOS Web という機能が含まれています。
この機能を活用することで、 Web ブラウザからネットワークの設定や、 SWU イメージのインストールなどを簡単に行うことができます。
(ただし、Armadillo と作業用 PC が同一 LAN 内に存在している必要があります)
以下の手順に沿って、 ABOS Web へアクセスし、initial_setup.swu
のインストールを行ってください。
まず、 図7.13「ABOSにアクセスするための接続」 のとおりに Armadillo に配線を行い、電源を入れてください。
-
-
Armadillo-900 開発セット
-
-
ACアダプタ(12V/2.0A)
-
-
作業用 PC
-
-
LAN HUB
-
-
Ethernetケーブル
-
-
起動デバイス設定スイッチ
1分ほど待機して、ABOSDE でローカルネットワーク上の Armadillo をスキャンします。
図7.14「ABOSDE で ローカルネットワーク上の Armadillo をスキャンする」 の赤枠で囲われているボタンをクリックしてください。
Armadillo が正常に起動していた場合、図7.15「ABOSDE に表示されている Armadillo を更新する」 の一覧に起動した Armadillo が armadillo.local という名称で表示されます。
表示されない場合は1分ほど待機してから図7.15「ABOSDE に表示されている Armadillo を更新する」の赤枠で囲われているマークをクリックしてスキャンを再度試みてください。
ただし、ATDE のネットワークをブリッジ接続以外に設定している場合は Armadillo がリストに表示されない場合があります。表示するためにはATDE のネットワークをブリッジ接続に設定してください。
また、ABOS Web が動作する Armadillo が同じ LAN 上に複数あると、ABOS Web に接続する URL のホスト名部分(armadillo.local)が、2台目では armadillo-2.local、3台目では armadillo-3.local のように、違うものが自動的に割り当てられます。
目的の Armadillo がどのホスト名なのか不明な場合には、Armadillo のラベルに記載されているMACアドレスと一致するもの( 図7.16「ABOSDE を使用して ABOS Web を開く」 の赤枠に表示されます )を探してください。
また、 Armadillo を社内LANやインターネットに直接に接続できないなどの場合は、
ATDE を社内LAN(インターネット)に接続しながら Armadillo とリンクローカルアドレスで1対1の接続を行うこともできます。
詳細はブログ 「Armadillo Base OS:Armadilloをインターネットに繋げない環境でのソフトウェア開発を行うために」をご参照ください。
続いて、図7.16「ABOSDE を使用して ABOS Web を開く」 の赤枠で囲われているマークをクリックして、
ABOS Web を Web ブラウザで開きます。
ABOS Web が正常に起動していれば、Web ブラウザに パスワード登録画面( 図7.17「パスワード登録画面」 )が表示されます。
initial_setup.swu
を作成する手順で設定したパスワードを入力して、ABOS Web のログイン用パスワードを設定します。
パスワード登録画面で、"パスワード" フィールドと "パスワード(確認)" フィールドに、登録したいパスワードを入力してから、"登録" ボタンをクリックしてください。
パスワード登録完了画面が表示されたら、パスワード登録の完了です。
パスワード登録完了画面にある "ログインページ" というリンクをクリックすると、ログイン画面が表示されますので、先ほど登録したパスワードを入力して "ログイン" ボタンをクリックしてください。
ログインに成功すると、ABOS Web の設定画面( 図7.20「トップページ」 )に表示が変わり、設定操作を行うことができます。
これで、ABOS Web へのアクセスが完了しました。
7.1.3.4. ABOS Web から initial_setup.swu
をインストール
ABOS Web のトップページから"SWU インストール"をクリックして、 図7.21「SWU インストール」 の画面に遷移します。
"参照…"から ~/mkswu/initial_setup.swu
を選択し、"インストール"をクリックしてください。
数分ほど待機すると 図7.22「SWU インストールに成功した画面」 のように"インストールが成功しました。"と表示され、Armadillo が再起動します。
(ABOS Web も再起動されるので、再起動完了後にページを更新するとログイン画面に戻ります)
これで Armadillo に初期設定をインストールする手順が完了です。
インストール完了後に ~/mkswu ディレクトリ以下にある mkswu.conf
と、鍵ファイルの swupdate.*
をなくさないようにしてください。
![[ティップ]](images/tip.png) | ABOS Web にブラウザから直接アクセスする |
---|
ABOSDE を使わずに、 直接 Web ブラウザのアドレスバーに ABOS Web のURLを入力することでも ABOS Web にアクセスできます。
ATDE で Web ブラウザを起動した後、Web ブラウザのアドレスバーに次の URL を入力してください: https://armadillo.local:58080 複数台の Armadillo が接続されている場合には、armadillo.local の部分が armadillo-2.local や armadillo-3.local となっている可能性があります。
これらは ABOSDE のリストに表示されているホスト名と同名ですので、目的の Armadillo と一致するホスト名を入力してください。 また、Web ブラウザから直接アクセスする方法では、ホスト名ではなくIPアドレスを指定することもできます。
例えば、Armadillo の(ネットワークコネクタの)IPアドレスが 192.0.2.80 である場合は、次の URL を入力してください: https://192.0.2.80:5808 IPアドレスを固定している場合はIPアドレスを指定する方法が便利になる場面もあります。
また、IPアドレスを指定する方法は ATDE のネットワークを NAT に設定している場合でも有効です。 |
![[ティップ]](images/tip.png) | ABOS Web からログアウトする |
---|
ログアウトを行う場合は、サイドメニューから "ログアウト" を選択してください。
ログアウトすると、ログイン画面が再び表示されますので、ABOS Web をすぐに使わないのであれば、Web ブラウザを閉じてください。 |
7.1.4. Python アプリケーションで動作確認する
本項では LEDを点滅させる Python のサンプルアプリケーションを使用して、
Armadillo による開発方法の勝手を大まかに把握したい方を想定した簡単な動作確認を行います。
なお、開発環境のセットアップに直接関わる手順ではないので、この動作確認が不要な方は本項をスキップしてください。
Armadillo でのアプリケーションの開発には ABOSDE を使用します。
VS Code の左ペインの [A9E] から [Python New Project] を実行(右に表示されている三角形ボタン)し、表示されるディレクトリ選択画面からプロジェクトを保存する
ディレクトリを選択してください。
保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。
この操作により、選択した保存先に、入力したプロジェクト名と同名のディレクトリが作成されます。
また、ここでは次のように設定しています。
-
保存先 : ホームディレクトリ
-
プロジェクト名 :
my_project
プロジェクトを作成したら、VS Code で my_project
のディレクトリを開いてください。
プロジェクトを作成する度に、初期設定を行う必要があります。
初期設定では主に Armadillo と SSH で接続するための秘密鍵と公開鍵の生成を行います。
以下の手順を実施してください。
VS Code の左ペインの [my_project] から [Setup environment] を実行します。
選択すると、 VS Code の下部に以下のようなターミナルが表示されます。
このターミナル上で以下のように入力してください。
|
パスフレーズを設定します。設定しない場合は何も入力せず Enter を押します。
|
|
1 でパスフレーズを設定した場合は、確認のため再度入力してください。
|
|
ここで何か任意のキーを押すとターミナルが閉じます。
|
パスフレーズを設定した場合は、アプリケーションを Armadillo へ転送する時にパス
フレーズの入力を求められることがあります。
![[ティップ]](images/tip.png) | |
---|
ssh の鍵は $HOME/.ssh/id_ed25519_vscode (と id_ed25519_vscode.pub ) に保存されていますので、
プロジェクトをバックアップする時は $HOME/.ssh も保存してください。 |
7.1.4.3. アプリケーション実行用コンテナイメージの作成
Armadillo 上でアプリケーションを実行するためのコンテナイメージを作成します。
ここで作成したコンテナイメージは SWU イメージを使用して Armadillo へインストールします。
コンテナイメージの作成および SWU イメージの作成も VS Code で行います。
VS Code の左ペインの [my_project] から [Generate development swu] を実行します。
コンテナイメージの作成にはしばらく時間がかかります。
VS Code のターミナルに以下のように表示されるとコンテナイメージの作成は完了です。
作成した SWU イメージは my_project
ディレクトリ下に development.swu
という
ファイル名で保存されています。
7.1.4.4. アプリケーション実行用コンテナイメージのインストール
上で作成した development.swu
を Armadillo へインストールします。
initial_setup.swu
をインストールしたときと同様に ABOS Web からインストールさせることも可能ですが、
ここでは ABOSDE を使用してインストールする手順をご紹介します。
図7.30「ABOSDE で Armadillo に SWU をインストール」 のように、目的の Armadillo の隣にある赤枠で囲まれているボタンをクリックしてください。
パスワードの入力を要求されますので、ABOS Web のパスワードを入力してください。
その後、 ~/my_project/development.swu
を選択してインストールを開始します。
インストールが成功すると、VS Code のターミナルに Successfully installed SWU
と表示されます。
インストール後に自動で Armadillo が再起動し、1分ほど待機するとLED が点滅します。
7.1.4.5. ssh
接続に使用する IP アドレスの設定
以下の手順にしたがい、
ABOS Web が動作している Armadillo の一覧を確認し、
ssh 接続に使用する Armadillo の IP アドレスを指定してください。
なお、この手順は Armadillo の IP アドレス が変更される度に行う必要があります。
図7.14「ABOSDE で ローカルネットワーク上の Armadillo をスキャンする」 の赤枠で囲われているボタン、
または 図7.15「ABOSDE に表示されている Armadillo を更新する」 の赤枠で囲われているマークをクリックして、
ローカルネットワーク上で ABOS Web が実行されている Armadillo をスキャンしてください。
その後、目的の Armadillo について、図7.31「ABOSDE を使用して ssh 接続に使用する IP アドレスを設定する」 の赤枠で囲われているマークをクリックしてください。
これにより、指定した Armadillo の IP アドレスを ssh 接続に使用する IP アドレスに設定することができます。
また、プロジェクトディレクトリ内の config/ssh_config
ファイルに指定した Armadillo の IP アドレスが記載されます。
ATDE のネットワークを NAT に設定している場合や、ABOS Web を起動していない場合等、
ABOSDE のリストに Armadillo が表示されない場合は、
プロジェクトディレクトリに入っている config/ssh_config
ファイルを編集して
IP アドレスを書き換えてください。
|
Armadillo の IP アドレスに置き換えてください。
|
![[ティップ]](images/tip.png) | |
---|
Armadillo を初期化した場合や、プロジェクトを実行する Armadillo を変えた場合は,
プロジェクトの config/ssh_known_hosts に保存されている公開鍵で Armadillo を認識できなくなります。
その場合はファイルを削除するか、「Setup environment」タスクを再実行してください。 |
VS Code の左ペインの [my_project] から [App run on Armadillo] を実行すると、
アプリケーションが Armadillo へ転送されて起動します。
VS Code のターミナルに以下のメッセージが表示されることがあります。
これが表示された場合は yes
と入力して下さい。
アプリケーションを終了するには VS Code の左ペインの [my_project] から [App stop on Armadillo] を実行してください。
動作確認として使用した Python アプリケーションを削除します。
ABOSDE から Armadillo のコンテナイメージを全て削除する SWU イメージを作成します。
この方法はコンテナイメージを全て削除する方法ですので、開発中に複数のコンテナイメージを使用している場合などはそれらも削除されることに注意してください。
VS Code の左ペインの [COMMON PROJECT COMMAND] から [Generate Container Clear Swu] を実行すると、SWU イメージが作成されます。
SWU イメージは ~/mkswu/container_clear.swu
に保存されます。
この SWU イメージを Armadillo へインストールします。
図7.30「ABOSDE で Armadillo に SWU をインストール」 のように、目的の Armadillo の隣にある赤枠で囲まれているボタンをクリックしてください。
パスワードの入力を要求されますので、ABOS Web のパスワードを入力してください。
その後、 ~/mkswu/container_clear.swu
を選択してインストールを開始します。
インストール後に自動で Armadillo が再起動し、LED が点滅しなくなります。
以上で開発環境のセットアップと動作確認の手順は終了です。
7.3. 開発前に知っておくべき Armadillo Base OS の機能・特徴
「Armadillo Base OSとは」にて Armadillo Base OS についての概要を紹介しましたが、開発に入るにあたってもう少し詳細な概要について紹介します。
7.3.1. 一般的な Linux OS 搭載組み込み機器との違い
Linux OS 搭載組み込み機器ではアプリケーションの実行環境をユーザーランド上に直接用意し、Systemdなどでアプリケーションを自動実行させるのが一般的です。
Armadillo Base OS 搭載機器では、アプリケーションの実行環境をコンテナ内に用意して、コンテナ起動用設定ファイルを所定の場所に配置することでコンテナ(=アプリケーション)を自動実行させます。
また、Linux OS 搭載組み込み機器では、ストレージの保護のために overlayfs で運用するのが一般的です。
そのため、アプリケーションが出力するログや画像などのデータは、 USBメモリなどの外部デバイスに保存する必要があります。
Armadillo Base OS 搭載機器もルートファイルシステムが overlayfs 化されていますが、内部に USBメモリなどと同じように使用できるユーザーデータディレクトリを持っており、別途外部記録デバイスを用意しておく必要はありません。
Armadillo Base OS 搭載機器は、標準でセキュアエレメントを搭載しており、対応した暗号化方式の認証鍵や証明書を安全に保存・利用することが可能です。
7.3.2. Armadillo Base OS 搭載機器のソフトウェア開発手法
Armadillo Base OS 搭載機器上で動作するソフトウェアの開発は、基本的に作業用PC上で行います。
ネットワークの設定は ABOS Web という機能で、コマンドを直接打たずとも設定可能です。
開発環境として、ATDE(Atmark Techno Development Environment)という仮想マシンイメージを提供しています。
その中で、ABOSDE(Armadillo Base OS Development Environment)という、Visual Studio Code にインストールできる開発用エクステンションを利用してソフトウェア開発を行います。
ABOSDE を使用することで、コンテナ及びコンテナ自動起動用設定ファイルの作成、コンテナ内におけるパッケージのインストール、コンテナ内で動作するアプリケーション本体の開発をすべてVS Code内で行うことができます。
Armadillo-900 開発セット では、開発・製造・運用時にソフトウェアを書き込む際に、 SWUpdate という仕組みを利用します。
SWUpdateは、デバイス上で実行されるプログラムで、ネットワーク/ストレージ経由でデバイスのソフトウェアを更新することができます。
Stefano Babic, DENX software engineering, Germany によってオープンソースで開発が進められています。
Armadillo-900 開発セット では、 SWUpdateを利用することで次の機能を実現しています。
-
機密性、完全性、真正性の担保
-
A/Bアップデート(アップデートの二面化)
-
リカバリーモード
-
ソフトウェアの圧縮、暗号化、署名付与
-
Armadillo Twin でのリモートアップデート対応
-
Web サーバーでのリモートアップデート対応
-
ダウングレードの禁止
![[注記]](images/note.png) | |
---|
2024年2月までは、hawkBit の WebUI を利用したアップデートも紹介していましたが、
hawkBit は 2024年3月22日 に行われたバージョン 0.5.0 へのアップデートで、
これまで採用していた Web UI を廃止しました。
これに伴い、今後 OTA によるアップデートを行いたい場合は、
Armadillo Twin の利用を推奨します。 なお、hawkBit 0.4.1 の配布は継続していますので、こちらを利用する場合は
Armadillo-900 開発セット 開発用ツール から
「Hawkbit docker-composeコンテナ」 をダウンロードして展開してください。 hawkBit に関する詳細な情報は
hawkBit 公式サイト を参照してください。 |
swuパッケージは、SWUpdate独自のソフトウェアの配布フォーマットです。
SWUpdateでは、1回のアップデートは1つのswuパッケージで行われます。
swuパッケージには、次のような様々なものを含めることができます。
-
アップデート対象のイメージファイル
-
アップデート対象のイメージファイルのチェックサム
-
アップデート前後に実行するスクリプト
-
書き込み先ストレージの情報
-
U-Boot 環境変数の書き換え情報
-
ソフトウェアのバージョン情報
-
etc…
SWU イメージは swupdate
(https://sbabic.github.io/swupdate/swupdate.html) によって Armadillo Base OS上で検証とインストールが実行されます。
SWU イメージを Armadillo に転送するための方法は、用途や状況に合わせて様々な方法を用意しています。例えば、 USB メモリから読み取る、ウェブサーバーからダウンロードするなどです。
ユーザーは SWU イメージをネットワーク/ストレージ経由で Armadillo にインストールします。
インターネットを通じて Armadillo にインストールする場合、以下の脅威が存在することが考えられます。
-
攻撃者が正規のユーザーを偽りデータをインストールする(なりすまし)
-
データの一部を悪意のあるコードに書き換えられる(改ざん)
-
データを盗み見される(盗聴)
Armadillo Base OS では暗号化技術、SHA-256 によるハッシュ化、デジタル署名を駆使することで、インストールするデータに対する機密性、完全性、真正性を保証します。
それらの機能は SWUpdate によって実現しています。
SWUpdate は以下の対策を提供します。
-
SWU イメージ内の Armadillo にインストールするデータを暗号化する
-
デジタル署名により正規の SWU イメージであることを保証する
-
復号したデータに対してもチェックサムの値を計算して、インストールするデータが正しいことを保証する
これらの対策により、たとえ攻撃者が不正な SWU イメージを Armadillo に送信したとしてもデジタル署名により正規の SWU イメージでないことが分かります。
攻撃者がインターネット上で SWU イメージ内のデータを書き換えたとしても、インストール前にそのデータに対してチェックサムが正しいかを確認します。
そのため、不正なデータが Armadillo にインストールされることはありません。
また、攻撃者がネットワーク上で SWU イメージのデータを盗み見たとしても暗号化されているので、重要なデータが漏洩することもありません。
7.3.3.4. A/Bアップデート(アップデートの二面化)
A/B アップデートは、
Flash メモリにパーティションを二面確保し、
アップデート時には交互に利用する仕組みです。
常に使用していない方のパーティションを書き換えるため次の特徴を持ちます。
-
○ アップデートによって動作中のソフトウェアは破壊されない
-
○ 書き込みが電源断などで中断しても、すぐに復帰出来る
-
○ 機器が動作中に書き込みが出来る
-
× 使用Flashメモリ量が増える
アップデート直後に起動に失敗した場合、起動可能な状態へ復帰するためアップデート前の状態にロールバックします。
ロールバック状態の確認は 「ロールバック状態を確認する」 を参照してください。
自動ロールバックが動作する条件は以下の通りです:
-
アップデート直後の再起動、または「
abos-ctrl rollback-clone
」コマンドを実行した後(アップデートが成功した後では古いバージョンに戻りません)
以下のどちらかに該当した場合:
-
rootfs にブートに必要なファイルが存在しない
(/boot/Image, /boot/armadillo.dtb)
-
起動を 3 回試みて、Linux ユーザーランドの「reset_bootcount」サービスの起動まで至らなかった
また、ユーザースクリプト等で「abos-ctrl rollback」コマンドを実行した場合にもロールバック可能となります。
このコマンドで「 --allow-downgrade
」オプションを設定すると古いバージョンに戻すことも可能です。
いずれの場合でもロールバックが実行されると /var/at-log/atlog
にログが残ります。
![[注記]](images/note.png) | |
---|
Armadillo Base OS 3.19.1-at.4 以前のバージョンではアップデート直後の条件が存在しなかったため、古いバージョンに戻ることができる問題がありました。 最新の Armadillo Base OS へのアップデートを推奨しますが、上記バージョン以前の Armadillo Base OS をご利用でダウングレードを防ぎたい場合は、以下のコマンドを入力することで回避可能です: [armadillo ~]# sed -i -e 's/fw_setenv bootcount/& \&\& fw_setenv upgrade_available/' /etc/init.d/reset_bootcount
[armadillo ~]# tail -n 3 /etc/init.d/reset_bootcount
fw_setenv bootcount && fw_setenv upgrade_available
eend $? "Could not set bootloader env"
}
[armadillo ~]# persist_file -v /etc/init.d/reset_bootcount
'/mnt/etc/init.d/reset_bootcount' -> '/target/etc/init.d/reset_bootcount' |
イメージをインストールする方法として以下に示すような方法があります。
手元でイメージをインストールする方法
-
ABOS Web を使用した手動インストール
-
ABOSDE から ABOS Web を使用した手動インストール
-
USBメモリまたは microSD カードからの自動インストール
-
外部記憶装置からイメージのインストール(手動)
リモートでイメージをインストールする方法
-
Armadillo Twin を使用した自動インストール
-
ウェブサーバーからイメージのインストール(手動)
-
ウェブサーバーからの定期的な自動インストール
それぞれのインストール方法の詳細については、以下に記載しております。
もし、作成した SWU イメージのインストールに失敗する場合は、「swupdate がエラーする場合の対処」をご覧ください。
ABOS Web を使用した手動インストール
Armadillo-900 開発セット で動作している Web アプリケーションのABOS Webを使用してアップデートすることができます。
「SWUインストール」を参考にしてください。
ABOSDE から ABOS Web を使用した手動インストール
VS Code 拡張機能の ABOSDE を使用することで、Armadillo-900 開発セット で動作している ABOS Web 経由でアップデートすることができます。
「Armadillo に SWU をインストールする」を参考にしてください。
USBメモリまたはmicroSDカードからの自動インストール
Armadillo-900 開発セットにUSBメモリを接続すると自動的にアップデートが始まります。
アップデート終了後にArmadillo-900 開発セットは自動で再起動します。
USBメモリやmicroSDカードをvfatもしくはext4形式でフォーマットし、作成した.swuのファイルをディレクトリを作らずに配置してください。
[ATDE ~/mkswu]$ df -h
Filesystem Size Used Avail Use% Mounted on
: (省略)
/dev/sda1 15G 5.6G 9.1G 39% /media/USBDRIVE
[ATDE ~/mkswu]$ cp initial_setup.swu /media/USBDRIVE/
[ATDE ~/mkswu]$ umount /media/USBDRIVE 
|
USBメモリがマウントされている場所を確認します。
|
|
ファイルをコピーします。
|
|
/media/USBDRIVEをアンマウントします。コマンド終了後にUSBメモリを取り外してください。
|
エラーの場合、/var/log/messageに保存されます。例えば、コンソールで証明書が間違っているイメージのエラーは以下の様に表示されます。
[armadillo ~]# tail /var/log/messages
Nov 19 10:48:42 user.notice swupdate-auto-update: Mounting sda0 on /mnt
Nov 19 10:48:42 user.notice swupdate-auto-update: Trying update /mnt/initial_setup.swu
Nov 19 10:48:42 user.info swupdate: START Software Update started !
Nov 19 10:48:42 user.err swupdate: FAILURE ERROR : Signature verification failed
Nov 19 10:48:42 user.err swupdate: FAILURE ERROR : Compatible SW not found
Nov 19 10:48:42 user.err swupdate: FATAL_FAILURE Image invalid or corrupted. Not installing ...
|
証明書エラーのメッセージ。
|
外部記憶装置からイメージのインストール(手動)
USBメモリやmicroSDカード等の外部記憶装置のルートディレクトリ以外にSWUイメージを保存して、イメージのインストールを行います。
ルートディレクトリに保存すると自動アップデートが行われますので、/var/log/messagesを確認してください。
以下は外部記憶装置が/dev/mmcblk2p1(microSDカード)として認識された場合に、イメージのインストールを行う例です。
[armadillo ~]# mount /dev/mmcblk2p1 /mnt
[armadillo ~]# swupdate -i /mnt/swu/initial_setup.swu
SWUpdate v5f2d8be-dirty
Licensed under GPLv2. See source distribution for detailed copyright notices.
[INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1
[INFO ] : SWUPDATE started : Software Update started !
[INFO ] : SWUPDATE running : [read_lines_notify] : No base os update: copying current os over
[INFO ] : SWUPDATE running : [read_lines_notify] : Removing unused containers
[INFO ] : SWUPDATE running : [read_lines_notify] : swupdate triggering reboot!
Killed
Armadillo Twin を使用した自動インストール
Armadillo Twin で Armadillo-900 開発セット を複数台管理してアップデートすることができます。
「Armadillo Twin から複数の Armadillo をアップデートする」を参考にしてください。
ウェブサーバーからイメージのインストール(手動)
SWUイメージをウェブサーバーにアップロードして、イメージのインストールを行います。
以下は、http://server/initial_setup.swu のイメージをインストールする例です。
[armadillo ~]# swupdate -d '-u http://server/initial_setup.swu'
SWUpdate v5f2d8be-dirty
Licensed under GPLv2. See source distribution for detailed copyright notices.
[INFO ] : SWUPDATE running : [main] : Running on AGX4500 Revision at1
[INFO ] : SWUPDATE running : [channel_get_file] : Total download size is 25 kB.
[INFO ] : SWUPDATE started : Software Update started !
[INFO ] : SWUPDATE running : [read_lines_notify] : No base os update: copying current os over
[INFO ] : SWUPDATE running : [read_lines_notify] : Removing unused containers
[INFO ] : SWUPDATE running : [read_lines_notify] : swupdate triggering reboot!
Killed
ウェブサーバーからの定期的な自動インストール
swupdate-urlを有効にしたら、定期的にチェックしてインストールします。
以下はサービスの有効化とタイミングの設定の例です。
[armadillo ~]# rc-update add swupdate-url
[armadillo ~]# persist_file /etc/runlevels/default/swupdate-url
[armadillo ~]#
echo https://download.atmark-techno.com/armadillo-900/image/baseos-900-latest.swu \
> /etc/swupdate.watch
[armadillo ~]# echo 'schedule="0 tomorrow"' > /etc/conf.d/swupdate-url
[armadillo ~]# echo 'rdelay="21600"' >> /etc/conf.d/swupdate-url
[armadillo ~]# persist_file /etc/swupdate.watch /etc/conf.d/swupdate-url 
|
swupdate-urlサービスを有効します。
|
|
サービスの有効化を保存します。
|
|
イメージのURLを登録します。一行ごとにイメージのURLを設定することができ、複数行にイメージのURLを設定することができます。
|
|
チェックやインストールのスケジュールを設定します。
|
|
変更した設定ファイルを保存します。
|
USBメモリからのアップデートと同様に、ログは/var/log/messagesに保存されます。
![[ティップ]](images/tip.png) | |
---|
initial_setupのイメージを作成の際に /usr/share/mkswu/examples/enable_swupdate_url.desc を入れると有効にすることができます。 |
Armadillo Base OS ではルートファイルシステムに overlayfs を採用しています。
その為、ファイルを変更した後 Armadillo の電源を切ると変更内容は保持されません。
開発中などに rootfs の変更内容を保持するには、変更したファイルに対して persist_file
コマンドを使用します。
persist_file
コマンドの詳細については、「persist_file について」を参照してください。
また、 SWUpdate によってルートファイルシステム上に配置されたファイルについては、 persist_file
を実行しなくても保持されます。
開発以外の時は安全のため、 persist_file
コマンドではなく SWUpdate による更新を実行するようにしてください。
7.3.4.1. 電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)
「ファイルの取り扱いについて」 にて、 Armadillo Base OS 上のファイルは通常、 persist_file
コマンドを実行せずに電源を切ると変更内容が保存されないと紹介しましたが、表7.2「電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)」に示すディレクトリ内にあるファイルはこの限りでありません。
表7.2 電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)
ディレクトリ | 備考 |
---|
/var/app/volumes | SWUpdate の最中や後も保持され続けます。ロールバックが発生しても、アップデート前の状態には戻りません。ログやデータベースなど、アプリケーションが動作中に作成し続けるようなデータはこのディレクトリに保存してください。 |
/var/app/rollback/volumes | SWUpdate の最中や後も保持され続けます。ロールバックが発生すると、アップデート前の状態に戻ります。コンフィグファイルなど、アプリケーションのバージョンに追従してアップデートするようなデータはこのディレクトリに保存してください。 |
![[ティップ]](images/tip.png) | |
---|
コンテナを前のバージョンに戻した場合(ロールバック)、/var/app/rollback/volumes/ のデータの前のバージョンに戻ります。 その為、アプリケーションのバージョンに依存するようなデータは /var/app/rollback/volumes/ に入れることを推奨します。 mkswu の swdesc_files (--extra-os 無し)と podman_start の add_volumes では、相対パスはそのディレクトリをベースにします。
/var/app/rollback/volumes/myvolume は myvolume で簡潔に指定できます。
|
![[警告]](images/warning.png) | |
---|
Copy-on-Write (CoW) について。 この二つの volumes ディレクトリは btrfs と呼ばれるファイルシステムに保存されています。
btrfs ではデータは Copy on Write(CoW)を使ってデータ完全性を保証しますが、その保証にはコストがあります。 数百 MB のファイルに小さな変更を頻繁に行う場合 CoW を無効化することを推奨します。
CoW を無効化されたファイルにチェックサムが入らなくなりますので、極端な場合以外に残してください。
|
chattr +C でディレクトリに NoCow を設定します。これから作成されるファイルが NoCow で作成されます。すでに存在していたファイルに影響ないのでご注意ください。
|
|
lsattr 確認します。リストの C の字があればファイルが「no cow」です。
|
|
インストールディスクは、 Armadillo の eMMC の中身をまとめて書き換えることのできる microSD カードを指します。
インストールディスクは、インストールディスクイメージを microSD カードに書き込むことで作成できます。
インストールディスクには以下の2つの種類があります。
インストールディスクの作成方法は「初期化インストールディスクの作成」を参照してください。
参照先では初期化インストールディスクの場合の手順を示していますが、「Armadilloのソフトウェアをビルドする」 でビルドしたイメージについても同じ手順になります。
その際のインストールディスクイメージ(.img
)は、以下のコマンドを実行して作成してください。
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a900
: (省略)
[ATDE ~/build-rootfs-[VERSION]]$ ls baseos-900*img
baseos-900-[VERSION].img
[ATDE ~/build-rootfs-[VERSION]]$ sudo ./build_image.sh --board a900 \
--boot ~/uboot-[VERSION]/u-boot-dtb.imx \
--installer ./baseos-900-[VERSION].img
コマンドの実行が完了すると、baseos-900-[VERSION]-installer.img というファイルが作成されていますので、
こちらを使用してください。
Armadillo-900 開発セット を用いた製品のソフトウェア設計は、一般的な組み込み開発と基本的には変わりません。
しかし、 Armadillo Base OS という独自OSを搭載しているため、ソフトウェアの設計には特有のポイントがいくつかあります。
本章では、それらの設計時に考慮すべき Armadillo Base OS 特有のポイントについて紹介していきます。
7.4.1. 開発者が開発するもの、開発しなくていいもの
Armadillo Base OS では、組み込み機器において必要になる様々な機能を標準で搭載しています。
図7.40「開発者が開発するもの、開発しなくていいもの」は、 Armadillo Base OS 搭載製品において、開発者が開発するものと開発しなくていいものをまとめた図です。
開発しなくていいものについては設計を考える必要はありません。
開発するものに絞って設計を進めることができます。
![[ティップ]](images/tip.png) | |
---|
拡張ボードを追加するためにデバイスツリーのカスタマイズが必要となる場合は、デバイスツリー(dtbo)の追加が必要となります。 使用するデバイスによっては、Linux カーネルドライバの追加が必要となり、Linux カーネルのカスタマイズが必要となります。 |
Armadillo Base OSでは基本的にユーザーアプリケーションを Podman コンテナ上で実行します。
そのため、実行環境として Armadillo Base OS を意識する必要はありません。
Podmanは、同じくコンテナを扱えるソフトウェアである Docker と基本的に互換性があります。
アットマークテクノでは、アットマークテクノが提供する Debian GNU/Linux ベースのコンテナイメージを提供しておりますが、それ以外のlink:Docker Hub などから使い慣れたディストリビューションのコンテナイメージを取得して開発することができます。
アプリケーションが出力するユーザーデータで保存が必要なものは、「電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)」にも記載があるとおり、 /var/app/volumes/ 以下に配置してください。
色々な場所にデータが保存されていますと Armadillo-900 開発セット の初期化を行う際に削除の処理が煩雑になりますので、 /var/app/volumes/ 以下に集約してください。
7.4.2.3. LTE 通信を使用する場合に考慮すべきこと
LTE 通信は、周辺の状況や工事などによって長時間通信ができなくなる可能性があります。そのため、クラウドやサーバーへ送信すべきデーターを即時に送信できない可能性があります。
データーの再送処理や動作しているコンテナ内にキャッシュする処理を実装して、上記状況に備えてください。
ユーザーアプリケーションのログは、不具合発生時の原因究明の一助になるため必ず残しておくことを推奨します。
ユーザーアプリケーションが出力するログは、「電源を切っても保持されるディレクトリ(ユーザーデータディレクトリ)」にも記載があるとおり、 /var/app/volumes/ 以下に配置するのが良いです。
コンテナの中から /var/app/volumes/ ディレクトリにアクセスすることになります。
手順についての詳細は実際に開発を行う箇所にて紹介します。
Ethernet、LTE、Bluetooth、WLANなどの無線系のログ
一般に不具合発生時によく疑われる箇所なので、最低でも接続・切断情報などのログを残しておくことをおすすめします。
ソフトウェアのバージョン
/etc/sw-versions というファイルが Armadillo Base OS 上に存在します。
これは、 SWUpdate に管理されている各ソフトウェアのバージョンが記録されているファイルです。
このファイルの内容をログに含めておくことで、当時のバージョンを記録することができます。
A/B 面どちらであったか
アップデート後になにか不具合があって、自動的にロールバックしてしまう場合があります。
後でログを確認する際に、当時 A/B 面どちらであったかで環境が大きく変わってしまい解析に時間がかかる場合があるので、どちらの面で動作していたかをログに残しておくことをおすすめします。
図7.41「現在の面の確認方法」に示すコマンドを実行することで、現在 A/B どちらの面で起動しているかを確認できます。
|
この実行結果から今の面は/dev/mmcblk0p1であることが分かります。
|
Armadillo-900 開発セットのウォッチドッグタイマーは、i.MX 8ULPのWDOG(Watchdog Timer)を利用しています。
ウォッチドッグタイマーは、U-Boot によって有効化されます。標準状態でタイムアウト時間は10秒に設定されます。
何らかの要因でウォッチドッグタイマーのキックができなくなりタイムアウトすると、システムリセットが発生します。
ウォッチドッグタイマーの設定変更は、ioctlシステムコール経由で行うことができます。詳細な情報については、Linux カーネルのソースコードに含まれているドキュメント(Documentation/watchdog/watchdog-api.rst)を参照してください。
![[ティップ]](images/tip.png) | |
---|
ウォッチドッグタイマーを停止することはできません。 |
7.4.5. コンテナに Armadillo の情報を渡す方法
Armadillo Base OS からコンテナに環境変数として情報を渡すためにコンテナ起動設定ファイルを使用します。
コンテナ起動設定ファイル(conf ファイル)に関しては「コンテナ起動設定ファイルを作成する」を参照してください。
アットマークテクノが提供する情報を環境変数として渡す
コンテナ起動設定ファイルに add_armadillo_env
を使用してください。
アットマークテクノが設定した LAN1(eth0)の MACアドレス、個体番号などの Armadillo の情報を環境変数としてコンテナに渡します。
add_armadillo_env
については「個体識別情報の環境変数の追加」を参照してください。
任意の情報を環境変数として渡す
コンテナ起動設定ファイルに add_args
を使用してください。
add_args
については「podman run
に引数を渡す設定」を参照してください。
add_args
を下記のように使用することでコンテナに環境変数として情報を渡すことができます。
|
シェルコマンドの出力を環境変数に代入する場合は <値> として $(シェルコマンド) を使用してください。
|
add_args --env
の例を示します。
これにより、コンテナ内の環境変数 MY_ENV
に文字列 my_value
が設定されます。
ABOS Web では以下の要素についてお客様自身で用意したものを使用して
カスタマイズすることができます。
-
ロゴ画像
-
ヘッダロゴアイコン画像
-
ヘッダタイトル
-
favicon 画像
-
背景色
-
メニューの表示名
ABOS Web をお客様の最終製品に組み込む場合、自社のロゴ画像に変更するといったような
使い方ができます。
カスタマイズは、「設定管理」で行うことができます。
![[注記]](images/note.png) | |
---|
カスタマイズは ABOS Web のバージョン 1.3.0 以降で対応しています。 |
ロゴ画像
ログインページや新規パスワード設定画面で表示される画像です。
「ファイルを選択」をクリックしてアップロードしたい画像ファイルを選択してください。
フォーマットは PNG のみで、ファイルサイズは 3MB のものまでアップロードできます。
ヘッダロゴアイコン画像
画面左上に常に表示されている画像です。
「ファイルを選択」をクリックしてアップロードしたい画像ファイルを選択してください。
フォーマットは PNG のみで、ファイルサイズは 3MB のものまでアップロードできます。
ヘッダタイトル
画面左上に常に表示されている文字列です。24文字まで入力できます。
favicon 画像
Web ブラウザのタブなどに小さく表示される画像です。
favicon 画像は以下の種類を favicon
ディレクトリに保存して、
favicon
ディレクトリごと zip 圧縮したものをアップロードしてください。
表7.3 用意する favicon 画像
ファイル名 | 縦横サイズ | 説明 |
---|
android-chrome-192x192.png | 192x192 | スマートフォンのホームに Web ページを追加した時に使用されます。 |
android-chrome-512x512.png | 512x512 | Web ページを開いた時のスプラッシュ画面に使用されます。 |
apple-touch-icon.png | 180x180 | スマートフォンのホームに Web ページを追加した時に使用されます。 |
favicon-16x16.png | 16x16 | Web ブラウザで使用されます。 |
favicon-32x32.png | 32x32 | Web ブラウザで使用されます。 |
mstile-150x150.png | 150x150 | Windows でスタート画面にピン止めしたときに使用されます。 |
背景色
5 種類の中から選択できます。
メニューの表示名
画面左にあるメニューの表示名を変更する、または非表示にすることができます。
「メニュー項目を変更する」をクリックし、変更用ページへ行ってください。
各メニュー項目名と説明を変更することができます。
項目名を空欄にするとそのメニューは非表示になります。
入力し終わったらページ下部の「メニューを設定」をクリックしてください。
画像やメニューの変更後、すぐに Web ブラウザ画面に反映されない場合は、
お使いの Web ブラウザの設定でキャッシュの削除を行ってください。
変更完了後は、「カスタマイズ機能を無効にする」をクリックするとカスタマイズ項目が非表示になり
それ以上カスタマイズできなくなります。お客様の最終製品に ABOS Web を組み込む場合に実行してください。
![[ティップ]](images/tip.png) | |
---|
Armadillo 内の /etc/atmark/abos_web/customize_disable ファイルを削除すると、
再びカスタマイズ項目が表示されるようになります。 |
7.6. ABOS Web から Armadillo の電源を操作する
開発中及び運用中に Armadillo の再起動または電源を切るには、ターミナルでコマンドを実行することでも可能ですが、ABOS Webからも実行可能です。
ABOS Web から Armadillo の電源を操作するには図7.46「「電源制御」の位置」に示すサイドメニューの項目を選択してください。
この項目を選択すると図7.47「「電源制御」の画面」に示す画面が表示されます。
操作可能な機能は以下です。
表7.4 制御できる機能
機能名 | Armadillo内で実行されるコマンド | 説明 |
---|
再起動 | reboot | Armadillo を再起動します。 |
電源オフ | poweroff | Armadillo の電源を切ります。 |
これらの機能を ABOS Web で選択すると、確認画面が表示されます。
よければ「OK」を選択してください。
電源オフを実行した場合、Armadillo の LED が消えるまで電源を抜かないでください。
7.7.1. m33-firmware-at とは
Armadillo-900 シリーズには、Linux を実行する2つの Arm Cortex-A35 コアに加えて、1つの Arm Cortex-M33 コアが搭載されています。
一部の I/O インタフェースは A35 コアからアクセスできないため、
M33 コア上に独自の RTOS ファームウェア「m33-firmware-at」を起動し、
図7.48「Armadillo-900 で使用している i.MX 8ULP の簡易構造」の様にコア間通信を介してLinuxから操作できるようにしています。
m33-firmware-at は主に以下の 3 つの役割を担います。
-
Linux から M33 に接続されている I/O を操作可能にする
-
サスペンド時に消費電力を最適化する
-
必要に応じて任意のコードを RTOS 環境で実行する
本章では、上記の3つ目の任意のコードを m33-firmware-at に追加する方法について解説します。
ブートローダーイメージのソースコードをダウンロード、ビルド、インストールすることで、m33-firmware-at を改造できます。
詳細なビルドとインストール手順は 「ブートローダーをビルドする」 を参照してください。
![[ティップ]](images/tip.png) | |
---|
改造した m33-firmware-at でエラーが発生した場合は HardFault_Handler が実行されて、
デバッグコンソールが有効の場合にデバッグ情報を表示して、
Armadillo をリセットします。 imx-boot 2023.04-at5 以降ではタイミングによって3パターンがあります:
* u-boot SPL 実行中にフォルトすると自動的にロールバックします。SWU で新しいイメージをインストールした場合は自動的に前のバージョンに戻りますので、修正してまたインストールしてください。
* 起動時から 30 秒以内にフォルトした場合は 30 秒まで待ってからリセットします。再起動の繰り返しの場合はそのタイミングで再び更新する形で修正してください。
* 起動時から 30 秒以降の場合はすぐにリセットします。 早いタイミングの自動復帰が失敗する可能性がありますので、起動できなかった場合はインストールディスクで初期化してください。
念の為定期的に 「開発したシステムをインストールディスクにする」 の手順で複製用インストールディスクを作成しておくことを推奨します。 |
ブートローダーの開発前に以下の注意点をご確認ください。
-
ブートローダーを改造すると、 Armadillo が起動しなくなる可能性があります。
ハードウェアの故障でなければ、インストールディスクから復旧可能です。
予め 「初期化インストールディスクの作成」 通りにインストールディスクを作成しておくか、SD カードで開発を行うことを推奨します。
Linux と m33-firmware-at はコア間通信で連携するため、長期間更新されていない状態から片方だけを更新すると正常に動作しない可能性があります。
原則として、常に適合性を維持するように更新を提供しますが、m33-firmware-at のコア部分を更新できるように開発することを推奨します。
m33-firmware-at のソースコードを github に公開していますので、ブートローダーをダウンロードした後 m33-firmware-at を git リポジトリと置き換えると管理しやすくなります。
[ATDE ~]$ tar xf imx-boot-[VERSION].tar.zst
[ATDE ~]$ cd imx-boot-[VERSION]
[ATDE ~/imx-boot-[VERSION]]$ rm -rf m33_firmware_at
[ATDE ~/imx-boot-[VERSION]]$ git clone https://github.com/atmark-techno/m33-firmware-at m33_firmware_at
-
ATDE のストレージ容量を抑えるため、デフォルトでは
gcc-arm-none-eabi
パッケージがインストールされていません。インストールされていない場合は、ソースコードアーカイブに含まれているバイナリが利用されるため、 m33-firmware-at のビルドは行われません。開発前に m33-firmware-at ビルド状態の確認 の手順でビルドできることを確認してください。
m33-firmware-at のファイル構成は以下の通りです。
Linux ドライバーに必要なサービス
Linux ドライバーとの連携は srtm サービスで行います。 app_srtm.c
で初期化処理を行い、各ドライバーの対応は以下のファイルで行います。
-
srtm/services/srtm_*_service.[ch]
: Linux ドライバーからのプロトコル実装
-
app_*.c
: ハードウェア操作の実装
電源と電圧管理
起動時の電圧管理やサスペンド時の消費電力の最適化は main.c
と lpm.c
で行います。
カスタマイズ用ディレクトリ
custom
ディレクトリに任意のコードを実装することで、 m33-firmware-at を容易に変更できます。
以下のサンプルファイルを提供しています。
custom/custom.c
: 起動時、サスペンド前後等のタイミングで実行されるコードを追加できるファイルです。
このファイルの init 処理にコードを追加してアプリケーションを構築できます。 GPIO の設定や FreeRTOS の機能の利用も可能です。
![[注記]](images/note.png) | |
---|
Linux で利用できる機能を m33 側で利用する際は同時に利用しないようにしてください。 GPIO に関しては app_gpio.h の API 通りに利用すれば他の処理は不要です。 他のインタフェースに関しては Linux から利用しないようにするか、各 app_*.c の init 処理で予約してLinuxから利用できないようにしてください。 |
-
custom/cli_custom.c
: デバッグシリアル接続のコマンド追加。
custom/app_tty_custom.c
: Linux の仮想 tty ドライバー。
arch/arm64/boot/dts/freescale/armadillo_900-customize.dts
ファイル等に以下の内容を設定して 「独自の DTS overlay を追加する」 通りにインストールすると、仮想 tty デバイスが生成されます:
&{/} {
aliases {
ttyrpmsg2 = "/m33-custom-uart";
};
m33-custom-uart {
compatible = "fsl,imx-rpmsg-tty-serial";
port_type = <TTY_TYPE_CUSTOM>;
port_name = "custom port"; /* 32文字までの任意文字列 */
};
};
custom_init()
は tty が初期化される時に実行されます。複数のデバイスを生成する場合は port_name で区別できます。
tx/rx は Linux 側から見た名称です。 Linux 側の tty に書き込むと custom_tx()
関数が実行されます。
SRTM_TtyService_NotifyAlloc()
と SRTM_TtyService_NotifySend()
を利用すると Linux にメッセージが送信できます。
ビルドシステム
ビルドシステムは armgcc
ディレクトリにあります。
ファイルを追加する場合は armgcc/CMakeLists.txt
の add_executable
命令に追加してください。
NXP社の mcux-sdk のドライバを追加したい場合は armgcc/config.cmake
を変更してください。
m33-firmware-at のソースコードで PRINTF
を使用して簡易的な解析ができます。
ログの取得については 「RTD用コンソール を使用する」 を参照してください。
シリアル接続後、簡易コンソールで以下のコマンドを利用できます。
-
help
: 利用可能なコマンド一覧
-
log
: ログバッファーの内容を再表示
-
version
: m33-firmware-at のバージョンを表示(git からビルドした場合は git describe
によるタグかコミット情報が記載されます)
md
, mw
: u-boot に似た memory display/write コマンド。こちらのコマンドはデフォルト状態で利用できません。
main.h
で「#define CLI_RAW_MEM
」をコメントアウトしてイメージを更新するとコマンドが追加されます。
-b
, -w
, -l
, -q
オプションで byte (1 byte), halfword (2 bytes), word (4 bytes), double word (8 bytes) を扱えます。
md
にアドレスとアイテム数を指定して、メモリ内容を表示します。mw
にアドレスと値を指定します。
サスペンド関連の解析には、 main.h
の DEBUG_SUSPEND (サスペンド中でもシリアル出力を無効化しない)と DEBUG_SUSPEND_SKIP_JTAG_PINS (サスペンド中に jtag のピンを無効化しない)設定も利用できます。
JTAG デバッガーを利用した解析ができます。
弊社では PALMiCE4 を利用して、以下の機能を確認しています。
詳細はコンピューテックス社の セットアップ説明書 を参照ください。
-
メモリ、レジスターの取得と書き込み
-
ステップ実行・Break(ASM コード、C ソース両方)
-
ローカルまたはグローバル変数の値の取得と変更
-
FreeRTOS のデバッグ機能(タスクやタイマー情報)
以下では Armadillo 固有の情報のみを記載します。
ここに記載の無い内容については、コンピューテックス社にお問い合わせください。
-
Watchdog の無効化。JTAG で break をすると watchdog タイマーによる再起動が発生しますので、JTAG を利用する際に
main.h
ファイルの define DEBUG_DISABLE_WDOG を有効化してください。
C ソースの連携や FreeRTOS のデバッグ機能にはデバッグ情報が必要です。
以下の手順で有効化できます。
|
デバッグビルドの実行。一度実行すると、「 build.sh release 」で無効化するまでは imx-boot ディレクトリの「 make imx-boot_armadillo-900 」コマンドでデバッグビルドが利用されます。
|
|
imx-boot に組み込まれるファームウェアのバイナリ
|
|
デバッガーに提供する ELF ファイル(デバッグ情報あり)
|
-
接続に関しては 「JTAG を使用する」 を参照してください。
7.8. ABOSDEによるアプリケーションの開発
ここでは、ABOSDE(Armadillo Base OS Development Environment) によるアプリケーション開発の概要とABOSDEで作成される各プロジェクトの違いについて説明します。
ABOSDE は Visual Studio Code にインストールできる開発用エクステンションです。
ABOSDE を使用することで、コンテナ及びコンテナ自動起動用設定ファイルの作成、コンテナ内におけるパッケージのインストール、コンテナ内で動作するアプリケーション本体の開発をすべてVS Code内で行うことができます。
ABOSDEでは、以下のようなアプリケーションを開発できます。
-
CUI アプリケーション
-
C 言語アプリケーション
表7.5「ABOSDEの対応言語」に示すように、アプリケーション毎に対応している言語が異なります。
表7.5 ABOSDEの対応言語
アプリケーションの種類 | 使用言語(フレームワーク) |
---|
CUI アプリケーション | シェルスクリプト |
Python |
C言語アプリケーション | C 言語 |
どのようなアプリケーションを開発するかによってABOSDEによる開発手順が異なります。図7.50「参照する開発手順の章を選択する流れ」を参考に、ご自身が開発するアプリケーションに適した章を参照してください。
-
CUI アプリケーション
-
C 言語アプリケーション
対象ユーザー
-
C 言語でないと実現できないアプリケーションを開発したい
-
既存の C 言語によって開発されたアプリケーションを Armadillo で動作させたい
-
開発環境に制約がある
マニュアルの参照先
ここでは Armadillo の性能を最大限に生かした GUI アプリケーションを
作ることのできる Flutter を使った開発方法を紹介します。
![[注記]](images/note.png) | |
---|
i.MX 8ULP には、 H.264 などの動画用のハードウェアデコーダーは搭載されていないため、
アプリケーション内で動画の再生を行うと期待通りのフレームレートでは再生されない可能性があります。 |
Flutterとはモバイルアプリケーションや Web アプリケーションの開発に使われる
GUI アプリケーション開発ツールキットです。
マルチプラットフォームなので、ソースコードの大部分を共通化可能で一度開発したアプリケーションは最小限の工数で別の
プラットフォームへ移植できます。さらに、プラットフォーム間でアプリケーションの見た目も統一することができます。
アプリケーション開発言語として Dart を使用しています。
Flutter を使うことで Armadillo 上でも GUI アプリケーションを開発することができます。
以下は Flutter で開発したアプリケーションを Armadillo 上で動かしている例です。
Armadillo 向けに Flutter アプリケーションを開発する場合の流れは以下のようになります。
ここでは、開発開始時の ATDE 上でのセットアップ手順について説明します。
ATDE をお使いでない場合は、先に 「開発の準備」 を参照して ATDE のセットアップを完了してください。
Flutter アプリケーションのサンプルとして以下を用意しております。
-
Flutter Demo アプリケーション
-
GUI アプリケーション
各プロジェクトは以下のようなアプリケーションの画面となります。
![[警告]](images/warning.png) | |
---|
以降の手順でサンプルアプリケーション毎に VS Code でクリックする箇所や生成されるファイル名等が変わります。 |
VS Code の左ペインの [A900] から [<アプリケーション名> New Project]を実行し、表示されるディレクトリ選択画面からプロジェクトを保存するディレクトリを選択してください。実行するためには右に表示されている三角形ボタンを押してください。
保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。
この操作により、選択した保存先に、入力したプロジェクト名と同名のディレクトリが作成されます。
また、ここでは次のように設定しています。
-
保存先 : ホームディレクトリ
-
プロジェクト名 :
my_project
以下では例として [GUI アプリケーション] の作成を行っています。
初期設定では主に Armadillo と SSH で接続するための秘密鍵と公開鍵の生成を行います。
作成したプロジェクトディレクトリへ移動して VS Code を起動してください。
VS Code の左ペインの [my_project] から [Setup environment] を実行します。
選択すると、 VS Code の下部に以下のようなターミナルが表示されます。
このターミナル上で以下のように入力してください。
|
パスフレーズを設定します。設定しない場合は何も入力せず Enter を押します。
|
|
ここで何か任意のキーを押すとターミナルが閉じます。
|
パスフレーズを設定した場合は、アプリケーションを Armadillo へ転送する時にパス
フレーズの入力を求められることがあります。
7.9.3.4. アプリケーション実行用コンテナイメージの作成
Armadillo 上でアプリケーションを実行するためのコンテナイメージを作成します。
ここで作成したコンテナイメージは SWU イメージを使用して Armadillo へインストールするため、
事前に mkswu を参照して SWU の初期設定を行ってください。
コンテナイメージの作成および SWU イメージの作成も VS Code で行います。
VS Code の左ペインの [my_project] から [Generate development swu] を実行します。
コンテナイメージの作成にはしばらく時間がかかります。
VS Code のターミナルに以下のように表示されるとコンテナイメージの作成は完了です。
作成した SWU イメージは my_project
ディレクトリ下に development.swu
という
ファイル名で保存されています。
使用するコンテナのディストリビューションは以下のとおりです。
7.9.5. Armadillo に転送するディレクトリ及びファイル
コンテナイメージ以外に、以下に示すディレクトリやファイルを Armadillo に転送します。
ここでは、プロジェクト名は my_project
としています。
-
Armadillo に転送するディレクトリ及びファイル
-
my_project/swu/app
-
my_project/app/build/elinux/arm64/[debug または release]/bundle
図7.63「コンテナ内のファイル一覧を表示するタブ」 の赤枠で囲われているタブをクリックすることで、development.swu
または「リリース版のビルド」で作成される release.swu
に含まれるコンテナ内のファイルおよびディレクトリを表示します。
クリック後の表示例を 図7.64「コンテナ内のファイル一覧の例」 に示します。
コンテナ内のファイル一覧は [Generate development swu] または [Generate release swu] を実行することで ATDE 上に作成されるコンテナイメージから取得しています。
そのため、[Generate development swu] または [Generate release swu] を実行していない場合はコンテナ内のファイル一覧は表示されません。
その場合は [Generate development swu] または [Generate release swu] を先に実行してください。
![[注記]](images/note.png) | |
---|
この機能を使用するにあたり、ATDE上でプロジェクトのコンテナイメージからコンテナを作成します。 コンテナ名は「プロジェクト名-abosde」を使用します。
例えば、プロジェクト名が my_project の場合、コンテナ名は「my_project-abosde」になります。 ユーザー自身で同名のコンテナを既に作成していた場合、そのコンテナはこの機能を使用時に削除されます。 |
![[注記]](images/note.png) | |
---|
コンテナ内のファイル一覧には、ファイルおよびディレクトリのみを表示しています。
シンボリックリンク、特殊デバイスファイルなどは表示していません。 |
7.9.6.1. resources ディレクトリについて
図7.65「resources ディレクトリ」に示すように ATDE 上のプロジェクトディレクトリには container/resources
ディレクトリがあります。
container/resources
ディレクトリ下に、コンテナ内と同じパスでファイルまたはディレクトリを配置することで、それらは [Generate development swu] または [Generate release swu] を実行時にコンテナ内にコピーされます。
例えば、コンテナ内にある /etc/adduser.conf
を上書きする場合は、編集した adduser.conf
ファイルをプロジェクトディレクトリにある container/resources/etc/adduser.conf
に配置してください。
プロジェクトディレクトリにある container/resources 下のファイルおよびディレクトリを操作する方法は以下の 2 通りがあります。
-
エクスプローラーを使用する
-
ABOSDEのコンテナ内のファイル一覧表示機能を使用する
ABOSDEのコンテナ内のファイル一覧表示機能を使用することで、視覚的にファイル構成や、差分があるファイルを把握しながら操作可能です。
以降に詳細を説明します。
7.9.6.4. container/resources
下にあるファイルを開く
図7.71「container/resources
下にあるファイルを開くボタン」 の赤枠で囲われている表記のボタンをクリックすることで、プロジェクトディレクトリにある container/resources
下のファイルをエディタに表示することができます。
この例では、プロジェクトディレクトリにある container/resources
下の add_file
をエディタに表示します。
7.9.6.6. コンテナ内のファイルを container/resources
下に保存
図7.73「コンテナ内のファイルを container/resources
下に保存するボタン」 の赤枠で囲われている表記のボタンをクリックすることで、コンテナ内にあるファイルをプロジェクトディレクトリにある container/resources
下に保存します。
ファイルが container/resources
下に保存されると、図7.74「編集前のファイルを示すマーク」 に示すように、ファイル名の右側に "U" のマークが表示されます。
"U" のマークはプロジェクトディレクトリにある container/resources
下のファイルとコンテナ内にあるファイルの内容が同一であることを示します。
container/resources
下にあるファイルを編集して再表示すると、図7.75「編集後のファイルを示すマーク」 に示すように、ファイル名の右側に "M" のマークが表示されます。
"M" のマークはプロジェクトディレクトリにある container/resources
下のファイルとコンテナ内にあるファイルの内容に差があることを示します。
プロジェクトディレクトリにある container/resources
下とコンテナ内にあるファイルまたはディレクトリを比較して、同名でかつファイルの種類が異なる場合、図7.76「コンテナ内にコピーされないことを示すマーク」 に示すように、ファイル名の右側に "E" のマークが表示されます。
"E" のマークが表示された場合、そのファイルまたはディレクトリは [Generate development swu] または [Generate release swu] を実行してもコンテナにコピーされません。
7.9.7. Armadillo 上でのセットアップ
Flutter アプリケーションのビルドモードには Debug、 Profile、 Release の3種類があり、
VS Code からは Debug、Release モードの実行が可能です。
Debug モードでビルドしたアプリケーションは後述するホットリロード等のデバッグ機能を用いて、
効率的に開発が可能ですが、アプリケーションの動作が重くなります。
特に動画やアニメーションの動作に大きく影響が出ますので、
その場合は Release モードで動作を確認してください。
7.9.8.2. サンプルアプリケーションのビルド
Flutter のサンプルアプリケーションのビルド方法を説明します。
プロジェクトディレクトリへ移動し VS Code を起動します。
VS Code の左ペインの [my_project] から [Debug app run on ATDE] を実行すると、
Debug モードでアプリケーションがビルドされ ATDE 上で起動します。
![[注記]](images/note.png) | |
---|
flutter-elinux をイントール後に初めてビルドを実行する時は、必要なファイルのダウンロード処理が行われるため、
アプリケーションが起動するまでに時間がかかります。 |
GUI アプリケーションの場合は以下のようなアプリケーションが起動します。
アプリケーションを終了するにはウィンドウ右上の X ボタンを押してください。
また、Release モードでアプリケーションを実行するには、VS Code の左ペインの [my_project] から [Release app run on ATDE] を実行してください。
サンプルアプリケーションのソースコードは、 app/lib
にあります。
サンプルアプリケーションをベースとして開発を進める場合は、 app/lib
下にソースコードを
保存してください。
Flutter には様々な機能を実現するためのパッケージが豊富に存在しており、
主に こちらのサイトで見つけることができます。
目的のパッケージをアプリケーションで使えるようにするためには、
アプリケーションディレクトリの中で以下のコマンドを実行します。
例として dart_periphery パッケージをインストールします。
video_player や camera など以下に挙げたパッケージは、
ATDE 内の /opt/flutter-elinux-packages
にあるパッケージと組み合わせて使う必要があります。
表7.6 組み合わせて使うパッケージ
パッケージ名 | /opt/flutter-elinux-package 内のパッケージ名 |
---|
video_player | video_player_elinux |
camera | camera_elinux |
audioplayers | audioplayers_elinux |
path_provider | path_provider_elinux |
shared_preferences | shared_preferences_elinux |
なし | joystick |
これらのパッケージをインストールする場合は以下のようにインストールしてください。
パッケージをアンインストールする場合は pub remove
を実行します。
7.9.8.4. BLE パッケージをインストールする
アプリケーションから BLE を使用するために必要なパッケージは、
VS Code からインストールすることができます。
左ペインの [my_project] から [external packages] を開き [universal_ble] の右にある
+
をクリックするとインストールされます。
すでにインストール済みの状態で -
をクリックするとアインストールされます。
一番右にある丸アイコンをクリックすると Web ブラウザで universal_ble
パッケージの API リファレンスページを開きます。
ここでは、実際に Armadillo 上でアプリケーションを起動する場合の手順を説明します。
7.9.9.1. ssh
接続に使用する IP アドレスの設定
VS Code 上で ABOSDE(Armadillo Base OS Development Environment) から、
ABOS Web が動作している Armadillo の一覧を確認し、
指定した Armadillo の IP アドレスを ssh 接続に使用することができます。
ただし、ATDE のネットワークを NAT に設定している場合は Armadillo がリストに表示されません。
図7.85「ABOSDE で ローカルネットワーク上の Armadillo をスキャンする」 の赤枠で囲われているボタンをクリックすることで、
ローカルネットワーク上で ABOS Web が実行されている Armadillo をスキャンすることができます。
図7.86「ABOSDE を使用して ssh 接続に使用する IP アドレスを設定する」 の赤枠で囲われているマークをクリックすることで、
指定した Armadillo の IP アドレスを ssh 接続に使用する IP アドレスに設定することができます。
図7.87「ABOSDE に表示されている Armadillo を更新する」 の赤枠で囲われているマークをクリックすることで、
ABOSDE に表示されている Armadillo を更新することができます。
ATDE のネットワークを NAT に設定している場合や、ABOS Web を起動していない場合等、
ABOSDE のリストに Armadillo が表示されない場合は、
プロジェクトディレクトリに入っている config/ssh_config
ファイルを編集して
IP アドレスを書き換えてください。
|
Armadillo の IP アドレスに置き換えてください。
|
VS Code の左ペインの [my_project] から [Debug app run on Armadillo] を実行すると、
Debug モードでビルドされたアプリケーションが Armadillo へ転送されて起動します。
VS Code のターミナルに以下のメッセージが表示されることがあります。
これが表示された場合は yes
と入力して下さい。
アプリケーションを終了するには VS Code の左ペインの [my_project] から [App stop on Armadillo] を実行してください。
また、Release モードでアプリケーションを実行するには、VS Code の左ペインの [my_project] から [Release app run on Armadillo] を実行してください。
アプリケーションのソースコードに修正を加えた後にコンパイルをせずに即座に動作確認をしたい場合、
ホットリロード機能を使うことができます。
この機能を使うには Debug モードでアプリケーションをビルドしている必要があります。
ホットリロード機能を使うには、アプリケーション実行時に表示される VS Code のターミナルで r
を入力してください。
その後、以下のようなメッセージが表示され修正が反映されます。
アプリケーションをデバッグモードで起動することで VS Code のデバッガ機能を使用したデバッグができるようになります。
デバッガを使用すると、ブレークポイントで処理を止めて変数の値を確認したり、ステップ実行などができるようになります。
デバッグモードのアプリケーションでは、リリースモードに比べて動作が遅くなり操作に対するレスポンスが遅延することがあります。
特に外部機器と接続してデータをやり取りするようなアプリケーションで、遅延が原因で接続がタイムアウトしてしまうようなことがある場合は、
デバッグモードの場合はタイムアウトしないようにするなどの対応を行う必要があります。
デバッグ完了後、最終的にはリリースモードでのテストを行ってください。
7.9.10.1. VS Code に Flutter エクステンションをインストールする
VS Code に Flutter エクステンションをインストールします。
マーケットプレイスの検索フォームに「flutter」と入力し、
表示された「Flutter」の 「Install」ボタンをクリックしてインストールしてください。
次に Flutter Sdk Path を設定します。VS Code 上で Ctrl + ,
キーを押して設定画面を開き、
検索フォームに「Flutter Sdk Paths」と入力し、「Add Item」をクリックしてください。
表示されたフィールドに、/opt/flutter-elinux/flutter
と入力し「OK」をクリックしてください。
7.9.10.2. アプリケーションを Debug モードで実行する
VS Code の左ペインの [my_project] から [Debug app run on ATDE] または [Debug app run on Armadillo] を実行してください。
7.9.10.3. アプリケーションのデバッグを開始する
VS Code の [Run and Debug] 画面を表示し、上部の三角ボタンをクリックすると
VS Code からアプリケーションのデバッグを開始します。
デバッグを開始すると VS Code のウィンドウ上部にデバッガを操作するためのアイコンが表示されます。
デバッガの機能としては次のものがあります。
ブレークポイントの設定
ソースコードの行数表示の左をクリックすると丸印が付きます。処理をここで止めることができます。
Continue
ブレークポイントで停止したところから再び実行を継続します。
Step Over
クリックするごとに、ブレークポイントで停止したところから一行ずつ実行します。
Step Into
関数の中へ入ります。
Step Out
関数の中にいる場合、その関数を最後まで実行した後に関数から出ます。
Hot Reload
図7.93「ホットリロード機能を使う」 と同じ機能です。
Restart
アプリケーションを再起動します。
Disconnect
デバッグを終了します。
Widget Inspector
アプリケーション上に配置してある Widget のツリー構成を確認できます。
ここでは完成したアプリケーションをリリース版としてビルドする場合の手順について説明します。
VS Code の左ペインの [my_project] から [Generate release swu] を実行すると、
リリース版のアプリケーションを含んだ SWU イメージが作成されます。
事前に 「SWUイメージの作成」 を参照して SWU の初期設定を行ってください。
![[注記]](images/note.png) | |
---|
リリース版の SWU イメージには、開発用の機能は含まれていません。
このため、リリース版の SWU イメージをインストールした Armadillo では、
[Debug app run on Armadillo] や [Release app run on Armadillo] を
使用したリモート実行や、Flutter のデバッグ機能は使用できません。 |
作成した SWU イメージは my_project
ディレクトリ下に release.swu
という
ファイル名で保存されています。
この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールすると、
Armadillo 起動時にアプリケーションも自動起動します。
7.9.14. Armadillo 上のコンテナイメージの削除
development.swu
または release.swu
を Armadillo にインストールすることで保存されたコンテナイメージを削除する方法は、
「VS Code から実行する」 を参照してください。
ここではシェルスクリプトおよび Python を使った CUI アプリケーションの開発方法を紹介します。
開発手順としてはシェルスクリプトと Python で同じであるため、シェルスクリプトの場合の例で説明します。
7.10.1. CUI アプリケーション開発の流れ
Armadillo 向けに CUI アプリケーションを開発する場合の流れは以下のようになります。
ここでは、開発開始時の ATDE 上でのセットアップ手順について説明します。
ATDE をお使いでない場合は、先に 「開発の準備」 を参照して ATDE 及び、 VS Code のセットアップを完了してください。
VS Code の左ペインの [A9E] から [Shell New Project] を実行し、表示されるディレクトリ選択画面からプロジェクトを保存する
ディレクトリを選択してください。
実行するためには右に表示されている三角形ボタンを押してください。
Python の場合は [Python New Project] を実行してください。
保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。
この操作により、選択した保存先に、入力したプロジェクト名と同名のディレクトリが作成されます。
また、ここでは次のように設定しています。
-
保存先 : ホームディレクトリ
-
プロジェクト名 :
my_project
ここでは、実際に Armadillo 上でサンプルアプリケーションを起動する場合の手順を説明します。
プロジェクトディレクトリへ移動し VS Code を起動します。
プロジェクトには下記のディレクトリがあります。
app
: アプリケーションのソースです。Armadillo ではビルドしたアプリケーションが /var/app/rollback/volumes/my_project
にコピーされます。
-
requirements.txt
: Python プロジェクトにのみ存在しており、このファイルに記載したパッケージは pip を使用してインストールされます。
config
: 設定に関わるファイルが含まれるディレクトリです。
container
: スクリプトを実行するコンテナの設定ファイルが含まれるディレクトリです。
-
packages.txt
: このファイルに記載されているパッケージがインストールされます。
-
Dockerfile
: 直接編集することも可能です。
デフォルトのコンテナコンフィグ( app.conf )ではシェルスクリプトの場合は app
の src/main.sh
または Python の場合 src/main.py
を実行しますので、リネームが必要な場合にコンテナのコンフィグも修正してください。
このサンプルアプリケーションは、CPU と SOC の温度を /vol_data/log/temp.txt
に出力し、
アプリケーションLED を点滅させます。
初期設定では主に Armadillo と SSH で接続するための秘密鍵と公開鍵の生成を行います。
作成したプロジェクトディレクトリへ移動して VS Code を起動してください。
VS Code の左ペインの [my_project] から [Setup environment] を実行します。
選択すると、 VS Code の下部に以下のようなターミナルが表示されます。
このターミナル上で以下のように入力してください。
|
パスフレーズを設定します。設定しない場合は何も入力せず Enter を押します。
|
|
1 でパスフレーズを設定した場合は、確認のため再度入力してください。
|
|
ここで何か任意のキーを押すとターミナルが閉じます。
|
パスフレーズを設定した場合は、アプリケーションを Armadillo へ転送する時にパス
フレーズの入力を求められることがあります。
![[ティップ]](images/tip.png) | |
---|
ssh の鍵は $HOME/.ssh/id_ed25519_vscode (と id_ed25519_vscode.pub ) に保存されていますので、
プロジェクトをバックアップする時は $HOME/.ssh も保存してください。 |
7.10.3.4. アプリケーション実行用コンテナイメージの作成
Armadillo 上でアプリケーションを実行するためのコンテナイメージを作成します。
ここで作成したコンテナイメージは SWU イメージを使用して Armadillo へインストールするため、
事前に 「SWUイメージの作成」 を参照して SWU の初期設定を行ってください。
コンテナイメージの作成および SWU イメージの作成も VS Code で行います。
VS Code の左ペインの [my_project] から [Generate development swu] を実行します。
コンテナイメージの作成にはしばらく時間がかかります。
VS Code のターミナルに以下のように表示されるとコンテナイメージの作成は完了です。
作成した SWU イメージは my_project
ディレクトリ下に development.swu
という
ファイル名で保存されています。
7.10.3.5. Python アプリケーションに Bluetooth Low Energy パッケージをインストールする
Python アプリケーションの場合は、アプリケーションから Bluetooth Low Energy を使用するために必要なパッケージを
VS Code からインストールすることができます。
左ペインの [my_project] から [external packages] を開き [bleak] の右にある
+
をクリックするとインストールされます。
すでにインストール済みの状態で -
をクリックするとアインストールされます。
一番右にある丸アイコンをクリックすると Web ブラウザで bleak
パッケージの API リファレンスページを開きます。
![[注記]](images/note.png) | |
---|
Bluetooth Low Energy パッケージのインストールは ABOSDE のバージョン 1.8.4 以降で、かつ 2024 年 7 月 24 日以降に
「プロジェクトの作成」 の手順で新たに作成したプロジェクトで使用できるようになります。 |
使用するコンテナのディストリビューションは以下のとおりです。
7.10.5. Armadillo に転送するディレクトリ及びファイル
コンテナイメージ以外に、以下に示すディレクトリやファイルを Armadillo に転送します。
ここでは、プロジェクト名は my_project
としています。
-
Armadillo に転送するディレクトリ及びファイル
図7.111「コンテナ内のファイル一覧を表示するタブ」 の赤枠で囲われているタブをクリックすることで、development.swu
または「リリース版のビルド」で作成される release.swu
に含まれるコンテナ内のファイルおよびディレクトリを表示します。
クリック後の表示例を 図7.112「コンテナ内のファイル一覧の例」 に示します。
コンテナ内のファイル一覧は [Generate development swu] または [Generate release swu] を実行することで ATDE 上に作成されるコンテナイメージから取得しています。
そのため、[Generate development swu] または [Generate release swu] を実行していない場合はコンテナ内のファイル一覧は表示されません。
その場合は [Generate development swu] または [Generate release swu] を先に実行してください。
![[注記]](images/note.png) | |
---|
この機能を使用するにあたり、ATDE上でプロジェクトのコンテナイメージからコンテナを作成します。 コンテナ名は「プロジェクト名-abosde」を使用します。
例えば、プロジェクト名が my_project の場合、コンテナ名は「my_project-abosde」になります。 ユーザー自身で同名のコンテナを既に作成していた場合、そのコンテナはこの機能を使用時に削除されます。 |
![[注記]](images/note.png) | |
---|
コンテナ内のファイル一覧には、ファイルおよびディレクトリのみを表示しています。
シンボリックリンク、特殊デバイスファイルなどは表示していません。 |
7.10.6.1. resources ディレクトリについて
図7.113「resources ディレクトリ」に示すように ATDE 上のプロジェクトディレクトリには container/resources
ディレクトリがあります。
container/resources
ディレクトリ下に、コンテナ内と同じパスでファイルまたはディレクトリを配置することで、それらは [Generate development swu] または [Generate release swu] を実行時にコンテナ内にコピーされます。
例えば、コンテナ内にある /etc/adduser.conf
を上書きする場合は、編集した adduser.conf
ファイルをプロジェクトディレクトリにある container/resources/etc/adduser.conf
に配置してください。
プロジェクトディレクトリにある container/resources 下のファイルおよびディレクトリを操作する方法は以下の 2 通りがあります。
-
エクスプローラーを使用する
-
ABOSDEのコンテナ内のファイル一覧表示機能を使用する
ABOSDEのコンテナ内のファイル一覧表示機能を使用することで、視覚的にファイル構成や、差分があるファイルを把握しながら操作可能です。
以降に詳細を説明します。
7.10.6.4. container/resources
下にあるファイルを開く
図7.119「container/resources
下にあるファイルを開くボタン」 の赤枠で囲われている表記のボタンをクリックすることで、プロジェクトディレクトリにある container/resources
下のファイルをエディタに表示することができます。
この例では、プロジェクトディレクトリにある container/resources
下の add_file
をエディタに表示します。
7.10.6.6. コンテナ内のファイルを container/resources
下に保存
図7.121「コンテナ内のファイルを container/resources
下に保存するボタン」 の赤枠で囲われている表記のボタンをクリックすることで、コンテナ内にあるファイルをプロジェクトディレクトリにある container/resources
下に保存します。
ファイルが container/resources
下に保存されると、図7.122「編集前のファイルを示すマーク」 に示すように、ファイル名の右側に "U" のマークが表示されます。
"U" のマークはプロジェクトディレクトリにある container/resources
下のファイルとコンテナ内にあるファイルの内容が同一であることを示します。
container/resources
下にあるファイルを編集して再表示すると、図7.123「編集後のファイルを示すマーク」 に示すように、ファイル名の右側に "M" のマークが表示されます。
"M" のマークはプロジェクトディレクトリにある container/resources
下のファイルとコンテナ内にあるファイルの内容に差があることを示します。
container/resources
下とコンテナ内にあるファイルまたはディレクトリを比較して、同名でかつファイルの種類が異なる場合、図7.124「コンテナ内にコピーされないことを示すマーク」 に示すように、ファイル名の右側に "E" のマークが表示されます。
"E" のマークが表示された場合、そのファイルまたはディレクトリは [Generate development swu] または [Generate release swu] を実行してもコンテナにコピーされません。
7.10.7. Armadillo 上でのセットアップ
7.10.7.2. ssh
接続に使用する IP アドレスの設定
VS Code 上で ABOSDE(Armadillo Base OS Development Environment) から、
ABOS Web が動作している Armadillo の一覧を確認し、
指定した Armadillo の IP アドレスを ssh 接続に使用することができます。
ただし、ATDE のネットワークを NAT に設定している場合は Armadillo がリストに表示されません。
図7.125「ABOSDE で ローカルネットワーク上の Armadillo をスキャンする」 の赤枠で囲われているボタンをクリックすることで、
ローカルネットワーク上で ABOS Web が実行されている Armadillo をスキャンすることができます。
図7.126「ABOSDE を使用して ssh 接続に使用する IP アドレスを設定する」 の赤枠で囲われているマークをクリックすることで、
指定した Armadillo の IP アドレスを ssh 接続に使用する IP アドレスに設定することができます。
図7.127「ABOSDE に表示されている Armadillo を更新する」 の赤枠で囲われているマークをクリックすることで、
ABOSDE に表示されている Armadillo を更新することができます。
ATDE のネットワークを NAT に設定している場合や、ABOS Web を起動していない場合等、
ABOSDE のリストに Armadillo が表示されない場合は、
プロジェクトディレクトリに入っている config/ssh_config
ファイルを編集して
IP アドレスを書き換えてください。
|
Armadillo の IP アドレスに置き換えてください。
|
![[ティップ]](images/tip.png) | |
---|
Armadillo を初期化した場合や、プロジェクトを実行する Armadillo を変えた場合は,
プロジェクトの config/ssh_known_hosts に保存されている公開鍵で Armadillo を認識できなくなります。
その場合はファイルを削除するか、「Setup environment」タスクを再実行してください。 |
VS Code の左ペインの [my_project] から [App run on Armadillo] を実行すると、
アプリケーションが Armadillo へ転送されて起動します。
VS Code のターミナルに以下のメッセージが表示されることがあります。
これが表示された場合は yes
と入力して下さい。
アプリケーションを終了するには VS Code の左ペインの [my_project] から [App stop on Armadillo] を実行してください。
ここでは完成したアプリケーションをリリース版としてビルドする場合の手順について説明します。
VS Code の左ペインの [my_project] から [Generate release swu] を実行すると、
リリース版のアプリケーションを含んだ SWU イメージが作成されます。
事前に 「SWUイメージの作成」 を参照して SWU の初期設定を行ってください。
![[注記]](images/note.png) | |
---|
リリース版の SWU イメージには、開発用の機能は含まれていません。
このため、リリース版の SWU イメージをインストールした Armadillo では、
[App run on Armadillo] を使用したリモート実行は使用できません。 |
作成した SWU イメージは my_project
ディレクトリ下に release.swu
というファイル名で保存されています。
この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールすると、
Armadillo 起動時にアプリケーションも自動起動します。
ここでは C 言語によるアプリケーション開発の方法を紹介します。
C 言語によるアプリケーション開発は下記に当てはまるユーザーを対象としています。
-
既存の C 言語によって開発されたアプリケーションを Armadillo で動作させたい
-
C 言語でないと実現できないアプリケーションを開発したい
上記に当てはまらず、開発するアプリケーションがシェルスクリプトまたは Python で実現可能であるならば、「CUI アプリケーションの開発」を参照してください。
7.11.1. C 言語によるアプリケーション開発の流れ
Armadillo 向けに C 言語によるアプリケーションを開発する場合の流れは以下のようになります。
ここでは、開発開始時の ATDE 上でのセットアップ手順について説明します。
ATDE をお使いでない場合は、先に 「開発の準備」 を参照して ATDE 及び、 VS Code のセットアップを完了してください。
VS Code の左ペインの [A9E] から [C New Project] を実行し、表示されるディレクトリ選択画面からプロジェクトを保存する
ディレクトリを選択してください。
実行するためには右に表示されている三角形ボタンを押してください。
保存先を選択すると、プロジェクト名を入力するダイアログが表示されるので、任意のプロジェクト名を入力してエンターキーを押してください。
この操作により、選択した保存先に、入力したプロジェクト名と同名のディレクトリが作成されます。
また、ここでは次のように設定しています。
-
保存先 : ホームディレクトリ
-
プロジェクト名 :
my_project
ここでは、実際に Armadillo 上でサンプルアプリケーションを起動する場合の手順を説明します。
プロジェクトディレクトリへ移動し VS Code を起動します。
プロジェクトには下記のディレクトリがあります。
app
: 各ディレクトリの説明は以下の通りです。
-
src
: アプリケーションのソースファイル(拡張子が .c )と Makefile を配置してください。
-
build
: ここに配置した実行ファイルが Armadillo 上で実行されます。
-
lib
: 共有ライブラリの検索パスとしてこのディレクトリを指定しているので、ここに共有ライブラリ(拡張子が .so )を配置することができます。
config
: 設定に関わるファイルが含まれるディレクトリです。
container
: スクリプトを実行するコンテナの設定ファイルが含まれるディレクトリです。
-
packages.txt
: このファイルに記載されているパッケージがインストールされます。
-
Dockerfile
: 直接編集することも可能です。
デフォルトのコンテナコンフィグ( app.conf )では C 言語の場合は build/main
を実行しますので、リネームが必要な場合にコンテナのコンフィグも修正してください。
このサンプルアプリケーションは、CPU と SOC の温度を /vol_data/log/temp.txt
に出力し、
アプリケーションLED を点滅させます。
初期設定では主に Armadillo と SSH で接続するための秘密鍵と公開鍵の生成を行います。
作成したプロジェクトディレクトリへ移動して VS Code を起動してください。
VS Code の左ペインの [my_project] から [Setup environment] を実行します。
選択すると、 VS Code の下部に以下のようなターミナルが表示されます。
このターミナル上で以下のように入力してください。
|
パスフレーズを設定します。設定しない場合は何も入力せず Enter を押します。
|
|
1 でパスフレーズを設定した場合は、確認のため再度入力してください。
|
|
ここで何か任意のキーを押すとターミナルが閉じます。
|
パスフレーズを設定した場合は、アプリケーションを Armadillo へ転送する時にパス
フレーズの入力を求められることがあります。
![[ティップ]](images/tip.png) | |
---|
ssh の鍵は $HOME/.ssh/id_ed25519_vscode (と id_ed25519_vscode.pub ) に保存されていますので、
プロジェクトをバックアップする時は $HOME/.ssh も保存してください。 |
7.11.3.4. packages.txt の書き方
ABOSDEではコンテナイメージにパッケージをインストールするために container
ディレクトリにある packages.txt
を使用します。
packages.txt
に記載されているパッケージは "apt install" コマンドによってコンテナイメージにインストールされます。
C 言語による開発の場合、packages.txt
に [build] というラベルを記載することで、ビルド時のみに使用するパッケージを指定することが出来ます。
図7.141「C 言語による開発における packages.txt の書き方」に C 言語による開発の場合における packages.txt
の書き方の例を示します。
ここでは、パッケージ名を package_A 、package_B 、package_C としています。
|
このラベル以降のパッケージはビルド時のみに使用されます。
|
上記の例の場合、Armadillo 上で実行される環境では package_A 、package_B のみがインストールされ、package_C はインストールされません。
"[build] package_C" のように [build] の後に改行せずに、一行でパッケージ名を書くことは出来ませんのでご注意ください。
7.11.3.5. ABOSDEでの開発における制約
Makefile は app/src
直下に配置してください。
app/src
直下の Makefile を用いて make コマンドが実行されます。
ABOSDE では make コマンドのみに対応しています。
app/build
と app/lib
内のファイルが Armadillo に転送されますので、実行ファイルは app/build
、共有ライブラリ( 拡張子が .so ファイル )は app/lib
に配置してください。
7.11.3.6. アプリケーション実行用コンテナイメージの作成
Armadillo 上でアプリケーションを実行するためのコンテナイメージを作成します。
ここで作成したコンテナイメージは SWU イメージを使用して Armadillo へインストールするため、
事前に 「SWUイメージの作成」 を参照して SWU の初期設定を行ってください。
コンテナイメージの作成、 実行ファイルや共有ライブラリの作成およびSWU イメージの作成も VS Code で行います。
VS Code の左ペインの [my_project] から [Generate development swu] を実行します。
コンテナイメージの作成にはしばらく時間がかかります。
VS Code のターミナルに以下のように表示されるとコンテナイメージの作成は完了です。
作成した SWU イメージは my_project
ディレクトリ下に development.swu
という
ファイル名で保存されています。
使用するコンテナのディストリビューションは以下のとおりです。
図7.144「コンテナ内のファイル一覧を表示するタブ」 の赤枠で囲われているタブをクリックすることで、development.swu
または「リリース版のビルド」で作成される release.swu
に含まれるコンテナ内のファイルおよびディレクトリを表示します。
クリック後の表示例を 図7.145「コンテナ内のファイル一覧の例」 に示します。
コンテナ内のファイル一覧は [Generate development swu] または [Generate release swu] を実行することで ATDE 上に作成されるコンテナイメージから取得しています。
そのため、[Generate development swu] または [Generate release swu] を実行していない場合はコンテナ内のファイル一覧は表示されません。
その場合は [Generate development swu] または [Generate release swu] を先に実行してください。
![[注記]](images/note.png) | |
---|
この機能を使用するにあたり、ATDE上でプロジェクトのコンテナイメージからコンテナを作成します。 コンテナ名は「プロジェクト名-abosde」を使用します。
例えば、プロジェクト名が my_project の場合、コンテナ名は「my_project-abosde」になります。 ユーザー自身で同名のコンテナを既に作成していた場合、そのコンテナはこの機能を使用時に削除されます。 |
![[注記]](images/note.png) | |
---|
コンテナ内のファイル一覧には、ファイルおよびディレクトリのみを表示しています。
シンボリックリンク、特殊デバイスファイルなどは表示していません。 |
7.11.5.1. resources ディレクトリについて
図7.146「resources ディレクトリ」に示すように ATDE 上のプロジェクトディレクトリには container/resources
ディレクトリがあります。
container/resources
ディレクトリ下に、コンテナ内と同じパスでファイルまたはディレクトリを配置することで、それらは [Generate development swu] または [Generate release swu] を実行時にコンテナ内にコピーされます。
例えば、コンテナ内にある /etc/adduser.conf
を上書きする場合は、編集した adduser.conf
ファイルをプロジェクトディレクトリにある container/resources/etc/adduser.conf
に配置してください。
プロジェクトディレクトリにある container/resources 下のファイルおよびディレクトリを操作する方法は以下の 2 通りがあります。
-
エクスプローラーを使用する
-
ABOSDEのコンテナ内のファイル一覧表示機能を使用する
ABOSDEのコンテナ内のファイル一覧表示機能を使用することで、視覚的にファイル構成や、差分があるファイルを把握しながら操作可能です。
以降に詳細を説明します。
7.11.5.4. container/resources
下にあるファイルを開く
図7.152「container/resources
下にあるファイルを開くボタン」 の赤枠で囲われている表記のボタンをクリックすることで、プロジェクトディレクトリにある container/resources
下のファイルをエディタに表示することができます。
この例では、プロジェクトディレクトリにある container/resources
下の add_file
をエディタに表示します。
7.11.5.6. コンテナ内のファイルを container/resources
下に保存
図7.154「コンテナ内のファイルを container/resources
下に保存するボタン」 の赤枠で囲われている表記のボタンをクリックすることで、コンテナ内にあるファイルをプロジェクトディレクトリにある container/resources
下に保存します。
ファイルが container/resources
下に保存されると、図7.155「編集前のファイルを示すマーク」 に示すように、ファイル名の右側に "U" のマークが表示されます。
"U" のマークはプロジェクトディレクトリにある container/resources
下のファイルとコンテナ内にあるファイルの内容が同一であることを示します。
container/resources
下にあるファイルを編集して再表示すると、図7.156「編集後のファイルを示すマーク」 に示すように、ファイル名の右側に "M" のマークが表示されます。
"M" のマークはプロジェクトディレクトリにある container/resources
下のファイルとコンテナ内にあるファイルの内容に差があることを示します。
container/resources
下とコンテナ内にあるファイルまたはディレクトリを比較して、同名でかつファイルの種類が異なる場合、図7.157「コンテナ内にコピーされないことを示すマーク」 に示すように、ファイル名の右側に "E" のマークが表示されます。
"E" のマークが表示された場合、そのファイルまたはディレクトリは [Generate development swu] または [Generate release swu] を実行してもコンテナにコピーされません。
7.11.6. Armadillo に転送するディレクトリ及びファイル
コンテナイメージ以外に、以下に示すディレクトリやファイルを Armadillo に転送します。
ここでは、プロジェクト名は my_project
としています。
-
Armadillo に転送するディレクトリ及びファイル
-
my_project/app/build
-
my_project/app/lib
7.11.7. Armadillo 上でのセットアップ
7.11.7.2. ssh
接続に使用する IP アドレスの設定
VS Code 上で ABOSDE(Armadillo Base OS Development Environment) から、
ABOS Web が動作している Armadillo の一覧を確認し、
指定した Armadillo の IP アドレスを ssh 接続に使用することができます。
ただし、ATDE のネットワークを NAT に設定している場合は Armadillo がリストに表示されません。
図7.158「ABOSDE で ローカルネットワーク上の Armadillo をスキャンする」 の赤枠で囲われているボタンをクリックすることで、
ローカルネットワーク上で ABOS Web が実行されている Armadillo をスキャンすることができます。
図7.159「ABOSDE を使用して ssh 接続に使用する IP アドレスを設定する」 の赤枠で囲われているマークをクリックすることで、
指定した Armadillo の IP アドレスを ssh 接続に使用する IP アドレスに設定することができます。
図7.160「ABOSDE に表示されている Armadillo を更新する」 の赤枠で囲われているマークをクリックすることで、
ABOSDE に表示されている Armadillo を更新することができます。
ATDE のネットワークを NAT に設定している場合や、ABOS Web を起動していない場合等、
ABOSDE のリストに Armadillo が表示されない場合は、
プロジェクトディレクトリに入っている config/ssh_config
ファイルを編集して
IP アドレスを書き換えてください。
|
Armadillo の IP アドレスに置き換えてください。
|
![[ティップ]](images/tip.png) | |
---|
Armadillo を初期化した場合や、プロジェクトを実行する Armadillo を変えた場合は,
プロジェクトの config/ssh_known_hosts に保存されている公開鍵で Armadillo を認識できなくなります。
その場合はファイルを削除するか、「Setup environment」タスクを再実行してください。 |
VS Code の左ペインの [my_project] から [App run on Armadillo] を実行すると、
実行ファイルや共有ライブラリを作成した後、アプリケーションが Armadillo へ転送されて起動します。
VS Code のターミナルに以下のメッセージが表示されることがあります。
これが表示された場合は yes
と入力して下さい。
アプリケーションを終了するには VS Code の左ペインの [my_project] から [App stop on Armadillo] を実行してください。
ここでは完成したアプリケーションをリリース版としてビルドする場合の手順について説明します。
VS Code の左ペインの [my_project] から [Generate release swu] を実行すると、
リリース版のアプリケーションを含んだ SWU イメージが作成されます。
事前に 「SWUイメージの作成」 を参照して SWU の初期設定を行ってください。
![[注記]](images/note.png) | |
---|
リリース版の SWU イメージには、開発用の機能は含まれていません。
このため、リリース版の SWU イメージをインストールした Armadillo では、
[App run on Armadillo] を使用したリモート実行は使用できません。 |
作成した SWU イメージは my_project
ディレクトリ下に release.swu
というファイル名で保存されています。
この SWU イメージを 「SWU イメージのインストール」 を参照して Armadillo へインストールすると、
Armadillo 起動時にアプリケーションも自動起動します。
ABOSDE では SWU イメージの生成と同時に SBOM が生成されます。
生成される SBOM 名は SWU イメージ.spdx.json
になります。
json 形式で ISO/IEC5962で国際標準となっているSPDX2.2のフォーマットに準拠しています。
SBOM についての詳細は 「SBOM の提供」 をご参照ください。
7.12.1. SBOM 生成に必要なファイルを確認する
SBOM の生成には以下の二つのファイルが必要です。
SBOM の生成にはライセンス情報を示したコンフィグファイルを使用します。コンフィグファイルは config/sbom_config.yaml.tmpl
になります。
SWU イメージ作成時にこのコンフィグファイルからバージョン番号をアップデートした swu/sbom_config.yaml
が生成されます。
リリース時にはコンフィグファイルの内容を確認し、正しい内容に変更してください。
各項目の詳細な説明については SPDX specification v2.2.2 (https://spdx.github.io/spdx-spec/v2.2.2/) をご覧ください。
SBOM に含めるコンテナイメージ等の情報については desc ファイルに記載されています。
各項目の説明については 「SWU イメージと同時に SBOM を作成する」 をご覧ください。
SBOM の利点のひとつに、スキャンツールに入力することでソフトウェアに含まれる脆弱性を検出することができる点が挙げられます。
ここでは、 Google が提供しているオープンソース SBOM スキャンツール OSV-Scanner[] を用いて、開発したソフトウェアに既知の脆弱性が含まれているかを確認する方法を紹介します。
7.13.1. OSV-Scanner のインストール
以下の手順はすべて ATDE 上で行います。
OSV-Scanner は GitHub にてビルド済みの実行ファイルが配布されているのでそちらを使用します。
OSV-Scannerのリリースページから、最新の実行ファイル(osv-scanner_linux_amd64)をクリックしてダウンロードしてください。
次に、図7.171「OSV-Scanner をインストールする」のコマンドを実行することで、 OSV-Scanner がインストールされます。
osv-scanner --help
コマンドを実行して、正しくインストールされていることを確認してください。
これで OSV-Scanner のインストールが完了しました。
7.13.2. OSV-Scanner でソフトウェアの脆弱性を検査する
図7.173「OSV-Scanner を用いて SBOM をスキャンする」に示すコマンドを実行することで、ソフトウェアに含まれる既知の脆弱性を検出します。
ここでは例として ABOSDE で開発したアプリケーションの SBOM をスキャンします。
SBOM 生成については 「SWU イメージと同時に SBOM を作成する」 を参照してください。
|
今回は見やすさのために format を markdown に設定しています
|
上記の例では、 development.swu に含まれるソフトウェアから既知の重要な脆弱性が5件検出されました。
OSV URL 列の URL にアクセスすることで各脆弱性の詳細を確認することができます。
Armadillo 上で動作するシステムの開発が完了したら、製造・量産に入る前に開発したシステムのテストを行ってください。
テストケースは開発したシステムに依ると思いますが、 Armadillo で開発したシステムであれば基本的にテストすべき項目について紹介します。
長期間のランニングテストは実施すべきです。
ランニングテストで発見できる現象としては、以下のようなものが挙げられます。
長期間稼働することでソフトウェアの動作が停止してしまう
開発段階でシステムを短い時間でしか稼働させていなかった場合、長期間ランニングした際になんらかの不具合で停止してしまう可能性が考えられます。
開発が完了したら必ず、長時間のランニングテストでシステムが異常停止しないことを確認するようにしてください。
コンテナの稼働情報は podman stats
コマンドで確認することができます。
メモリリークが発生する
アプリケーションのなんらかの不具合によってメモリリークが起こる場合があります。
また、運用時の Armadillo は基本的に overlayfs で動作しています。
そのため、外部ストレージやボリュームマウントに保存している場合などの例外を除いて、動作中に保存したデータは tmpfs (メモリ)上に保存されます。
よくあるケースとして、動作中のログなどのファイルの保存先を誤り、 tmpfs 上に延々と保存し続けてしまうことで、メモリが足りなくなってしまうことがあります。
長時間のランニングテストで、システムがメモリを食いつぶさないかを確認してください。
メモリの空き容量は図7.174「メモリの空き容量の確認方法」に示すように free コマンドで確認できます。
開発したシステムが、想定した条件下で正しく動作することは開発時点で確認できていると思います。
しかし、そのような正常系のテストだけでなく、正しく動作しない環境下でどのような挙動をするのかも含めてテストすべきです。
よくあるケースとしては、動作中に電源やネットワークが切断されてしまった場合です。
電源の切断時には、 Armadillo に接続しているハードウェアに問題はないか、電源が復旧した際に問題なくシステムが復帰するかなどをよくテストすると良いです。
ネットワークの切断時には、再接続を試みるなどの処理が正しく実装されているか、 Armadillo と サーバ側でデータなどの整合性が取れるかなどをよくテストすると良いです。
この他にもシステムによっては多くの異常系テストケースが考えられるはずですので、様々な可能性を考慮しテストを実施してから製造・量産ステップに進んでください。
7.15. ユーザー設定とユーザーデータを一括削除する
ユーザー設定とユーザーデータを一括削除することができます。
ユーザー設定の削除では ABOS Web から設定できる以下の項目を削除します。
ネットワーク設定
-
LAN、WLAN、WWAN の設定を全て削除します。WLAN はクライアント設定とアクセスポイント設定の両方を削除します。
-
DHCP 設定
-
NAT 設定
-
VPN 設定
-
NTP 設定
ABOS Web から設定できるものであっても以下は削除されません。
-
Rest API トークン
-
UI カスタマイズの内容
ユーザーデータの削除では以下のデータを削除します。
-
/var/app/volumes
ディレクトリ下のファイルを全て
-
/var/log
ディレクトリ下のファイルを全て
ユーザー設定とユーザーデータを削除するには Armadillo 上で abos-ctrl reset-default
コマンドを使用します。
|
何もオプションを付けない場合、 DRY-RUN モードとなり実際に削除は行われません。
実際に削除を行う時に実行されるコマンドが表示されるのみです。
|
表示されたコマンドを確認し実際に削除されてもよい場合は、以下のように -f
オプションを付けて
実行してください。
コマンド実行後は自動的に Armadillo が再起動します。
ABOS Web または Rest API から実行することもできます。
ABOS Web から実行する場合は 「ユーザー設定とユーザーデータの削除」 を参照してください。
Rest API から実行する場合は 「Rest API : ユーザー設定とユーザーデータの管理」 を参照してください。
![[注記]](images/note.png) | |
---|
再起動後、再び設定が必要な場合は ABOS Web や REST API を使用して行ってください。
特に Armadillo Twin を利用している場合は、必ずネットワークの再設定を行ってください。 |