アルファチャネル付きフォントの描画など、小物ソフトを色々作っていたが、GPS を接続してテストしてみる事にした。
以前にストロベリーリナックスで購入した物だけど、SUP500Fです。
この GPS は65チャンネルで更新レートが最大 10Hz とゆーのが特徴です、最近サーキットでは GPS のロガーが大流行りで、8000円で小型のやつを多くの人が付けてます。

「PhotoMete887」
GPS の測位データ解析では、フリーの LAP+ をみなさん使っているようですね・・

自分のシステムでは、専用の GPS を接続する為、測位データのロギングと合わせて、エンジン回転や、タイヤの速度、ストロークセンサー、重力など、複数のデータを統合してロギング出来るところがメリットです。
GPS モジュールは色々調べた感じでは、この「SUP500F」が性能と価格（6300円）で良さそうです。

GPS をロガーユニットと別の位置へ取りつけ出来るようにモジュール化して、必要部品を小さなケースに押し込んでいます。

解析ソフトは、新規に作成しようと思いますが、それなりの規模になると思うので、時間はかかりそうです・・

とりあえず、AVR に A/D コンバーター、MCP3208 を繋いでみた。
AVR で A/D との通信ソフトを書き、簡単なプロトコルで、SH 側にデータを転送。
一応、１秒辺り、１００回分の変換データを SH 側に転送している。
秋月で売られているMCP3208はタイプＣのグレードなので、積分非直線性が 2LSB の物だけど、それでも１２ビットの分解能があるのはありがたい、それと、この A/D には、サンプルホールドも内臓されているのも良い。（４００円）

基準電圧は、4.096V としたいとこだが、電源電圧が 3.3V では、駄目なようで（当然か）、3.2768V とした。
LM385-2.5 を使い、OP アンプで増幅している。（トリマ抵抗で調整）

SH 側、プロトコルの解析ルーチンにバグがあり、多少時間がかかったが、何とか正常に動作するようになった感じ。
こんな簡単なソフトもさっくり書けなくなったなんて・・・、結構ブルーである・・・

それと、シリアルコミュニケーションで、オーバーランやフレーミングエラーなどがあった場合に、正しい動作をしていないようなので、改修の必要がある・・・

後は、GPS モジュールを繋いで、その通信関係を作れば、ハード的には大体完了な感じか・・

あっ、ちなみに、laptime 計測のクラスも作ってみた、これは 1/100 単位まで計測可能なもので、RTC とはあんまし関係は無いけども・・

あ、そうそう、SH-2A のシステムクロック用水晶を追加して、18MHz 駆動で、周辺デバイスを現在の 24MHz から 36MHz にする必要がある、そして、LCD のクロックを 9MHz にしないと、フレームのインターバールが 60Hz にならない。
※フレーム数は、ゲーム製作などで慣れている 60Hz にしないと、何となく気持ち悪い。
先日秋葉原に行った折、18MHzの水晶を探したが何処にも売っていなかった、昔の背が高いやつはあって、一応買ったが、背が高いので、イマイチ取りつけたくない感じだ・・
それで、いつものチップワンストップで調べたら、５０個くらい買わないと、イマイチ高い、でも５０個も買ってどうすんだよってゆーのもある、うーーん・・・

SH-2A 内臓の RTC は、バックアップが出来ない為、事実上使えません、そこから始まったのですがー、外部に AVR を置き、RTC の代わりをさせてみました。
データのやり取りは、シリアルコミュニケーションで行う為、オーバーヘッドも少なく、そこそこ良いシステムだったのですが、問題は消費電力です。
AVR を 32.768KHz とかで駆動すれば、かなり消費電力削減に効果を上げるのですが、それはそれで、マイナス面もあります。
他の問題として、SH 側の電源が落ちた場合に AVR の出力ポートから、SH 側に電気が逃げます、これを避ける為にダイオード入れるとか多少回路を工夫しないと駄目とゆー面もあります、なかなか一筋縄ではいきません。

そんなこんなで、結局 RTC 専用デバイスを付けました。
秋月で、「RTC-4543SA」とゆー 250円のデバイスが売りだされていたのがトリガーなんですけどね（笑）
これは、インターフェースもシリアルタイプで、以前に500円で売られていたやつ（I2C）とは違い、インターフェースも簡単です。（自分的には）
※それと、RTC に500円は払えないけど、250円なら許容範囲かもです（笑）
※もちろん、I2C の専用ハードがあれば、関係無いのですが、以前に、I2C 専用ポートが使えないので汎用ポートを使って、ソフト的に I2C のプロトコルを処理するコードを書いたところ、結構苦労しました・・

