CQ-FRK-NXP-ARM (7) CQ gcc 用サンプル・プログラム (2) ― 2009年05月16日 16時15分07秒
ＣＱ出版の特設ページに 2009年5月13日 付けで
「gcc サンプル・プログラム アップデート」 が出ていた。
さっそく試してみよう。
ld.exe:C:\Keil\ARM\GNU\TEST\CQ\gcc_sample\memory.def:22: syntax error
だめだこりゃ、まだ直っていない。
リンカースクリプトを修正してもう一度コンパイル
やっぱりだめだ
ld.exe: ERROR: Source object startup.o has EABI version 0, but target gcc_sample.elf has EABI version 5
でも startup は修正できている
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
「gcc サンプル・プログラム アップデート」 が出ていた。
さっそく試してみよう。
ld.exe:C:\Keil\ARM\GNU\TEST\CQ\gcc_sample\memory.def:22: syntax error
だめだこりゃ、まだ直っていない。
リンカースクリプトを修正してもう一度コンパイル
やっぱりだめだ
ld.exe: ERROR: Source object startup.o has EABI version 0, but target gcc_sample.elf has EABI version 5
でも startup は修正できている
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
Luminary Micro ― 2009年05月14日 21時34分16秒
CQ-FRK-NXP-ARM (8) Micro Embeded System ― 2009年04月21日 23時51分44秒
MES の環境 で LPC2388 をコンパイルしてみる。
ベースとなるサンプルは何でもいいがいつものように WinARM の中の examples\uvision_glue_test にする。
まず、LPC23xx.xml の作成だ。
これはアプリケーションパスに置く。
注意点はパスの指定にスペースが入らないようにすることだ。
次に、
１．アプリケーションパスに LPC23xx というディレクトリを作成しその中に LPC23xx.h をコピーする。
２．同じディレクトリに LPC2378-ROM.ld をコピーする。
３．同じディレクトリに Startup.S をコピーする。
これで完了！
ちょっと扱いにくいが 今までの中では一番軽い。
参考：
Micro Embeded System
WinARM
環境： MES Ver2.5 r1 + CQ-FRK-NXP-ARM
ベースとなるサンプルは何でもいいがいつものように WinARM の中の examples\uvision_glue_test にする。
まず、LPC23xx.xml の作成だ。
これはアプリケーションパスに置く。
注意点はパスの指定にスペースが入らないようにすることだ。
次に、
１．アプリケーションパスに LPC23xx というディレクトリを作成しその中に LPC23xx.h をコピーする。
２．同じディレクトリに LPC2378-ROM.ld をコピーする。
３．同じディレクトリに Startup.S をコピーする。
これで完了！
ちょっと扱いにくいが 今までの中では一番軽い。
参考：
Micro Embeded System
WinARM
環境： MES Ver2.5 r1 + CQ-FRK-NXP-ARM
CQ-FRK-NXP-ARM (7) CQ gcc 用サンプル・プログラム ― 2009年04月16日 22時22分57秒
ＣＱ出版の特設ページに
「gcc 用サンプル・プログラムに関する情報」 があった。
見てみるとコンパクトにまとめられている。
さすがＣＱ出版と思ったがコンパイルできない。
不具合は三つ
「GCCのインストール＆使い方」ではちゃんとコンパイルできているのに．．．
ひとつは startup.s の .global _startup を削除することで解決できる。
もうひとつは memory.def のアドレスの後 (0x40000000) にスペースを入れることで解決できる。
しかし EABI のバージョンが異なるとかいうエラーはどうしてよいのか分からない。
ところが、 make を使うと上記三つのエラーも出ることなくコンパイルできる。
IDE が勝手なオプションを付加しているせいなのか？
私の環境は (Ride7 or µVision3) + GNU C
「gcc 用サンプル・プログラムに関する情報」 があった。
見てみるとコンパクトにまとめられている。
さすがＣＱ出版と思ったがコンパイルできない。
不具合は三つ
(.text+0x20): multiple definition of `_startup' ld.exe: ERROR: Source object startup.o has EABI version 0, but target gcc_sample.elf has EABI version 5 ld.exe: memory.def:23: syntax error
「GCCのインストール＆使い方」ではちゃんとコンパイルできているのに．．．
ひとつは startup.s の .global _startup を削除することで解決できる。
もうひとつは memory.def のアドレスの後 (0x40000000) にスペースを入れることで解決できる。
しかし EABI のバージョンが異なるとかいうエラーはどうしてよいのか分からない。
ところが、 make を使うと上記三つのエラーも出ることなくコンパイルできる。
IDE が勝手なオプションを付加しているせいなのか？
私の環境は (Ride7 or µVision3) + GNU C
Micro Embeded System ― 2009年04月13日 21時22分41秒
Micro Embeded System を見てみると
MES Ver2.5 r1 がリリースされていた。（2009/3/25）
STR710 が追加になって H8 がなくなっている。
あ～これも時代の流れか．．．
それはそうと h8flush がどうなったのか気になる。
4.0 になって STR710 が追加になっている以外変更はないような気がする。
参考： Micro Embeded System
MES Ver2.5 r1 がリリースされていた。（2009/3/25）
STR710 が追加になって H8 がなくなっている。
あ～これも時代の流れか．．．
それはそうと h8flush がどうなったのか気になる。
4.0 になって STR710 が追加になっている以外変更はないような気がする。
参考： Micro Embeded System
CQ-FRK-NXP-ARM (6) GCC Developer Lite ― 2009年04月12日 18時49分04秒
GCC Developer Lite で LPC2388 をコンパイルしてみる。
CQ-STARM でもやったので今回もやってみよう。
ベースとなるサンプルは何でもいいが WinARM の中の examples\uvision_glue_test にする。
まず、TARGET の作成だ。
１．C:\Program Files\BestTech\GCC Developer Lite\TARGET の中にディレクトリ LPC23XX を作成する。
２．uvision_glue_test の Common を LPC23XX の中にコピーする。
３．Common の中身をライブラリにする。名前は liblpc23xx.a にしよう。（irq.c,swi_handler.S,target.c,timer.c）
４．C:\Program Files\BestTech\GCC Developer Lite\TARGET\LPC23XX の中に LPC23xx.h Startup.o を入れる。
５．LPC23XXFROM.DEF を作成して C:\Program Files\BestTech\GCC Developer Lite\TARGET の中に入れる。
これで完了！
ためしに、コンパイルしてみよう。
examples\uvision_glue_test のファイル
main.c
fio.c fio.h
uart.c uart.h
を適当なディレクトリに入れて main.c に以下のファイルをインクルードする。
後は、main.c をコンパイルすればでき上がるはずだ。
参考：WinARM
TARGET LPC23XX
環境： GCC Developer Lite + CQ-FRK-NXP-ARM
CQ-STARM でもやったので今回もやってみよう。
ベースとなるサンプルは何でもいいが WinARM の中の examples\uvision_glue_test にする。
まず、TARGET の作成だ。
１．C:\Program Files\BestTech\GCC Developer Lite\TARGET の中にディレクトリ LPC23XX を作成する。
２．uvision_glue_test の Common を LPC23XX の中にコピーする。
３．Common の中身をライブラリにする。名前は liblpc23xx.a にしよう。（irq.c,swi_handler.S,target.c,timer.c）
４．C:\Program Files\BestTech\GCC Developer Lite\TARGET\LPC23XX の中に LPC23xx.h Startup.o を入れる。
５．LPC23XXFROM.DEF を作成して C:\Program Files\BestTech\GCC Developer Lite\TARGET の中に入れる。
これで完了！
ためしに、コンパイルしてみよう。
examples\uvision_glue_test のファイル
main.c
fio.c fio.h
uart.c uart.h
を適当なディレクトリに入れて main.c に以下のファイルをインクルードする。
#include "fio.c" #include "uart.c"
後は、main.c をコンパイルすればでき上がるはずだ。
参考：WinARM
TARGET LPC23XX
環境： GCC Developer Lite + CQ-FRK-NXP-ARM
CQ-FRK-NXP-ARM (5) printf (7) ― 2009年04月06日 21時51分48秒
もう一度 printf に挑戦してみる。
今まで気にしていなかったが
crt0.S を見ると USR_Stack_Size が 0 になっている。
ここを 0x00001000 にしてみよう。
ついでに _read と Memory Dump も追加する。
これで scanf も使えるはずだ。
ターミナルの設定は以下の二つにチェックを入れる。
行末に改行文字をつける
ローカルエコーする
さっそく動かしてみよう！
使い方はアドレスとサイズを１６進数で入力する。
特に問題はないようだ。
まあ、表面上のことだけかもしれないが．．．
と思っていたら Ride7 で作成したプロジェクトが動かない。
ソースは同じなのになぜ？
参考： WinARM
rprintf test file scanf も動いたかな？サンプル（動いたかな？サンプルに上書き）
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
今まで気にしていなかったが
crt0.S を見ると USR_Stack_Size が 0 になっている。
ここを 0x00001000 にしてみよう。
ついでに _read と Memory Dump も追加する。
これで scanf も使えるはずだ。
ターミナルの設定は以下の二つにチェックを入れる。
行末に改行文字をつける
ローカルエコーする
さっそく動かしてみよう！
使い方はアドレスとサイズを１６進数で入力する。
特に問題はないようだ。
まあ、表面上のことだけかもしれないが．．．
と思っていたら Ride7 で作成したプロジェクトが動かない。
ソースは同じなのになぜ？
参考： WinARM
rprintf test file scanf も動いたかな？サンプル（動いたかな？サンプルに上書き）
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
CQ-FRK-NXP-ARM (5) printf (6) ― 2009年04月05日 20時27分33秒
small printf を実装する。
printf の実装に挫折したので small printf に変更。
これも使い勝手のよさそうなのがあるので使わせてもらおう。
(lpc213x_lpc214x_examples_20061205.zip)
この中にある rprintf というやつだ。
早速リンクして動かしてみよう。
今回はいけたようだ。 printf の次は scanf か？
ここでちょっと出来上がったバイナリサイズを比較してみよう。
printf 42,004バイト
iprintf 24,804バイト
rprintf 6,020バイト
なし 4,688バイト
う～ん rprintf いいね～
参考： WinARM
rprintf test file 動いたかな？サンプル（動くだろうサンプルに上書き）
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
printf の実装に挫折したので small printf に変更。
これも使い勝手のよさそうなのがあるので使わせてもらおう。
(lpc213x_lpc214x_examples_20061205.zip)
この中にある rprintf というやつだ。
早速リンクして動かしてみよう。
今回はいけたようだ。 printf の次は scanf か？
ここでちょっと出来上がったバイナリサイズを比較してみよう。
printf 42,004バイト
iprintf 24,804バイト
rprintf 6,020バイト
なし 4,688バイト
う～ん rprintf いいね～
参考： WinARM
rprintf test file 動いたかな？サンプル（動くだろうサンプルに上書き）
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
CQ-FRK-NXP-ARM (5) printf (5) ― 2009年04月04日 21時06分12秒
sprintf から printf へ
syscalls.c の _write を有効にしてさっそくテストだ。
putchar_serial0 を uart0Putch に置き換えてコメントを外す。
うまく行く予感．．．
あれ！ またしても．．．
今度は何がいけないの？
シリアルをモニタしてみる。
予定していないコードが入っている。
putchar で連続出力しても問題ない。
printf で文字だけ出力しても問題ない。
書式指定した時だけおかしくなる。
ワークエリアが不足しているか、かぶっている感じだ
でも、どこを触ってよいのか分からない
この部分は先送りにして
small printf を追加しよう。
参考： WinARM
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
syscalls.c の _write を有効にしてさっそくテストだ。
putchar_serial0 を uart0Putch に置き換えてコメントを外す。
うまく行く予感．．．
あれ！ またしても．．．
今度は何がいけないの？
シリアルをモニタしてみる。
予定していないコードが入っている。
putchar で連続出力しても問題ない。
printf で文字だけ出力しても問題ない。
書式指定した時だけおかしくなる。
ワークエリアが不足しているか、かぶっている感じだ
でも、どこを触ってよいのか分からない
この部分は先送りにして
small printf を追加しよう。
参考： WinARM
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
CQ-FRK-NXP-ARM (5) printf (4) ― 2009年04月03日 21時42分54秒
sprintf の続き．．．
文字列出力の間に待ち時間を入れてみる。
正常に出力できる。
バッファの空きを見てないのか？
ためしにバッファを１２８バイトから５バイトにしてみる。
５文字しか表示しない。
これはもう決まりだ uart.c の中の uartxPutch() を調べてみよう。
みてみるとバッファーフルの時エラーで返している。
どうもここが原因のようだ。
というわけで uartxPutch() を一部変更する。
を以下のようにする。
さて、もう一度挑戦だ。
結果は．．． 同じ
途中で止まってしまう。
もう打つ手がない。
volatile でも入れてみよう。
結果は．．． うまくいった。
でもどこに入れた volatile が効いたのか分からない。
ま、いいことにしよう。
参考：WinARM
printf test file 動くだろうサンプル（動かないサンプルに上書き）
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
文字列出力の間に待ち時間を入れてみる。
正常に出力できる。
バッファの空きを見てないのか？
ためしにバッファを１２８バイトから５バイトにしてみる。
５文字しか表示しない。
これはもう決まりだ uart.c の中の uartxPutch() を調べてみよう。
みてみるとバッファーフルの時エラーで返している。
どうもここが原因のようだ。
というわけで uartxPutch() を一部変更する。
を以下のようにする。
さて、もう一度挑戦だ。
結果は．．． 同じ
途中で止まってしまう。
もう打つ手がない。
volatile でも入れてみよう。
結果は．．． うまくいった。
でもどこに入れた volatile が効いたのか分からない。
ま、いいことにしよう。
参考：WinARM
printf test file 動くだろうサンプル（動かないサンプルに上書き）
環境： (Ride7 or µVision3) + GNU C + CQ-FRK-NXP-ARM
最近のコメント