電子工作に関連するお話など・・
以前に、gcc-6.2.0 で、RL78 の gcc をビルドした時、C++ の構築時に
失敗した（１６ビットＣＰＵだとポインターが１６ビットなのが原因の
よう）ので、試さなかったが、ＲＸマイコンは純粋な３２ビットなので、
ビルドできるよなと思い、やってみた。
普通に成功した・・・
※６系は、ビルドも速い気がする。
5.4.0 では、「-flto」でビルドすると、ソースによっては、リンク時に
gcc がクラッシュする事があった、6.2.0 だと、今のところ、クラッシュ
しない～
バイナリーも小さくなる～
これは、もしかしたら、「良い」のかもしれない・・・
６系は、主に、C++1z に向けた、コンパイラと思っていたのだが、色々と
改修が進んでいるのかもしれない。
gcc-6.2.0 でコンパイルしたＲＸマイコンのプログラムも普通に動作する
ようだ。
ＲＸ２４Ｔのフラッシュ書き込みプログラムが動くようになった。
以前に実装したＲＸ６３Ｔ版と微妙に違うので、それを修正して、対応しただけ
なのだけど、ＲＸ６３Ｔより簡略化されているので、簡単だった。
※まだ、実装されていないプロトコルがある。（プロテクションＩＤの設定など）
ＲＸ６３Ｔでは、内臓発振器の周波数が低い為、速度をキックする場合には、外部
接続クリスタルの周波数を設定して、内部のクロックデバィダをプログラムする必
要があったが、ＲＸ２４Ｔでは、内部発振器の周波数はそこそこ高いので、その必
要は無くなった。
# Platform: 'Cygwin' # Configuration file path: 'rx_prog.conf' # Device: 'RX24T' # Serial port path: 'COM12' # Serial port speed: 115200 # Input file path: 'DS3231_sample.mot' # Motolola Sx format load map: (exec: 0x00000000) # 0xFFFC0000 to 0xFFFC1B4B (6988 bytes) # 0xFFFFFFD0 to 0xFFFFFFFF (48 bytes) # Total (7036 bytes) # Serial port alias: COM12 ---> /dev/ttyS11 # Serial port path: '/dev/ttyS11' # Connection OK. #01/01: Device: RX200 Series (LittleEndian) #01/01: Device ID: 0x33306638 #01/01: Data area: 1D #01/01: User Area: FFFC0000, FFFFFFFF #01/01: Data Area: 00100000, 00101FFF #01/02: Block: FFFC0000, 00000800, 00000080 #02/02: Block: 00100000, 00000400, 00000008 #01/01: Change baud rate: #01/01: ID Protect: Disable Write: ################################################ Verify: ################################################
-----
rx_prog では、rx63t_protocol.hpp、rx24t_protocol.hpp と２つの制御プログラム
を使っている、C++ では、通常このような場合には、インターフェースクラスを使
って切り替えるのが一般的ではあるが、「new」を使いたくないとか、ポインター
でアクセスするのが好きじゃ無いとか色々あり、boost::variant を使ってみた。
これを使って、各メソッドに対応する visitor クラスを実装すれば、同じような
共有化が出来る。
最初は、個々の visitor クラスの実装が面倒とも思ったが、インターフェースクラス
を書くのと大差無い事が判った。
これからは、boost::variant を積極的に使っていきたい～
ただ、エラー発生時に、非常にわかり難いエラーメッセージが出力される・・・
この辺りは慣れが必要と思う・・・
ＲＬ７８で、単線によるフラッシュプログラムですが、Windows 以外、シリアル
ドライバーの挙動に問題があり、全滅です・・
最近、アマゾンで買った中華製ＣＰ２１０２シリアルコンバーターも試しましたが、
やはり駄目でした、Linux 環境では、かなり良いとこまで進みますが、やはり途中
で駄目になります。
この問題は、以下のような事のようです。
・ＴＸＤ信号からＢＲＫを信号を送出できない（ＯＳ－Ｘの場合）
・フレーミングエラーを無視出来ない（ＯＳ－Ｘ、Ｌｉｎｕｘ）
※ＲＬ７８では、送信は２ストップビット、受信は１ストップビットの為
何か、別の方法があるのかもしれませんが、簡単に解決するには、中間に、単線信号
に変換するマイコンを入れるなどするしか無いようです。
※最新ドライバーをインストールしても、状況は同じようです・・・
-----
ＣＰ２１０２シリアルモジュールですが、裸で使うと、ショートの危険などあるので、
ケースに入れました。
・ＵＳＢのコネクターは、マイクロＵＳＢに交換しています。
・電源ランプとして、赤色ＬＥＤが付いているので、上部に穴をあけ、ホットボンド
で塞いであります。
・３．３Ｖ専用です。
・レギュレーターチップの上にスペーサーとして３ｍｍの板を乗せ、中の基板を固定
してあります。
・コネクターは６ピンの圧着用ピンヘッダーを使いました、これもアマゾンで、大量
購入したものです。
・信号としては、電源、送受信、/RTS、/CTS を出しています。
ケースは、「タカチ電気工業」のＣＳ７５Ｎを使いました。
・このケース、デザインも機能も優れており、加工しやすく、安く、お気に入りです！
加工は、リューターと棒ヤスリを使いましたが、いつも、削りすぎで、余分な隙間な
どできたりしますが、今回はパーフェクトでは無いけど、まぁまぁの出来です。
先日購入したＲＸ２４Ｔで、ＬＥＤの点滅が出来た。
ＲＸシリーズは、ＲＸ６２１に始まり、ＲＸ６３Ｔ、ＲＸ６４Ｍ、ＲＸ２４Ｔと色々扱う
事になった。
基本的にシリーズが違っても、内蔵ペリフェラルは、似通っているので、リソースの使い
まわしが出来るのがありがたい。
以前から、マイクロマウスをやろうかと思い、非常にゆっくり準備している。
本来、ＲＸ２４Ｔは、モーターの制御向けシリーズとして、ＲＸ２３Ｔの後継で、動作
周波数が８０ＭＨｚまでアップされ、注目していたが、チップワンストップで、
数量をある程度まとめると安いのを見つけて、購入した。
※１０個で＠４６０円くらい。
８０ＭＨｚで動作し、２５６Ｋのフラッシュと１６ＫのＲＡＭなど、コストパフォーマン
スが高い。
元々、このシリーズは、ブラシレスモーターの制御をターッゲットにしたものなのだが、
もちろん、それ以外の用途でも十分使えると思う、多少ＲＡＭの容量が少ないが・・
とりあえず、モーター制御に特化したものに利用する予定で、迷路の解析部分の「頭脳」
は、別に何かを使う予定でいる。
※１個のマイコンで全てまかなえればシンプルなのだが、初号機は、柔軟性など考えて、
とりえあず分離しておきたい。
ＲＸ２４Ｔで少し違うのは、内部のフラッシュは、最大でも３２ＭＨｚまでしか動作しな
い為、フルスピード（８０ＭＨｚ）で動かす場合には、ウェイトを入れる必要がある点で、
device::SYSTEM::PRCR = 0xA50B; // クロック、低消費電力、関係書き込み許可 device::SYSTEM::MEMWAIT = 0b10; // 80MHz 動作 wait 設定
レジスタのプロテクトを解除後、スピードをキックする為に備えて、ウェイトを入れてお
く必要がある。
今回最大周波数は８０ＭＨｚなので、外部発信は、１０ＭＨｚのクリスタルを使った。
ＬＥＤは、Ｐ００（４）に赤色ＬＥＤ（ＶＦ：１．９Ｖ）を１．５Ｋの抵抗を入れて、吸い
込みで接続してある。
LTO のトラブルをうけて、gcc をより新しいバージョンへ移行する事にした。
とは言っても、時間はかかるものの（１時間もかからないが・・）、そんなに新しい
事は無い。
まず、パッケージの選択、６系は、まだ移るには早いようなので、５系の最新、５．４
にする。
合わせて、binutils、newlib も割と最新で統一した。
binutils-2.27.tar.gz gcc-5.4.0.tar.gz newlib-2.4.0.tar.gz
今回から、C コンパイラのビルドオプションは、「--disable-multilib」に変更した。
３２ビットのＲＸマイコンには必要ないうえに、付けるとビルド時間が長くなるようだ。
gcc-4.9.4 で、「-flto」を付けた場合に、リンク時に gcc がクラッシュするトラブルは
起こらないようだ・・
ただ、コンパイルするプログラムに依存すると思われるものなので、たまたま、クラッシュ
しないだけかもしれない・・
クラッシュするようだと、-flto は諦めるしかない・・・
・-flto の場合
text data bss dec hex filename 4012 48 1316 5376 1500 uart_sample.elf
・無しの場合
text data bss dec hex filename 4092 48 1316 5456 1550 uart_sample.elf
プログラムが短いので、効果が分かりにくいものの、小さくなっている。
最近 gcc の最適化オプションに関連するトラブルで悩んでいる・・・
gcc 4.8 から導入されたと言われる「LTO」(Link-Time Optimization)は、ソース単位
を超えた最適化を行う。
非常に有用で、サイズ、スピード、共に改善するようだ。
ＲＬ７８では、ＳＤカードを扱うようになってバイナリーサイズが肥大化してきたので、
積極的に「-flto」を追加するようになった。
バイナリーが１０％程小さくなり、大きな効果がある事が分かった。
しかし・・・
最近、ＲＬ７８のフラッシュ書き込みプログラムの実装を進めて、ＭＳＹＳ２環境では
書き込みが出来るようになった。
そこで、ＯＳ－ＸやＬｉｎｕｘでもテストを始めてみたのだが、書き込みプログラムは
ＭＳＹＳ２以外では動作しなかった。
まあこれは、仕方無い、原因を特定して修正するだけなのだが、問題は、ＯＳ－Ｘ、
Ｌｉｎｕｘでビルドした rl78-elf-gcc だった。
明らかにＭＳＹＳ２で作成したバイナリーと異なっている。
調べると、どうやら、どこからも参照されないテーブルや関数が、全て無くなっていて、
最終的なバイナリーに含まれていない。
これは、主に、割り込みベクターや、割り込みプログラムなどで、無ければ当然動作し
ない。
しかしながら、ＭＳＹＳ２でビルドしたバイナリーには、ちゃんと含まれている。
つまり、ＭＳＹＳ２で作成した gcc と、ＯＳ－Ｘ、Ｌｉｎｕｘでビルドした gcc では
異なっているという事だ、確かに、ファイルパスの扱いなどが違うので、異なってはい
ると思うが、ビルドしたバイナリーが異なるのは、非常に問題だ。
リンカースクリプト内には、「KEEP」宣言もしてあっても、削除されてしまう。
※これは、MSYS2 でビルドした gcc では起こらない。
とりあえず、「#pragma GCC optimize ("O0")」をベクター領域で宣言する事で、回避
できる事は分かったものの、釈然としない・・
まだ LTO は実装が始まったばかりで、「枯れていない」という事なのかもしれない。
それと、ＲＬ７８では、０ｘ００００～０ｘ２ＦＦＦまでの領域は、ミラー領域として、
データ領域のアクセスでは、実際には、０ｘＦ００００～０ｘＦ２ＦＦＦの、データ・
フラッシュ領域がアクセスされるのだが、ＬＴＯを使うと、コードが、０ｘ００００～
０ｘ２ＦＦＦまでには配置されずに、その領域を有効に使えない為、割り込み駆動のタ
スクをその領域に配置するようにセクションを調整しているものの、これも、全く配置
されない・・・
MSYS2 の gcc では、ちゃんと配置される。
さらに問題は色々あって、RX マイコン用 gcc でも、LTO を使うと、リンカー時に、
gcc がクラッシュする場合があるようだ・・・
これは、プログラムによって、する場合としない場合があるようで、非常に困る。
当面 LTO を使う事ができない。
gcc-5.4.0 で、このバグが直っているかもと思い、試してみたが、駄目のようだ・・・
ＲＸ６４Ｍ用に定義ファイルの整備を進めている。
実装して、動かしてみると、ＲＸ６３Ｔと色々違う部分も多い事が分かる。
大きく変わったところは、割り込みベクター関係で、割り込み要因や、ベクター番号
がかなり違う・・・
ペリフェラルが多いので、以前と同じようには扱えなくなり、苦肉の策で拡張した感
じが見受けられる。
たとえば、タイマー割り込み（ＣＭＴ）は２ユニット２チャンネルあり、割り込みは
４つだが、そのうち２つを使う事ができる。（ＣＭＩ０、ＣＭＩ１）
ＣＭＩ２、ＣＭＩ３は、「選択型割り込み」に分類されており、要因と割り込みベク
ターをどうするかをプログラムしなければならない。
シリアルコミュニケーションでは、受信エラーと、送信完了割り込みが、グループ割
り込みに分類されており、それらを使う場合にやはりプログラムしなければならない。
送信動作は、送信完了割り込みを使った方が、実装が簡単なので、以前の実装では、
送信完了割り込みを使っていたが、そうすると、ＲＸ６３Ｔなどと共通化が難しくな
るので、実装を変更して、送信割り込みに変更する事にした。
とりあえず、この割り込み修正は、うまくいった。
ＲＸ６４Ｍの他にＲＸ２４Ｔも１０個購入したので、近いうちに、ＬＥＤ点滅から始
める予定なのだが、主に、各ペリフェラルの制御クラスを共通化したいのだけど、
ＲＸ６３Ｔ、ＲＸ６４Ｍ、ＲＸ２４Ｔ、ＲＸ６２１、ＲＸ６３０、ＲＸ６２Ｎと、様
々なグループがあり、似ている部分とそうでも無い部分など、うまくグループの違い
を吸収する構成を考えないと・・・
ＲＬ７８に寄り道していた為、ＲＸマイコン関係はしばらく停滞していたが、ようやく
再開、ＲＸ６４Ｍのブートが出来た。
ＲＸ６４Ｍは、ＲＸマイコングループ中では、かなり豪勢なデバイスで、単価も高く
２０００円くらいした。
Ｆｌａｓｈは２ＭＢあり、内蔵ＲＡＭも５１２Ｋバイトもある。
※外部バスに３２ビットでＳＤＲＡＭを繫ぐ予定なので、１７６ピンのタイプとした。
・１７６ピンＬＱＦＰタイプ
単純に電源を全て接続し、パスコンを入れ、制御端子を設定する。
今回、ＵＳＢ接続は行わず、シリアル接続とした。
※ＯＳ－ＸやＬｉｎｕｘの開発環境を意識している。
ＲＬ７８やＲ８Ｃと違い、ＲＸマイコンは内臓発信機を使う文化が無いため、必ず外部
にクリスタルを接続する必要がある。
※今回１２ＭＨｚを使った。
ＲＸ６４Ｍには高速オンチップオシレーターが内臓されており、１６ＭＨｚ、１８ＭＨｚ、２０ＭＨｚ
から選択できるようになっている。
しかし、やはりクリスタルの方が正確であるので、クリスタルを接続する事とする。
※最近の内臓発信器の精度は、極めて高いので、そのうち、クリスタルを必要としなくなるのだと思う。
EMLE(10) ---> Vss MD/FINED(18) ---> Boot:Low / SingleChip:High PC7/UB(76) ---> Vss (serial boot) VCL(14) ---> 0.1uF で Vss に接続 RES#(21) ---> Reset ボタン（10K でプルアップ）
さて、ブートが出来たので、早速ＬＥＤの点滅でもやってみよう～
ＲＸ６４Ｍには、非常に沢山のＩ／Ｏがあるので、定義を実装するのは相当時間がかか
りそうではある・・・、かなり共通に出来そうなのと、Ｒ８Ｃ、ＲＬ７８で、テンプレ
ートの書き方が進歩した事もあり、洗練されてきている感があるが、とりあえず、必要
になったら実装する感じで、進める事とする～
さて、ＬＥＤをどこに接続するか・・・
色々考えたが、Ｐ０７（１７６）に吸い込みで赤色ＬＥＤを接続した、電流制限は
１．５Ｋオーム
電源用にブルーＬＥＤでも接続しようと思ったが、古いロットなので、順方向電圧降下が
３．８Ｖもあり、無理と分かった・・・
最近のブルーＬＥＤは、ＶＦが２．９Ｖとかで、効率が上がっている。
ＬＥＤの点滅は、簡単なので、直ぐに出来た。
やっと、ＲＬ７８のフラッシュへの書き込みが出来るようになった。
これで、「Renesas Flash Programmer」に頼る必要が無くなったと言いたいところだけど、
書き込めるのは Windows 環境のみという現状・・・
ＯＳ－Ｘでは、初期のブートモードにエントリーする部分で失敗し、Linux 環境では、初
期設定で失敗する。
調べると、どうも、シリアルドライバーの不具合のように思うが、ドライバーは最新のよ
うでもある・・・
現在ＵＳＢシリアルチップはＦＴＤＩのＦＴ２３１ＸＳを使っているだが、別のチップで
試してみたいので、中華製のアダプターを複数購入、配達待ちとなっている。
ソースコード共通化の為、「termios.h」の API を使っているけど、逆に Windows 版が、
バグがあり、偶然通信できているだけなのかもしれない。
一番の懸念は、ＲＬ７８のブートモードで、ＴＯＯＬ端子１本を使う半二重モードは、
ＰＣ－＞ＲＬ７８は「２ストップビット」、ＲＬ７８－＞ＰＣは「１ストップビット」と
変則仕様になっている・・（何故、こんな仕様にしたのか、問いただしたい！）
一般的なシリアルドライバーでは、受信と送信で別々の通信フォーマットを設定できるよ
うには作られていない為、本来なら、これは、フレーミングエラーが発生してまともに通
信できないのだが、termios API で、これを無視する設定があり、Windows では、それが
機能しており、通信ができている。
Linux のドライバーは、無視する設定をしても、無視してくれないようだ・・・
一方ＯＳ－Ｘでは、送信データ出力のレベルを制御する機能が正常に動作していないよう
で、ＲＬ７８をブートモードに「入れる」事が出来ずに失敗する。
-----
・ＲＬ７８／Ｇ１３（１２８Ｋ）のみの検証
・データフラッシュへの書き込みは試していない
・単線式の書き込みモードのみ対応
・リセット制御は、ＲＴＳ端子を利用
ＲＬ７８へのフラッシュ・プログラムは、Ｒ８ＣともＲＸとも違う仕様で（元々メーカー
が違うのでしょうがないのだけど・・・）動くまでに多少時間を要した。
ＲＬ７８では、以下の特徴がある：
・基本的に内臓フラッシュの読み出しは行えない。
・「Verify」は行える。
・書き込み時に、内部で「Verify」も行う為、書き込み終了時に「Verify」を行う必要が
ほぼ無い。
Renesas RL78 Series Programmer Version 0.10b
Copyright (C) 2016, Hiramatsu Kunihito (hira@rvf-rc45.net)
usage:
rl78_prog [options] [mot file] ...
Options :
-P PORT, --port=PORT Specify serial port
-s SPEED, --speed=SPEED Specify serial speed
-d DEVICE, --device=DEVICE Specify device name
-V VOLTAGE, --voltage=VOLTAGE Specify CPU voltage
-e, --erase Perform a device erase to a minimum
-v, --verify Perform data verify
-w, --write Perform data write
--progress display Progress output
--device-list Display device list
--verbose Verbose output
-h, --help Display this
主に更新を続けている Git なのだけど、ちょっとした工夫で、開発環境が
より良くなる事は多い。
以前から、Makefile を少しづつアップデートをし続けて、現在に至ってい
る。
知り合いに、cmake を使うと柔軟で便利と言われていて、確かにそうだけど、
そこは天邪鬼な自分、「make」だけで何とかならないか・・・
※cmake を使って Makefile を作る手間が面倒
gcc のビルドだと、最初に「configure」を動かして、ビルドのオプション
を設定し、必要な中間ファイルを作成したりして、最終的に「Makefile」が
作成される。
また、Windows、OS-X を主なプラットホームにしているので、どちらでも遜
色無く機能してもらい、一元管理したい。
結局、「Makefile」だけの工夫で、全てまかなえている。
・従属規則を自動で生成する事
・コンパイルして生成したオブジェクトを１つのディレクトリーに集約する事
・リリース、デバッグなどのビルド切り替えが出来る事
・基本「make」だけタイプすれば、全てが生成できる事
ユーザーが記述すべき部分：
#=======================================================#
# #
# RL78 Makefile #
# #
#=======================================================#
TARGET = lcd_filer_sample
DEVICE = R5F100LGAFB
FATFS_VER = ff12a
BUILD = release
VPATH = ../
ASOURCES = common/start.s
CSOURCES = common/init.c \
common/vect.c \
common/option_bytes.c \
$(FATFS_VER)/src/ff.c \
$(FATFS_VER)/src/option/unicode.c \
common/time.c
PSOURCES = main.cpp \
common/font6x12.cpp
これは、「RL78/G13」の「Makefile」の先頭部分ではあるが、基本的に、ソース
コードの指定だけすれば良い。
従属規則は、自動で生成される。
「ASOURCES」はアセンブラのソース
「CSOURCES」は C 用ソース
「PSOURCES」は C++ 用ソースとなっている。
バックスラッシュで改行をエスケープして、１行に１ファイルとしている。
※この方が見やすいし、再利用する場合に利便性が高い。
「VPATH」は特別な変数で、この場合、一つ手前のディレクトリー以下にあるファ
イルを参照出来るようにしている。
※「VPATH」の値には make がサーチするディレクトリのリストを指定します。
「BUILD」に「release」とすれば、リリースビルド、「debug」とすればデバッグ
ビルドとなる。
生成されたオブジェクトは、「release」又は「debug」ディレクトリーが作られて
その中に全て格納される。
この中には、従属規則のパスが記述されたファイル、「source.d」も格納される。
新しいプロジェクトでは、Makefile をコピーして、必要な部分を少し編集すれば
良く、IDE でプロジェクトを再設定するより簡単だとおもう、この辺りも、IDE を
使わない理由の一つだと思う。
デバッグとリリース時のコンパイラオプションの違い：
ifeq ($(BUILD),debug)
POPT += -g
COPT += -g
PFLAGS += -DDEBUG
CFLAGS += -DDEBUG
endif
ifeq ($(BUILD),release)
PFLAGS += -DNDEBUG
CFLAGS += -DNDEBUG
endif
ビルド・ディレクトリーが「release」か、「debug」で、コンパイル・オプション
を切り替えている。
従属規則の自動生成：
これが、一番のキモとも言える、従属規則は、ソースコードでインクルードされた
全てのファイルパスを示したもので、この規則を使って、「make」がファイルの更
新が起こった場合に自動で対応するソースをコンパイルする事が出来る。
この規則を自分で記述するのは愚かと思えるくらい面倒で、ソースのインクルード
を増やしたり減らしたりする度に記述をやりなおさないとならないし、インクルー
ドを全て巡らないとならない。
※大抵、make の入門編などでは、これを入力させるように説明している事が多い。
そこで、これらを、ソースコードから辿って、自動で生成する事にした。
以前は、専用コマンド「makedepend」を使っていたが、gcc に「-MM」というオプ
ションがありこれにより、ソースコードがインクルードしているファイルをリスト
出来る、ただし、gcc が出力するパスは、完全では無い為、「sed」を使って、完
全なパスを生成するように工夫している。
$(BUILD)/%.d: %.c
mkdir -p $(dir $@); \
$(CC) -MM -DDEPEND_ESCAPE $(COPT) $(CFLAGS) $(APPINCS) $< \
| sed 's/$(notdir $*)\.o:/$(subst /,\/,$(patsubst %.d,%.o,$@) $@):/' > $@ ; \
[ -s $@ ] || rm -f $@
※ C ソース用
$(BUILD)/%.d: %.cpp
mkdir -p $(dir $@); \
$(CP) -MM -DDEPEND_ESCAPE $(POPT) $(PFLAGS) $(APPINCS) $< \
| sed 's/$(notdir $*)\.o:/$(subst /,\/,$(patsubst %.d,%.o,$@) $@):/' > $@ ; \
[ -s $@ ] || rm -f $@
※ C++ ソース用
※「DEPEND_ESCAPE」は、特定のヘッダーで、従属規則が正しく生成できない場合に、
それをエスケープする。
release/main.o release/main.d: main.cpp ../G13/system.hpp ../common/io_utils.hpp \ ../common/port_utils.hpp ../G13/port.hpp ../common/fifo.hpp \ ../common/uart_io.hpp ../G13/sau.hpp ../G13/intr.hpp \ ../common/itimer.hpp ../G13/timer.hpp ../common/task.hpp \ ../common/adc_io.hpp ../G13/adc.hpp ../common/delay.hpp \ ../common/format.hpp ../common/monograph.hpp ../common/font6x12.hpp \ ../common/kfont12.hpp ../ff12a/src/ff.h ../ff12a/src/integer.h \ ../ff12a/src/ffconf.h ../common/sdc_io.hpp ../ff12a/mmc_io.hpp \ ../common/csi_io.hpp ../ff12a/src/diskio.h ../common/string_utils.hpp \ ../common/time.h ../common/filer.hpp ../common/bitset.hpp \ ../common/switch_man.hpp ../chip/ST7565.hpp
※これは、自動で生成された、「main.cpp」の従属規則「release/main.d」
プラットホーム毎の違いを吸収する：
ifeq ($(OS),Windows_NT)
SYSTEM := WIN
else
UNAME := $(shell uname -s)
ifeq ($(UNAME),Linux)
SYSTEM := LINUX
endif
ifeq ($(UNAME),Darwin)
SYSTEM := OSX
OSX_VER := $(shell sw_vers -productVersion | sed 's/^\([0-9]*.[0-9]*\).[0-9]*/\1/')
endif
endif
この判定で、変数「SYSTEM」にＯＳの属性が代入される。
又、「OSX」の場合、「OSX_VER」にバージョン番号が代入される。