2023年12月26日火曜日

「MSX DEVCON」アムステルダム報告会

「MSX DEVCON」アムステルダム報告会 概要

12月26日、「MSX DEVCON」アムステルダム報告会に参加してきました。

今回のイベントは、西 和彦さんによりオランダ、アムステルダムで12月9日に開かれた「DEVCON」の報告会です。

会場は、東京国立博物館・平成館大講堂で13:00より行われました。

東京国立博物館・平成館大講堂


以下のように、事前にX(旧Twitter)で参加人数を調査され、300人ほどの会場を用意されたとのことですが…


実際に会場に集ったのは、多くて100人を少し超える程度。

しかしこれは、決して日本での「MSX3」への関心が低くなったわけではないでしょう。

まず、この年末の多忙な時期というタイミング、それに加え、ネット配信や録画で自宅で参加したいというニーズが高かったものと考えられます。

それでも、アムステルダムでのイベントの報告をいち早く日本のファンに届けたいという西さんの思いは伝わってきます。

「MSX3」は、あくまでも「Made in Japan」の精神にブレはありません。

おそらく、後日、会場の模様は録画でも配信されるでしょうから、あえてこのブログで報告会の内容を細々と記述する必要はないでしょう。

ここでは、個人的な感想を勝手に述べさせていただきたいと思います。

会場の様子


「MSX3」は高価なHDMIセレクタ?

すでに公開されている「MSX3」のプロトタイプの姿は以下の通りです。


今回の報告会において、初めて「MSX3」の具体的な姿、そして目指す方向性が見えてきました。

まず「MSX3」は、どのカテゴリーの製品なのかということです。

今、私たちが普段使用している情報機器は、パソコンとスマートフォンの二つです。

40年前に発売されたMSXは、一般的にはパソコンというカテゴリに属する製品でした。

したがって、その後継としての「MSX3」もまたパソコンであると考える方が自然ではあります。

では、現在広く使われているWindowsやMacOSと競合するものを目指すのか?

答えはノーです。

パソコンよりも遥かに気軽でウェアラブルなスマートフォンの立ち位置ではどうでしょう。

「MSX3」は、iOSやAndroidと競合するものを目指すのか?

こちらも、答えはノーです。

いずれの方向も、既に双璧がシェアを争う構図が確定しており、今後数年に渡って大きな変化はないでしょう。

MSXが、今からこれらの分野の3番手を狙うのは現実的ではありません。

では、どうするか?

そもそも、40年前に発売されたMSXが単なる「パソコン」であったのかどうかを疑う必要があります。

当時、人々が直に使い得る情報機器は、非常に高価なオフィスコンピュータくらいなものでした。

(PC88や、ましてやPC98は、非常に高価でした。)

それより規模は小さいものの、安価で、一般の人が購入できる価格でコンピュータを提供したことが、MSXの偉業と言えるでしょう。

それが、日本のその後のモノづくり、技術者の育成にどれだけの貢献をしたかを含めて。

このように、MSXとは「パソコン」とういう概念に囚われず「安価に入手できる、本来手にできなかったモノ」と定義すれば、「MSX3」は必ずしも第3のパソコンでなくても良いのです。

では現在、個人ではなかなか手にできない情報機器とは何でしょうか?

それは、富岳などに代表されるスーパーコンピュータです。

西さんの思い描く近未来とは、誰もがスーパーコンピュータ…つまり「MSX3」を使って、ユーザが個人でメタバースを運営したり、AIを育てたり、気象予報が可能となる世界でしょう。

更には、日本のモノづくりへの貢献です。

国立研究開発法人、産業技術総合研究所のスーパーコンピュータ、AI橋渡しクラウド(AI Bridging Cloud Infrastructure、ABCI) は、多くの企業によって、数カ月先まで予約が埋まっている状態だと聞きます。

スーパーコンピュータを使いたくても使えない状況。

「MSX3」には、このような状況を打開し、スピーディーに企業や個人が大規模なシステムの開発を推進できる起点になる可能性すら感じさせます。

重要なことは、MSXは、それらが可能な砂場(サンドボックス)を安く提供するまではやります、と。

しかし、その砂場でどういう遊びをするのかは、ユーザに委ねられている点です。

したがって「MSX3」は、ユーザが何も手を加えなければ、高価なHDMIセレクタに過ぎないと、西さんは仰られました。

用意されていないものは、自分で作る。

この精神性もまた、MSXの伝統と言えるでしょう。


「MSX3」を簡単にまとめると…


◯インターネット接続

◯HDMI接続の映像出力

◯32bitと64bitのCPU

◯メタバースに対応し得るビデオとオーディオ

◯すべての人にスーパーコンピュータを

◯IoTへの新たなるアプローチ


これらは、既にプロトタイプに実装されているといいます。

より具体的な中身については、今後発表されるSDK(Software Development Kit)を精査する必要があります。

待ち遠しいですね!


「MSX3」と「MSX turbo」の関係は?

「すべての人にスーパーコンピュータを」

このベクトルは、本来、3つある新しいMSXの内の一つ「MSX turbo」が担う分野だったはずです。

私も「MSX3」とは全く別のラインで、スーパーコンピュータ「MSX turbo」が登場するものと思っていましたが、どうやら違ったようです。

「MSX3」は、そのCPUボードを最大16枚スタックすることができるそうです。

すなわち、ユーザのニーズ、必要な処理速度に合わせてCPUボードを増設することによって、メニコアのシステムに育てて行くことが可能とのこと。

つまり「MSX turbo」とは「MSX3」の延長であると解釈するのが正解のようです。


「お前のMSX、何段?」

「今は8段だけど、次のボーナスで12段にするぜ!」


…なんて会話が、ヘビーユーザの間で交わされるのでしょうか?

「MSX3」のOSはLinuxベースであり、その上に「TAOX」というレイヤーを被せます。

