2024年6月30日日曜日

TOPPERS/ASP - Arduino UNO R4版 その8

前回からの続きです。

このテーマを最初からご覧になる場合はこちらからどうぞ。


「e2 Studio」で普通にFSPを使う

さて、これまでにも何回か言及している通り、この「TOPPERS/ASP Arduinp UNO R4版」を使った「Arduino」は、もはやArduinoではありません。

便利な「Arduino IDE」も使えませんし、豊富なArduino用のライブラリも使えません。

つまり、安価なRenesas RAマイコン評価ボードになってしまったとも言えます。

しかし、単にライブラリという意味では「Arduino IDE」ではなく「e2 studio」を使用した開発でもFSP(Flexible Software Package)が使用できます。

このFSPについては、過去記事を参照してください。

FSPをうまく利用すれば、Arduino用のライブラリとまでは言えませんが、RAマイコンの持つ色々な機能をライブラリとして利用したソフトウェアを楽に開発できます。

いきなり「TOPPERS/ASP Arduinp UNO R4版」上でFSPを使うのは少々ハードルが高いです。

ですので、今回は、OSレスでフツーにFSPを使用する方法をご紹介します。

そのためには、以前作成した「Hinagata」プロジェクトを「e2 studio」で開きます。

んなもんとっくに消しちゃったよ~って方は、コチラを参考に再度作成してください。

「e2 studio」 - 1


今回は、この「Hinagata」プロジェクトでFSPを使用して、シリアル通信ポートを使えるようにライブラリを追加しましょう。

どのピンにシリアルポートを割り当てましょうか?

シリアル通信には、TXD(送信)、RXD(受信)、GNDの計3本の線が必要です。

GNDは適当で良いとして…、TXD(送信)、RXD(受信)は、以下の回路図のピンを使用することにしましょう!

回路図


絵にすると、以下の通りです。

Arduino UNO R4


これで…

SCI2」というシリアルポートの送信(TXD)信号を「P302」というポートに

SCI2」というシリアルポートの受信(RXD)信号を「P301」というポートに、それぞれ設定すれば良いことが分かります。

これを「e2 studio」で「Hinagata」プロジェクトに設定すればよいのですが、マイコンのピンを機能に割り付ける作業は、実は以前の記事で行っています。

その時に、今回使用する「P302」も「P301」も「SCI2」というシリアルポートで使用できるように既に設定されています。

したがって、残りの作業はシリアル通信のライブラリを設定することだけです!

「e2 studio」の左側の「プロジェクト・エクスプローラー」で「Hinagata」プロジェクト以下に「configuration.xml」というファイルがありますので、これをダブルクリックしてください。

すると、画面中央には「[Hinagata]FSP Configuration」というタブが追加されると思います。

「e2 studio」 - 2

次に、開いた「[Hinagata]FSP Configuration」タブの下にもいくつかのタブがありますので、この中から「Stacks」というタブをクリックします。

以下のように、なにやら「HAL Common Stacks」と題された表示に切り替わります。

「e2 studio」 - 3


この画面で必要なスタック…ライブラリとかドライバを追加していきます。

今回はシリアル通信、すなわちUARTのスタックを追加すれば良いわけですね。

HAL Common Stacks」という表示の右側に「New Stack >」というボタンがありますので、これをクリックするとメニューが表示されます。

メニューの中から「Connectivity」を、更に展開されるメニューで今回のお目当てである「UART(r_sci_uart)」を順にクリックします。

「e2 studio」 - 4


すると、以下のように「HAL Common Stacks」の表示が切り替わり、UARTスタックが追加されたことが分かります。

追加されたUARTスタックですが、デフォルトのままでは都合が悪いので、プロパティをいじらないとなりません。

それには「[Hinagata]FSP Configuration」タブの下のビューの中の「プロパティー」タブをクリックします。

「e2 studio」 - 5


以下は、分かりやすいように拡大した「プロパティー」タブです。

ここには、追加されたUARTスタックの各種設定が表示されています。

これらの中から以下の項目を変更します。

前述した通り、今回は「SCI2」というシリアルポートを使用したいので、それに沿った変更を行います。


Name:g_uart2

Channel:2

Callback:uart2_callback

「e2 studio」 - 6


次に、以下の項目を確認しておきます。

ボーレートが115200bpsに設定されていることは、覚えておきましょう。

また、こちらも前述の通り、送信(TXD_MOSI)信号が「P302」というポートに、受信(RXD_MISO)信号が「P301」というポートに、それぞれ設定されていることを確認します。


Baud Rate:115200

TXD_MOSI:P302

RXD_MISO:P301

「e2 studio」 - 7


オッケー。

じゃあ、この状態でUARTスタックを追加した新しい「Hinagata」プロジェクトのソースコードを出力しましょう。

メインビューの「[Hinagata]FSP Configuration」タブの右上にある「Generate Project Content」ボタンをクリックします。

「e2 studio」 - 8


こんなポップアップが出たら「続行」ボタンをクリックで。

そういや、UARTスタックの追加とかプロパティの変更とか、保存してなかったや…。

「Generate Project Content」ポップアップ


処理が終わると、UARTスタックが追加された「Hinagata」プロジェクトが出来上がっているはずです。

試しに画面左側の「プロジェクト・エクスプローラー」で「ra_gen」ディレクトリ以下の「hal_data.c」をダブルクリックして、ソースコードを見てみましょう。

ソースコードの中にUARTスタックのプロパティで設定した「g_uart2」という文字列がいくつか確認できますね?

「e2 studio」 - 9


更に、新しい「Hinagata」プロジェクトのソースツリーの中には「uart」と記述されたソースコードやヘッダファイルがいくつも見つかります。

これらが追加されたUARTスタックの本体です。

「e2 studio」 - 10


さて、UARTスタックを手に入れた新しい「Hinagata」プロジェクトですが、これをビルドして動かしても何も起こりません。

UARTスタックを使う…すなわちシリアル通信を行うアプリケーションを実装しないと本当に正しく動くのか分かりませんよね?

というわけで、簡単なプログラムを実装して動作確認をしてみましょう。

プログラムを記述するのは「src」ディレクトリ以下の「hal_entry.c」です。

さっそく開いてみましょう。

「e2 studio」 - 11


