RX24TでLED点滅

先日購入したRX24Tで、LEDの点滅が出来た。

RXシリーズは、RX621に始まり、RX63T、RX64M、RX24Tと色々扱う
事になった。

基本的にシリーズが違っても、内蔵ペリフェラルは、似通っているので、リソースの使い
まわしが出来るのがありがたい。

以前から、マイクロマウスをやろうかと思い、非常にゆっくり準備している。
本来、RX24Tは、モーターの制御向けシリーズとして、RX23Tの後継で、動作
周波数が80MHzまでアップされ、注目していたが、チップワンストップで、
数量をある程度まとめると安いのを見つけて、購入した。
※10個で@460円くらい。
80MHzで動作し、256Kのフラッシュと16KのRAMなど、コストパフォーマン
スが高い。
元々、このシリーズは、ブラシレスモーターの制御をターッゲットにしたものなのだが、
もちろん、それ以外の用途でも十分使えると思う、多少RAMの容量が少ないが・・

とりあえず、モーター制御に特化したものに利用する予定で、迷路の解析部分の「頭脳」
は、別に何かを使う予定でいる。
※1個のマイコンで全てまかなえればシンプルなのだが、初号機は、柔軟性など考えて、
とりえあず分離しておきたい。

RX24Tで少し違うのは、内部のフラッシュは、最大でも32MHzまでしか動作しな
い為、フルスピード(80MHz)で動かす場合には、ウェイトを入れる必要がある点で、

	device::SYSTEM::PRCR = 0xA50B;	// クロック、低消費電力、関係書き込み許可

	device::SYSTEM::MEMWAIT = 0b10; // 80MHz 動作 wait 設定

レジスタのプロテクトを解除後、スピードをキックする為に備えて、ウェイトを入れてお
く必要がある。

今回最大周波数は80MHzなので、外部発信は、10MHzのクリスタルを使った。

LEDは、P00(4)に赤色LED(VF:1.9V)を1.5Kの抵抗を入れて、吸い
込みで接続してある。

img_0849s

RX24T LED 点滅

RXマイコン用 gcc-5.4.0 の構築

LTO のトラブルをうけて、gcc をより新しいバージョンへ移行する事にした。

とは言っても、時間はかかるものの(1時間もかからないが・・)、そんなに新しい
事は無い。

まず、パッケージの選択、6系は、まだ移るには早いようなので、5系の最新、5.4
にする。
合わせて、binutils、newlib も割と最新で統一した。

  binutils-2.27.tar.gz
  gcc-5.4.0.tar.gz
  newlib-2.4.0.tar.gz

今回から、C コンパイラのビルドオプションは、「--disable-multilib」に変更した。
32ビットのRXマイコンには必要ないうえに、付けるとビルド時間が長くなるようだ。

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 LTO のトラブル

最近 gcc の最適化オプションに関連するトラブルで悩んでいる・・・

gcc 4.8 から導入されたと言われる「LTO」(Link-Time Optimization)は、ソース単位
を超えた最適化を行う。
非常に有用で、サイズ、スピード、共に改善するようだ。

RL78では、SDカードを扱うようになってバイナリーサイズが肥大化してきたので、
積極的に「-flto」を追加するようになった。
バイナリーが10%程小さくなり、大きな効果がある事が分かった。

しかし・・・

最近、RL78のフラッシュ書き込みプログラムの実装を進めて、MSYS2環境では
書き込みが出来るようになった。
そこで、OS-XやLinuxでもテストを始めてみたのだが、書き込みプログラムは
MSYS2以外では動作しなかった。
まあこれは、仕方無い、原因を特定して修正するだけなのだが、問題は、OS-X、
Linuxでビルドした rl78-elf-gcc だった。
明らかにMSYS2で作成したバイナリーと異なっている。

調べると、どうやら、どこからも参照されないテーブルや関数が、全て無くなっていて、
最終的なバイナリーに含まれていない。
これは、主に、割り込みベクターや、割り込みプログラムなどで、無ければ当然動作し
ない。
しかしながら、MSYS2でビルドしたバイナリーには、ちゃんと含まれている。

つまり、MSYS2で作成した gcc と、OS-X、Linuxでビルドした gcc では
異なっているという事だ、確かに、ファイルパスの扱いなどが違うので、異なってはい
ると思うが、ビルドしたバイナリーが異なるのは、非常に問題だ。

