1 / 10

インストール・ビルド

Install and Build

MWXライブラリを用いてアプリケーションを記述（本書ではアクトと呼びます）し、実行するために開発環境のセットアップが必要です。

環境 (OSなど)

開発環境を構築するためには、ソフトウェア群のインストール、またこれらの利用許諾に同意する必要があります。また、PC、ワークステーション上でセキュリティ設定等が必要になる場合があります。

配布時には十分注意しておりますが、ウィルスなどの確認はお客様のほうでも留意いただくようお願いいたします。
お客様のセキュリティの考え方や運用（例：外部アプリケーションのインストールの可否）については、お客様の環境の管理者にご確認ください。

また、開発環境をインストールまた動作するにあたり、OSが介在し設定等必要になる場合があります（例：開発元が不明なアプリケーションの実行。開発環境または紹介するツール群の多くは、アプリケーションは開発元を証明する仕組みが組み込まれせん）。設定方法については、一般の情報を参考いただくようお願いいたします。

MWXライブラリを用いてアプリケーションを記述するには以下が必要です。

MWSDK(ソフトウェア開発環境)
開発用エディタ(Microsoft社のVisualStudio Codeを紹介します)

コンパイラのツールチェインなどは比較的環境への依存度が低いため、多くの環境で動作することが期待できますが、サポート中のWindows10バージョンを推奨します。動作環境の差異により動作しないような場合は、当社で確認している環境を参考に別途環境を用意してください。

以下、開発で使用しているバージョンを挙げます。

Windows10 #1809, #1903
.NET CLR v4.0.30319
FTDI社のドライバが動作していること (MONOSTICK, TWELITE Rを動作させるため)

WSL (Windows Subsystem Linux) 環境下でもコンパイラを動作させることが出来ます。ただしコンパイルのみでファームウェアの書き換え等はWindows10上のユーティリティから実施してください。

WSL環境は必須ではありません。

コンパイラのツールチェインなどは比較的環境への依存度が低いため、多くの環境で動作することが期待できますが、現在サポート中のディストリビューションを推奨します。動作環境の差異により動作しないような場合は、当社で確認している環境を参考に別途環境を用意してください。

以下、開発で使用しているバージョンを挙げます。

Ubuntu 16.04 LTS 64bit
Ubuntu 18.04 LTS 64bit

＊32bitのシステムはサポートしません。

以下、開発で使用しているバージョンを挙げます。

macOS 14.06

Visual Studio Code など開発環境について

開発環境を動作させるための環境や使用方法については、その開発元やコミュニティの情報を参照ください。

コード記述作業の効率面で Visual Studio Code (VSCode) の利用を推奨します。

MWXライブラリでは、C言語の開発に比べ、読み込むヘッダファイルが多くなるため、VSCode上でのコード解釈等にはより多くのPCのリソースを要求します。

ビルド環境による差異

Linux/WSL環境下/macOSのビルド結果はWindows10の結果と異なります。通常系の動作で差異が見られることは当社が把握する限りありませんが、特にgccのLTOを無効にしているためバイナリサイズが数%程度大きくなる傾向にあります。

動作等に疑問を感じた際は、必ず Windows10 上のビルドを実施し再現することを確認してから、お問い合わせください。

TWELITE SDK のインストール

下の記述は TWELITE STAGE SDK MWSDK2020_12 に対応します。

TWELITE STAGE SDK をダウンロードした場合は、配布zipアーカイブを、日本語や空白文字が含まれないディレクトリに展開します。

TWELITE STAGE については以下もご覧ください。

3. 環境変数の設定

TWELITE STAGE アプリを用いる場合は、環境変数の設定は不要です。コマンドラインでビルドを行う場合は設定してください。

MWSDK_ROOT, MWSDK_ROOT_WINNAME(Windows10のみ) の設定が必要です。

ここでは展開後のディレクトリ名を C:\MWSTAGE とします。別のディレクトリにインストールした場合は、読み替えてください。

C:\MWSTAGE\Tools\SET_ENV.CMD を実行してください。以下の環境変数を設定します。

MWSDK_ROOT
MWSDK_ROOT_WINNAME

例えば以下のような設定になります。

MWSDK_ROOT=C:/MWSTAGE/MWSDK/
MW_ROOT_WINNAME=C:\MWSTAGE\MWSDK\

インストールしたPC上からTWELITE STAGE SDKをアンインストールするには以下を行ってください。

UNSET_ENV.cmdを実行してください。環境変数の設定を解除します。
MWSTAGEディレクトリを削除してください。

開発環境やシェルに MWX_ROOT環境変数を反映されるように設定してください。

方法はいくつかありますが、ホームディレクトリの.profile（ファイルがなければ新しく作成してください）に以下の設定を追加します。この設定でVSCodeのビルドまで可能です。

MWSDK_ROOT=/foo/bar/MWSTAGE/MWSDK/ export MWSDK_ROOT

エディタを使用せずに追加するには以下のようにコマンド入力します。$はプロンプトで環境によって表示が違います。/foo/bar/MSWSDKの部分はインストールしたディレクトリに応じて書き換えてください。

$ cd $HOME
$ echo MWSDK_ROOT=/foo/bar/MWSTAGE/MWSDK>>.profile
$ echo export MWSDK_ROOT>>.profile

開発環境やシェルに MWX_ROOT環境変数を反映されるように設定してください。

MWSDK_ROOT=/foo/bar/MWSTAGE/MWSDK/ export MWSDK_ROOT

$ cd $HOME
$ echo MWSDK_ROOT=/foo/bar/MWSTAGE/MWSDK>>.profile
$ echo export MWSDK_ROOT>>.profile

環境全体にMWSDK_ROOTを適用にするにはLaunchDを用います。

VS Codeの一部の設定で環境変数を参照していますが、ビルドには必須ではありません。

4. ライブラリの修正の適用

SDKに収録された時点から、ライブラリソースコードに修正がある場合があります。改版履歴を参照の上、必要に応じでライブラリソースコードを差し替えてください。

VS Codeのインストール

MWSDKでは、アクト（ソースコード）記述をより容易に行うため、VisualStudio Code(VS Code)を紹介しています。添付のアクトには、VS Codeで適切にコード解釈が行われるように設定したファイルが含まれます。