「TAOX」自体は、OSというよりもPosixに依存するフレームワークのようで、ロボット・アプリケーションの分野で普及する「ROS」に近いイメージでしょうか。

おそらく、この「TAOX」が、CSP(Communicating sequential processes)すなわち、並行処理を担うレイヤーになるでしょう。

「TAOX」は、以前から開発されているものですが、一般的に情報は少なく、こちらについても詳細はSDK待ちということになるでしょう。

以前のDEVCONでは、プログラミング言語として「Occam」を使用すると説明がありましたが、今回は触れられていません。

流石に古すぎたか?

個人的には、CSPの思想を受け継ぐのであれば、今であれば「Go lang」が使えると面白いと思います。


ゲームは重要!

ゲームに関しては、西さん独特のシニカルな言い回しで仰いました。

「わたしゃゲームは嫌いだ。でも、MSXにとってゲームは非常に重要だ。

同時に、現在「kibidango」でのクラウドファンディングで募集中のMSX0各機種が、非常に苦戦しているとのことでした。

確かにキツそうです。

(購入予定はなかったけど、急遽応援します。)

クラウドファンディング苦戦中


この原因について、西さんは「ゲームを置き去りにしてしまった。ゲームは今までMSXが生き残ってきた重要な要素であり、今後はそれを無視できない。」と仰っています。

西さんのことですから、今後、この分野でも大きな動きを起こすでしょう。

また、この日も「株式会社D4エンタープライズ」の鈴木代表も登壇されましたが、ゲームの供給という点でプレッシャーは大きいでしょう。

そもそも「MSX3」は「メタバースに対応し得るビデオとオーディオ」を搭載できます。

8K対応の「ORIN GPU」で「Open GL」に対応するとのことで、旧作ばかりではなく、新しい、そして、かなり高度なゲームを開発できる土壌はあるはず。

有力なサードパーティの参入に期待したいところですが、それには何より、まずユーザサイドで盛り上がる必要がありますね。

メーカーに、活発な市場と思わせなければなりません。

配布資料の黄色リボン


西さん、ここまでのMSX3に開発経緯を記した「反省記2」の執筆も進めているそうです。

前作の「反省記」も、モノづくりに関わる人間の一人として、着眼点やその発想の方法に大きな感銘を受けた内容でした。

こちらも楽しみです。

さて、まだまだ目が離せないMSX界隈の状況。

今後も注目していきたいと思います。

皆様、良いお年を!

2023年12月22日金曜日

「pcDuino3」でYocto Project その5

前回からの続きです。

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


「Yocto Project」におけるレシピとは?

「Yocto Project」を使う上で、絶対に避けて通れないのが「レシピ」という概念です。

レシピって聞いて、皆さん何を思い浮かべるでしょうか?

そう、お料理のレシピですよね。


はい、これでもう「Yocto Project」のレシピは理解できたも同然です!


例えば、今晩の夕食はカレーライスにしようと思います。

カレーライス


まず「ご飯」のレシピを想像してみましょう。

「ご飯」を炊くためには、まず、お米が必要です。

お米は、何処で買いましょう?

どうやって、どのくらい研ぎましょうか?

炊飯器にどのくらいの水を入れましょうか?

どのくらいの時間蒸らしましょうか?

…などなど、細かく書くと意外と複雑ですよね。

次に「カレールー」のレシピです。

これは「ご飯」よりも、もっと複雑です。

何処産のターメリックをどれくらい使いましょうか?

何処産のカルダモンをどれくらい使いましょうか?

何処産のシナモンをどれくらい使いましょうか?

何処産のコリアンダーをどれくらい使いましょうか?

辛さは?

…こりゃキリがないですね。

他にも「野菜」や「お肉」の調理方法が書いてあるレシピが、カレーライスを作るためには必要です。


これを「Yocto Project」でLinuxディストリビューションを作る場合に置き換えてみます。

まず「Linuxカーネル」のレシピがあります。

「Linuxカーネル」をビルドするには、ソースコードが必要です。

ソースコードは、どこからダウンロードしましょう?

どのアーキテクチャでビルドしましょうか?

どういったオプションでビルドしましょうか?

どのようなモジュールを追加しましょうか?

…などなど「ご飯」の時と似てますよね。

他にも「ブートローダー」や「BusyBox」など、Linuxが動作するために必要な部材のレシピが存在します。

前回「git clone」して生成された「poky」というディレクトリの中には、これらのレシピがたくさん入っています。

料理のレシピは、紙のメモ等かもしれませんが、そこはLinuxなので「Yocto Project」のレシピはテキストファイル形式で存在しています。

拡張子は「.bb」です。

以下の通り「poky」ディレクトリの下層、たとえば「~/poky/meta/recipes-kernel/」ディレクトリの中には、たくさんのソフトウェアごとのディレクトリがあって…

「poky」ディレクトリの下層 - 1


その中に、それぞれの「.bb」ファイルが存在するのを確認できますね。

「poky」ディレクトリの下層 - 2


興味のある方は、レシピがどういう風に書かれているか、見てみるのも良いかもしれません。

(但し、訳が分かんなくてもヘコタレナイこと!)


「bitbake」コマンドとは?

さて、カレーライスの場合は、私たち自身がレシピを読みながら料理をしなければなりません。

では、Linuxディストリビューションの場合は?

それを行うのが、ビストロ「Yocto Project」の料理長「bitbake」コマンドさんだったのです。

前回、以下のようなコマンドを打ちましたよね?

終わるまでに5時間くらい掛かった例のヤツ。


$ bitbake core-image-minimal


これは、料理長「bitbake」さんに「core-image-minimal」というお料理を注文したことになります。

「bitbake」さん、料理長なのにお客さんの注文取ったり、色々大変なので「グズグズすんな」とか「トロトロしてんじゃねー」とか「ぁくしろよ!」とか言っちゃダメ。