リンカースクリプト内には、「KEEP」宣言もしてあっても、削除されてしまう。
※これは、MSYS2 でビルドした gcc では起こらない。

とりあえず、「#pragma GCC optimize ("O0")」をベクター領域で宣言する事で、回避
できる事は分かったものの、釈然としない・・
まだ LTO は実装が始まったばかりで、「枯れていない」という事なのかもしれない。

それと、RL78では、0x0000~0x2FFFまでの領域は、ミラー領域として、
データ領域のアクセスでは、実際には、0xF0000~0xF2FFFの、データ・
フラッシュ領域がアクセスされるのだが、LTOを使うと、コードが、0x0000~
0x2FFFまでには配置されずに、その領域を有効に使えない為、割り込み駆動のタ
スクをその領域に配置するようにセクションを調整しているものの、これも、全く配置
されない・・・
MSYS2 の gcc では、ちゃんと配置される。

さらに問題は色々あって、RX マイコン用 gcc でも、LTO を使うと、リンカー時に、
gcc がクラッシュする場合があるようだ・・・
これは、プログラムによって、する場合としない場合があるようで、非常に困る。
当面 LTO を使う事ができない。

gcc-5.4.0 で、このバグが直っているかもと思い、試してみたが、駄目のようだ・・・

RX64M 割り込みなど・・

RX64M用に定義ファイルの整備を進めている。

実装して、動かしてみると、RX63Tと色々違う部分も多い事が分かる。
大きく変わったところは、割り込みベクター関係で、割り込み要因や、ベクター番号
がかなり違う・・・
ペリフェラルが多いので、以前と同じようには扱えなくなり、苦肉の策で拡張した感
じが見受けられる。

たとえば、タイマー割り込み(CMT)は2ユニット2チャンネルあり、割り込みは
4つだが、そのうち2つを使う事ができる。(CMI0、CMI1)
CMI2、CMI3は、「選択型割り込み」に分類されており、要因と割り込みベク
ターをどうするかをプログラムしなければならない。

シリアルコミュニケーションでは、受信エラーと、送信完了割り込みが、グループ割
り込みに分類されており、それらを使う場合にやはりプログラムしなければならない。

送信動作は、送信完了割り込みを使った方が、実装が簡単なので、以前の実装では、
送信完了割り込みを使っていたが、そうすると、RX63Tなどと共通化が難しくな
るので、実装を変更して、送信割り込みに変更する事にした。

とりあえず、この割り込み修正は、うまくいった。

RX64Mの他にRX24Tも10個購入したので、近いうちに、LED点滅から始
める予定なのだが、主に、各ペリフェラルの制御クラスを共通化したいのだけど、
RX63T、RX64M、RX24T、RX621、RX630、RX62Nと、様
々なグループがあり、似ている部分とそうでも無い部分など、うまくグループの違い
を吸収する構成を考えないと・・・
img_0845s

RX64M UART(SCI)サンプル

俺俺 RX マイコンボードを作ろう!(その3)

RL78に寄り道していた為、RXマイコン関係はしばらく停滞していたが、ようやく
再開、RX64Mのブートが出来た。

RX64Mは、RXマイコングループ中では、かなり豪勢なデバイスで、単価も高く
2000円くらいした。
Flashは2MBあり、内蔵RAMも512Kバイトもある。
※外部バスに32ビットでSDRAMを繫ぐ予定なので、176ピンのタイプとした。

・176ピンLQFPタイプ
img_0844s

単純に電源を全て接続し、パスコンを入れ、制御端子を設定する。

今回、USB接続は行わず、シリアル接続とした。
※OS-XやLinuxの開発環境を意識している。

RL78やR8Cと違い、RXマイコンは内臓発信機を使う文化が無いため、必ず外部
にクリスタルを接続する必要がある。
※今回12MHzを使った。

RX64Mには高速オンチップオシレーターが内臓されており、16MHz、18MHz、20MHz
から選択できるようになっている。
しかし、やはりクリスタルの方が正確であるので、クリスタルを接続する事とする。
※最近の内臓発信器の精度は、極めて高いので、そのうち、クリスタルを必要としなくなるのだと思う。

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 でプルアップ)