VS Codeはソースファイルやヘッダファイルを読み込み、ソースコードを解釈し、これによりソースコードの記述の助けとなる関数定義情報や、関数・メソッド名の補完などを行います。C言語の開発に比べて、MWXライブラリでは読み込まれるヘッダファイルの分量が多くなります。環境によってはエディタの動作が重く感じる場合があります。

VSCode のインストール

当サポートでは VSCode のインストール方法、使用方法のお問い合わせについては対応いたしません。一般で得られる情報を参照ください。

環境によっては、インストールのためにセキュリティ設定などが必要になる場合があります。インストールの可否はシステム管理者にご確認の上、手順は配布元や一般の情報を参考にしてください。

VSCode では、以下のことができます。

ソースコードの編集
GIT への接続（お客様が独自にソース管理を GIT 上で行う場合）
ソースコード解釈に基づく intellisense（＊全ての定義が正確に解釈されることを保証するわけではありません）

VSCode はリンク先より入手してください。

プラグインの導入

Visual Studio Code が C/C++ 言語の記述を解釈できるようにするために、プラグインをインストールします。

C/C++ for Visual Studio Code

注記事項

MWXライブラリのサンプルには .vscode の定義を含めています。この定義は MWSDK_ROOT 環境変数を用い、ライブラリのソースコード({MWSDK_ROOT}/TWENET/current以下)を特定しています。

TWELITE STAGEからVSCodeを始動した場合、上記の環境変数などを設定します。既に始動済みであるような場合など、設定が反映されない場合もあります。

VS Code のソースコードの解釈はコンパイラでの解釈とは完全には一致しません。またソースコードの編集状況によっては解釈がより不完全な状態になる場合もあります。

アクトのビルド

MWXライブラリで記述したアプリケーションプログラムをアクト(Act)と呼びます。まずは、これをビルドして書き込みます。

ビルドディレクトリ構成について
ビルドスクリプトについて
VS Code でのビルドについて

本ページでは、いくつかのビルド方法を記載していますが、いずれの方法も最終的にはmakeコマンドを実行しています。詳細はMakefileの解説を参照ください。

ビルドディレクトリ構成について

MWSDKをインストールしたディレクトリMWSDK_ROOT (例 C:\MWSDK)を開きます。以下のような構成になっています。

MWSDK_ROOT
  |
  +-ChipLib      : 半導体ライブラリ
  +-License      : ソフトウェア使用許諾契約書
  +-MkFiles      : makefile
  +-Tools        : コンパイラ等のツール一式
  +-TWENET       : TWENET/MWXライブラリ
  +-Act_samples  : アクトサンプル
  ...

アクトファイルはAct_samples 以下に格納しています。（以下は一部割愛しています）

Act_samples
  |
  +-CoreAppTwelite    : App_TweLiteと同じ構成のボード用のアクト
  +-PAL_AMB           : 環境センス PAL 用のアクト
  +-PAL_MAG           : 開閉センス PAL 用のアクト
  +-PAL_MOT           : 動作センス PAL 用のアクト
  ..
  +-Parent-MONOSTICK  : 親機アクト、MONOSTICK用
  +-PingPong          : PingPong アクト
  +-PulseCounter      : パルスカウンタを利用したアクト
  +-act0              : スクラッチ（とりあえず書いてみる）用アクト

これらのアクトは、MWXライブラリの記述の参考となるシンプルな例ですが、多くのアクトは以下の機能を有しています。

センサー値を取得する
センサー値取得後、無線パケットを親機宛に送信する
送信完了後、一定時間スリープする（または割り込みを待つ）

Parent-MONOSTICKのアクトによりパケットの受信と表示を行っています。この親機用のアクトは、アスキー形式で出力しています。 (:00112233AABBCC...FF[CR][LF] のような : で始まり、途中は１６進数のバイトをアスキー文字2字で表現する形式です。末尾の??は同様に2字のバイトとなりますがLRCというチェックサムバイトになります。参考：アスキー形式)

実際に動作させてみるときは、以下の組み合わせを試してみてください。

では、アクトの中から PingPong のディレクトリの中を見てみましょう。

Act_samples にある他のアクトもビルドできます。その場合、ディレクトリ名・ファイル名は読み替えるようにしてください。

Act_samples
  +-PingPong
    +-PingPong.cpp   : アクトファイル
    +-build          : ビルドディレクトリ
    +-.vscode        : VS Code 用の設定ファイル

必ずディレクトリ直下にディレクトリと同名の .cpp ファイルが必要です。

小規模なアクトならこの.cppファイル内に記述します。規模が大きくなってきたときはMakefileの解説を参考にして複数のファイルに分割してビルドすることが出来ます。

PingPong ディレクトリ直下にアクトファイル PingPong.cpp があります。ディレクトリ名を変更した場合は、必ず .cpp ファイルの名前もディレクトリ名と同名にします。

次にビルドディレクトリを開きます。

Act_samples
  +-PingPong
    +-build
      +-Makefile        : makefile
      +-build-BLUE.cmd  : TWELITE BLUE 用ビルドスクリプト
      +-build-RED.cmd   : TWELITE RED 用ビルドスクリプト
      +-build-clean.cmd : obj_* ファイル削除

ビルドに必要なスクリプトとMakefileが格納されています。

ビルドスクリプト(Windows10)

macOS, Linux ではVS Codeまたはコマンドラインによるビルドを行います。

ビルドスクリプトは、エラーがあまり出ることのない、完成済みのアクト、サンプル提供のアクトなどに向いています。

以下は Windows10用のスクリプト（バッチファイル）です。

実行後にbinファイルが生成されPingPong_BLUE_???.bin またはPingPong_RED_???.bin のファイル名になります。???はバージョン番号やライブラリのバージョン文字に置き換わります。

BINファイルが出来上がればビルド成功です。

objs_BLUEディレクトリはビルド中に生成された中間ファイルです。削除してもかまいません。

ビルドを迅速にするためパラレルビルドのオプションを設定しています。このためエラーが出た場合はエラーメッセージを視認しづらくなっています。