でもって「core-image-minimal」の注文を受けた「bitbake」料理長、厨房に戻ると「core-image-minimal」に必要な食材を買い出しに行きます。

…え、今からかいっ!?

まあ、そういったツッコミは、例え話なんでご勘弁を。

たくさんのレシピに書かれている部材をすべて買い揃えた「bitbake」料理長、厨房に戻って、これまたレシピ通りに各食材を調理していきます。

こうして「bitbake」料理長の大車輪の活躍で出来上がったのが「core-image-minimal」というお料理、すなわち、Linuxディストリビューションとなります。


「Yocto Project」におけるレイヤーとは?

コスプレする人のことじゃないです。

「Yocto Project」には、レシピの他、もう一つ重要な概念「レイヤー」というものがあります。

前回ビルドした「core-image-minimal」は、いわばプレーンなカレーライス、学食の300円のカレーみたいなもんで、なんのヒネリもないシンプルなものです。

(今思うと、アレはアレで美味しかったなぁ。)

これをグレードアップして、カツカレーライスにしたいと思います。

しかし、カツカレーライスを作るためには、ベースのプレーンなカレーライスのレシピに加えて、上に乗せるカツのレシピも必要になります。

カツも一から作るとなれば、結構大変です。

お肉は何処で買えば良いのか?

油の量や温度はどうするのか?

...などなど。

カレーライスとは別の料理として、複数のレシピが必要になりそうです。

これを「Yocto Project」風に言えば、カレーライスの上に、カツのレシピが含まれた、カツの「レイヤーを加える」必要があるわけです。

おまけに、このカツカレーライスに福神漬をトッピングしちゃった日にゃ、ダイコンやらレンコンやら、それらの味付けやらで、複数のレシピが含まれた福神漬の「レイヤーを加える」ことになります。

すなわち、レイヤーとは、ある要素を一纏めにしたレシピの集合体と言えます。

前回作った「core-image-minimal」が、プレーンなカレーライス。

今後、この記事で作ろうとする「pcDuino3」向けの「core-image-minimal」が、カツカレーライス。

このように例えるなら「pcDuino3」向けのLinuxディストリビューションは、前回作った「core-image-minimal」に「レイヤーを加える」ことによって作成することになります。

レイヤーは原則として「meta-xxx」というディレクトリ名が付けられます。

このディレクトリの中に、関連するレシピ、すなわち「.bb」ファイルがたくさん配置されています。

(「.bb」ファイル以外のものもありますが、それは今は気にしないで。)

ディレクトリを配置しただけではダメです。

レイヤーの場所を教えてあげないと「bitbake」料理長、その中のレシピが見れなくて困っちゃう。

それをやっているのが以下のパスの「bblayers.conf」ファイルです。


/home/yocto/poky/build/conf/bblayers.conf

「bblayers.conf」のあるディレクトリ


この「bblayers.conf」ファイル、中身はこんな感じのテキストです。

「bblayers.conf」の内容

これを見ると、なにやら「BBLAYERS」という変数に、パスのリストを代入しているように見えます。

この代入により「meta」と「meta-poky」と「meta-yocto-bsp」の3つレイヤーが登録されていることになります。

わずか3つ!

すなわち、前回作った「core-image-minimal」は、非常に少ないレイヤーで構成されていたことが分かります。

そりゃ学食の300円カレーだもの…。


「meta-sunxi」レイヤー

さて「pcDuino3」用のLinuxディストリビューションを作るために必要なレイヤーを手に入れなければなりません。

ところで「pcDuino3」のような名の通ったボードでLinuxを動かすために、白紙の状態から独自のレシピを書いてレイヤーを作ることは、まず無いと思います。

そういったものは、大概はコミュニティの方々が既に開発して、公開している上にメンテナンスまでやってくれています。

本当にありがたいですよね。

お仕事で独自のLinuxボードを作って、それにLinuxを動かす場合でも、使用したCPUのベンダーが必要なレシピやレイヤーを提供していることがほとんどで、最小限のカスタマイズで移植可能です。

では「pcDuino3」に必要なレイヤーがどこにあるか?

結論から言うと、まず以下の「meta-sunxi」レイヤーのページを御覧ください。

このページは「Yocto Project」の元となった、組み込み機器用のLinuxディストリビューションを作るためのソフトウェアフレームワーク「OpenEmbedded」がサポートする、公式の各種レイヤー情報ページです。

そして、このページの「Machines」タブをクリックしてください。


https://layers.openembedded.org/layerindex/branch/master/layer/meta-sunxi/

「OpenEmbedded Layer Index」 - 1


このページを下の方へスクロールしますと…。

「OpenEmbedded Layer Index」 - 2


pcduino3」という表記がありますね。

どうやら、このレイヤーを使えば良いらしいことが分かります。

「OpenEmbedded Layer Index」 - 3


因みに「sunxi」って何?って思いますよね。

これは「pcDuino3」に搭載されている、中国Allwinner Technology社のCPUシリーズの型番に由来します。

「pcDuino3」に搭載されているものは「A20(sun7i)」です。

他にも、このシリーズには「A10 (sun4i)」や「A13 (sun5i)」などが存在します。

つまり「sunxi」の「x」は、型番の番号のアスタリスクになっているわけです。

スンシィー、寸志!?…なんか中国語っぽい意味かと思ったけど違ったみたい。


さて、今回は作業無くウンチクだけで終了。

次回から、実際にこのレイヤーをどのように「Yocto Project」に組み込むか?をやっていきたいと思います。


<続く>

2023年12月15日金曜日

TOPPERS/ASP - Arduino UNO R4版 その4

前回からの続きです。

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


Cygwinターミナルでのビルド

雛形プロジェクトができましたので、ここで生成されたソースコードの一部を「TOPPERS/ASP Arduino UNO R4版」のソースコードを補完しましょう。

その前に「Cygwin」のインストールをお願いします。