さて、ブートが出来たので、早速LEDの点滅でもやってみよう~
RX64Mには、非常に沢山のI/Oがあるので、定義を実装するのは相当時間がかか
りそうではある・・・、かなり共通に出来そうなのと、R8C、RL78で、テンプレ
ートの書き方が進歩した事もあり、洗練されてきている感があるが、とりあえず、必要
になったら実装する感じで、進める事とする~

さて、LEDをどこに接続するか・・・
色々考えたが、P07(176)に吸い込みで赤色LEDを接続した、電流制限は
1.5Kオーム

電源用にブルーLEDでも接続しようと思ったが、古いロットなので、順方向電圧降下が
3.8Vもあり、無理と分かった・・・
最近のブルーLEDは、VFが2.9Vとかで、効率が上がっている。

LEDの点滅は、簡単なので、直ぐに出来た。

rx64m_first_sample

RL78/G13のフラッシュ書き込みプログラム

やっと、RL78のフラッシュへの書き込みが出来るようになった。

これで、「Renesas Flash Programmer」に頼る必要が無くなったと言いたいところだけど、
書き込めるのは Windows 環境のみという現状・・・
OS-Xでは、初期のブートモードにエントリーする部分で失敗し、Linux 環境では、初
期設定で失敗する。

調べると、どうも、シリアルドライバーの不具合のように思うが、ドライバーは最新のよ
うでもある・・・
現在USBシリアルチップはFTDIのFT231XSを使っているだが、別のチップで
試してみたいので、中華製のアダプターを複数購入、配達待ちとなっている。

ソースコード共通化の為、「termios.h」の API を使っているけど、逆に Windows 版が、
バグがあり、偶然通信できているだけなのかもしれない。

一番の懸念は、RL78のブートモードで、TOOL端子1本を使う半二重モードは、
PC->RL78は「2ストップビット」、RL78->PCは「1ストップビット」と
変則仕様になっている・・(何故、こんな仕様にしたのか、問いただしたい!)
一般的なシリアルドライバーでは、受信と送信で別々の通信フォーマットを設定できるよ
うには作られていない為、本来なら、これは、フレーミングエラーが発生してまともに通
信できないのだが、termios API で、これを無視する設定があり、Windows では、それが
機能しており、通信ができている。

Linux のドライバーは、無視する設定をしても、無視してくれないようだ・・・

一方OS-Xでは、送信データ出力のレベルを制御する機能が正常に動作していないよう
で、RL78をブートモードに「入れる」事が出来ずに失敗する。

-----

・RL78/G13(128K)のみの検証
・データフラッシュへの書き込みは試していない
・単線式の書き込みモードのみ対応
・リセット制御は、RTS端子を利用

RL78へのフラッシュ・プログラムは、R8CともRXとも違う仕様で(元々メーカー
が違うのでしょうがないのだけど・・・)動くまでに多少時間を要した。

RL78では、以下の特徴がある:
・基本的に内臓フラッシュの読み出しは行えない。
・「Verify」は行える。
・書き込み時に、内部で「Verify」も行う為、書き込み終了時に「Verify」を行う必要が
ほぼ無い。

RL78(GitHub)

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

RL78_FlashProgrammer

ASUS UX32VD にも Ubuntu を入れてみる

前回のブログでHPのミニノートにUbuntuをインストールして、
気を良くしたのだが、いかんせん、あまりに反応が遅くて、辛い・・・

最近は、モバイル環境はMac-Bookばかりで、Windowsの
ノートをあまり使わなくなったので、UX32VDにもインストールし
てみた。
一応HDD仕様なので、それを外して、128GBのSSDに交換して
それにインストールしてみた。
※128GBのSSDはOrangePiに使う予定で買っておいたも
のだった・・

メモリーは4GBなので、64ビット版をインストールする。

ubuntu-ja-16.04-desktop-amd64.iso

前回の失敗から、最初から、USBインサーネットを接続し、インストー
ル中のアップデートも行うようにし、全てのソフトがインストールできる
ようにして行った。
順調に進み、小一時間でインストール出来た。

WiFiも認識し、何の問題も無く、遅さも感じない。
ブラウザも、小気味良く動作する。

img_0843s

SSDのせいなのか、起動も終了も極めて速い!

HP mini 1000 に Ubuntu をインストールする