エラーメッセージを効率的に参照したい場合は VS Code などの開発ツールの利用を推奨します。

クリーン（中間ファイルの削除）

build-clean.cmdを実行すれば、objs_ で始まるディレクトリを消去します。BINファイルは消去しません。

ビルドがうまくいかない場合は、まずエラーメッセージを確認して下さい。errorという文字列が含まれる行中のメッセージから、エラー原因が容易に特定できる場合も少なくありません。

objs_??? ディレクトリにある中間ファイルを削除してから再実行してみてください。（他の環境でビルドした中間ファイルが残っているとmake cleanを含めすべての操作が失敗します)

コマンドライン(Linux/macOS)でのビルド

コマンドライン環境でのビルドについて補足します。

コマンドライン(bash)についての利用の知識が必要です。

OS環境によっては各実行プログラムの動作時にセキュリティ警告が出る場合があります。警告を抑制する設定が必要になります。（警告を抑制してプログラムを動作する運用を行うかは、お客自身またはシステム管理者に相談の上、ご判断ください）

コマンドラインでのビルドは、bash(Bourne-again shell)が動作するウインドウでmakeを実行します。事前に環境変数MWSDK_ROOTが正しく設定されていることを確認してください。例えばC:/MWSDKにインストールした場合は ~/.profile に以下のような設定を行います。

MWSDK_ROOT=/mnt/c/MWSDK
export MWSDK_ROOT

コマンドライン(bash)よりmakeを実行します。makeがない場合はパッケージをインストールする必要があります。

$ make

Command 'make' not found, but can be installed with:

sudo apt install make
sudo apt install make-guile

$ sudo apt install make
...

Linux/WSL環境ではmakeまたはbuild-essentialパッケージをインストールします。
macOS環境ではXcodeでCommand Line Toolsをインストールします。

ビルドは以下のようになります。

$ cd $MWSDK_ROOT
$ cd Act_samples/PingPong/build
$ pwd
/mnt/c/MWSDK/Act_samples/PingPong/build

$ ls
... ファイル一覧の表示

$ rm -rfv objs_*
... 念のため中間ファイルを削除

$ make TWELITE=BLUE
... BLUE用に通常ビルド

$ make -j8 TWELITE=BLUE
... BLUE用にパラレルビルド(同時に8プロセス)

中間ファイルについて

ビルドが行われると objs_??? ディレクトリが作成され、その中に中間ファイルが生成されます。このファイルはコンパイルした環境に依存しているため、他の環境のファイルが残っているとmakeがエラーとなりビルドが失敗します。

makeがエラーとなった場合は直接objs_???ディレクトリを削除してください。

コマンド例

詳細はMakefileの解説をご覧ください。

VS Code でのビルドについて

ビルドには TWELITE STAGE を推奨します。

MWSDK付属のサンプルプロジェクトのVS Code定義ファイルは可能な限り実施しますが、一部定義が不完全なものも含まれます。

VS Code では、Act_samplesディレクトリ直下にあるワークスペースファイルを開くか、Act_samples以下のアクトディレクトリを開きます。

以下の例では英語インタフェースの画面例で、ワークスペースを開いています。

ワークスペースを開き [Terminal>Run Task...] を選択します。

ビルドするTWELITE無線モジュールの種別(BLUE/RED)とアクト名を選択します。以下の例ではBuild for TWELITE BLUE PingPong (TWELITE BLUE用/PingPongアクト) を選択しています。選択後すぐにビルドが始まります。

ビルド中の経過は画面下部の TERMINAL 部分に出力されます。

正しくビルドできた場合、上記画面例の反転表示部のように .elf ファイルが生成されるメッセージがサイズ情報(text data bss dec hex filenameと記載がある部分)とともに出力されます。

またBINファイル（上記では PingPong_BLUE_???.bin）ファイルがbuildディレクトリ下に出来上がっているはずです。確認してみてください。

ビルド定義には Windows10 のファイルシステムに適合しないディレクトリ名 (例：/c/User/...)を変換する(例：C:/User/...) 定義を追加しています。

変換は完全ではありませんが、コンパイルメッセージからエラーが発生しているファイル名と行番号を抽出できます。

.vscode/tasks.json 中の実行コマンドは sh -c "make ... | sed -E -e s#..." のようにコマンド呼び出しすることで、出力メッセージ中のドライブ名相当部の文字列を書き換えています。

...
"windows": {
    "command": "sh",
    "args": [
        "-c", "make TWELITE=BLUE 2>&1 | sed -E -e s#\\(/mnt\\)?/\\([a-zA-Z]\\)/#\\\\\\2:/#g"
    ],

ビルドがうまくいかない場合は、まずエラーメッセージを確認して下さい。errorという文字列が含まれる行中のメッセージから、エラー原因が容易に特定できる場合も少なくありません。

念のため、クリーン(objs_??? ディレクトリにある中間ファイルの削除)を行い、ビルドを再実行してみてください。（他の環境でビルドした中間ファイルが残っているとmake cleanを含めすべての操作が失敗します)

WSLについて

WSL (Windows Subsystem for Linux) は Windows10 のサブシステムとして動作する Linux 環境です。

Windows10 では特別な理由がない限りWSL (Windows Subsystem for Linux)は、MWSDKでアクトをビルドするのに必須ではありません。WSLについて、既に知見があり特に利用したい方のみ本節をご覧ください。ここではWSLのインストール方法や使用方法については紹介しません。

MWSDK2020_05 .. 2020_10

MWSDK/Tools/ba-elf-ba2-r36379.w10 以下に Windows10用とLinux用の実行形式が両方含まれます。WSLを動作させ環境変数MWSDK_ROOTを適切に設定します。

例えば C:\Work\MWSTAGE\MWSDK の場合は以下のように設定します。

$ export MWSDK_ROOT=/mnt/c/Work/MWSTAGE/MWSDK

MWSDK2020_12

TWELITE STAGE SDK パッケージには、WSL用の実行形式は含まれません。

MWSTAGE/Tools/ba-elf-ba2-r36379.wslというフォルダ名で、ツール一式を格納してください。ツールはMWSDK2020_10のMWSDK/Tools/ba-elf-ba2-r36379.w10を用いるのが平易です。