このページ(TOPPERS/ASPのビルドからデバッグまで~Cygwinの導入)を参考にしてください。


次に「TOPPERS/ASP Arduino UNO R4版」のソースコードをゲットしちゃいましょう。

今、インストールしたばかりの「Cygwin」を起動させてください。

起動したターミナルで、以下のコマンドを使ってソースコードのクローンを行います。


$ git clone https://github.com/RyutaroMorita/asp_arduino_uno_r4_gcc.git

Cygwinターミナル - 1


上記のコマンドの結果、以下のパスにasp_arduino_uno_r4_gcc」というディレクトリが生成されたはずです。

エクスプローラを開いて、確認してみてください。


C:\cygwin64\home\<ユーザ名>

エクスプローラ - 1


この「asp_arduino_uno_r4_gcc」というディレクトリの名前を「asp_1.9.2」と改名してください。

(深い意味はないです…説明がしやすいだけ。)

エクスプローラ - 2


改名した「asp_1.9.2」ディレクトリの中身は、こんな風になっていると思います。

エクスプローラ - 3


この「asp_1.9.2」ディレクトリの下層、以下のパスを表示してみてください。


C:\cygwin64\home\<ユーザ名>\asp_1.9.2\target\arduino_uno_r4_gcc

ターゲットディレクトリのエクスプローラ - 1


ここには、TOPPERS/ASPカーネルのターゲットボード、すなわち、今回の場合は「Arduino UNO R4」依存のソースコードが格納されています。

このターゲットディレクトリのエクスプローラ、開いておいてくださいね。


さて、前回作成した雛形プロジェクトのディレクトリを別のエクスプローラで開きます。

記事のとおりに作業していただいた場合は、以下のパスに生成されています。


C:\Users\<ユーザ名>\e2_studio\workspace\Hinagata

エクスプローラ - 4


この中の以下の4つのディレクトリを予め開いておいたターゲットディレクトリのエクスプローラにコピーしてください。


●ra

●ra_cfg

●ra_gen

●src

エクスプローラ - 5


コピーが終わった時点で、ターゲットディレクトリのエクスプローラは、こんな感じの表示になりましたか?

ターゲットディレクトリのエクスプローラ - 2


この作業でコピーした雛形プロジェクトのディレクトリの中に入っているソースコードを補完することによって、不完全だった「TOPPERS/ASP Arduino UNO R4版」のソースコードは、完璧なものになりました。


試しに「Cygwin」ターミナルを使ってTOPPERS/ASPのビルドを通してみましょう。

「Cygwin」ターミナルを開いて、以下のコマンドでTOPPERS/ASPソースツリーの場所まで移動しましょう。


$ cd asp_1.9.2/


次にその直下の「OBJ」ディレクトリに移動します。


$ cd OBJ/


コンフィギュレーターのパーミッションを実行可能に設定します。


$ chmod 755 ../cfg/cfg/cfg.exe


ここまで、大丈夫ですか?

Cygwinターミナル - 2


そうしたら「OBJ」ディレクトリの中にあるコンフィグファイル(sample1.cfg)の情報を元に、OSに必要な定義を記したソースコード(「kernel_cfg.c」と「kernel_cfg.h」)を生成します。

これは、以下のコマンドで実行します。


$ make depend


以下のような表示にならずエラーが出力される場合は、残念ながらこれまでの作業に誤りがあります。

お手数ですが、最初からご確認を!

Cygwinターミナル - 3


ここまで上手くいったら、ホンチャンのビルド。

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


$ make all


以下のように無事にビルドが通ったでしょうか?

Cygwinターミナル - 4


さて、ターミナルでのビルドが通ったら、次はIDE(統合開発環境)の「e2studio」を使ってデバッグできるようにしたいと思います…が。

その前に、デバッガの「E2 emulator Lite」とターゲットの「Arduino UNO R4」とを接続するためのケーブルを作らなければなりません。

というわけで、次回は半田付け作業です。


<続く>

2023年12月13日水曜日

TOPPERS/ASP - PIC32MX版 目次

絶滅危惧の「MIPS」アーキテクチャのマイコン「PIC32MX」。

今後、たとえ「ARM」アーキテクチャに移行してしまっても、PICはPICらしく。

DIPパッケージをラインナップするなど、あくまでもホビーユーザーに寄り添ったマイコンであり続けて欲しいでものですね。

以下、TOPPERS/ASP PIC32MX版に関する記事の目次です。


■TOPPERS/ASP - PIC32MX版 その1

TOPPERS/ASP - PIC32MX版 概要

必要なもの

ダウンロード/GitHub


■TOPPERS/ASP - PIC32MX版 その2

開発環境の構築(MPLAB X IDE編)


■TOPPERS/ASP - PIC32MX版 その3

開発環境の構築(XC32コンパイラ編)


■TOPPERS/ASP - PIC32MX版 その4

開発環境の構築(Eclipse編)


■TOPPERS/ASP - PIC32MX版 その5

MPLAB Harmonyとは?

MPLAB Harmonyのインストール

MPLAB HarmonyのIDEへの登録


■TOPPERS/ASP - PIC32MX版 その6

雛形プロジェクトの作成


■TOPPERS/ASP - PIC32MX版 その7

Harmony Frameworkのコピー

雛形プロジェクトで生成したソースコードのコピー

コマンドラインでのビルド


■TOPPERS/ASP - PIC32MX版 その8

プロジェクトの作成(Eclipse編)

プロジェクトの作成(MPLAB X IDE編)


■TOPPERS/ASP - PIC32MX版 その9

シリアル通信用の配線の引き出し

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


■TOPPERS/ASP - PIC32MX版 その10

サンプルプロジェクトの説明

PIC32MX版カーネルについて

ライセンスについて


なお、Qiitaにも上記の記事を1ページにまとめたダイジェスト版を投稿しました。