この「hal_entry.c」ファイルに、以下のように「received」というフラグと「uart2_callback()」という関数を記述します。

  1. #include "hal_data.h"
  2. FSP_CPP_HEADER
  3. void R_BSP_WarmStart(bsp_warm_start_event_t event);
  4. FSP_CPP_FOOTER
  5. // ここから ----------------------------------------------------------------
  6. volatile bool recieved = false; // 受信完了フラグ
  7. void uart2_callback(uart_callback_args_t *p_args)
  8. {
  9.     if (p_args->event == UART_EVENT_RX_COMPLETE) {
  10.         // 受信が完了したら「r_sci_usrt.c」ファイルの
  11.         // 「sci_uart_rxi_isr()」割り込みハンドラからここに来る
  12.         recieved = true;
  13.     }
  14.     if (p_args->event == UART_EVENT_TX_COMPLETE) {
  15.         // 送信が完了したら「r_sci_usrt.c」ファイルの
  16.         // 「sci_uart_tei_isr()」割り込みハンドラからここに来る
  17.     }
  18.     if (p_args->event == UART_EVENT_RX_CHAR) {
  19.         // 一文字受信したら「r_sci_usrt.c」ファイルの
  20.         // 「sci_uart_rxi_isr()」割り込みハンドラからここに来る
  21.     }
  22.     if (p_args->event == UART_EVENT_ERR_FRAMING) {
  23.         // フレーミングエラーを検出した時に「r_sci_usrt.c」ファイルの
  24.         // 「sci_uart_eri_isr()」割り込みハンドラからここに来る
  25.     }
  26.     if (p_args->event == UART_EVENT_BREAK_DETECT) {
  27.         // ブレークを検出した時に「r_sci_usrt.c」ファイルの
  28.         // 「sci_uart_eri_isr()」割り込みハンドラからここに来る
  29.     }
  30.     if (p_args->event == UART_EVENT_TX_DATA_EMPTY) {
  31.         // 送信バッファが空になった時に「r_sci_usrt.c」ファイルの
  32.         // 「sci_uart_txi_isr()」割り込みハンドラからここに来る
  33.     }
  34. }
  35. // ここまで ----------------------------------------------------------------
  36. /*******************************************************************************************************************//**
  37.  * main() is generated by the RA Configuration editor and is used to generate threads if an RTOS is used. This function
  38.  * is called by main() when no RTOS is used.
  39.  **********************************************************************************************************************/
  40. void hal_entry(void)
  41. ...


お次は、その下の「hal_entry()」内に以下のコードを加えます。

  1. /*******************************************************************************************************************//**
  2.  * main() is generated by the RA Configuration editor and is used to generate threads if an RTOS is used. This function
  3.  * is called by main() when no RTOS is used.
  4.  **********************************************************************************************************************/
  5. void hal_entry(void)
  6. {
  7.     /* TODO: add your own code here */
  8.     // ここから ----------------------------------------------------------------
  9.     uint8_t c;
  10.     // シリアル通信を開く
  11.     R_SCI_UART_Open(&g_uart2_ctrl, &g_uart2_cfg);
  12.     while (1) {
  13.         // 受信する
  14.         R_SCI_UART_Read(&g_uart2_ctrl, &c, 1);
  15.         // 受信するまで待つ
  16.         while (!recieved);
  17.         // 受信完了フラグをリセットする
  18.         recieved = false;
  19.         // 受信した一文字を送信する
  20.         R_SCI_UART_Write(&g_uart2_ctrl, &c, 1);
  21.     }
  22.     // ここまで ----------------------------------------------------------------
  23. #if BSP_TZ_SECURE_BUILD
  24.     /* Enter non-secure code */
  25.     R_BSP_NonSecureEnter();
  26. #endif
  27. }


なにをやっているのか?…というのは、まあ、コメントに書いた通りなのですが。

まず、追加した「uart2_callback()」というのは、コールバック関数というもので、チャンネル2のシリアルポートに割り込みが発生した場合に処理が飛んでくる関数です。

「uart2_callback」という名称については、UARTスタックを追加した時「callback」プロパティで設定しましたよね?

で、割り込みが発生して「uart2_callback()」関数が飛んできて、その中で「p_args->event」変数の内容を調べて、それが受信完了割り込み…すなわち「UART_EVENT_RX_COMPLETE」というフラグを含んでいた場合は、冒頭で定義した「received」変数を「true」にする…という処理をしています。

割り込みには受信完了のほか、送信完了やエラー発生など、色々なものがあります。

上記の例では、ご丁寧に受信完了以外の条件分岐も記述されていますが、何も実装していないし、今回は受信完了割り込みしか使わないので、面倒だったらそれ以外のif文は省いてオッケーです。


さて、次に「hal_entry()」です。

これは、最初から実装されている関数です。

C言語のプログラムは、一般的に「main()」という関数から処理が始まります。

しかしながらFSPでは、その役割は「hal_entry()」が担っています。

とはいえ、これはFSPのお作法というか…実際「Hinagata」プロジェクトのソースツリーの中にも「main.c」ファイルが存在し、その中に「main()」関数も記述されています。

この「main()」は開始早々この「hal_entry()」を呼んでいるので「hal_entry()」は、実質「main()」と同じですね。

(こんな回りくどい実装をしているのは「main()」を直接いじれなくなるRTOSを使う場合を想定している旨が、関数の上のコメントに書いてありますね。)

追記した部分ですが「c」という変数を定義した後に「R_SCI_UART_Open()」という関数を呼んでいます。

これでUARTスタック、すなわちシリアルポートを使用する準備をします。

その後、whileループに入ります。

ループの冒頭で「R_SCI_UART_Read()」という関数を呼んでいます。

これは、シリアル通信の受信を行う関数です。

この関数は、受信が終わるまでロックする…ということもなく、素通りします。

受信ができたらその時点で、受信データは関数に渡した「c」のポインタに格納される仕組みとなっています。

さっきから頭に「R_SCI_UART_うんちゃら」という名前の関数が出てきていますが、これこそが今回追加したUARTスタックで提供されている関数です。

これらの関数は、今回使用するものの他にも多く用意されています。

詳しくは、こちらを御覧ください。

さて「R_SCI_UART_Read()」で受信を指示した後は、更にループに入ります。

このループは「received」が「true」にならない限り、ここでずっとグルグル回っているという処理、すなわち無限ループになります。

「received」の初期値は「false」ですから、最初は必ずグルグル回ります。

その間に受信完了割り込みが起きて、前述の「uart2_callback()」の中で「received」が「true」に変化したら、ようやくこの無限ループから次に進むことができます。

このループ、要はシリアル通信の受信待ちです。

ループを抜けると、次の受信に備えて「received」を「false」に戻しておきます。

この時には既に「c」の中には受信した1文字のデータが格納されているはずです。

次の「R_SCI_UART_Write()」関数で、その受信した「c」の中の1文字のデータを今度はそのまま送信します。

送信後は、また受信処理に戻り、それを永遠に繰り返します。

すなわち今回のアプリケーションは、シリアル通信で1文字受信すると、それと同じ1文字を送信する…というテストプログラムになります。


さて、思惑通りに動くかな?

物理的な接続です!

まずは、Arduinoとデバッガーとパソコンを接続します。

このページを参考にして欲しいのですが、唯一違うのがシリアル通信部分。

今回は変換ケーブルから出ている信号線ではなくて、Arduinoのピンソケットから取りましょう。