ツールの選択

MWSDK/Tools/MkFiles/rules.mkで環境の判定とツールディレクトリの選択をしています。以下はrules.mkの抜粋でWSLENVの環境変数の有無で判定しています。

# Configure for WSL (Windows Subsystem Linux)
ifneq ($(origin WSLENV),undefined)
$(info !!!WSL environment, use Linux toolchain instead.)
TOOLCHAIN_PATH = ba-elf-ba2-r36379.wsl
endif

アクトの実行

ここではアクト(BINファイル)の書き込みと実行について解説します。

この節はWindows10環境のユーティリティTWE-Programmerを用いた解説です。

Linux/macOSではtweterm.pyを用います。本ページでの書き込み・実行の流れを参照いただいた上、tweterm.pyを利用ください。

TWE-Programmer, tweterm.pyはBINファイルの書き込み機能とターミナル機能がありますが、ターミナル機能については各システム用のターミナルソフトを利用することもできます。

Windows10: TeraTerm
Linux/macOS: screen など

BINファイルの書き込みと実行

出来上がったBINファイルをTWELITEに書き込むにはTWE-Programmerを使用します。詳しい使い方はこちらを参照ください。

BINファイルが出来上がれば、実機で動作させることになります。繊細な電子部品ですので、取り扱いには十分注意してください。以下に代表的な注意事項を記載します。

特にTWELITE Rを用いている場合は、多くの場合電子基板がケースなどを介さず直接外部に触れる状態で使用するため、意図しないショートやノイズなどUSBデバイスが正常に動作しない状態になる場合があります。

この場合は、アプリケーションを終了させUSBデバイスを抜き差しすることで通常は回復します。最悪、USBデバイスの破損やPCの破損も考えられます。

電子基板の取り扱いには十分注意してください。

回路の間違い
- 電源を入れる前にはもう一度回路を確認してください。
- 電池の逆差しや過大電圧には注意してください。
静電気
- 人感がない電圧であっても半導体の故障になりえます。大掛かりな対応をしなくとも、金属部に触れてから作業する・リストバンド・専用マットなど簡易にできる対応でも相応の効果はあります。
金属物などが触れることでのショート
- 電子基板の近くには金属物がないようにしてください。クリップなどが散らかっているとこれが原因でショートすることもありますし、電池が大放電して加熱する危険な状況も考えられます。

1. 事前に MONOSTICK や TWELITE R をPCに差し込んでドライバのセットアップを終了しておく。

デバイスが認識されれば、新たにCOMポートが追加されます。複数あってわかりにくい場合は、抜いた状態でのCOMポートと刺した状態でのCOMポートの様子を観察してみてください。

デバイスマネージャでデバイスの存在が確認できない場合は、FTDI社のドライバ導入を行ってみてください。FT232R用のドライバを選択します。

2. TWE-Programmer.exe を起動する。

{MWSDKインストールディレクトリ}/Tools/TWE-Programmerディレクトリを開き、TWE-Programmer.exe をダブルクリックします。

TWE-Programmer.exe を起動すると以下のような画面になります。画面例では、起動前に MONOSTICK を差し込んでいて COM6 に割り当てられています。

MONOSTICK や TWELITE R が表示されない場合は以下を試してください。

TWE-Programmer を終了する。
MONOSTICK や TWELITE RをPCから抜く（取り外す）。
もう一度MONOSTICK や TWELITE Rを差し込む。
TWE-Programmer を起動する。

これでもうまくいかない場合は以下も試してください。

PCから可能な限り他のUSBデバイスを取り外す。
PCを再起動してからMONOSTICK や TWELITE Rを差し込んでみる。
FTDI社のドライバを再導入してみる。

3. TWE-Programmer 上で BIN ファイルを指定する。

ファイルダイアログから BIN ファイルを指定します。

4. BINファイルの書き込み

BINファイルの書き込みは、BINファイルを指定すると自動で行われます。

5-1. 書き込み成功時

書き込みが成功するとTWELITEは自動でリセットして、ターミナルが表示されます（ターミナル接続するにチェックが入っている場合）。

MWSDK添付のアクトファイルは始動時にメッセージを表示します。何か表示されれば書き込みは無事終了し、TWELITE 無線モジュール上のアクトが無事に動作していることが確認できます。

ターミナルを開いたままで、アクトを編集して再度書き込みたいときはCtrl+Alt+Wキーを押します。

5-2. 書き込み失敗時

書き込みに失敗したときは、ターミナルは開かず、TWE-Programmerのウインドウ背景がピンク色になります。

書き込みが失敗したときは (再)書き込みボタンを押して、もう一度書き込みを実行してください。

TWE-Programmer が反応しないなど、うまくいかない場合は、以下を実行した上、USBへの接続からやり直してください。

TWE-Programmer を終了する
MONOSTICK や TWELITE Rを取り外す

場合によってはPCの再起動を行ってください。

TWELITE PAL での書き込み中に、ハードウェア・ウォッチドッグタイマーが作動し書き込みが中断する場合があります。再度、書き込みを行ってください。

tweterm.py

本プログラムは pyftdi () ライブラリサンプルスクリプト pyterm.py に TWELITE 用のファームウェア書き込みスクリプトを組み込んだものです。以下の機能があります。

TWELITE 用ファームウェアの書き込み　(TWELITE R/MONOSTICK)
シリアルポートでの動作振る舞いの確認

本スクリプトの OS X での実行には Python3 インタプリタが必要です。コマンドライン環境ならびに Python インタプリタの取り扱いに慣れた方を対象とします。

本スクリプトを Linux で動作させるには同等のパッケージ (libusb-dev, pyserial, pyftdi) を用意します。コマンドライン環境ならびに Python インタプリタの取り扱いに慣れた方を対象とします。

参考環境：Ubuntu 18.04 (x86-64 64bit), Python 3.6.5

動作環境・必要パッケージ

Mac OS X または Linux
python3.5 以降
libusb
pyserial
pyftdi

開発環境

以下の環境で開発、動作確認を実施しました。ただし、これら環境で動作を保証するものではありません。

インストール

パッケージのインストール