こっちの方が読み易いです。

よろしければ参考にしてください。

Qiita

TOPPERS/ASP - PIC32MX版 - Qiita

2023年12月8日金曜日

「pcDuino3」でYocto Project その4

前回からの続きです。

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


「Yocto Project」の構築

前回「VMware Workstation Player」上にインストールした「Ubuntu」を立ち上げましょう。

「Ubuntu」 - 1


ターミナルを起動します。

キーボードの「Ctrl」+「Alt」+「T」を同時に押すと楽です。

「Ubuntu」 - 2


Linuxを扱うと、どうしてもターミナル(コマンドライン)での作業が多くなります。

アレルギーのある方は、今のうちに慣れておきましょう。

さて「Yocto Project」を動作させるには、いくつかのプログラムを予めインストールしておくことが前提となります。

それがまた、エラい数です。

早速、これらをインストールしましょう!

下のコマンドをコピーして「Ubuntu」のターミナルにペーストしてリターンキーを押しましょう。

(頭の「$ 」以降をコピーしてください。)

Winodowsから「VMware Workstation Player」上の「Ubuntu」へコピー・アンド・ペーストできますし、逆もまた可です。


  • $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev python3-subunit mesa-common-dev zstd liblz4-tool file locales
ターミナル - 1


ね!エラい数でしょ?

こんなのイチイチ打ってられるかっ!

パスワードの入力が求められます。

yocto」でしたね。

ターミナル - 2

「sudo」は、以降のコマンドを管理者権限で実行させるコマンドで「apt install」というのが、以降に続くプログラムをダウンロード、インストールするコマンドです。

以下の画面では、作業を続行して良いかどうかを問われています。

ここは、リターンキーを押します。

ターミナル - 3


作業中…。

意外と速く進みます。

ターミナル - 4


ダウンロードとインストールが終わると、以下の表示になります。

ターミナル - 5

次に、UTF-8ロケールの設定を行います。

要は文字コードの設定なのですが「Yocto Project」はUTF-8じゃないとトラブるようです。

以下のコマンドを入力してリターンキーを押します。


$ sudo locale-gen en_US.UTF-8

ターミナル - 6


いよいよ「Yocto Project」をダウンロード/インストールします。

以下のコマンドを入力してリターンキーを押します。


$ git clone git://git.yoctoproject.org/poky

ターミナル - 7

地味に時間がかかる感じ?

終了した模様。

ターミナル - 8


以下のコマンドで、現在のホームディレクトリに「poky」というディレクトリが生成されたことが確認できます。

これが「Yocto Project」の実体です。


$ ls -l

ターミナル - 9


では、その中に突入!

ターミナルに「$ cd poky/」と入力してリターンキーを…と、その前に豆知識。

例えば、今回のようにターミナルでディレクトリを打ち込む機会って今後も結構あると思います。

今回の場合「cd po…」まで打ってから「Tab」キーを押してください。

タブ補完機能 - 1


そうすると、勝手に残りの「…ky/」が補完されます。

タブ補完機能 - 2


これは「タブ補完」と呼ばれているもので、現在のディレクトリ直下の存在するディレクトリやファイルの候補を自動的に補完してくれる機能です。

(存在しない場合は、何も起こりません。)

つまり、目的のディレクトリやファイルの頭から2~3文字だけ入力して「Tab」キーを押すことで名前が補完されるので、長いパスをタイピングする必要がなくなります。

これなら、ターミナルでのキー入力の回数が大幅に減って、大変楽になります。

実は私、若かりし頃Linuxを触りだしてから、かなり長いことこの機能を知りませんでした。

そして立派なターミナル・アレルギーになってしまいました。

でも、これを知ってからターミナルが大好き…にはなってませんがね。

まあ、…普通?


さて、話を戻して。

ターミナルに「$ cd poky/」と入力してリターンキーです。


$ cd poky/

ターミナル - 10


ここで思案のしどころ…。

一口に「Yocto Project」と言っても、ソフトウェアなので古いのやら新しいのやら、色々とバージョンがあります。

このページに一覧表があります。

どれを選びましょう?

ソフトウェアというものは、新しいほど良いという訳ではありません。

とはいえ、古すぎては「pcDuino3」に新しいディストーションを!…という、今回の趣旨に反します。

「Yocto Project」は、経験上、サポートが終わったばかりの状態が一番安定している気がします。

(最近は違うのかも?)

というわけで、今回は「Mickledore」というのを選びます。

Yocto Project Releasesページ


Mickledore」=ミクルドア…、イギリスにある山の名前みたいですね。

以下のコマンドを入力してリターンキーを押します。


$ git checkout -t origin/mickledore -b pcduino3

ターミナル - 11

このコマンドは、説明が必要かもしれません。

通常「git clone」コマンドでダウンロードされるソースコードやドキュメント類は、公開されている最新のものとなります。

しかしながら、今回は少し古い「Mickledore」を使用したいのです。

そのためには、ダウンロードされたソースコードやドキュメント類をその「時期」のものに先祖返りさせる必要があります。

この「時期」を指すのがリモートブランチと言って、上記のコマンドでは「origin/mickledore」の部分にあたります。

そして「origin/mickledore」のスナップショットをダウンロードしたソースコードやドキュメント類に反映させます。

これを「checkout」と呼びます。

リモートブランチ「origin/mickledore」は、管理者によって今後も変更されるかもしれません。

一方「checkout」したスナップショットは、今後、私達が変更するかもしれません。

この時点で「origin/mickledore」は分岐したことになります。

文字通りブランチ「枝」別れという訳です。

本家の「origin/mickledore」は、リモートブランチとして今後も「Yocto Project」のGitサーバで管理されます。

スナップショットは「pcduino3」という新たな名前のローカルブランチとして私達の開発用PCの中で管理していきます。


…とまあ、分かりにくい説明で申し訳ありません。