それで今回、AVR はそのまま残して、3.3Vで動作できる最大速度10MHzで動かすようにし、AVR に RTC を接続して、以前とおなじようにAVR で、RTC とのやりとりをさせています。
AVR は I/O プロセッサーとして動作します、SH とのシリアル速度も 96000 ボーに上げました～

また、12ビットのA/Dコンバーターも AVR に接続して、変換データを受け取るようにする予定もあります～

SH-2A にも A/D がありますが、10ビットなので、今回は、入力ポートとして使います。
※操作ボタンを付けました～

※現在のソースコード一式を、いつものアーカイブ場所に上げておきます。
AVR と RTC の接続などは、AVR のソースコードに書いてあるので、特に回路はいらないでしょう～、暇が出来たら、回路図を引きます。

STL 問題で、vector が使えない為、保留となっていたが、結局、C 言語インターフェースで読み込みを書いた。
pngin.h、pngin.c、jpegin.h、jpegin.cがそれだ。
※非常に簡単なややつで、エラーが発生した場合などはあまり考慮されていない・・

STL vector の件：
KPIT から一応回答が来たー、「問題無く動作する！」そちらの環境を送って欲しいとゆーものだった。

あれから、自分も色々調べた、それで判った事だが、KPIT では当然、HEW からgccを使う事を前提にしている、自分はcygwinでMakefileなのだが、それでも、オプションなど調べてKIPT＋HEWの環境と同じになるよう配慮したつもりでいるが、まだ何か足りない部分があるのだろう。
HEWでは、プロジェクト毎に独自のライブラリーを作成している、これに何かマジックがあるのかもしれないが、調べた限りでは、それも無い感じだし。

グローバルコンストラクターも初期化で呼んでいるし、他に何があるのだろうか？？

まぁ、今回は、メモリーも少ないし、（1MB）CとC++のクラス程度で、自分フレームワークを使う事も限られると思うので、何とかなるだろうけども（何とかする！？）・・

-----

現在、開発用に使っている基板は、車体に積んでテストするようには考えられていないので、ケースに入れられるベース基板も作る予定、そんで、インターフェース６月号をもう一冊買った。
最初アマゾンで見たら、中古でプレミア価格だったが、某HPで、CQから直接買える事が判り、自分も買ったが、送料もかからず良かった～

それと、PSPの液晶も買った、今度のはPSP-3000用なので（一番安い）コネクターの形状が違う為、今までのブレッドボードは使えないけど・・
このコネクター探すのが大変そうではある・・・

KPIT のC++で、STL vector が使えない問題で、多少の進展があったが、まだ解決していない。

まず、基本として、C++ の場合、グローバルコンストラクターを起動時に実行しておく必要があって、その実行アドレスのリストを、section .ctors に並べてあり、また、デストラクターは、.dtros に並べてある。
※.dtors のデストラクターリストは、exitで呼ばれるのだが、組み込みでは、終了する事が無いので、これは無視しても良いのかな！？

通常これは、crt0.o のスタートアップオブジェクトから、__main関数が呼ばれて、その中で実行するのが通例のようだが、組み込みプログラムなので、crt0.oは使っていない。
※「__main」は C++ の初期化関数で、「_main」とは区別される。
※良く考えたら、必要なのだが、C のプログラムが綺麗に走るようになってから、すっかり忘れていた。

で、そのリストをメモリー上に置いて、実行したけど、それでもvectorはうんともすんとも動かない（泣）
まだ何かあるようだ・・・

それと、もう一つ・・
g++ の libstdc++.a ライブラリーだが、これをリンクするだけで、非常に巨大となり、今回のようなシステムでは、ちょっと使えない感じ、vectorやstringを使うだけで、１００キロバイト程大きくなる。
※iostream を使うと、300キロとか大きくなる。
他にmapやlistなど色々使うとさらに巨大となるので、今回は標準のこのクラスを使うのは難しいかもしれない・・

自分用の小規模で機能を絞ったSTLに相当する物を用意すれば良い気もするが、これは相当大変そうである。
※template プログラムは、先人が創ったように完成度が高く、絶妙で巧妙な仕組みを用意するのは、自分のスキルを越えていると思う。

-----
KPIT はあきらめて、gcc をソースコードからビルドする試みも試しているが、cygwinでちゃんとコンパイル出来ないでいる。
コンパイルは通っても、make check ではねられる。

色々動くようになって、では、そろそろ自分フレームワークをコンパイルしようかと思い、進めてみたものの、基本的部分が動かない・・