以下の手順はパッケージ管理システムのバージョンアップや仕様変更で、そのまま適用できない場合があります。一般の情報などを参考にしてください。

以下では、Homebrew を用いた新しく全パッケージをインストールする例をご紹介します。

Homebrew

Homebrew をインストールします。

Python3

libusb

pyserial

pyftdi

お使いのディストリビューションのパッケージ導入法を調べてください。以下のパッケージが必要です。

python3.5 以降 (多くの場合導入されています)
libusb-dev
pyserial
pyftdi

パッケージ導入コマンド例。

実行

TWELITE SDK をインストールしたディレクトリを ${TWELITESDK} と記載します。

スクリプトは以下になります。

スクリプトに実行許可を与えます。

必要に応じて環境変数 PATH に追加しておきます。

利用方法

USBドライバのアンロード

libusb と OS のドライバが競合するため、ドライバをアンロード（無効に）しておきます。

FTDI 関連のドライバをアンロードします。

ドライバのアンロードは不要です。

エラーが出る場合は、ドライバをアンロードを試してみてください。

コマンドパラメータ

キーボード操作

Ctrl+C キーを入力することで制御プロンプトを表示し、いくつかの特別な操作が可能です。それ以外の場合は、直接 TWELITE 無線モジュールに入力文字列が送付されます。

書式解釈中は TWELITE からの電文は解釈できた電文のみ表示し、キーボードの入力はエコーバックされますが、アスキー形式の電文が完成した時に TWELITE に送付されます。

[実行例]

実行例中では、適宜改行を挟んでいます。

エラーが発生する場合は、シリアルポートの権限の問題かもしれません。root権限(sudo等)で実行します。

＜最初にデバイスがリストされるかを確認します＞

＜ファームウェアを書き込んでターミナルを起動します＞

以下の例では App_UART (UART 通信アプリ) を書き込み、起動メッセージを確認しています。

＜Ctrl+Cを入力すると制御プロンプトが表示されます＞

＜続けて i を入力します。インタラクティブモードに入ります＞

通常通り + + + と３回入力しても同じ結果になります。

＜書式の解釈の例：App_UART をバイナリ形式に設定しておきます＞

インタラクティブモードで m B Enter S と順に入力します。

＜書式の解釈の例＞

以下の例ではApp_UARTがバイナリ形式で入出力を行ないます。Ctrl+C B を入力します。

この状態では入出力は書式形式となります。キーボードの入力はアスキー形式、 TWELITE からの電文はバイナリ形式として解釈します。

TWELITE からの電文を受け取る例を示します。一番簡単な方法は TWELITE をリセットします。Ctrl+C r を入力します。

出力された [dbf...] がTWELITEからの電文で実際は0xdb 0xf1 0x67... と続くバイナリ列になります。

反対に TWELITE に電文を送る場合はアスキー書式で入力します。:7800112233AABBCCDDX と入力します。ここではペイロードが 0x7800112233AABBCCDD のデータをバイナリ形式で TWELITE に送付しています。直後に応答として [dba18001] が戻ってきています。

＜終了します＞

Ctrl+C Ctrl+C を入力します。

新しいプロジェクトの作成

新しいプロジェクトの作成は、すでにあるサンプルアクトのディレクトリを別の名前でコピーし、ファイル名の編集を行います。

コピー先のディレクトリは MWSDK 配下のディレクトリでなくても構いません。ただし、ディレクトリ名に空白文字や日本語名が含まれてはいけません。

MWSDK以外のディレクトリにコピーした場合 VS Code のワークスペース定義の一部が機能しなくなります。ワークスペースにmwxライブラリのソースコードディレクトリが追加されている場合は、新たに設定してください。

ライブラリソース設定をしなくてもビルドには影響はありません。より深いコード解釈をVSCode上で行い、編集効率を上げるための設定です。

プロジェクトのファイル構造は以下のようになっています（ここでは PingPong を例に挙げます）。

Act_samples
  +-PingPong
    +-PingPong.cpp   : アクトファイル
    +-build          : ビルドディレクトリ
    +-.vscode        : VS Code 用の設定ファイル

この PingPong ディレクトリを別の場所（ただしディレクトリ名に日本語や空白が含まない）にコピーします。

SomeDir
  +-AlphaBravo
    +-PingPong.cpp -> AplhaBravo.cpp ※ファイル名を変更
    +-build          : ビルドディレクトリ
    +-.vscode        : VS Code 用の設定ファイル

編集の必要があるのは、PingPong.cpp のファイル名です。これをディレクトリ名と同じAlphaBravo.cppに変更します。

build\build-BLUE.cmd を実行してBINファイルが生成されれば完了です（Windows10）。

Linux/WSL/macOS ではmake TWELITE=BLUEを実行して、ビルドが成功するか確認します。

~~プロジェクトのディレクトリ名と同じ名前の .cpp ファイルは必須です。~~ (MWSDK 2020-04 では、任意のファイル名でOKになりました)
ビルド対象のファイルを追加する場合は build/Makefile を編集します。編集方法は Makefile の解説をご覧ください。

ビルド定義 Makefile

Makefileはbuild/Makefileに格納されています。makeコマンドを実行することで、アクトをビルドするよう予め定義されています。

MWSDK 2020-04 では、プロジェクトディレクトリ中の .cpp ファイルを自動で検出するため、通常は Makefile の修正は不要です。

ソースファイルをサブディレクトリに格納するような場合は、編集が必要になります。

MWSDK 2019-12では、.cpp ファイルが複数ある場合は、Makefile の編集が必要です。

プロジェクトディレクトリを他の環境からコピーしたあとには、必ずbuild/objs_???ディレクトリを削除してください。他の環境での中間ファイルが残っているとmakeがエラーになります。

(MWSDK 2020-04) USE_APPDEPS=0 を付加して clean してから、改めて make コマンドを実行することでエラーを回避できます。

$ make USE_APPDEPS=0 TWELITE=BLUE clean ... $ make TWELITE=BLUE

makeのパラメータ

TWELITE=

ビルド対象をBLUEまたはREDで指定します。TWELITE BLUEならmake TWELITE=BLUEと指定します。

all

ビルドを実行します。通常は省略してmake TWELITE=BLUEのように実行します。

clean

