2012年11月24日土曜日

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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


組み込みシステム OS無し 設定の保存(EEPROM)

前回の記事でウォッチドッグタイマーについて書きましたが 関連項目です

・設定をEEPROMに書き込む
・状態をバックアップされるRAMに書き込む

 とありましたが、

まずは違いについての解説です EEPROMには書き込み回数の上限があるので、
デバイスの劣化を考えると頻繁に 書き込みを行っていると、いつか書き込み不可能になります。 

身近なもので設定を保存しているのもとしては、スマートフォンとか、ルーターが挙げられます。 どちらも常時電源を入れたままで使われることが多いものです。

 1.ルーターの場合
  ・ファームウェアー
  ・設定
   等がEEPROMに書き込まれて保存されているために電源を入れなおした時に、
  同じ状態で  動作できるようになっています。

 2.スマートフォンの場合   もうすこし詳しく、書いてみます
  ・ブートローダー
  ・OS
  ・ディスク(フラッシュメモリー)上のOS、アプリケーション、データ

スマートフォンの場合はフラッシュメモリー上にファイルシステムを構築して、
その上に  主にUnix系のOSを走らせていることが多いです。

android も iPhone も どちらも そうですね。

フラッシュメモリーの耐久性もあがってきているのと、物理ブロックに書き込みエラーが発生するようになった時に代替ブロックを割り当てる論理ブロックを使うようになってきているので出来ることだと思います。

 一見すると、無制限に書き込みを行っているようですが、OSだとバージョンアップした時に書き込まれその後は、読み込みだけです。


ログファイルなども、何かのイベントが発生した結果だけなので、有限です。

製品のライフサイクルを考えて、上限の書き込み回数をしっかりと把握した状態でなら、フラッシュに 現在のシステムの状態を全て保存しておくことも可能です。

ただし、やはり性能が向上したといえども、フラッシュには書き込み回数に上限があります。  そこのところが RAMへのバックアップと違うと言う事を意識して置いてください。

データーシート等を見ていただければ、上限書き込み回数が書かれていますので、一度目を通してみてください。

2012年11月2日金曜日

ラベルを修正しました

更新をサボっていましたが、久々に更新しました。 ついでに、ラベルを修正しました。 半角のカンマと全角のカンマの入力ミスです。 ”,、”並べてあると分かるのですが、

関連項目の検索性をあげるために

細かくラベルを付けるようにしていたために起きました。 

関連する項目をなるべく同じラベルにしています

特に宣伝等はしていないのでこのサイトに来る方は検索で来ていると思うので、そうしています。 放置も多々あると思いますが、終了宣言が無い限りぽつぽつと更新されると思っていてください。

なるべく多くのラベルを付けるようにとしていたのですが、文字数に制限があるようなので、エラーが発生するため、将来的に英文字短縮形にしていく事になると思います。(2012/11/24update)

組み込みシステム OS無し ウォッチドッグタイマー

割り込み処理の話を思いつきで書いていたら行き詰ったままなので、いったん放置して 違うことについて書いてみます。


 組込みシステムでは ”フェールセーフ”になるようにシステムを設計します。

 また別途書くことがあるかもしれませんが、 
・データのバックアップ(主にRAM)
 ・設定のバックアップ(EEPROM)
 ・電圧監視によるリセット
 ・ウォッチドッグタイマーの利用

 それぞれが関係してくるので、

全部を一気にとは行きませんが今回はウォッチドッグタイマーに 関して書いてみます。

 ハード回路としての、ウォッチドッグタイマーもあれば、CPU内蔵のウォッチドッグタイマーも あります。

 処理を簡略化してC言語のソースで表すと

 void main() {
     while(1) {
       func1();
       func2();
       func3();
       clear_wdc(); // ウォッチドッグタイマーのクリア処理
     }
 }

 こんな感じです、どこかの処理に異常が起きた場合にシステムが完全に停止してしまわないように するために、使用されます。

 割り込みの優先順位はかなり高く設定されます (システム全体の健全な動作に関わるため)

 その割り込み処理内で、何らかの処理を行いますが、システムをリセットしてしまうこともあります。

 ウォッチドッグの処理の割り込みの関数にジャンプしてきた場合は、何らかのトラブルが システムに起きていることになります。

 多くの場合は、設計不良、想定外の多重割り込み、場合に寄れば電気的なトラブルの可能性もわずかにありますが、システムごとに違います。

 いくつかの条件が整えば、WDT割り込みが発生したかどうかを確認できます 

・バックアップ可能なメモリーに発生した情報を格納、更新できること
・その情報に何らかの形で外部からアクセスできること
 例えば
  ・EEPROMに書き込んでおいてJTAG接続のICEで確認する
  ・1次電池、2次電池でバックアップされている、RAMに書き込んでおいて、
   サービスコンソールで  参照する
  ・あるいは、システムログとして保存しておいてメール、WIFIでの転送、
   SDカードへの書き込み等 方法としては幾つも考えられます


 関連する項目があるのでさらっとだけ説明して終わりにします。

2013/09/27 何故だか、改行などが変になっていたので修正しました。