調べると、STL vector が死ぬ！

こんな簡単なプログラムを作ると、死んでしまう・・・

std::vector pad;

pad.push_back(1); // ---> 死ぬ！

又、

pad.resize(10); // ---> 死ぬ！

一方、

std::vector pad(10);

とかで、初期化段階でサイズを指定すると、使える。

基本的に、KPIT v10.02 の C++ ライブラリーにバグがあるとしか思えないが、こんな基本的なとこで死ぬのはおかしい？？
多分、vector のアロケーターに SH2 で不味いコードが含まれているのだと思われるが、KPITのソースコードをダウンロードして不具合を見つけるのは、ちょっと骨が折れるので、とりあえず放置状態であるが、一応、KPIT にバグレポートを送った。

gcc のツールチェインを自分で構築してみようか・・
※時間と手間がかかるので余りやりたくない。

-----
そんで、vector が動かないと自分のフレームワークも全滅と思うが、画像操作系など、コンパイルだけはしてみた。

それに先だって、基本のライブラリー、Z、PNG、JPEG ライブラリーをソースコードからコンパイルして、ライブラリーを作ってみた。
この手の汎用ライブラリーは、configure によって開発環境の状態を取りこむのだが、クロス環境で自動で行うには、configureを改造する必要がある為、手作業で作ってみた。

それで、jpeg ライブラリーを使って純粋に C のコードで簡単な読み込みを書いて、テストしてみた。
SH-2AにはFPUが入っているハズだが、思った程高速では無い・・・
FPUを使う為におまじないが必要なのかもしれない・・

アーカイブにライブラリーなどをアップしておく。
PNG はテストしていないが、動くと思う。
※BMP のデコードは C++ のコードなので、vector 待ちです。

しかし、vector が使えないのは痛すぎる！

syscalls API の実装も進み、何とか普通に使えるようになってきた。

シリアルコミュニケーションインターフェースの API は、雑誌の記事にあったソースコードをコピーしたものだったので、全面書き換え、元々ポーリングだった動作を、送信、受信割り込みに変更した。
これで、パフォーマンスはある程度期待できると思われる。

SH72620 では、シリアルインターフェースは１６バイトの FIFO 付きなのだが、１６バイトでは少なすぎるので、ソフト処理で FIFO を実現している為、バッファサイズはいくらでも大きくできる、パフォーマンスはハードで処理するFIFOよりは悪いと思うが、まぁそれでもポーリングよりはずっと良いと思っている。

暇になったら、DMAC を使ってみたい～

-----
AVR の RTC だが、低消費な V タイプでは無いが、結構電気食う。
やっぱ 4MHz で動作させてるのが悪いと思うが、クロックを落とすと、通信の速度が出ないと思うので、4MHzとしたのだが・・
※４時間くらいのバックアップで 0.1V も落ちてるし・・・（涙）
この感じでは、実用性に問題あるかも・・
少なくとも、６ヵ月くらいはバックアップ出来ないと・・
※まぁ色々試せるのが試作ならではだしね・・
※I/Oプロセッサーの考えは悪く無いしね・・
雰囲気としては、AVR にさらに RTC を接続するとゆー本末転倒な事になりそう（笑）まぁ でもI/O プロセッサなんでー

-----
インクルードガードの話：
インターフェース誌のサンプルプログラムとか、色々観たけど、サンプルとは言え、品質が良くないなぁと感じる。
※いいかげんな書き方や、厳密では無い書き方が、あちこちに観られる。
※FatFsは「ELM」さんの実装だが、これはプロダクトとしては非常に考えられていて良く出来てる～
http://elm-chan.org/fsw/ff/00index_j.html
素晴らしい～（ありがとう～）

さて、本題！、良くヘッダーを多重にインクルードしないように、インクルードガードを書くけど。

#ifndef XXX
#define XXX

・・・

#endif

この「XXX」で、みんな、こんな書き方をしてる、ファイル名が、「init.h」なら、「__INIT_H__」とか・・
このアンダースコアーをダブルで加える書き方は、システムライブラリーなどで予約された書式なので、アプリケーションレベルのソースコードには書いてはいけない。
この事実を知らない人が多いようだ・・・

あと、プロトタイプの宣言でも、C++ から呼べるように、数行加えておいて欲しいものだ・・

加えて、API の説明や引数、戻り値の説明も書いておいて欲しい。
※自分のソースコードでは、Doxygen で展開すると幸せになれるようになるべく記述してる。

基本の「const」も必要なら、ちゃんと書こう！
※それだけで、バグを減らせるのだから。