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」ってやるだけでしょ…って?

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


<続く>

2024年2月18日日曜日

TOPPERS/ASP - Arduino UNO R4版 その7

前回からの続きです。

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


プログラムの転送とデバッグ

ターゲットの「Arduino UNO R4」とデバッガの「E2 emulator Lite」を前々回作成したケーブルで接続します。

こんな感じ。

「Arduino UNO R4」と「E2 emulator Lite」の接続例


これからTOPPERS/ASPのサンプルプログラムを動かす際には、動作確認のためにどうしてもシリアルポートが必要です。

そこで、以下のような市販のUSB/シリアル通信変換ケーブルを用意します。

市販のUSB/シリアル通信変換ケーブル


作成したケーブルからシリアル通信用のTXD)、RXD)、GND)の線を出しておきましたよね?

それらを以下のように接続します。

作成したケーブルからのシリアル通信用の線


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

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


続いて、このUSB/シリアル通信変換ケーブルをパソコンに繋いでみましょう。

パソコン上でデバイスマネージャーを開きます。

ポート(COMとLPT)のサブカテゴリーとして「USB Serial Port」というポートが追加されているはずです。

(私のパソコンでは、「COM15」として認識されていますね。)

このポート番号、覚えておいて下さい。

デバイスマネージャー


ここで「E2 emulator Lite」とパソコン、「Arduino UNO R4」とパソコンをそれぞれUSBケーブルで接続しましょう。

厄介なのは「E2 emulator Lite」がUSB mini-B、「Arduino UNO R4」がUSB Type-Cと、異なるケーブルが必要なことです。

それぞれを接続すると、ご覧の通り通電します。

「E2 emulator Lite」とパソコン、「Arduino UNO R4」とパソコンをそれぞれ接続


次に「TeraTerm」をご用意ください。

インストールしていない方は、このページ(TOPPERS/ASPのビルドからデバッグまで~サンプルプロジェクトのデバッグ)の「TeraTermの導入」の項目を参考にしてください。

もちろん、シリアル通信のターミナルであれば、他のものもお使いいただけます。

今回のTOPPERS/ASPのサンプルプログラムは、シリアル通信のメッセージを出力しますので、先程「USB Serial Port」として認識されたシリアルポート番号でターミナルを立ち上げておきましょう。

設定は、こんな感じです。

ボーレートは「9600」です。

(私のパソコンは、USB/シリアル通信変換ケーブルをCOM15として認識していました。)

TeraTerm - シリアルポートの設定


さて、「e2 Studio」に戻りましょう。

まだサンプルプログラムをビルドしていない場合は、画面右側の「ビルド・ターゲット」タブの中、「OBJ」ディレクトリ直下の「all」をダブルクリックして、ビルドを完了させましょう。

<追記>

この記事を書いている過程で、雛形プロジェクトの作成時に「Arduino UNO R4」のクロック設定の作業を忘れていることに気が付きました。

大変お手数ですが「TOPPERS/ASP - Arduino UNO R4版 その3~クロックの設定」を追記しましたので、こちらに戻ってクロック設定を行ってから、再び生成された雛形プロジェクトのソースコードをTOPPERS/ASPのディレクトリにコピーしてください。

「e2 studio」 - 1


次にデバッガの設定を行います。

画面上部にある緑色の「虫マーク」。

その脇に「▼」ボタンがありますので、それをクリック。

そこで現れた「デバッグの構成」という項目をクリックしましょう。

「e2 studio」 - 2


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

左側のリストから「Renesas GDB Hardware Debugging」という項目をダブルクリックしてください。

「デバッグ構成」ダイアログ - 1


ダイアログ右側がガラリと変わりましたね?

「デバッグ構成」ダイアログ - 2


この「デバッグ構成」ダイアログの各項目に対し、以下の設定を入力します。


名前:<任意の構成名(ここでは「OBJ」)>

プロジェクト:<プロジェクト名(ここでは「asp_1.9.2」)>

C/C++アプリケーション:C:\cygwin64\home\<ユーザ名>\asp_1.9.2\OBJ\asp.exe

Build Configuration:Use Active

「自動ビルドを無効にする」を選択

「デバッグ構成」ダイアログ - 3


お次は現在の「メイン」タブから「Debugger」タブへクリックして切り替えます。