ピンソケットの位置は、今一度、このページの冒頭の図を参考に。

GNDSCI_TXD2およびSCI_RXD2の3本ですね。

こんな感じ。

物理的接続


USB/シリアル通信変換ケーブル側の配線は、上からTXDRXDGNDの順番でこんな感じです。

USB/シリアル通信変換ケーブル側の配線


これで「Hinagata」プロジェクトを走らせましょう。

まずは「プロジェクト・エクスプローラー」で「Hinagata」プロジェクトを右クリック、出てきたメニューから「プロジェクトのビルド」を左クリックしてください。

「e2 studio」 - 12

ビルドが終わったら、再び「プロジェクト・エクスプローラー」で「Hinagata」プロジェクトを右クリック、出てきたメニューから、今度は「デバッグ」を左クリック、更に表示されたメニューから「Renesas GDB Hardware Debugging」を左クリックします。

「e2 studio」 - 13


以下のダイアログが表示されたら「E2 Lite (ARM)」を選択状態にして、ダイアログ下部の「OK」ボタンをクリック。

「Renesas Hardware Debugging」ダイアログ - 1


再度、以下のダイアログが表示されたら「R7FA4M1AB」を選択状態にして、ダイアログ下部の「OK」ボタンをクリックです。

「Renesas Hardware Debugging」ダイアログ - 2


これでオッk…ああ!?

まあ、とりあえず「OK」ボタンをクリックで。

致命的なエラー


これを修正するには、このページの中盤くらいにある「エミュレーターから電源供給」の項目を「いいえ」に設定する必要があるようです。

デバッグの構成は「Hinagata.elf」という名前で、この時点で作成されています。

設定できたら「デバッグ」ボタンをクリックして、デバッグ開始です!

デバッグの構成


デバッグが開始されると、いくつかのポイントで自動的にブレークがかかります(2回くらいだっけか?)。

ブレークがかからなくなるまで「」ボタンをクリックしてプログラムを続行させましょう。

次に「TeraTerm」の起動です。

今回は、UARTスタックのプロパティで115200に設定したのですよね?

TeraTerm - 1


接続ができたら「TeraTerm」の画面でキーボードから何か文字を入力してみてください。

このように、入力した文字が「TeraTerm」にそのまま表示されれば動作確認は完了です!

TeraTerm - 2


「Hinagata」プロジェクトに無事UARTスタックが追加され、それが正常に動いていることが確認できました。

今回はUARTスタック、すなわちシリアル通信のライブラリを追加しましたが、I2CやSPIなどの他の通信の場合でも、FSPの使い勝手は概ね一緒です。

更には、AD変換やタイマーなど、FSPを使えばデバイスドライバを作成することなく簡単にこれらの機能をファームウェアで使用することが可能です。

便利な時代になりましたね~。


さて、今回はTOPPERS/ASPとは関係なく、フツーにFSPを使うだけの記事となってしまいました。

次回は、今回と同じプログラムを「TOPPERS/ASP Arduino UNO R4版」で動かす例を紹介します。

便利なFSPとTOPPERS/ASPを組み合わせて使うことができますよ!

あとは、今回のプログラムは受信待ちに「received」をフラグに無限ループを使うという、ある意味でダサい実装となってしまいました。

それがTOPPERS/ASPなどのRTOSを使用することで、どれだけスマートな実装になるのかも説明させていただきます。


…なにげに前回の投稿から2ヶ月も経っていたのですね。

ブログを書くのも趣味の一つなのですが、本業が忙しくてそれができないようだと、ライフワークバランスが崩壊しているなぁ~…と思います。

ライフのためのワークであって、ワークのためのライフでは本末転倒だと思う今日このごろです。


<続く>

2024年5月1日水曜日

MLAA License

OSSライセンスのメインページはこちらからどうぞ。

ライセンスの目次はこちらです。


 名称:「MLAAライセンス」(MLAA)


Raytrace no arealight


タイプ:

・コピーレフト…×

・ライセンス文の掲示…〇(ソースコード頒布のみ)

・コピーライト(著作権)…〇(ソースコード頒布のみ)

・その他…〇(バイナリ頒布のみ)


原文:


  • Copyright: 2010 Jorge Jimenez (jorge@iryoku.com)
  •      2010 Belen Masia (bmasia@unizar.es)
  •      2010 Jose I. Echevarria (joseignacioechevarria@gmail.com)
  •      2010 Fernando Navarro (fernandn@microsoft.com)
  •      2010 Diego Gutierrez (diegog@unizar.es)
  •      2011 Lauri Kasanen (cand@gmx.com)

  • Redistribution and use in source and binary forms, with or without
  • modification, are permitted provided that the following conditions are met:
  • .
  • 1. Redistributions of source code must retain the above copyright notice,
  •     this list of conditions and the following disclaimer.
  • .
  • 2. Redistributions in binary form must reproduce the following statement:
  • .
  •     "Uses Jimenez's MLAA. Copyright (C) 2010 by Jorge Jimenez, Belen Masia,
  •     Jose I. Echevarria, Fernando Navarro and Diego Gutierrez."
  • .
  •     Only for use in the Mesa project, this point 2 is filled by naming the
  •     technique Jimenez's MLAA in the Mesa config options.
  • .
  • THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
  • IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
  • THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  • PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL COPYRIGHT HOLDERS OR CONTRIBUTORS
  • BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  • CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  • SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  • INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  • CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  • ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  • POSSIBILITY OF SUCH DAMAGE.


日本語訳:


  • Copyright: 2010 Jorge Jimenez (jorge@iryoku.com)
  •      2010 Belen Masia (bmasia@unizar.es)
  •      2010 Jose I. Echevarria (joseignacioechevarria@gmail.com)
  •      2010 Fernando Navarro (fernandn@microsoft.com)
  •      2010 Diego Gutierrez (diegog@unizar.es)
  •      2011 Lauri Kasanen (cand@gmx.com)

  • 以下の条件が満たされる場合、修正の有無にかかわらず、
  • ソースおよびバイナリ形式での再配布および使用が許可されます:
  • ,
  • 1. ソース コードを再配布する場合は、上記の著作権表示、このライセンス文、
  •    および下に記述する免責事項を保持する必要があります。
  • .
  • 2. バイナリ形式で再頒布する場合は、次のステートメントを掲示する必要があります:
  • ,
  •     「JimenezのMLAAを使用しています。Copyright (C) 2010 by Jorge Jimenez、Belen Masia、
  •     Jose I. Echevarria、Fernando Navarro、Diego Gutierrez」
  • ,
  •     Mesaプロジェクトでのみ使用する場合、この条文2は、Mesaのコンフィグレーション・オプションで
  •     「technique」に「Jimenez's MLAA」という名前を付けることで満たされます。
  • ,
  • このソフトウェアは、<著作権所有者>と協力者によって「ありのまま」で提供され、
  • 明示的か黙示的かを問わず、商品性および特定目的への適合性の暗黙の保証を含む、
  • またそれらに限定されない、いかなる保証もしません。
  • いかなる場合も<著作権所有者>と協力者は契約に沿った行為か否かを問わず、
  • 損害発生の原因如何を問わず、
  • かつ責任の根拠が契約か厳格責任か(過失その他の)不法行為か否かを問わず、
  • 仮にそのような損害が発生する可能性を知らされていたとしても、本ソフトウェアの使用によって発生した
  • (代替品または代用サービスの調達、使用の喪失、データの喪失、利益の喪失、業務の中断も含む、またそれらに限定されない)
  • 直接損害、間接損害、偶発的な損害、特別損害、懲罰的損害、または結果損害について、
  • 一切責任を負わないものとします。