要は、ダウンロードした最新の「Yocto Project」を少し古いバージョンに戻したよ!ってコトで。

次に「Yocto Project」の動作に必要な環境変数の設定と「build」ディレクトリを作成します。

以下のコマンドを入力してリターンキーを押します。

環境変数が設定され、さらに「build」ディレクトリが作成されて、そこに移動した様子が分かります。


$ source oe-init-build-env

ターミナル - 12

「Ubuntu」のエクスプローラーで見ても「poky」ディレクトリ以下に「build」ディレクトリが出来ていますね。

「build」ディレクトリ

さてさて、早速「Yocto Project」の試運転と行きましょうか。

そこで、ちょっと相談があるんですが…。

今、このページを読んでくれて、実際に試そうと思っている方!


今何時ですか?


…というのも、次のコマンドは終了までにとても長い時間がかかります。

試運転ですから、最小限の軽いLinuxディストリビューションを作ろうと思っています。

まずは、いきなり「pcDuino3」用ではなく、デフォルト設定の「x86-64」アーキテクチャ用、すなわち普通のPC向けのディストリビューションです。

それでも、開発用PCのスペックと、ネットの環境によっては5時間以上は覚悟です。

「Yocto Project」のビルドツールである「bitbake」は、相当に処理が重いため、その間はPCをほぼ専有されてしまいます。

ですので、次のコマンドは就寝前に実行することをオススメします。

朝起きれば、きっとディストリビューションのビルドが成功しているはずですよ。

普段の行いが良ければ。

…というわけで、布団の入る前に、以下のコマンドを入力してリターンキーを押します。


$ bitbake core-image-minimal

ターミナル - 13

なにやら、始まりましたよ~。

これは、ディストリビューションに含まれる様々なソフトウェアのソースコードをダウンロードしてはビルドする...ということを延々と繰り返しているようです。

ターミナル - 14

そして、就寝!!


起床!!


眠い目を擦りながらも、すかさず開発用PCの画面を確認。

よし!どうやらディストリビューションのビルドに成功したみたいです。

エラーが出た時って、真っ赤なエラーメッセージがビッシリ出力されるので一目で分かります。

ターミナル - 15


ビルドの成果物は、以下のパスに生成されています。

階層、深すぎですね…。


/home/yocto/poky/build/tmp/deploy/images/qemux86-64

ビルドの生成物のディレクトリ

タイムスタンプを見てみると、ディストリビューションのイメージファイルの生成時間が「4:50」くらい。

「bitbake」コマンドを打ったのが昨晩「0:00」くらいだったので、やっぱり5時間コースですね。

仕事でLinuxを扱っていた頃、今回のように会社で帰宅時に「bitbake」コマンドを打って、夜通しビルドを行うことがよくありました。

それで、翌朝出社して画面を見ると、大量のエラーが出てビルド失敗。

その日の出鼻を挫かれた感じで、一日中スッキリしない気分…なんてことは、組み込みLinuxエンジニアあるあるです。

エラーの原因は、色々あります。

単純にパラメータの入力ミスとかなら分かるのですが、ネットワークの切断だったり「Ubuntu」のフリーズだったり、はたまたソースコードのダウンロード元のサーバが落ちていたりなどなど、納得いかない理由であることもしばしば…。

どうやら、今回構築した「Yocto Project」は、正常に動作してくれたようです。


さて、今回はここまで。

今回は試運転だったので「pcDuino3」では動かないディストリビューションを作りました。

次回以降は、これを「pcDuino3」で動くようにする作業をやっていきましょう。


<続く>

2023年12月1日金曜日

TOPPERS/ASP - Arduino UNO R4版 その3

前回からの続きです。

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


Flexible Software Package (FSP)とは?

FSPとは、ドライバ、プロトコル・スタックなどを開発者に提供するソースコードのライブラリです。

いわゆるRenesas社純正のライブラリパッケージであり、これを使用するとマイコンに内蔵されているペリフェラル(周辺機器)を簡単に利用することができるというものです。

今回の「TOPPERS/ASP Arduino UNO R4版」のカーネル内でも、I/O関連のドライバなどは、このFSPのものを使用しています。

ところが、このFSPのソースコードのライセンスの条項が不明瞭なために再配布できません。

そのため「TOPPERS/ASP Arduino UNO R4版」のソースコードが不完全なものとなり、そのままではビルドが通らず、通すためには手動で不足分のソースコードをコピーしていただくという手間を強いることになってしまいました。

面倒くさい思いをさせてしまって申し訳ありません。

ですが、このFSPを上手く利用すれば「Arduino UNO R4」に搭載されているRAマイコンのすべての周辺機器を最小限のコーディングで簡単に利用できるようになります。

後々、このFSPの便利な使い方の例も書いていきたいと思いますので、どうぞよろしく。

さて、ビルドを通すために足りていないFSPのソースコードを何処から入手すれば良いのか?

そのためには、インストールした「e2 studio」上で雛形となるプロジェクトを作って、そこで生成されたFSPのソースコードを「TOPPERS/AS Arduino UNO R4版」のソースツリーにコピーするという方法を採ります。


雛形プロジェクトの作成

まずは「e2 studio」を起動して下さい。

「e2 studio」 - 1


次に、アプリケーションメニューの「ファイル」から「新規」をクリックし「Renesas C/C++ Project」をクリック、更に展開されたメニューから「Renesas RA」をクリックします。

「e2 studio」 - 2


以下のようなダイアログが表示されたら「Renesas RA C/C++ Project」の表示をクリックして選択状態にしてから、ダイアログ下部の「次へ」ボタンをクリックしましょう。

「New C/C++ Project 」ダイアログ


以下のように「Renesas RA C/C++ Project」ダイアログが表示されたら「Project name」の下のテキストボックスにプロジェクト名を入力します。

雛形プロジェクトなので「Hinagata」とでもしましょうかね。