すっかり忘れていたのだけど、HP mini 1000 と言うノートPCがあった・・
このPCにはWindowsXPがインストールされている。
・Atom N270 1.6GHz
・2GBメインメモリー(アップグレードしてある!通常だと1GB)
・60GBHDD
・WindowsXP
久しぶりに掘り起こして、電源を入れた(ちゃんとバッテリーパックを外してあった)
ら、ちゃんと起動した。

そこで、このノートにLinuxをインストールする事にした。(XPは捨てる!)

まず、どのディストリビューションを選ぶか・・・
最近、OS-XとWindows7ばかりで、すっかりご無沙汰で、どれがホットなの
かまるで分からない・・
とりあえず、無難な「Ubuntu」の日本語バージョンを入れる事にした。
※32ビット版だ

ubuntu-ja-14.04-desktop-i386.iso

・まずisoイメージをダウンロードして、DVDに書き込む。
・USB接続ドライブを繋げて、DVDからブート。
※N270 1.6GHzはかなり遅いだろうなと思ったが、まあ我慢できる。
・インストール(この段階ではネットワークを認識していない)
・起動して、判る範囲で色々設定。
※あまり、この環境を使った事が無いので、使い方が良く判らない。
※WiFiが認識しないが、その他は、ほぼ自動認識しているようだ。
・USB接続インサーネットを接続したら、自動で認識したので、アップデートする。

img_0842s
※ソフトウェアーアップデートは、かなり時間を要する・・・

途中で、インストーラーが固まり、再起動したら、GUIが動かなくなった・・・

結局、最初からインストールをやり直す事に・・・

初めての環境は、インストールをやり直す事はよくあるので、まぁ気にしない~
※ただ、このマシン、流石に遅くて、かなり時間がかかる・・・

今度は、最初からUSBインサーネットも接続して、インストールの段階で、アップ
デートを併用するようにし、「オープンソース以外のソフト・インストール」もチェック
して、行った。

かなり時間がかかったが、一応動くようになった。

色々触ってみると、最新版はかなり完成度が高く、普通に使える事が判った。

ただ、やはり、N270は遅い・・・

全てのプロジェクトをビルドするスクリプト

今回のネタは凄く短い・・・

実は、少しぶれてた・・
要は、複数ディレクトリーに色々なプロジェクトがあり、それらを全てコンパイル
する手順だった。

「glfw_app」の場合

drwxr-xr-x 1 hira None   0 9月  22 09:02 basic/
drwxr-xr-x 1 hira None   0 9月  22 09:05 bmc/
drwxr-xr-x 1 hira None   0 9月  22 09:09 cave/
drwxr-xr-x 1 hira None   0 7月   9 08:21 common/
drwxr-xr-x 1 hira None   0 9月  22 09:13 daev/
drwxr-xr-x 1 hira None   0 9月  21 12:43 dllcollect/
drwxr-xr-x 1 hira None   0 7月   9 08:21 docs/
drwxr-xr-x 1 hira None   0 9月  22 09:16 effv/
drwxr-xr-x 1 hira None   0 9月  22 09:16 gui_test/
drwxr-xr-x 1 hira None   0 9月  22 00:00 image/
drwxr-xr-x 1 hira None   0 9月  22 09:16 iod_make/
drwxr-xr-x 1 hira None   0 7月   9 08:21 libraries/
drwxr-xr-x 1 hira None   0 8月  17 15:38 MPU6050viewer/
drwxr-xr-x 1 hira None   0 9月  22 09:24 open_ide/
drwxr-xr-x 1 hira None   0 9月  22 09:24 piano_sim/
drwxr-xr-x 1 hira None   0 9月  21 22:21 player/
drwxr-xr-x 1 hira None   0 9月  22 09:25 pmdv/
drwxr-xr-x 1 hira None   0 9月  22 09:27 pn/
drwxr-xr-x 1 hira None   0 9月  22 09:27 spinv/
drwxr-xr-x 1 hira None   0 9月  22 09:28 vfs/
drwxr-xr-x 1 hira None   0 9月  22 09:29 vplayer/

一番簡単なのは、各プロジェクトのディレクトリーを指定して、「make」を実行す
る方法だ、しかしこれだと、プロジェクトが増える度に編集が必要となる。