解説:

「MLAA」とは「Morphological Antialiasing」の略で、コンピューターグラフィックでは欠かせないアンチエイリアスの技法の一つです。

このライセンスは、Jorge Jimene氏を中心とするコミュニティが開発したアルゴリズムを含むグラフィック・ライブラリの一部に適用されています。

特徴は、ソースコード頒布か、バイナリ頒布かによって再配布の条件が異なることです。

バイナリ頒布の場合は、四条項BSDライセンスなどと同様、謝辞の掲示が必要になります。

このライセンスに限り謝辞の掲示の回避策も言及されていますが、このような条件は「真のオープンソース・ソフトウェアではない」とする意見もあり、しばしば議論となっています。


適用例:

「libgl1-mesa-dri」、「libglapi-mesa」、「libglapi-mesa」など、OpenGLなどのグラフィックAPIのオープンソース実装である「MESA」で使用されるライブラリの一部に適用されています。


頒布のために執るべき行動:


ソースコード頒布の場合:

ライセンス条文1により、ソースコードの改変の有無に関わらず、冒頭に記述されるこのライセンス文をそのまま改変することなく配布しましょう。

また同条文によるコピーライト(著作権)は、上記を守ることによって自動的に条件が満たされます。


バイナリ頒布の場合:

著作権表示やライセンス文の掲示の代わりに、以下の「その他:」で触れる謝辞を掲示する必要があります。


その他:

ライセンス条文2により、バイナリ頒布の場合、指定されている謝辞を掲示する必要があります。

但し、この条文2は、該当のソフトウェアをMesaプロジェクトでのみで使用し、且つコンフィグレーションの際に「technique」オプションで「Jimenez's MLAA」を選択することを条件に回避することができます。

(結構専門的な知識が必要なので、無理に回避しようとしない方が無難です。)

掲示は、このライセンスのソフトウェアを含む製品の取扱説明書やWebページなど、必ず容易にユーザーの目に触れる形で記述しましょう。

2024年4月24日水曜日

BSD 4-Clause License

OSSライセンスのメインページはこちらからどうぞ。

ライセンスの目次はこちらです。


名称:「四条項BSDライセンス」(BSD-4-clause)


BSDライセンス・ロゴ


タイプ:

・コピーレフト…×

・ライセンス文の掲示…〇

・コピーライト(著作権)の掲示…〇

・その他…〇


