組み込みシステム ＯＳ無し 状態の保存(RAM)

一つ前の　記事と　密接に関係するので珍しく続けて2個の記事を書きます。

一つ前の記事｛設定の保存(EEPROM）｝の話は、まだ比較的分かりやすかったと思います。

今回の記事はウォッチドッグとも関係してきます。


何らかの理由で、システムの動作がおかしくなった場合にも、出来る限り処理を続行させる必要のある状況もあります。


 　バグでソフトが止まったままになる事が最悪です。


言葉だけで書いても分かりにくいので、Ｃ言語のスケルトンを載せておきます。

 //----------------------------------------------------------------------------- void check_restore_ram() {
　　　 if( check_ram_status()) { // 保存されているＲＡＭの状態が正しいかチェック
　　　　　restore_ram();
　　　 } else {
　　　　　 clear_ram();
　　　 }
 }
//-----------------------------------------------------------------------------

void save_ram() {
　　copy_dram_sram();　　     // 通常のＲＡＭからバックアップ用のＲＡＭにコピー
　　calc_set_check_val();　　　// バックアップメモリーの妥当性チェックデータを書き込み 
}
//----------------------------------------------------------------------------- void main() {
　　check_restore_ram();
　　loop(1) {
　　　　func1();
　　　　func2();
　　　　func3();
　　　　wdc_clear();
　　　　save_ram();
　　 }
}
//-----------------------------------------------------------------------------

雰囲気を理解してもらうために出来る限りシンプルにしています。 

かなり省略している部分もありますが、自分で理解して、省略している部分を補えないと トラブルの元になりますので、頑張って理解して実装してください 

特にclear_ram()の部分とスタートアップルーチンあたりはバッティングします。

スタートアップルーチンの定数設定の部分は時間を浪費するので、大胆にカットして この部分で行うのがいいと思います。

システムのＲＡＭ容量しだいですが、複数世代のバックアップを世代管理して妥当性チェックで ＯＫだったものをなんとか使うと言う場合もあるようです。

当然ですが、妥当性チェックのデータ自身もバックアップＲＡＭにおく必要があります。 妥当性チェックの値はチェックサムないしは、ＣＲＣにて計算して複数持っておき、不一致が発生した場合は、迷わず初期化するしかないと思います。

電圧低下検地のデバイスからの割り込みが発生した場合、

ＣＰＵの動作は不定状態になると仮定する必要があるので、

積極的にリセットを繰り返して、瞬間停電にも備えたほうがいいかもしれません。

 割と大サービスで書いてはあるんですが、あまりに事細かに書きすぎても問題なので、これぐらいの 説明で理解できる方でないと厳しいです。

組み込みシステム 機材のお話（放出予定）

組み込み開発で必要となる機材の調達方法ですが、

１．新品でメーカーから買う
２．レンタルで借りる（受注元が借りて支給というケースが多い）
３．レンタル会社の放出品を買う（販売ページがあることが多い）
４．オークションで入手する
５．電子系の部品会社から通信販売で買う
５．自作する


４．５．あたりでは秋月電子とか有名ですね

でここまでがメインの記事です




==========================================================================
==========================================================================
==========================================================================


これ以降は、ちと個人的な宣伝になります、時々UPDATEする形になると思います。
（保有している機材の放出予定）




準備が整い次第オークションに出す予定にはしていますが、予定は未定です


興味のある方は連絡を頂ければ、メールをさせて頂きます。



一応リンクを貼っておきます

==========================================================================


＜ヤフーオークション風夢の出品＞


==========================================================================


7/19　現在の予定

・AF9723　10baseIF　付き　1Gbit GANGユニット　2種類　4個
・KMC　partner ET2 本体、電源、プローブ（新品）




==========================================================================
==========================================================================
==========================================================================

組み込みシステム で デバッグプリント

基本的には組み込みシステムでは　デバッグプリントは使えないことが多いですが、

そのかわりの方法をいかにして実現するかというのも工夫だと思います。

以前に紹介したシリアルポートを利用する方法もありますがそれも出来ないと仮定します。


ICEを繋いだ状態で、動作していると仮定して、ソフトの完成度も上がってきていて、でも時々動作がおかしいような場合は困りますね。

もしも、OSを使っていなくて、メモリー（RAM）に空き容量を確保できるのなら、主要な変数（出来れば構造体にしておいたほうがいい）をリングバッファ的に書き込んでいく方法があります。

リングバッファに　関しては、また別に書く必要がありますが・・・


簡単にこの方法を　説明すると


例）
　int dbg_data[1024];
  int dbg_idx;


こんな感じで変数を作っておいて、毎ループ、主要なデータを保存してやります

カウンターの更新はバッファサイズに合わせてやってください


動作がおかしくなった時に、きっとブレークポイントを設定していると思うので

その時に変数の動きを確認すれば、内部で何が起きていたのか推測できます


上の例では簡略化しすぎているので何もわかりませんけどね。

組込み開発の測定器：ロジックアナライザ

風夢です、実は、本当はこの記事をずいぶん前から書きたかったのですが、他にも書かないとって思うことがあったので、遅くなってしまいました。

