とりあえず、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」も必要なら、ちゃんと書こう！
※それだけで、バグを減らせるのだから。

コンパクトなシステムを作るには AVR は最適です。

C 言語（gcc）でプログラム出来、高速で安くて、使いやすい。

たとえば、LED の点滅を考えても、タイマーIC 555でやるより、ATTINY2313 とかの方が安くてプログラマブルです（笑）

今回、SH-2Aで、バックアップ可能な RTC をどうするか色々考えました、秋月とかで入手できる、RTC でも良いのですが、どうせなら、変わった事がしたいので、あえて、AVR を RTC として使う事にしました。

SH-2Aとのインターフェースは、シリアル TXD、RXD を使い、インテリジェントな I/O プロセッサとして機能するようにします。

RTC の他、AVR 内臓の EEPROM を利用する事で、オドメーターの保持などにも使い、12ビットの A/D も欲しいので、その変換なども受け持たせる予定でいます。
今回、仮に ATMEGA88 でやってますが、もっと PIN 数が多くて高機能なデバイスでも良いかもしれません・・
※ATMEGA88 は秋月で230円です。

AVR-ISP は以前に作ったものですが、まだまだ使えます～

現状２０１０年８月８日のアーカイブで、時間関係を除いて、syscalls 関係の実装がだいぶ進みました～

printf、fopen、fclose、などなど、通常のファイル読み込みと書き込みは出来るようになってます。
※時間関係ハードが無い為、書きこんだファイルは、2008-1-1、0:0:0になります。

本当は、テストプログラムを一通り作る必要があるのですが、簡単なテストのみで済ませています。
※「mainloop.cpp」にある。
なので、まだバグを含んでいると思います、何か不具合があれば、この BBS に書き込んで下さい、対応したいと思います。

そろそろ、C++の自分フレームワークをコンパイルして組み込もうかと思いますが、RTC が先ですかね・・・
RTC は、ほんとどうしようかと思います・・・

SH72620 のハードウェアーマニュアルを読んだけど、RTCのバックアップ動作に関しての項目を見つけられませんでしたが、内臓RTCはバックアップは考えられていないのでしょうか？？？
でも、そんなの意味無いですよね。

前から思ってたのですが、RTC って、なんでハードロジックで全て構成するのが多いのか、ただのバイナリーカウンターだけで良いと思いますが・・・

マキシムのRTCには、３２ビットのバイナリーカウンターだけで構成されたRTCのデバイスがあるようですね、チップワンストップとかでも購入できるので買ってみようかと思ったけど、電圧タイプが不明なんで（1.2V、3V、3.3V仕様などがある）スルーしました。

次にちょっと考えたのが、AVRなどのワンチップマイコンを使って、RTCのバイナリカウンターを構成する試みです、これはアイデアとしては、前からありましたが、消費電流がどのくらいで、3Vのリチウムボタン電池でどのくらい持つものなのか・・
SHとのインターフェースとか、解決する事も多いですけどね・・
値段としては、100円のマイコンなんで、コストは安いですよね、秋月のRTCは500円しますから（笑）

aitendo の液晶キャリーボード、確かに便利で安いし、あれば重宝する事間違い無しなのだが、色々問題もある。

１）LEDバックライト用のDC/DCコンバーターに問題あり
・電流の大小で明るさが変化するLEDデバイスに対して、定電圧の回路になってる。
この液晶のバックライトは、白色LEDが６個直列に接続されたものみたいなので、23Vなら、妥当な値かもしれないが、バラツキで高い電圧が出て、LEDを壊す事が無いよう、パターンを切って、直列に抵抗を入れておいた、大体１００オームくらい入れておいたが、もう少し少なくして明るくしても良いかもしれない。
・回路図では、出力側に、22uF、0.1uFのコンデンサが入っているようなのだが、この表面実装部品、ほんとに22uFもある？って感じで、実際、電源入れると、安定しない（寄生発振してるようだ）、コイルやダイオードが凄く発熱する。
そこで、並列に10uFのコンデンサを入れてみたら、安定した。

２）液晶モジュールのロジック電源がいいかげん過ぎる
・この液晶モジュールは2.5V～4.5Vまでの定格なのだが、この基板では、LCD-POW（自分は5Vで使っている）から、抵抗を直列に入れていきなり繋いである。
ロジックは3.3Vなので、この抵抗を外して、3.3Vの電源ラインを繋いでおいた。
※LCD-POWERは3.3Vで使うものなのかもしれない・・

以上の改修で、問題無く使えるようになっている。

３）コネクターのピン名の不思議
・この拡張ボードで、ピンの名前として、R0～R7、G0～G7、B0～B7と、RGBの8ビットぽくネームが振られているが・・・
LCDのモジュールとは、まるで、イジワルしてるかのように接続されている・・・・・
「R0～R7」は赤ではなく、青へ、「B0～B7」は青では無く、赤へ、つまり、赤、青が逆になっていて、さらに、LSB、MSBも逆になっている。
なんで、こんな余計な事するのか、不思議でならない・・・
※はい、これを知らずに、間違った結線しましたよ・・・

４）RGB565からRGB888への拡張
・この液晶、RGB888で１６００万色フルカラー対応なのだが、SH-2Aは16ビットカラー出力（RGB565）なので、5ビットを8ビットへ、6ビットを8ビットに拡張する必要がある。
その拡張は、上位ビットをそのまま下位ビットに順番に繋ぐだけなのだが、思いついた時には、クールだと思った（笑）
キャリーボードには、2.54ミリピッチと2ミリピッチ用コネクターが出ているので、使わない2mmピッチ側で拡張しておいた。

まぁ、何だかんだ言っても300円だからね。

-----
あ、そうそう、LCDモジュールのLEDバックライト用のフレキは、正位置にそのまま繋ぐと、表裏が逆となってしまうので、1回転する。

現在実装中のソースコードをココに置く。

SH-2A モーター・サイクル・コンピューター・ソースコード・アーカイブ

↑ここに最新版のソースコードを置いておくが、必ずしも十分なテストが行われている訳ではなく、いきなり動作しないかもしれないので注意する事。
また、テスト用のコードが含まれていたり色々です。

安定版が出来たら、別途アーカイブをアップする事とする。

C コンパイラは、「KPIT Commins GNUSHv10.01-ELF」を元にしている、標準ライブラリー「libc.a」に独自の改修を行っている為、インストール後に改修を行う必要がある。
※readme.txtを参照の事。

ファイル入出力は、まだ全然だ・・・

------

・test.raw は 480 × 272 ピクセル、RGB の生データ
※起動時に画面表示に使ってる。

・logger.bin は、御存じのように、実行バイナリー

↑の二つのファイルを SD カードに書き込み（logger.bin は app.bin にリネームする）「SPIwriterUser」を使って、「ff_loader」をフラッシュROM後半に書き込み、JPP をショートしてリセットすれば、起動するだろう～