ビルドの中間ファイルを削除します。make TWELITE=BLUE cleanのように実行します。

cleanall

すべての中間ファイルを削除します。make cleanallのように実行します。buildディレクトリのobjs_???ディレクトリをすべて削除するのと同じです。

USE_APPDEPS=0 または 1

1 (デフォルト) を設定すると、ファイルの依存関係をもとに、ビルドファイルを決定します。例えば、ヘッダファイルに変更があった場合に関連するソースファイルが再コンパイル対象となります。

0 では依存関係を評価しません。0 に設定した場合、矛盾ある中間ファイルが残っていても makefile がエラーになりません。

Makefile 定義

アクトの規模に応じて、また、ビヘイビアの定義をする場合には、通常はソースファイルを分割してビルドします。

ビルドファイルの一つは{プロジェクトフォルダ名.cpp}です。

他にファイルを定義する場合は、プロジェクトフォルダのbuild/Makefileを編集します。

##############################################################################
# Copyright (C) 2019 Mono Wireless Inc. All Rights Reserved.
# Released under MW-SLA-*J,*E (MONO WIRELESS SOFTWARE LICENSE
# AGREEMENT). 
##############################################################################
# USER PROJECT BUILD DEFINITION.
##############################################################################

#####################################################################
### set TWELITE model
TWELITE ?= BLUE
#TWELITE = RED

#####################################################################
### set application version (MUST SET THIS.)
VERSION_MAIN = 0
VERSION_SUB  = 1
VERSION_VAR  = 0

#####################################################################
### set an additional source file
###   the default file name is dirname.

### for C++ files compiled with g++ (must have .cpp suffix)
APPSRC_CXX += myAppBhvParent.cpp
APPSRC_CXX += myAppBhvParent-handlers.cpp
APPSRC_CXX += myAppBhvChild.cpp
APPSRC_CXX += myAppBhvChild-handlers.cpp

### for C files compiled with gcc (must have .c suffix)
#APPSRC += my_c_file.c

### Additional Src/Include Path
# if set, find source files from given dirs.
#
APP_COMMON_SRC_DIR_ADD1 = ../Parent
APP_COMMON_SRC_DIR_ADD2 = ../Child
#APP_COMMON_SRC_DIR_ADD3 = 
#APP_COMMON_SRC_DIR_ADD4 =

#####################################################################
### set misc option for compiler

### C++ flags passed to g++
# e.g. CXXFLAGS += -DMY_DEFS
#CXXFLAGS +=

### C++/C flags passed to g++/gcc
# e.g. CFLAGS += -DMY_DEFS
#CFLAGS +=

### include opts
# e.g. INCFLAGS += -I../my_common_src/
#INCFLAGS +=

### optimize flag (default is -Os, normally no need to change)
#OPTFLAG=-O2

#####################################################################
### must include mwx.mk (the makefile body part.)
MWSDK_PATH?=$(realpath $(MWSDK_ROOT))
include $(MWSDK_PATH)/MkFiles/mwx.mk
#####################################################################

上記はサンプルPAL_AMB-bihaviorでのMakefileの例です。

VERSION_???

### set application version (MUST SET THIS.)
VERSION_MAIN = 0
VERSION_SUB  = 1
VERSION_VAR  = 0

バージョン番号を指定します。ビルド結果ファイル名に反映されます。

コンパイル中は -DVERSION_MAIN=0 -DVERSION_SUB=1 -DVERSION_VAR=0のように定義として渡されます。

ソースファイルの追加

(MWSDK 2020-04) サブディレクトリにファイルを配置しない場合は、追加指定は不要になりました。プロジェクトファイルにある .c .cpp ファイルがすべて追加されます。

ソースファイルを追加する際に必要なのはAPPSRC_CXXとAPP_COMMON_SRC_DIR_ADD?です。

サブディレクトリにソースファイルを配置する場合は必ずディレクトリ APP_COMMON_SRC_DIR_ADD? の指定が必要です。

ソースファイル名をAPPSRC_CXXに追記します。このファイル名にはディレクトリ名が含まれてはいけません。サブディレクトリにあるものもディレクトリなしで指定します（つまり同じファイル名がサブディレクトリにある場合は、ビルドが失敗します）

APPSRC_CXX += myAppBhvParent.cpp
APPSRC_CXX += myAppBhvParent-handlers.cpp
APPSRC_CXX += myAppBhvChild.cpp
APPSRC_CXX += myAppBhvChild-handlers.cpp

次にソースファイルがプロジェクトディレクトリ以外の場所に格納されている場合の検索パスを指定します。最大４つまで設定できます。

APP_COMMON_SRC_DIR_ADD1 = ../Parent
APP_COMMON_SRC_DIR_ADD2 = ../Child

ディレクトリの指定はMakefileからの相対パスになります。

コンパイル・リンカオプション

その他にもいくつかのオプションをコンパイラ・リンカに渡すことができます。

他のプラットフォーム

他のプラットフォームでも一部の機能(serparser, pktparser, コンソール用Serialオブジェクト)をビルドできるように、ビルド定義を用意しています。必要なファイルのみを切り出しています。

ビルド定義は{mwxライブラリ格納}/stdioフォルダに格納しています。ビルド方法はREADME.md(リンクはGitHub上)を参照してください。

C++11でのコンパイルが出来ること。
C++11の標準ライブラリヘッダが利用できること (utility, algorithm, functional, iteratorなど)
new/delete/virtualは使用しません。
newによるメモリ確保は例外的に使用する場合があります。
- serparser/pktparserでnew演算子を利用するalloc_heapではdeleteによる処理を行っています。
- （参考）ただしmwxライブラリとしてはdeleteについては考慮しない前提で設計されている部分もあります。

アクトのビルド

MWXライブラリで記述したアプリケーションプログラムをアクト(Act)と呼びます。まずは、これをビルドして書き込みます。

ビルドディレクトリ構成について
ビルドスクリプトについて
VS Code でのビルドについて

ビルドディレクトリ構成について

MWSDKをインストールしたディレクトリMWSDK_ROOT (例 C:\MWSDK)を開きます。以下のような構成になっています。