原文:


  • Copyright (c) <year>, <copyright holder>
  • All rights reserved.

  • Redistribution and use in source and binary forms, with or without
  • modification, are permitted provided that the following conditions are met:
  • 1. Redistributions of source code must retain the above copyright notice,
  •    this list of conditions and the following disclaimer.
  • 2. Redistributions in binary form must reproduce the above copyright notice,
  •    this list of conditions and the following disclaimer in the documentation
  •    and/or other materials provided with the distribution.
  • 3. All advertising materials mentioning features or use of this software
  •    must display the following acknowledgement:
  •    This product includes software developed by the <organization>.
  • 4. Neither the name of the <organization> nor the names of its contributors
  •    may be used to endorse or promote products derived from this software
  •    without specific prior written permission.

  • THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> ''AS IS'' AND ANY
  • EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
  • WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  • DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
  • DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
  • (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  • LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
  • ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  • (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
  • SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


日本語訳:


  • Copyright (c) <年>, <著作権所有者>
  • All rights reserved.

  • 以下の条件が満たされる場合、修正の有無にかかわらず、
  • ソースおよびバイナリ形式での再配布および使用が許可されます:
  • 1. ソース コードを再頒布する場合は、上記の著作権表示、このライセンス文、
  •    および下に記述する免責事項を保持する必要があります。
  • 2. バイナリ形式で再頒布する場合は、上記の著作権表示、このライセンス文、
  •    および下に記述する免責事項を、頒布物とともに提供されるドキュメントおよび/または
  •    その他の資料に転載する必要があります。
  • 3. このソフトウェアの機能または使用について言及するすべての広告資料には、
  •    次の謝辞を掲示する必要があります。
  •    「この製品には、<著作権者>によって開発されたソフトウェアが含まれています。」
  • 4. <著作権者>の名前もその貢献者の名前も、書面による事前の特別な許可がない限り、
  •    このソフトウェアから派生した製品を広報または宣伝するために使用することはできません。

  • このソフトウェアは、<著作権所有者>によって「ありのまま」で提供され、
  • 明示的か黙示的かを問わず、商品性および特定目的への適合性の暗黙の保証を含む、
  • またそれらに限定されない、いかなる保証もしません。
  • いかなる場合も<著作権所有者>は契約に沿った行為か否かを問わず、
  • 損害発生の原因如何を問わず、
  • かつ責任の根拠が契約か厳格責任か(過失その他の)不法行為か否かを問わず、
  • 仮にそのような損害が発生する可能性を知らされていたとしても、本ソフトウェアの使用によって発生した
  • (代替品または代用サービスの調達、使用の喪失、データの喪失、利益の喪失、業務の中断も含む、またそれらに限定されない)
  • 直接損害、間接損害、偶発的な損害、特別損害、懲罰的損害、または結果損害について、
  • 一切責任を負わないものとします。


解説:

BSDライセンスと呼ばれるものは、コピーレフトではないオープンソース・ライセンスの中では最もメジャーなライセンスです。

これにはいくつかの種類がありますが、この「四条項BSDライセンス」が最も古く制約の厳しいもので「旧BSDライセンス」とも呼ばれています。

特徴的なのは、コピーライト(著作権)に加え、謝辞の掲示も行わなければならないことです。

ライセンス条文3において<著作権者>を含めた謝辞を掲示せよ、としているのに対し、ライセンス条文4において<著作権者>を宣伝に使うな、と一見矛盾しているように見えます。

これはあくまで、主に商用利用する際に自社の製品の販売促進、いわゆるマーケティングのために<著作権者>の名前を使うな、ということであり、それ以外の目的の資料等には謝辞を記載しなさい、という意味です。

つまり、<著作権所有者>の開発したソフトウェアを使っているので、ウチの製品はオススメですよ~!ってニュアンスがダメなわけです。

(以前の記事の内容は間違ってました、すいません!)


適用例:

「Newlib」など、またそれを含む「GCC」などの主要なオープンソース・ソフトウェアに含まれます。

大半が「三条項BSDライセンス」などの修正ライセンスに移行していますが、未だ数多くのソフトウェアに適用されています。


頒布のために執るべき行動:


ソースコード頒布の場合:

ライセンス条文1により、ソースコードの改変の有無に関わらず、冒頭に記述されるこのライセンス文をそのまま改変することなく配布しましょう。

また同条文によるコピーライト(著作権)は、上記を守ることによって自動的に条件が満たされます。


バイナリ頒布の場合:

ライセンス条文2により、このライセンス文を掲示する必要があります。

また同条文により、ライセンス文の先頭に記述されているコピーライト(著作権)を掲示する必要があります。

これらの掲示は、このライセンスのソフトウェアを含む製品の取扱説明書やWebページなど、必ず容易にユーザーの目に触れる形で記述しましょう。


その他:

ライセンス条文3により、ソースコード/バイナリと頒布の形式に問わず、指定されている謝辞を掲示する必要があります。

掲示は、このライセンスのソフトウェアを含む製品の取扱説明書やWebページなど、必ず容易にユーザーの目に触れる形で記述しましょう。

2024年4月23日火曜日

Beer-ware License

OSSライセンスのメインページはこちらからどうぞ。

ライセンスの目次はこちらです。


名称:「Beer-ware License」(Beerware)


ビールのイラスト


タイプ:

・コピーレフト…×

・ライセンス文の掲示…〇

・コピーライト(著作権)の掲示…×

・その他…〇


原文:


  • "THE BEER-WARE LICENSE" (Revision 42):
  • <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you
  • can do whatever you want with this stuff. If we meet some day, and you think
  • this stuff is worth it, you can buy me a beer in return Poul-Henning Kamp


日本語訳:


  • 「ビールウェアライセンス」 (改訂 42):
  • <phk@FreeBSD.ORG>がファイルを書きました。
  • このライセンス文を保持している限り、この著作物に関して何をしても構いません。
  • いつか出会った時、この著作物に価値があると思ったら、お礼にポール・ヘニング・カンプにビールを奢ることができます。


解説:

デンマークのソフトウェア開発者、ポール・ヘニング・カンプ氏の考案したユニークなOSSライセンスです。


適用例:

「libbsd0」に含まれる「man/mdX.3bsd」、「src/hash/md5hl.c」、「src/hash/helper.c」など。


頒布のために執るべき行動:


ソースコード頒布の場合:

頒布の形式の言及なしに「このライセンス文を保持している限り…」とあるため、ソースコードの改変の有無に関わらず、冒頭に記述されるこのライセンス文をそのまま改変することなく配布しましょう。


バイナリ頒布の場合:

頒布の形式の言及なしに「このライセンス文を保持している限り…」とあるため、このライセンス文を掲示した方が良いでしょう。

掲示は、このライセンスのソフトウェアを含む製品の取扱説明書やWebページなど、必ず容易にユーザーの目に触れる形で記述しましょう。


その他:

街角でポール・ヘニング・カンプ氏に出会ったら、感謝の気持ちを込めてビールをご馳走してあげてくださいw

2024年4月21日日曜日

オープンソース・ソフトウェアのライセンス

仕事で自社の製品に組み込まれているオープンソース・ソフトウェアのライセンスについての調査を命じられました。

私も今までの経歴からオープンソースのソフトウェアを利用して製品開発を行ってきましたので、その手の書籍も熟読しており、人より少しだけライセンスについての知識は持ち合わせているつもりだったのですが…。

OSSライセンスの教科書


これが大苦戦中!

例えば、組み込みLinuxを使用した製品があったとして、その中にはカーネルを始めブートローダーやルートファイルシステムに含まれるものなど、下手をすると数百のオープンソース・ソフトウェアが含まれます。

そして、それらには各々のライセンスが設定されています。

作業としては、地道にこれらを一つ一つ調べて表にしていきます。

このリンクのようなページもありますし、面倒だが楽勝なお仕事だと…私もね、思っていた時期がありましたよ…。

作業を始めてから直ぐに困難に直面しました。

全てが「GPL」だの「BSD」だのの有名なライセンスならまだ良し。

オープンソース・ソフトウェアの数が膨大であることと同時に、そのライセンスも実に多様であることが分かりました。

初めて見るマイナーなライセンスや、古すぎて忘れ去られたライセンス、はたまた、そのソフトウェア開発者が個人で定めたオリジナルなライセンスなどなど…。

会社の法務・知財部門が知りたいのは、ザックリ主に以下の項目でしょう。


1.コピーレフトのライセンスか否か?

2.ライセンス文の掲示が必要かどうか?

3.コピーライト(著作権)の掲示が必要かどうか?

4.それ以外の条件があるかどうか?(「謝辞」の掲示など


これらに絞って、各々のライセンスを調べていけば良いのですが、こういった法律が絡む文章は極めて難解、かつ曖昧な文言で記述されており、英語力の乏しい私には重労働なのです。

Google先生に翻訳をお願いしても、何やらそれらしいが、よくわからない日本語訳が返ってきます。

ならば、ということで、マイナーなライセンスを含めて一覧でわかりやすく日本語で解説しているようなWebページがないかと検索してみましたが見つからず…。


…う~ん、そういうページがないなら自分で作るかぁ。


というわけで、今後、このブログではオープンソース・ライセンスに関する備忘録を呟くことがあるかもしれません。

いやぁ、コーディングとかではなく地味な仕事なので、調査の結果が誰かの役に立つかも!?というモチベーションが欲しいというのが本音です。


重要だけど、つまらない仕事ってありますよね。

でも大人なんだから「やりたい仕事」と「やるべき仕事」の分別を付けないと…。

2024年3月17日日曜日

超ハイエンド・ノートブック! PowerBook 180c

Apple社のノートパソコン「PowerBook 180c」です。

「PowerBook 180c」 - 1


発売は1993年6月頃とのことですから、今から約30年以上も前の機種になります。

以前ご紹介した「PowerBook 2400c」 の発売が1997年ですから、それよりも更に古いモデルです。

TFTカラー液晶を初めて搭載したMacであり、CPUは33MHzのMC68030と当時最強の処理スピードを持っていたということもあり、定価は実に100万円近くしたそうです。

(33MHzのCPUで最強ってあ~た…今の感覚で言えば、昆虫?

当時でも大変な高級機種であり、手にするのはデザインや印刷業界のプロフェッショナルが中心で、一般人にとっては高嶺の花だったそうです。

さっきから「~だそうです」って伝聞形式なのは、理由があります。

当時学生だった私がこんなもん新品で買えるわけがありません。

これは、昨年まで在籍していた前職で、やはり転職していってしまった先輩より受け継いだものなのです。

この先輩からは、アセンブラを教わりました。

今にして思えば、恩人、その後の私のキャリアを決定付けたキーマンですね。

かなり昔の話、確か2005年くらいだったと思います。

先輩はこの威風堂々たる「PowerBook 180c」本体と、巨大なACアダプタを持って私のデスクまでやってきて「これいる?」って。

「PowerBook 180c」 - 2


だから、有無も言わさず「ください!」と言いました。

多分先輩は、当時社内では珍しかったMacユーザーの私を覚えていてくれたのでしょう。

(因みに、当時は仕事で「iBook」というモデルを使ってたっけ?)

しかしながら、譲り受けた時点でも相当な骨董品。

ですので、私もこの「PowerBook 180c」について何も知らなかったのです。

「PowerBook 180c」 - 3


筐体は、13.3インチの「MacBook Air」と比較して、上から見れば面積はそれなりにコンパクトと言えなくもないのですが…

「PowerBook 180c」 - 4


すごく分厚いです。

何倍の厚みだコレ?

「PowerBook 180c」 - 5


しかし、その分上質なキーボードとトラックボールを備えています。

「PowerBook 180c」 - 6


背面のインターフェイスも同時期のデスクトップのMacに劣らず充実しています。

(カバーがあったのですが、加水分解により樹脂が脆くなったので撤去…。)

「PowerBook 180c」 - 6


右の側面には、フロッピーディスクドライブも完備です。

未だにちゃんと動作します。

「PowerBook 180c」 - 7


それにしても、画面のフチが広いですね~。

液晶のサイズは8.4インチに過ぎません。

「PowerBook 180c」 - 8


さて、譲り受けた「PowerBook 180c」は、仕事でバリバリ使われていたわりには、ご覧の通りかなり綺麗な状態でした。

きっと、大切に使われていたんだろうな…。

ただし、トラックボールが動かなかったり、システムが不安定で時折ハードディスクから異音も発生していました。

しかし、電源回路や液晶は良い状態でした。

まず、トラックボールについては、デジトラの故障(水でも入ったかな?)が判明し、これを交換することで修理できました。

問題は、不安定なシステムです。

ハードディスクを交換してOSをクリーンインストールするのが手っ取り早いと判断し、分解しました。

しかし、開けてビックリ!

2.5インチサイズのハードディスクなのですが、インターフェイスが譲り受けた当時の主流だったIDEではなく、SCSIだったのです。

SCSIのハードディスク、当時でも買えないことはなかったのですが、主にサーバー用途向けであり、極めて高価でした。

さ~て困った。

ネットで安価なSCSIのハードディスクを探す日々が続きます。

すると、気になるキーワードを見つけました。

「コンパクトフラッシュを起動ディスクに!」

つまり、SCSIのハードディスクを模したような基板にコンパクトフラッシュを挿入すると、それをハードディスクとして使えますよ~という製品です。

これは「ARTMIX.COM」さんの製品で、なんと!今調べたら製品ページが残っていました!

今は、コンパクトフラッシュではなくて、SDカードで同じことを実現できるようです。

極めてニッチな製品ですが、根強い需要があるのでしょうね。

(因みに、この時の経験が後の「PowerBook 2400c」レストアに活かされました。)

これだぁ~!

…ということで、早速購入しました。

OSは、この「PowerBook 180c」で使用できる最後のバージョンということで、漢字Talkの最終バージョン「7.5.5」よりも更に新しい「System 7.6.1」をコンパクトフラッシュにクリーンインストールしました。

HDからSSDに換装したようなものです。

起動もかなり早くなり、クリーンインストールによってシステムも安定しました。

…といっても、MacOSX以前のMacOSの安定性なんてタカが知れてますけどねw

「PowerBook 180c」 - 9


こうして、レストアは完了。

しかし、すでにその時点から見ても古すぎるシステム。

アプリケーションも色々入れてはありますが、もはや実用的なものはありません。

ブラウザやメーラーもありますが、満足に表示できるページも受け取れるメッセージもなく…。

「PowerBook 180c」 - 10


これといって使用用途はなく、ここ十数年に渡って、たまにインテリアの一部として起動させておくにとどまりました。

でも起動させておくと、分かる人は必ず足を止めてくれるんですよね。

一方で、パソコンなどに興味がない方から見れば、手間と時間とお金をかけて使えない道具を修理して維持することは、バカバカしく思えるかもしれません。

自分でも、バカだなぁ~とは思います。


しかし、しかしですよ~!?


まずもって、起動させておくだけで人を魅了するようなパソコンが、この世にどれだけ存在するでしょうか?

もはや、Macはパソコンではなく芸術作品なのです!

「PowerBook 180c」 - 11


さらに、この時代の完動品のMacが次々と減っていく中で、私はそれを運良く所持できた幸運な者です。

この文化遺産の動態保存、維持に努めることは、もはや私に課せられた使命であると言っても過言ではない!

「PowerBook 180c」 - 12


…ハァ、ハァ…。

ちょっと興奮してしまいましたね、すいません。


まあ、Mac信者などという言葉があるように、この時代のMacには単なる工業製品にとどまらない魅力的な何かがあったのでしょう。

それは、フェラーリやポルシェなどのクルマの世界に近いものかもしれません。

今のパソコン(現行のMacも含めて!)で、そのような魅力を持つ製品はありません。

パソコンが憧れのマシーンだった時代から、文房具などと同様の身近な道具に変化した時代の流れの残光、それがこのPowerBookシリーズだったのかもしれませんね。

「PowerBook 180c」 - 13


以前ご紹介した「PowerBook 2400c」と共に、こちらも可能な限り維持していきたいと思います。

これを譲ってくれた先輩も、まさか自分の「PowerBook 180c」が今でも動いていて、今の時を刻んでいるとは思っていないだろうなぁ~。

「PowerBook 180c」 - 14


先輩、元気だと嬉しいなぁ…。

2024年3月3日日曜日

「pcDuino3」でYocto Project その8

前回からの続きです。

このテーマを最初からご覧になる場合はこちらからどうぞ。


実用的なディストリビューションの作成

前回までで「pcDuino3」で動くディストリビューションを作成することができるようになりました。

「pcDuino3」


しかし、このディストリビューションは「Yocto Project」で最初から用意されているディストリビューション・タイプの中でも「core-image-minimal」という最小限のもの。

クックック…、ヤツは我らYoctoディストリビューションの中でも最弱…。

そのままでは、実用性がありません。

そこで今回は、この「core-image-minimal」をベースに代表的なJavaScriptの実行環境の一つ「Node.js」を使えるように改造したいと思います。

「Node.js」で何か凝ったものを開発しようと思えば、JavaScriptのパッケージ管理ツールの「NPM」も必要です。

また、ソースコードを管理するためには「Git」コマンドも使いたいものですよね。

さらには「core-image-minimal」にはロクなGUIを積んでいませんので「pcDuino3」側でコーディング作業を行うのは困難です。

ですので、パソコン側から「pcDuino3」を操作したいので「OpenSSH」というプロトコルも載せちゃいましょう。

この「OpenSSH」を「pcDuino3」に積んでおけば、パソコン側で「VisualStudio Code」などのリッチなIDE(統合開発環境)を使って「Node.js」による開発を行えるようになりますよ。

というわけで、現在の「core-image-minimal」に加えるパッケージは、以下の4つとなります。


◯nodejs

◯nodejs-npm

◯openssh

◯git


問題は、これらをどうやってディストリビューションに組み込むか、ということですが…。

それには、前回「pcDuino3」用のディストリビューションを作るために、ほんのチョットだけ修正した「local.conf」ファイルを編集することによって行います。

「local.conf」ファイルの開き方は、前回の記事を参考にしてください。

以下のように「local.conf」の末尾に呪文を追記しましょう。

  1. #
  2. # Memory Resident Bitbake
  3. #
  4. # Bitbake's server component can stay in memory after the UI for the current command
  5. # has completed. This means subsequent commands can run faster since there is no need
  6. # for bitbake to reload cache files and so on. Number is in seconds, after which the
  7. # server will shut down.
  8. #
  9. #BB_SERVER_TIMEOUT = "60"
  10. # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
  11. # track the version of this file when it was generated. This can safely be ignored if
  12. # this doesn't mean anything to you.
  13. CONF_VERSION = "2"
  14. # ↓以下を追記↓
  15. #
  16. # for pcDuino3
  17. #
  18. CORE_IMAGE_EXTRA_INSTALL += "nodejs nodejs-npm openssh git"


この呪文の意味、なんとなく分かりますよね?

CORE_IMAGE_EXTRA_INSTALL」という変数にインストールしたいソフトウェアのパッケージをスペース区切りで記述して代入しています。

このように「Yocto Project」においては、作成するディストリビューションにソフトウェアやパッケージをインストールしたい場合「local.conf」などの設定ファイルに任意の変数へ追加代入することによって行います。

注意しなければならないのは、今回は「CORE_IMAGE_EXTRA_INSTALL」という変数に代入しましたが、ソフトウェアや機能によっては、別の変数を使用しなければならない場合があることです。

このような変数には、他にも「IMAGE FEATURES」や「DISTRO_FEATURES」などがありますので、インストールしたいソフトウェアや機能のドキュメントなどを事前に調査しておくことが必要です。

しかしながら、殆どの場合は「CORE_IMAGE_EXTRA_INSTALL」で大丈夫でしょう。

さて「local.conf」の追記が完了したら、こちらの記事を参考に再度「core-image-minimal」を「bitbake」コマンドでビルドしましょう。

今回も完了までに結構な時間がかかりますので、コマンドの実行は就寝前がオススメです。


スワップの設定

朝起きて「bitbake」コマンドが無事終了していた方は幸いです。

しかし、私の場合はダメでしたぁ~。

ターミナルは以下のようなエラー表示。。。

最悪の寝覚めだ…。

この「ld tarminated with signal 9 [killed]」というエラーメッセージ、実は一番目にする機会が多いものです。

ターミナル - 1


これの主な原因は、メモリ不足です。

ログを見ていると「nodejs」のコンパイル中にエラーが発生しています。

「nodejs」は、巨大なソフトウェアです。

「Yocto Project」がソフトウェアのソースコードをダウンロードして、それをビルドしてディストリビューションにインストールする作業を繰り返していることは、以前の記事でもご説明した通り。

それらのソフトウェアの中には、このようなコンパイルのためホスト側のパソコンに膨大なメモリを要求するソフトウェアもあります。

コンパイルを試みたものの、その過程でメモリが食い尽くされて、Linuxカーネルがたまらず「Signal 9」を発生させてプロセスを中断したことが、今回の顛末です。

では、どうするか?

ホストのパソコンにメモリを増設すれば良いのですが、お金がかかるからヤダ。

となれば、ハードディスクの余りの容量を仮想のメモリをして使用するための「スワップ」というLinuxの機能を使いましょう。

まずは、今のLinuxのスワップの状況を調べてみましょう。

ターミナルから以下のコマンドを入力します。


$ free -m

ターミナル - 2


単位はM(メガ)ですので、現在、このLinuxには「4095MB - 4GB」程度のスワップ領域が有効になっていることが分かります。

本来のメモリ16GBに加えて、スワップも4GBですよ!?

そんなにあっても足らない?

「Node.js」恐ろしい子…。

では、この容量を増やしてやりましょう。

まずは、現在のスワップ機能をオフにする必要があります。

以下のコマンドを実行します。


$ sudo swapoff /swapfile

ターミナル - 3

次にスワップ領域を拡張しましょう。

どの程度に拡張するかが問題です、

多いほど良さそうな感じがしますが、一般に多すぎても意味がないという説もあります。

今回は、本来のメモリと同じ容量である16GBに拡張します。

足りなくて再度ビルドに失敗するようであれば、またトライすれば良いし…。

(やたら時間がかかるので、失敗すると凹むけど!)

以下のコマンドでスワップ領域の予約を行います。


$ sudo fallocate -l 16G /swapfile

ターミナル - 4

スワップ領域の実態は、ルートディレクトリに配置されている「swapfile」というファイルです。

以下のコマンドでパーミッションを設定しておきます。


$ sudo chmod 600 /swapfile

ターミナル - 4


次に、実際のスワップ領域の作成です。

以下のコマンドを実行してください。


$ sudo mkswap /swapfile

ターミナル - 5


スワップ領域が作成できましたので、これを有効化しましょう。

以下のコマンドです。


$ sudo swapon /swapfile

ターミナル - 6


コレで良し!!

念のため、確認だけはしておきましょうか。

うん、ちゃんと16GBに拡張できていますね!


$ free -m

ターミナル - 7


この状態で、こちらの記事を参考に再度「$ bitbake core-image-minimal」に挑戦です。

今度は、絶対に上手くいきますよ!


「OpenSSH」の検証

無事に「core-image-minimal」がビルドできたら、こちらの記事を参考にSDカードを作成して「pcDuino3」を起動させたいところなんですが…。

その前に「pcDuino3」のネットワーク環境を考える必要があります。

「pcDuino3」にはWiFiが無くて、有線LANポートが一つしかありません。

そして、ここに繋ぐネットワークはインターネットに接続できて、且つ、開発用のパソコンとも接続できなければなりません。

今どきのお宅は、WiFiしかなくて有線LANのネットワークなんて少数派なんじゃないですかね?

ウチもそうです。

そうすると「pcDuino3」は家のネットワークに参入できません。

ですので、私は、以下のようなWiFiー有線LANブリッヂを買ってきました。

WiFiー有線LANブリッヂ


Amazonさんで¥3,000程度ですね。

これは、名の如く有線LANポートしかない機器をWiFiネットワークに接続させるためのブリッヂです。

組み込み用途などで使用頻度の高い安価なLinuxボードでは、WiFiが非搭載の場合が多いです。

そのような機器のソフトウェアの開発の際に、こういったブリッヂは非常に有意義ですので、一台持っておいても絶対に損はありませんよ。

ちなみに、電源はUSBのバス供給です。

これを「pcDuino3」に接続して、新しいディストリビューションのSDカードでLinuxを起動します。

Linuxの起動


起動が完了したら「root」でログインします。

パスワードは入力の必要がありません。

「pcDuino3」のターミナル - 1


ログインできたら、まずは「pcDuino3」のIPアドレスを調べておきましょう。

このIPアドレスが分かれば、以後の作業はすべて「OpenSSH」を使って開発用のパソコンでリモートに行うため、非常に効率が良くなりますよ。

以下のコマンドでIPアドレスを調べます。

私が試した時は「pcDuino3」は「192.168.179.12」というIPアドレスが割り振られたことが確認できますね。


# ip a

「pcDuino3」のターミナル - 2


以降の作業は、開発用のパソコンで今まで作業していた「VMware Workstation Player」上の「Ubuntu」Linuxではなく、Windowsで行うことにします。

まずは、現在の開発用のパソコンのIPアドレスも調べてみましょう。

Windowsのコマンドプロンプトを開いて以下のコマンドでIPアドレスを調べます。

私のパソコンは「192.168.179.15」というIPアドレスが割り振られたことが確認できます。


> ipconfig

Windowsのコマンドプロンプト


パソコンが「192.168.179.15」。

「pcDuino3」が「192.168.179.12」ですから、これらは同じクラスですので、お互いに通信できます。

それが確認できたところで、ターミナルソフトウェア「TeraTerm」を起動します。

インストールしていない方は、こちらの記事を参考にしてください。

以下のダイアログが表示されたら「ホスト」の欄に「pcDuino3」のIPアドレスである(今回の場合は)「192.168.179.12」を入力して「OK」ボタンをクリックします。

「新しい接続」ダイアログ


次は以下のようなダイアログが現れます。

「ユーザ名」のテキストボックスに「root」と入力し、下方の「OK」ボタンをクリックです。

「SSH認証」ダイアログ


すると「TeraTerm」の表示が以下の様になり、ターミナルで「pcDuino3」のLinuxへログインできたことになります。

ここまでできれば、新しく作成したLinuxディストリビューションに追加した「OpenSSH」が正しく動作していることが確認できます。

「TeraTerm」ターミナル - 1


一応「pcDuino3」の時計の時刻合わせだけは行っておきましょう。

時計があまり大きく狂っていると、以降の作業においてSSH認証のエラーが出る可能性があります。

とはいえ「pcDuino3」の電源を一度でも落としてしまうと、また狂ってしまうんですけどね…。

以下のコマンドで現在設定されている時刻を確認します。


# date

「TeraTerm」ターミナル - 2


設定する時刻が「2024年2月25日 1時15分」だったら以下のコマンドです。


# date 022501152024

「TeraTerm」ターミナル - 3


「Node.js」の検証

「OpenSSH」の次は「Node.js」の動きも確認しておきましょう。

「Node.js」の起動は、以下のコマンドを入力することによって行います。

バージョン情報など、何か表示されましたね?

プロンプトが「#」から「>」になっているのに注目です。


# node

「TeraTerm」ターミナル - 4


これだけでも、新しく作成したLinuxディストリビューションに追加した「Node.js」が正しく動作していることが確認できますが、それだけだと面白くないので、簡単なプログラムを実行させてみましょう。

「>」というプロンプトに以下のプログラムを入力し、エンターキーを入力します。

お約束の例のヤツです。


> console.log("Hello World!");

「TeraTerm」ターミナル - 5


「Ctrl」+「c」を押すと「Node.js」が終了し、プロンプトが「>」から「#」に戻ります。

「TeraTerm」ターミナル - 6


以上で「Node.js」の検証は終了です。


「NPM」の検証

「Node.js」を使って開発を進めていく上では、様々なパッケージやツールを別途ダウンロードする必要が出てきます。

そのためのパッケージ管理ツールが「NPM」であり、こちらも新しいディストリビューションに追加しました。

こちらも検証しておきましょう。

まず以下のコマンドで「sample」というディレクトリを作成し、その中へ移動します。


# mkdir sample

# cd sample/

「TeraTerm」ターミナル - 7


おそらく「Node.js」を使うなら、いずれ必ず使うであろう「ejs」というテンプレート・エンジンを「NPM」を使ってダウンロードしてみましょう。

以下のコマンドを実行するとダウンロードできるはずです。


# npm install ejs

「TeraTerm」ターミナル - 8


「sample」ディレクトリの中に以下のようなディレクトリやファイルが確認できたら「NPM」の検証も完了です。


# ls -l

「TeraTerm」ターミナル - 9


以下のコマンドで、元のディレクトリに戻りましょう。


# cd ..

「TeraTerm」ターミナル - 10


「Git」の検証

最後に「Git」の検証を行います。

何でも良いのですが、リポジトリからソースコードをクローンします。

ここでは、私のリポジトリから「openocd_nora」というソースコードをクローンしてみます。

ちょっと長いけど、以下のコマンドです。

クローンが始まったでしょうか?


# git clone https://github.com/RyutaroMorita/openocd_nora.git

「TeraTerm」ターミナル - 11


正しくクローンできたでしょうか?


# ls -l

「TeraTerm」ターミナル - 12


以上で「core-image-minimal」に新たに追加したすべてのソフトウェアが正しく動作していることが確認できました!


「pcDuino3」用のLinuxディストリビューションも、ここまでくれば、かなり実用的なものになったはずです。

次回は、今まで慣れ親しんだ最小限のディストリビューション「core-image-minimal」を離れ、よりリッチでGUIの表示を持つ「core-image-sato」というディストリビューションのビルドを行いたいと思います。

え、単に「bitbake core-image-sato」ってやるだけでしょ…って?

いやいや、これが結構大変だったんですよ~。


<続く>

Simplicity Studioを使ってみた! その1

「Simplicity Studio」のインストール 急遽、 Silicon Labs 社のマイコンを使用することになり、その統合開発環境「 Simplicity Studio 」をインストールしました。 手順が多く結構ハマったので、その備忘録です。 まずは、インストーラーのダウ...