「デバッグ構成」ダイアログ - 4


新しく現れた各項目に対し、以下の設定を入力します。


Debug hardware:E2 Lite (ARM)

Target Device:R7FA4M1AB

「デバッグ構成」ダイアログ - 5


さて、お次は現在の「GDB  Settings」タブから「Connection Settings」タブへクリックして切り替えます。

「デバッグ構成」ダイアログ - 6


たくさん設定項目があるんですが、ここでは「エミュレーターから電源供給」の項目だけは忘れずに「いいえ」にしておいて下さい。

「デバッグ構成」ダイアログ - 7


最後にもう一丁!

現在の「Debugger」タブから「共通」タブへクリックして切り替えます。

「デバッグ構成」ダイアログ - 8


エンコードの設定で「その他」に選択し、文字コードを「UTF-8」に設定してあげて下さい。

これをしないと、デバッガーからの日本語メッセージが文字化けしてしまいます。

これでよ~やく、ダイアログ下部の「適用」ボタンと「デバッグ」ボタンを順にクリックすることで、デバッガーが起動しプログラムの転送が開始されます。

「デバッグ構成」ダイアログ - 9


プログラムの転送が終わると、以下のようにスタートアップ・アドレスでプログラムが止まった状態になります。

「e2 studio」 - 3


ここからプログラムを続行してみましょう。

画面上部の「」ボタンをクリックすると、プログラムが続行されます。

「e2 studio」 - 4


はい、ここで長らく放置していた「TeraTerm」を見てみましょう。

以下のように、サンプルプログラムが動作していることが確認できます。

TeraTermの表示


プログラムを停止する場合は、画面上部の「」ボタンをクリックします。

停止させてみましょう。

「e2 studio」 - 5


ついでに「e2 studio」の表示を「デバッグモード」から「C/C++モード」に変更します。

「e2 studio」の画面右上のボタンで切り替えができます。「C/C++」ボタンをクリックします。

「e2 studio」 - 6


ブレークポイントを仕掛けましょう。

画面右の「プロジェクト・エクスプローラー」のソースコードリストの中から「sample1.c」をダブルクリックし、ソースコードを表示します。

このソースコードの丁度中盤くらい、メインタスクの始めに仕掛けましょうか。

ブレークポイントは、ソースコードビューの左端をダブルクリックすることにより丸が表示され、セットすることができます。

(解除したい場合もダブルクリックします。丸が消えます。)

「e2 studio」 - 7


これで本当にブレークポイントがかかるのか、試してみましょう。

画面上部にある緑色の「虫マーク」。

その脇に「▼」ボタンがありますので、それをクリック。

すると今後は、さっき色々と入力した「OBJ」のデバッグ設定が登録されていますので、これをクリックすると、デバッガが起動します。

「e2 studio」 - 8


しばらくして、プログラムの転送と書き込みが完了すると、前と同じようにスタートアップ・アドレスでプログラムが停止しますので、画面上部の「」ボタンをクリックして、プログラムを続行させます。

「e2 studio」 - 9


程なくして、以下のように正しくブレークポイントを仕掛けた位置でプログラムが停止するはずです。

ここからは、「F6」キーでステップオーバー、「F5」キーでステップインなど、おなじみの操作が使用できます。

因みに、ステップオーバーやステップインなどを行っている時に命令が飛んでしまったり前後したりする場合は、最適化のせいです。

デバッグ時は、このページ(TOPPERS/ASPのビルドからデバッグまで~サンプルプロジェクトのデバッグ)の「サンプルプログラムのデバッグ」の項目を参考に最適化を解除しましょう。

「e2 studio」 - 10


さてさて、これでTOPPERS/ASPをビルドして動かすところまで、一通りの説明ができたと思います。

次回は、応用編。

このTOPPERS/ASPとRenesas社純正のライブラリパッケージ「Flexible Software Package (FSP)」を組み合わせて使う方法について書いていけたらなぁ…と思います。

豊富なライブラリが使えるようになれば、電子工作の幅が広がりますよ!


<続く>

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

前回からの続き です。 このテーマを最初からご覧になる場合は こちら からどうぞ。 「Simplicity Studio」でプログラミング インストールしたSilicon Labs社のマイコン用の統合開発環境「 Simplicity Studio 」で、テストプログラムを動かして...