MWSDK_ROOT
  |
  +-ChipLib      : 半導体ライブラリ
  +-License      : ソフトウェア使用許諾契約書
  +-MkFiles      : makefile
  +-Tools        : コンパイラ等のツール一式
  +-TWENET       : TWENET/MWXライブラリ
  +-Act_samples  : アクトサンプル
  ...

アクトファイルはAct_samples 以下に格納しています。（以下は一部割愛しています）

Act_samples
  |
  +-CoreAppTwelite    : App_TweLiteと同じ構成のボード用のアクト
  +-PAL_AMB           : 環境センス PAL 用のアクト
  +-PAL_MAG           : 開閉センス PAL 用のアクト
  +-PAL_MOT           : 動作センス PAL 用のアクト
  ..
  +-Parent-MONOSTICK  : 親機アクト、MONOSTICK用
  +-PingPong          : PingPong アクト
  +-PulseCounter      : パルスカウンタを利用したアクト
  +-act0              : スクラッチ（とりあえず書いてみる）用アクト

これらのアクトは、MWXライブラリの記述の参考となるシンプルな例ですが、多くのアクトは以下の機能を有しています。

センサー値を取得する
センサー値取得後、無線パケットを親機宛に送信する
送信完了後、一定時間スリープする（または割り込みを待つ）

実際に動作させてみるときは、以下の組み合わせを試してみてください。

では、アクトの中から PingPong のディレクトリの中を見てみましょう。

Act_samples にある他のアクトもビルドできます。その場合、ディレクトリ名・ファイル名は読み替えるようにしてください。

Act_samples
  +-PingPong
    +-PingPong.cpp   : アクトファイル
    +-build          : ビルドディレクトリ
    +-.vscode        : VS Code 用の設定ファイル

必ずディレクトリ直下にディレクトリと同名の .cpp ファイルが必要です。

次にビルドディレクトリを開きます。

Act_samples
  +-PingPong
    +-build
      +-Makefile        : makefile
      +-build-BLUE.cmd  : TWELITE BLUE 用ビルドスクリプト
      +-build-RED.cmd   : TWELITE RED 用ビルドスクリプト
      +-build-clean.cmd : obj_* ファイル削除

ビルドに必要なスクリプトとMakefileが格納されています。

ビルドスクリプト(Windows10)

macOS, Linux ではVS Codeまたはコマンドラインによるビルドを行います。

ビルドスクリプトは、エラーがあまり出ることのない、完成済みのアクト、サンプル提供のアクトなどに向いています。

以下は Windows10用のスクリプト（バッチファイル）です。

BINファイルが出来上がればビルド成功です。

objs_BLUEディレクトリはビルド中に生成された中間ファイルです。削除してもかまいません。

エラーメッセージを効率的に参照したい場合は VS Code などの開発ツールの利用を推奨します。

クリーン（中間ファイルの削除）

build-clean.cmdを実行すれば、objs_ で始まるディレクトリを消去します。BINファイルは消去しません。

コマンドライン(Linux/macOS)でのビルド

コマンドライン環境でのビルドについて補足します。

コマンドライン(bash)についての利用の知識が必要です。

MWSDK_ROOT=/mnt/c/MWSDK
export MWSDK_ROOT

コマンドライン(bash)よりmakeを実行します。makeがない場合はパッケージをインストールする必要があります。

$ make

Command 'make' not found, but can be installed with:

sudo apt install make
sudo apt install make-guile

$ sudo apt install make
...

Linux/WSL環境ではmakeまたはbuild-essentialパッケージをインストールします。
macOS環境ではXcodeでCommand Line Toolsをインストールします。

ビルドは以下のようになります。

$ cd $MWSDK_ROOT
$ cd Act_samples/PingPong/build
$ pwd
/mnt/c/MWSDK/Act_samples/PingPong/build

$ ls
... ファイル一覧の表示

$ rm -rfv objs_*
... 念のため中間ファイルを削除

$ make TWELITE=BLUE
... BLUE用に通常ビルド

$ make -j8 TWELITE=BLUE
... BLUE用にパラレルビルド(同時に8プロセス)

中間ファイルについて

makeがエラーとなった場合は直接objs_???ディレクトリを削除してください。

コマンド例

詳細はMakefileの解説をご覧ください。

VS Code でのビルドについて

ビルドには TWELITE STAGE を推奨します。

MWSDK付属のサンプルプロジェクトのVS Code定義ファイルは可能な限り実施しますが、一部定義が不完全なものも含まれます。

VS Code では、Act_samplesディレクトリ直下にあるワークスペースファイルを開くか、Act_samples以下のアクトディレクトリを開きます。

以下の例では英語インタフェースの画面例で、ワークスペースを開いています。

ワークスペースを開き [Terminal>Run Task...] を選択します。

ビルド中の経過は画面下部の TERMINAL 部分に出力されます。

またBINファイル（上記では PingPong_BLUE_???.bin）ファイルがbuildディレクトリ下に出来上がっているはずです。確認してみてください。

ビルド定義には Windows10 のファイルシステムに適合しないディレクトリ名 (例：/c/User/...)を変換する(例：C:/User/...) 定義を追加しています。

変換は完全ではありませんが、コンパイルメッセージからエラーが発生しているファイル名と行番号を抽出できます。

