iとか、jなどの変数名が文字カウンターと受信データそのものに使われている。iとかjは内部のカウンターなどだけに使う名前で、具体的な意味を持つ変数には、それを連想できそうな名前にするのが、わかりやすいプログラムの定石だが、それが守られていない。それは良いとしてもmainの中に勝手に割り込み関数の実行ステートメントが挿入されている。割り込みで飛び込んでくる関数をmainで実行しても意味がない。これ以上追及するのも大人げないので、さっさと消して先に進む。しかけは、いつものようにPCからのキーボード受信待ちでプログラムを止め、キー入力で動く簡易なモニターである。手始めにLEDの点・消灯のコマンドを入れる。ほどなくコンパイルはOKになった。送信はうまく行ってWelcomeメッセージは出るが、入力を受け付けない。難しいことは何もしていない。それなのに、さっぱり入力データが所定のバッファーに入らない。何度もソースを見直すが間違っていない。ロジックアナライザーを登板させるのも気が引けるぐらい簡単なところなのに動かない。そのうち、今度の環境にはデバッガーが入っていることに気が付いた。やせ我慢しないで積極的にこれを使ってみよう。このデバッガー、ブレークポイントを設定してもそこで止まってくれない(フラッシュ下では無理なのか)。変数は表示できるので、キーを延々と打ってステップ実行で動きを追いかけてみた。違ってさすがは32ビットマシンである。UARTの受信だけで結構なステップ数である。その結果、原因が判明した。何のことはない、以前苦労した外部変数の宣言ミスだった。データを受け取るところと、それを取り出すところが違うので外部変数にしてあったのだが、同じ名前でもタイプが違うとエラーにもならないで別の変数になってしまう。今度の場合は、extern宣言のとき、うっかりデータタイプをつけ忘れたのが原因である。警告は出ていたのだろうが見落とした。それにしても、デバッガーにはお世話になった。今度のデバッガーは、UARTの入出力がデバッグ中にも動いたので助かった。デバッガーによっては、UARTのような時間依存する入出力では動かないものが多い。これでプログラムのテストは、LEDの点滅、UARTの動作まで進んだ。ここまで来れば本番を入れても大丈夫だろう。CooCoxに画像表示ソースを移植する(9/24/2014)いよいよ、心電計の画像表示のプログラムをCooCoxで開発するステージに達した。2年前に開発したグラフィック気圧計のソースコード一式をCooCox環境に持ち込む。このソースは、「ねむい」さんが開発したTFT液晶のSDカードのファイラー(ChaNさんが原型)がオリジナルで、ここの画面描画ルーチンを利用させてもらって2日分の気圧をグラフ表示している。今回はSDカードは使わないが、買ってきたTFT液晶のコントローラーが前と同じILI9325なので(というより同じものを探して買った)、描画部分を流用しようという腹づもりである。ねむいさんのソースは、数多くのプラットホームに対応しているだけでなく、数えきれないくらい多くの液晶コントローラーをサポートしてくれているのが嬉しい。液晶ディスプレイの初期化や、描画ルーチンはコントローラー単位に全部違うので、これだけサポートしてもらえると、安心してジャンク液晶を買うことが出来る。その設定は、makefileでの環境変数を定義するだけで一発で動くようになっており、そのためプログラム構造が階層化され、構成は非常に複雑で一筋縄ではいかない。今回はmakefileが使えないので、定義をどこでやるかが問題だ。量が膨大だからと言って立ちすくんでいては先に進めない。いうときは目をつぶってとにかくソースファイルを持ち込んでみることだ。プロジェクトのフォルダーにソース一式を放り込む。これだけではCooCoxはプロジェクトのリソースとしては認めてくれない。filesというアイテムが出てくる。これがどうやらプロジェクトにリソースを入れるコマンドだと当たりをつける。試しに、適当な名前で新しいgroupを定義してaddしてみるとフォルダーになった。filesは文字通り、ソースファイルが、そのディレクトリに入るようだ。自分の予想があたって上機嫌である。鼻歌まじりで、沢山のソースコードをプロジェクトに入れて行く。不思議なことに、プロジェクトフォルダー内のヘッダーファイルは自動的に探してincludeしてくれる。あとでも書くように、出来るところと出来ないところがある。適当なところで、ビルドをかける。予想通り膨大なエラーメッセージが出る。これは織り込み済みだ。ここからが勝負である。ひとつづつエラーメッセージを見ながらつぶしていく。1日半かけて、やっとのことで全体のコンパイルエラーはなくなった。同じようなことをやろうとしている方と、これからの自分のために(備忘録として)、遭遇したエラーの数々を簡単にまとめておく。volatileに戻してOK。うまく行っているソースもある。stm32ペリフェラルライブラリーのincludeを明示的にしないと引かないモジュールがある。これは前もそうだった記憶が。-->適当に#defineして追加。した達成感に満足する。この段階は壮大なオペラで言えば単に序曲が終わったくらいのところで、これからが何幕もある本番に入る。どんなドラマが待っているか、期待と不安が高まる。この気分はいつもたまらない。fault(9/25/2014)とはいえ、環境の異なるところへの、まとまったソース群の移植はそう簡単にはいかない。CooCoxは、makefileもリンカースクリプトも見えない統合環境である。このまま動くかどうかは何の保証もない。だいたい、このプログラムのUARTそのものは、ねむいさんのコードでは、printfが使われていた。ややこしいので最初はコメント化し、自前の別の出力関数を使うつもりをしていた(そのためのUARTテストでもある)。途中で計画を変更した。CooCoxのリポジトリを見ていると、その中にsyscalls.cがあるのを見つけた。printfは、標準入出力ライブラリを使うので、こうしたサポート関数が必要なのだが、CooCoxが持っているということは、メモリ管理をしてくれているということだ。このまま動くかもしれない。喜び勇んでsyscalls.cをincludeし、printfのコメントをはずしてコンパイルしてみる。