RL78 では、xxx_sample をプロジェクトのディレクトリーとして、そのディレクト
リーに移動して「make」するスクリプトを作っていた。

ADC_sample/            DS1371_sample/              KiCAD_lib/         SDC_sample/
ADC_SWITCH_sample/     DS3231_sample/              LCD_DOT_sample/    SOFT_DELAY_sample/
ff12a/                 LCD_FILER_sample/           START_BOARD/
ARITH_sample/          FIRST_sample/               LICENSE            TMPtest/
BMP180_sample/         G13/                        MPU6050_sample/    TOUCH_sample/
chip/                  I2C_sample/                 PWM_sample/        UART_sample/
common/                images/                     R5F100LGA.jpg      VS1063_PLAYER_sample/
DATA_FLASH_sample/     INTERVAL_TIMER_sample/      README.md          WAV_PLAYER_sample/
Doxyfile               INTERVAL_TIMER_TAU_sample/  rl78prog/

ただ、これだと、「rl78prog」内のツールはビルでされない・・

そこで、良く考えたら、「Makefile」が存在するディレクトリーだけ抜き出して、「make」
を起動すれば良いと判った、何でこんな簡単な事を思いつかなかったのか不思議である。

その要件に従い、shell スクリプトを作成した。
OS-X で期待した動作にならなかったので修正
「clean」を事前に全て実行するように修正

#!/bin/bash
CMDNAME=`basename $0`
if [[ $1 = "help" ]]; then
  echo "Usage: $CMDNAME [clean]"
  echo ""
  exit
fi

RED=`tput setaf 1`
GREEN=`tput setaf 2`
PINK=`tput setaf 5`
LIGHTBLUE=`tput setaf 6`
NOCOLOR=`tput sgr0`

# make clean
if [[ $1 = "clean" ]]; then
  for file in `ls -d *`
  do
    if [ -e "${file}/Makefile" ]; then
      cd "${file}"
      echo "${GREEN}Clean project: " ${file} "${NOCOLOR}"
      make clean >& /dev/null
      if [ $? -ne 0 ]; then
        echo "${RED}Error: " ${file} "${NOCOLOR}"
        echo ""
        break;
      fi
      cd ..
    fi
  done
fi

# make
for file in `ls -d *`
do
  if [ -e "${file}/Makefile" ]; then
    echo "${PINK}Start project: " ${file} "${NOCOLOR}"
    cd "${file}"
    make > /dev/null
    if [ $? -ne 0 ]; then
      echo "${RED}Compile error: " ${file} "${NOCOLOR}"
      echo ""
      break;
    fi
    cd ..
    echo "${LIGHTBLUE}Build project: " ${file} "${NOCOLOR}"
  fi
done

これで、glfw_app、R8C、RL78 と全て動的に全ビルドが出来るようになった。

機能としては、

sh all_project_build.sh

単独で起動すれば、全体に「make」を行なう。

sh all_project_build.sh clean

とすれば、一旦「make clean」してから「make」する。

OS-X って、何で「echo」の「-e」
オプションが出来ないのか・・・

汎用的なMakefile

主に更新を続けている Git なのだけど、ちょっとした工夫で、開発環境が
より良くなる事は多い。

以前から、Makefile を少しづつアップデートをし続けて、現在に至ってい
る。
知り合いに、cmake を使うと柔軟で便利と言われていて、確かにそうだけど、
そこは天邪鬼な自分、「make」だけで何とかならないか・・・
※cmake を使って Makefile を作る手間が面倒

gcc のビルドだと、最初に「configure」を動かして、ビルドのオプション
を設定し、必要な中間ファイルを作成したりして、最終的に「Makefile」が
作成される。

また、Windows、OS-X を主なプラットホームにしているので、どちらでも遜
色無く機能してもらい、一元管理したい。

結局、「Makefile」だけの工夫で、全てまかなえている。
・従属規則を自動で生成する事
・コンパイルして生成したオブジェクトを1つのディレクトリーに集約する事
・リリース、デバッグなどのビルド切り替えが出来る事
・基本「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++ 用ソースとなっている。
バックスラッシュで改行をエスケープして、1行に1ファイルとしている。
※この方が見やすいし、再利用する場合に利便性が高い。

「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」にOSの属性が代入される。
又、「OSX」の場合、「OSX_VER」にバージョン番号が代入される。

Just another WordPress site