...
"windows": {
    "command": "sh",
    "args": [
        "-c", "make TWELITE=BLUE 2>&1 | sed -E -e s#\\(/mnt\\)?/\\([a-zA-Z]\\)/#\\\\\\2:/#g"
    ],

WSLについて

WSL (Windows Subsystem for Linux) は Windows10 のサブシステムとして動作する Linux 環境です。

MWSDK2020_05 .. 2020_10

MWSDK/Tools/ba-elf-ba2-r36379.w10 以下に Windows10用とLinux用の実行形式が両方含まれます。WSLを動作させ環境変数MWSDK_ROOTを適切に設定します。

例えば C:\Work\MWSTAGE\MWSDK の場合は以下のように設定します。

$ export MWSDK_ROOT=/mnt/c/Work/MWSTAGE/MWSDK

MWSDK2020_12

TWELITE STAGE SDK パッケージには、WSL用の実行形式は含まれません。

ツールの選択

MWSDK/Tools/MkFiles/rules.mkで環境の判定とツールディレクトリの選択をしています。以下はrules.mkの抜粋でWSLENVの環境変数の有無で判定しています。

# Configure for WSL (Windows Subsystem Linux)
ifneq ($(origin WSLENV),undefined)
$(info !!!WSL environment, use Linux toolchain instead.)
TOOLCHAIN_PATH = ba-elf-ba2-r36379.wsl
endif

tweterm.py

TWELITE 用ファームウェアの書き込み　(TWELITE R/MONOSTICK)
シリアルポートでの動作振る舞いの確認

参考環境：Ubuntu 18.04 (x86-64 64bit), Python 3.6.5

動作環境・必要パッケージ

Mac OS X または Linux
python3.5 以降
libusb
pyserial
pyftdi

開発環境

以下の環境で開発、動作確認を実施しました。ただし、これら環境で動作を保証するものではありません。

インストール

パッケージのインストール

以下では、Homebrew を用いた新しく全パッケージをインストールする例をご紹介します。

Homebrew

Homebrew をインストールします。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Python3

$ brew install python3

libusb

$ brew install libusb

pyserial

$ pip3 install pyserial

pyftdi

$ pip3 install pyftdi

お使いのディストリビューションのパッケージ導入法を調べてください。以下のパッケージが必要です。

python3.5 以降 (多くの場合導入されています)
libusb-dev
pyserial
pyftdi

パッケージ導入コマンド例。

$ sudo apt-get install libusb-dev
$ sudo apt-get install python3-pip
$ pip3 install pyserial
$ pip3 install pyftdi

実行

TWELITE SDK をインストールしたディレクトリを ${TWELITESDK} と記載します。

スクリプトは以下になります。

${TWELITESDK}/Tools/tweterm/tweterm.py

スクリプトに実行許可を与えます。

$ chmod +x ${TWELITESDK}/Tools/tweterm/tweterm.py

必要に応じて環境変数 PATH に追加しておきます。

$ PATH=${TWELITESDK}/Tools/tweterm:$PATH

利用方法

USBドライバのアンロード

libusb と OS のドライバが競合するため、ドライバをアンロード（無効に）しておきます。

FTDI 関連のドライバをアンロードします。

$ sudo kextunload -b com.apple.driver.AppleUSBFTDI

ドライバのアンロードは不要です。

エラーが出る場合は、ドライバをアンロードを試してみてください。

$ sudo rmmod ftdi_sio
$ sudo rmmod usbserial

コマンドパラメータ

キーボード操作

[実行例]

実行例中では、適宜改行を挟んでいます。

エラーが発生する場合は、シリアルポートの権限の問題かもしれません。root権限(sudo等)で実行します。

＜最初にデバイスがリストされるかを確認します＞

$ tweterm.py -p ftdi:///?
Available interfaces:
  ftdi://ftdi:232:MW19ZZUB/1   (MONOSTICK)
  Please specify the USB device

＜ファームウェアを書き込んでターミナルを起動します＞

以下の例では App_UART (UART 通信アプリ) を書き込み、起動メッセージを確認しています。

$ tweterm.py -p ftdi://ftdi:232:MW19ZZUB/1 -b 115200 -F ../App_Uart_Master_RED_L1101_V1-2-15.bin 
*** TWE Wrting firmware ... ../App_Uart_Master_RED_L1101_V1-2-15.bin
MODEL: TWEModel.TWELite
SER: 102eebd

 file info: 0f 03 000b
erasing sect #0..#1..#2..
0%..10%..20%..30%..40%..50%..60%..70%..80%..90%..done - 10.24 kb/s
Entering minicom mode

!INF TWE UART APP V1-02-15, SID=0x8102EEBD, LID=0x78
8102EEBD:0>

＜Ctrl+Cを入力すると制御プロンプトが表示されます＞

*** r:reset i:+++ A:ASCFMT B:BINFMT x:exit>

＜続けて i を入力します。インタラクティブモードに入ります＞

*** r:reset i:+++ A:ASCFMT B:BINFMT x:exit>[+ + +]
--- CONFIG/TWE UART APP V1-02-15/SID=0x8102eebd/LID=0x00 -E ---
 a: set Application ID (0x67720103) 
 i: set Device ID (121=0x79) 
... ＜省略＞

通常通り + + + と３回入力しても同じ結果になります。

＜書式の解釈の例：App_UART をバイナリ形式に設定しておきます＞

インタラクティブモードで m B Enter S と順に入力します。

--- CONFIG/TWE UART APP V1-02-15/SID=0x8102eebd/LID=0x00 -E ---
 a: set Application ID (0x67720103) 
 i: set Device ID (121=0x79) 
 c: set Channels (18) 
 x: set RF Conf (3) 
 r: set Role (0x0) 
 l: set Layer (0x1) 
 b: set UART baud (38400) 
 B: set UART option (8N1) 
 m: set UART mode (B)*
 h: set handle name [sadkasldja] 
 C: set crypt mode (0) 
 o: set option bits (0x00000000) 
---
 S: save Configuration
 R: reset to Defaults
 
!INF Write config Success
!INF RESET SYSTEM...

＜書式の解釈の例＞

以下の例ではApp_UARTがバイナリ形式で入出力を行ないます。Ctrl+C B を入力します。

*** r:reset i:+++ A:ASCFMT B:BINFMT x:exit>
[FMT: console ASCII, serial BINARY]

この状態では入出力は書式形式となります。キーボードの入力はアスキー形式、 TWELITE からの電文はバイナリ形式として解釈します。

TWELITE からの電文を受け取る例を示します。一番簡単な方法は TWELITE をリセットします。Ctrl+C r を入力します。

*** r:reset i:+++ A:ASCFMT B:BINFMT x:exit>[RESET TWE]
[dbf1677201030001020f008102eebd0000]

出力された [dbf...] がTWELITEからの電文で実際は0xdb 0xf1 0x67... と続くバイナリ列になります。

:7800112233AABBCCDDX[dba18001]

＜終了します＞

Ctrl+C Ctrl+C を入力します。

*** r:reset i:+++ A:ASCFMT B:BINFMT x:exit>[
[EXIT]
Bye