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 」で、テストプログラムを動かして...