入力したらダイアログ下部の「次へ」ボタンをクリックです。

「Renesas RA C/C++ Project」ダイアログ - 1


以下のように表示か切り替わります。

ここでは、どんなターゲット向けのソフトウェアを作るのかを問われています。

まずは、ターゲットのマイコン(Device)が違いますね。

「Arduino UNO R4」に搭載されているマイコンは、デフォルトで表記されている型番ではありません。

ですので、これを変更する必要があります。

R7FA2A1AB3CFM」と表記されているテキストボックスの左に「...」というボタンがありますので、これをクリック!

「Renesas RA C/C++ Project」ダイアログ - 2


以下のようなダイアログが表示されますので「Arduino UNO R4」に搭載されているマイコンである「R7FA4M1AB3CFM」を正しく選択して「OK」ボタンをクリックします。

「Device Selection」ダイアログ


「Renesas RA C/C++ Project」ダイアログに戻ります。

Device Selection」の欄に正しいマイコンの型番が表示されていることを確認し、次は「Debugger」の欄に注目します。

今回は、デバッガに「E2 Lite(ARM)」を使用しますので、コンボボックスをこれに設定します。

正しく設定できたら、ダイアログ下部の「次へ」ボタンをクリックしましょう!

「Renesas RA C/C++ Project」ダイアログ - 3


次の表示は、何もせずに「次へ」ボタンをクリックしていいです。

「Renesas RA C/C++ Project」ダイアログ - 4


次の表示も、何もせずに「終了」ボタンをクリック!

「Renesas RA C/C++ Project」ダイアログ - 5


次のポップアップが表示されますので「パースペクティブを開く」ボタンをクリックしてください。

ポップアップ


これで雛形プロジェクトが作成されたはずなのですが「e2 studio」を起動したときと同じ表示のままです。

開いたはずのパースペクティブとやらは一体どこに?

実は、ちゃんと開かれているのです。

「ようこそ」ビューが邪魔しているんですね。

なので、これを除けてしまいましょう。

「e2 studio」の画面右上に「ようこそ」ビューの最小化ボタン(アンダーバーみたいなやつ)がありますので、これをクリックしてください。

「e2 studio」 - 3


すると、以下のような表示になります。

画面左側の「プロジェクト・エクスプローラー」のリストには、ちゃんと「Hinagata」プロジェクトが生成されていることが確認できますね。

「e2 studio」 - 4


マイコンのピンの設定

中央の「Summary」と書いてある「FSP Configuration」タブに注目してください。

「e2 studio」 - 5


このタブの下部には、更に複数のタブが存在しますが、その中の「Pins」タブをクリックしてください。

「e2 studio」 - 6


以下の表示に切り替わります。

「e2 studio」 - 7


ここは何をする画面かっていうと、マイコンのピンの設定です。

例えば、このピンはGPIOに使う…とか、このピンはシリアル通信に使う…とか。

すなわち、今回のターゲットである「Arduino UNO R4」で使用されるマイコンのピンの機能を設定するための作業となります。

そのためには「Arduino UNO R4」の回路図が必要ですね。

ここから、ダウンロードをお願いします。

この回路図で注目したいのは、回路図左上の「HEADERS」の部分です。

「Arduino UNO R4」の回路図 - 1


黄色い四角の左側「JANALOG」は、以下の部分に相当します。

「Arduino UNO R4」 - 1


黄色い四角の右側「JDIGITAL」は、以下の部分ですね。

「Arduino UNO R4」 - 2


例えば、今「e2studio」で開いている「Pin Configuration」で、シリアル通信「SCI2」のためのピン「P302_SCI2_TXD」と「P301_SCI2_RXD」を設定したい場合を考えます。

「Arduino UNO R4」の回路図 - 2


その場合は「Pin Configuration」の中の左側「Pin Selection」リストの中から「SCI2」を選択します。

次に、新たに切り替わった左の「Pin Configuration」の「Operaring Mode」の行の「Disabled」という表記の左側の「」マークをクリックします。

これはコンボボックスになっていて、設定できる機能が展開されます。

この中から「Asynchronous UART」(つまり普通のシリアル通信)を選択します。

「e2 studio」 - 8


すると、以下の表示に切り替わります。

「TXD_MOSI」が「P302」に、「RXD_MOSI」が「P301」に自動的に割り付けられたようです。

回路図では「P302_SCI2_TXD」と「P301_SCI2_RXD」という表記だったので、どうやらこれで正しいようですね。

「e2 studio」 - 9


「FSP Configuration」タブの左側の「FSP Visualization」のマイコンの絵でも「TXD_MOSI」と「RXD_MOSI」が表示され、このピンが「SCI2」の通信用のピンとして割り当てられたことが確認できます。

「e2 studio」 - 10


今回は「TXD_MOSI」が「P302」に、「RXD_MOSI」が「P301」に自動的に割り付けられましたが、これは偶然かもしれません。

もし、それぞれを違うピンに割り付けたい場合は「Pin Configuration」上でピン名の左側にある「」マークをクリックすることで、他のピンの候補を探して、設定することができます。

「e2 studio」 - 11


さて、このような作業を使用するすべてのピンで行うことになります。

このピンはアナログ入力、このピンはI2C通信用、などなど。

でも…


超ぉ~メンドクセエぇ!!


…ごもっとも。

ですので、今回のTOPPERS/ASPを動作させるための最低限の設定済みファイルをアタクシめが用意しときましたぜっ、ダンナ!(誰だオマエ?)

…てなわけで、ここからダウンロードしてください。

arduino_uno_r4.pincfg」というファイルがダウンロードできます。

これをインポートすれば、面倒な作業は一瞬で終わります!

ダウンロードが終わったら「Pin Configuration」の「Manage configutrations...」という表示をクリックしてください。

「e2 studio」 - 12