以前に、デジタルオシロスコープの紹介をしましたが、似ているようで、違う測定器です。


まず、取り扱える信号の数がオシロスコープと、ロジックアナライザでは圧倒的に違います。

一般的なオシロスコープでは、２CHもしくは４CHが標準的ですが、ロジックアナライザは１６CHとか
それ以上になります。

一般的にデータバスや、コントロールラインの信号レベルをH/Lを測定するのがロジックアナライザです。


例えば8ビットでデータを出力するデバイスからの、信号の読み込みをする場合にデバイスからは
リクエスト信号が出力されて、CPUは割り込み処理を行ってREAD信号を発生させてから、データバスに信号が流れます。

（READ信号も、状況しだいで　IO　READと　MEMORY　READ　の場合もあります　個別のCPUで違います）


当初のロジックアナライザは、このような感じのものでしたが、お値段は怖いほど高くて、扱うのにちょっとびびってしまうようなものでしたが、その後さらに機能面で進化しています。

CPUのデータバスに流れるのは、かなりの割合で実行コードなわけで、それはアセンブラレベルになりますが、CPUが何を実行しようとして　ロードしてるのか分かるということになります。

残念ながら、こういう高度なロジックアナライザを使ったことがないので、これ以上の詳細に関しては知りませんが、ICEでやっていることに近いところが外部から観測できることになります。


また、アジレンス等だったかな、デジタルオシロとロジックアナライザが組み合わさった製品も出てきているようです。

組込み開発の市場規模が大きくなるにつれて、それを支援する機材のほうも研究開発されて発展していってます、直接使う機会がなくても大体どういうものなのかを知っておかないと、いざそういう機材を使って開発に当たるときにロスタイムが発生してしまいます。

組込みシステム開発のソフトウェア技術者は、本当に日々勉強していくことが多い大変な分野です、ただし出来上がったものは製品という形で有形の物として存在しますので、やりがいも大きいです。

ハード屋さんにお願いしたいこと（アートワーク）

少し前の記事

＜空きポートの活用（デバッグ）＞

にも書いたことですが、小ロットで作成される、機器の場合、アートワークを決める時点で少し工夫をして頂ければ、ハードデバッグやソフトデバッグに活用できることがあります

JTAGのコネクタのように未実装状態で製品化するというほどのレベルまで行かなくても、使用しないポートをプルアップ、プルダウンしておくのにすこしだけでもパターンを伸ばして頂ければ

・シリアル通信
・IO
・AD/DA

等を付加して、システムトータルでの開発に役に立つことも考えられます


できれば＋Bとか取りやすかったり、TPとか立てれるようなランドにしてもらってれば

もっと楽ですけど


発想を、逆転して、ハードデバッグを行うために、そういう冶具を実装した基盤を提供して

スイッチなり、エンコーダー、シリアル入力に基づいて、確認したい動作をするように

ソフト屋に頼んで、先にがっしりとハードを固めてもらうのもありだと思います

組込開発の測定器 ：オシロスコープ

組込みシステムで　扱う電気信号がどうなっているのかを、目で見える形にしてくれるものが

オシロスコープです


以前には、アナログ式のオシロスコープ（ブラウン管を使った緑色のものでぼわーーんと暗くなる）で信号の波形を見るものでした


それを、デジタル処理で実現したものがデジタルオシロスコープです（緑色のCRTを使ってるものも当然ですがあります）


単純に波形を見ることはもちろん出来ますし、周波数を計ったり、電圧を測定することも出来ます



入出力の信号を見ることで、ソフトが正しく動作しているのか、あるいはハードに問題があるのかを

見つけるために使うことが多いです


外部信号からの割り込み動作が仕様どおりになっているかどうかとか


価格によって性能はぜんぜん違います

今は安くなってはいますし、USB接続でPCとつないでデータを保存できるものもあります


測定できる入力数、測定できる周波数の範囲等で大きく変わります



また　トリガー機能、メモリー機能等あります


トリガー　ある条件が整った時を基準として、前だったり、後ろだったりの状態を

メモリーすることが可能です、

トリガーから時差をつけてメモリーするというディレイ機能など使いこなすには、それなりの知識が必要となりますが、使えれば役に立ちます


何かのプロジェクトで身近にデジタルオシロスコープがある状況にある方は、管理している人に

お願いして、あれこれと触っておくことをお勧めします

メモリマップドIOとIOマップドIO

組込みシステム開発の場合、ハード屋さんから、割り付け表といわれる資料を貰います


その資料には　IOとかアドレスとか書かれています

IOはInput,Outputの略ですね

CPUからの制御線には M,IO,R,Wと有ります（CPUごとには違いますが簡略化します）

それとデータバス、アドレスバス、これを組み合わせて周辺機器（チップ）とのやり取りを行います


＜IOマップドIO＞

IOマップドIOというのは、IO信号と、アドレス、Write or Read 信号で外部とのやり取りを
行います


IO命令というのがマシン語レベルであるので、理解もしやすいと思います

ただし、IO命令に使われるアドレス幅に制限がある場合があります

IO命令自体も高速に行われる事が多いのでデータ量が小さい場合には便利です

