TOPPERS/SSPのGCCでのコンパイル

TOPPERS/SSP(FM3用-SPANSIONのCortex-M3)のGCCでコンパイルをしてみた。

(誤:ssp_cy8ckit050_gcc_20140309.zip -> 正:ssp_cq_frk_fm3_gcc-20140307.tar.gzでした。投稿を修正しました。)

環境:64bit版Windows 8.1 + Cygwin64(64ビット版Cygwin)

今回はCygwin上でクロスコンパイルをするのではなく、最も簡単と思われるMentor Graphics社の、
Sourcery CodeBench Lite Editionをインストールしました。
(Sourcery CodeBench自体はCygwin上でなくても動作します。)

1.Mentor Graphicsのサイトの以下のURLへいく。
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/

2.「ARM Processors」の「Download the EABI Release」をクリックする。
以下に移動する。
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/arm-eabi

3.この後メールで送られてきたインストール先のURLからインストーラ形式のファイルをダウンロード。

4.ファイルをダブルクリックしてインストーラの指示に従い(ほとんどNextボタンを押すだけ)インストール。

5.環境変数PATHに%HOME%\MentorGraphics\Sourcery_CodeBench_Lite_for_ARM_EABI\binが設定されているか確認(設定されていなければ自分で設定-コントロールパネル-システム-システムの詳細設定-詳細設定-環境変数から自分で設定)。

6.PCのCygwinのbash上で、TOPPERS/SSPのssp_cq_frk_fm3_gcc-20140307.tar.gzを展開する。

7.sspに移動。
cd ssp

8.ビルド用のディレクトリOBJSを作成、移動。
 mkdir OBJS
cd OBJS

9.configureスクリプトを修正
spp/configureの213行目にcfgの位置が展開されるソースの階層構造に合っていない。
(誤)$cfg = $opt_g ? $opt_g : “\$(SRCDIR)/cfg/cfg/cfg”;
(正)$cfg = $opt_g ? $opt_g : “\$(SRCDIR)/cfg/cfg”;
ASPでは合っているのですが、SSPではcfgの階層が一段浅いため、configureの生成したMakefileではcfgが見つからなくなります。
ここを修正すれば、Interface誌付属FM3基板用簡易パッケージの最新版をコンパイルすることは出来ました。

configureは他のパッケージでもcfgの階層があっていない可能性があります。

10.configureスクリプトを実行

../configure -T cy8ckit050_gcc
(またはperl ../configure -T cy8ckit050_gcc)

11. make実行

・インストールのポイント
Sourcery CodeBenchはフリースタンディング環境用のEABIを選択することがポイント。ホスト環境用のものを選択すると、toppers-users#4074のように「__aeabi_unwind_cpp_pr0」という未定義シンボルエラーが発生する。
https://www.toppers.jp/TOPPERS-USERS/2013-April/003896.html
フリースタンディング用であればtoppers-users 4076のようにこのエラーは発生せずコンパイルが終了する。

・SSPについての注意点
CY8CKIT-050 PSoC 5LP Development Kit(Cypress Semiconductor)簡易パッケージは、ssp\target\cy8ckit050_gccの下にMakefile.targetが存在しないため、make実行中にエラーになる。

・実機での動作は未確認
コンパイルをしたときは実機がなかったため、動作は未確認です。
また、TOPPERSプロジェクトが提供しているARMを含むシミュレータであるskyeyeで確認したかったのですが、skyeyeはCortex-M3には未対応、かつTOPPERSプロジェクトで配布されているskyeyeは32ビットCygwin用バイナリであり、Cygwin64上ではエラーもださすに終了してしまうため、この点は未確認です。

・skyfreeについての補足
skyeyeのソースは昔のCywgwinではコンパイルできたのですが、CygwinがWDM(Windows Driver Model)に対応して以降、ヘッダファイルの配置、内容などがドラスティックに変更されたため、現在提供されているCygwinではskyeyeは(TOPPERSプロジェクトから提供されている、修正版skyeyeも、soruceforge.netで配布されている最新版でも)コンパイルできなくなっています。
さらにcygwinは常に最新版のみ配布しているため、旧版のcygwinを入手することも、困難です。

JRubyでもtecsgenのテストケースが通るのを確認しました

raccのparser.rbへのとりあえずのパッチ作成に載せた試作パッチを、Linux(Fedora 7)とcgywin(1.5.25)上でJRubyで実行し、tecsgenの配布物に含まれるテストケースが通ることを確認しました。

Javaは、JDK 1.6 update14、JRubyは1.3.1を使用しました。

ただし、それぞれの箇所でいささか工夫が必要でした。

*Linux
tecsgenがCのヘッダファイルを読み込む(typedefで定義された型名や構造体タグ名を認識するため)時に、C処理系の独自の予約語が存在すると、tecsgenはそれを認識で来ません。
これによるパース失敗を避けるため、独自の予約語を読み込み前に削除しています。
具体的にはtecsgenの内部でCプリプロセッサ(あるいはC処理系のCプリプロセス処理機能)を呼び出し、空文字列に置換してから、ヘッダファイルを読み込みます。
具体的にはtecsgenのコマンドラインオプション-Dで空文字列に置き換える文字を指定します。
ただし、この指定が”-D__extension__”とされていたため、Linuxのgcc(4.1.3)では”1″に置き換えられて、コンパイルエラーになりました。
#cygwinではこの指定でも問題が起きませんでした。
#現在公開されているtecsgenは、主にcygwinで動作確認されています。

Linuxでは”-D__extension__=”とする必要がありました。

*cygwin
cygwinでJRubyを実行する場合、環境変数RUBYLIBへのパス名の設定方法に工夫が必要でした。
この工夫は、Rubyの場合は必要ありませんでした。

cygwinでフルパスで指定する場合、/cygdrive/c/のように
ドライブ名を/cygdrive/ドライブ名という指定をすることが
可能です。
しかし、この形式で指定した場合、rubyのスクリプトで
クラスFileのexpand_pathメソッドでフルパスに変換した
場合、
C:/cygdrive/c
と、先頭にドライブ名をつけたにも関わらず、/cygdrive/c
もつけたままであるため、存在しないパスになってしまいました。
これは、cygwinの標準のrubyとか、cygwin中から呼び出した
mswin32版rubyでは、経験しなかったことです。
どこが原因かまでは調べていませんが、cygwin上で、JRubyを
使ってtecsgen.rbを実行して、”ファイルが見つからない”
というようなエラーが発生した場合は、環境変数RUBYLIBの値を
確認してください。
もし、”/cygdrive/c”のような形式であれば、この部分をとり
さったパス名を指定してください。
以下をコマンドラインで実行してもよいと思います。

export RUBYLIB=`echo $PWD | sed ‘s/^\/cygdrive\/.//’`