以下の「Manage Pin Configrations」ダイアログが開いたら「Import」ボタンをクリックします。

「Manage Pin Configrations」ダイアログ - 1


続いて、以下の「Import Configration」ダイアログが開いたら「Browse...」ボタンをクリックします。

「Import Configration」ダイアログ - 1


ダウンロードした「arduino_uno_r4.pincfg」を選択すれば良いのですが…どこにも無いじゃん!って場合は、検索する拡張子を変更しましょう。

Altium Pin Configuration File(*.pincfg)」を選択します。

「Import from pin configuration file」ダイアログ - 1


そうすると「arduino_uno_r4.pincfg」が表示されるはずです。

これを選択し、ダイアログ下部の「開く」ボタンをクリックです!

「Import from pin configuration file」ダイアログ - 2


「Import Configration」ダイアログに戻ったら、追加された「arduino_uno_r4」のチェックボックスを有効にしてから、ダイアログ下部の「終了」ボタンをクリックです。

「Import Configration」ダイアログ - 2

「Manage Pin Configrations」ダイアログ に戻ったら、左側のリストに「arduino_uno_r4」が追加されていることを確認してください。

「Manage Pin Configrations」ダイアログ - 2


左側のリストに元々あった「R7FA4M1AB3CFM_pincfg」は、もういらないので削除しましょう。

ていうか、残ってると後々問題になります。

R7FA4M1AB3CFM_pincfg (Current)」を選択状態にしてから、右側の「Remove」ボタンをクリックします。

「Manage Pin Configrations」ダイアログ - 3

左側のリストで「R7FA4M1AB3CFM_pincfg (Current)」が削除されて「arduino_uno_r4 (Current)」だけが残っていることを確認して、ダイアログ下方の「OK」ボタンをクリックしてください。

ダイアログが消えて「Pin Configuration」に処理が戻ります。

「Manage Pin Configrations」ダイアログ - 4


するとどうでしょ?

ピンの設定が「arduino_uno_r4.pincfg」の内容に更新されていることが分かります。

「FSP Configuration」タブの左側の「FSP Visualization」のマイコンの絵も、設定を反映して、なにやら賑やかになってませんか?


クロックの設定

さて、お次は「Arduino UNO R4」のクロックの設定を行わなければなりません。

この雛形プロジェクトを作成した時点では、外部クロックのXTALを使用するように初期設定されているのですが、実際「Arduino UNO R4」には外部クロックのXTALが搭載されていません。

その代わりに、内部クロックを使用するように設定してあげなければいけません。

これを行うには「FSP Configuration」タブの下部の「Clock」タブをクリックして設定画面を開きます。

「e2 studio」 - 13


クロックの設定画面が開いたら、以下のように外部クロックのXTALを使用する設定から、内部クロック(HOCO 48MHz)を使用する設定に切り替えます。

変更は三箇所

「e2 studio」 - 14


<追記>

「Arduino UNO R4」には、サブクロックが実装されていません。

回路図を見るとRAマイコンの「XTAL」と「EXTAL」端子が未実装になっていることが分かると思います。

したがって、サブクロックを使用しない設定にしなければなりません。

これをやらないと、これから吐き出すコードの中のRTC設定処理でフリーズします。

(「FSP_HARDWARE_REGISTER_WAIT(R_RTC->RCR2_b.RESET, 0);」という行でデッドロック!)

サブクロックの設定は「FSP Configuration」タブの下部の「BSP」タブをクリック、更にその下部に配置されているビューの「プロパティ」タブをクリックして現れるリストボックスから行います。

もし「Subclock Populated」の項目が「Populated」になっていたら「Not Populated」へ変更しましょう。

(どうやら「e2 studio」のバージョンによってデフォルトの設定が変わるみたいです…。)

「e2 studio」 - 14.5


ソースコードの出力

時は来た!

設定内容をソースコードとして出力します。

「FSP Configuration」タブにおいて「Pin Configuration」の右側に「Generate Project Content」という表示があります。

これの「」マークをクリックです!

「e2 studio」 - 15


以下のポップアップが表示されますので「続行」ボタンをクリックします。

これで、設定内容に沿ったソースコードが雛形プロジェクトに出力されたはずです。

「Generate Project Content」ダイアログ


どんなふうに出力されたのかな?…って気になりませんか?

確認してみましょう。

「e2studio」を現在の「FSP Configuration」モードから「C/C++」モードに切り替えましょう。

この切り替えは、画面右上の「C/C++」ボタンで行います。

クリックしてみましょう。

「e2 studio」 - 16


画面左側の「プロジェクト・エクスプローラー」のリストから「Hinagata」、「ra_gen」の順に展開し「pin_data.c」をダブルクリックします。

すると、画面中央にソースコードが表示されます。

これが、今まで作業してきたピンの設定が出力されたものです。

ちょっと複雑ですが、定義名などの内容から「それっぽい」内容になっていることは分かりますね。

「e2 studio」 - 17


以上で、マイコンのピンの設定は完了です。


さて、今回は「TOPPERS/ASP Arduino UNO R4版」を動かす上で足りないソースコードを出力するための雛形プロジェクトを作りました。

また、その雛形プロジェクトで「Arduino UNO R4」に搭載されているマイコンのピン設定を行い、それを反映したソースコードも出力しました。

次のステップは「TOPPERS/ASP Arduino UNO R4版」のソースコードをダウンロードし、雛形プロジェクトで得られたソースコードをそこにコピーします。

その上で「TOPPERS/ASP Arduino UNO R4版」をターミナル(コマンドライン)でビルドするところまでを行っていきましょう。


<続く>

BSD 4-Clause License

  名称:「四条項BSDライセンス」(BSD-4-clause) タイプ: ・コピーレフト…× ・ライセンス文の掲示…〇 ・コピーライト(著作権)の掲示…〇 ・その他…〇 原文: Copyright (c) <year>, <copyright holde...