CPU内臓のIOとは別に使える場合もあります

割り付け表　には　IOとして書かれていると思います



＜メモリマップドIO＞

メモリマップドIOでは、広大なアドレスが使えます

通常、アドレスバスの２のｎ乗のアドレスバスの信号を一つまたは複数使って
周辺機器（デバイス、チップ）へのアクセス信号をハードウェアロジックで作成します

最近のCPUではアドレスバスの幅も広く、またやり取りするデータ量も多いので、
この方式はよく使われます

IOなのに、なんでメモリーアクセス？って、少し頭が混乱する原因です

欠点は、メモリーアクセスになるので、少し動作が遅い場合があります

ただし、最近のCPUでは、ある程度のアドレスの範囲でアクセス速度を指定できますので、問題にならない場合も多いです

この、アクセス速度の設定などは　スタートアップルーチンで記述する事が多いです

特に画面周りがあるものでは、データ量が多くなるので、多いと思います

組込みで欠かせないICE

風夢です。　ICEという名前は組込み開発をした事のある人なら、ほぼ全員知っているとは思いますが、それ以外の方にはなじみが無いかもしれないです。

簡単に言うと、デバッグを行うためにある高額な開発機材です。

操作するイメージは統合環境のデバッガとほぼ同じような感じです。

InCircitEmulatorの略だったような気がします（スペルに自信なし）


＜フルICE＞

初期のICEは、ターゲットとほぼ同じCPUが乗っていて、開発用のボードに専用のソケットをつけて、
そこからフレキシブル基盤でICE本体と繋げるようになっていました。ICEの代わりに内蔵ROMにプログラムを書き込んでやると単体で動作するものもありました。

この頃のICEは非常に高額で、1セットの金額で簡単に車が買えるようなものでした

まだまだアセンブラでのデバッグも多かった時代で、サポートソフトも貧弱で、Cの構造体の中身の
数値が見れなかったり、ローカル変数が見れなかったり、動作中にブレークポイントを設定した時に
動作がおかしくなったりして、独特の世界でした

ただし、ハードウェアブレークポイントの設定が出来る（特定アドレスのアクセスでブレーク）とか
実際のCPUが搭載されている（ターゲットとまったく同一ではないけど）メリットはありました

高級だったので、プロジェクトに一台のみというのが当たり前の時代でした


＜ROM　ICE＞

その後出てきた、ROM　ICEは、ROMの代わりにRAMにROMの内容を書き込んでやってターゲットボードに接続して、そのほかは何本かの制御線を接続して使うものでした。

価格はかなりやすくなりました。

ただし、デバッグ機能を実現するために、開発用と、リリース用で、一部メモリーマッピングやら
割り込み関係の変更を必要とされる場合もありました。

＜JTAG　ICE＞


さらに時代は進んで、JTAG　ICEというものが出てきて一般的になっています。

CPU自体にデバッグサポート用の機能が組み込まれて、接続も2個の小さなコネクタだけで
使えるようになりました

また、開発中のボードにはJTAG用のコネクタを実装して、完成品には付けないという形で
開発専用の基盤を作成する必要もなくなりました

また、CPUのベンダ毎に開発用の統合環境も提供され、デバッグ以外にも、スタートアップルーチンの一部とか、割り込みベクタの設定とかかなりの部分もサポートされて、以前よりも
ソフトウェア開発者の負担が減っているのも大きいです


ざっと、簡単にまとめてこんな感じかな

空きポートの活用（デバッグ）

組込みシステムの場合、全てのポートを使い切ることは少ないです。


　また、製品完成時には、ランプその他に使用するIOポートも、開発中にはシリアルポートとして
流用できる場合も多々あります。

　ハードデバッグ、あるいは、アプリケーションのデバッグ中に特定の機能をチェックするために、
シリアルポートを利用して、ターミナルモードの様な物を組み込むと、チェック作業の能率があがる
事も多々あります。


　ただし、パターン設計時にその様なポートを、最低限半田付けできるようになっていないと難しいかもしれません。

　理想的にはランド、もしくはTP（テストポイント）になっていればいいのですが。


　また、シリアルポートが使用できても、TTLレベルでの出力になっている場合が多いので、レベルコンバーター（MAX２３２？等）を使ってPCとの接続を出来るようにしないといけません。


多少、ハードルは高いとは思いますが、実現できた場合には

・ハードの機能検証をターミナルモードで実行できるようにしておけば、
　ハード検証作業（修正後の確認を含む）にソフト技術者がかける手間が減らせます


・複数人数で開発中の場合に、アプリケーション担当者が（データ作成だけの場合もあり）
　ICE等の操作方法をしらなくても、動作確認が出来る

・上の例と半分かぶりますが、ICE実機、ROM実機とある場合にICE実機を取り合うことが減ります

・PC上のソフトの場合はデバッグプリント等もできますが、組込みシステムでは出来ないことが
　多いので、内部状態をシリアルで出力して、PCにてログしておくようにしておくと、異常な動作を
　発見した場合の解析に役立ちます


・場合によったらカバレッジテスト的にも使えるかもしれません