検索条件

から
タグで絞り込み (タグなし)(1) Android(2) Linux(12) PC(3) PC::ハード(2) デバイス(2) デバイス::ESP32(1) デバイス::その他(1) プログラム(2) メモ(4) 戯言(1) 戯言::日記(1) 理工(1) 電子(2) 電子::その他(1) 電子::オーディオ(1)
日付で絞り込み 2000年(2) 2006年(1) 2007年(2) 2008年(5) 2009年(3) 2010年(2) 2011年(2) 2013年(1) 2015年(2) 2017年(1) 2018年(1) 2019年(1) 2020年(1) 2021年(1) 2023年(1)
全26件 (4/6ページ) 一覧表示に切り替え

2009/01/28(水)超低消費電力なメモ

はてブ数 電子::その他

超低消費電力アプリケーションのためのデバイス選択メモ。

MPU

MSP430F54xx

16bitマイコンながら、恐ろしいまでの低消費電力。今現在、この右に出るデバイスはない。180uA@1MHzで、その他徹底した低消費電力対策がされている。ADC, RTC, SPI等々内臓。内部にレギュレータを内蔵しているようで、供給電圧に関わらずコア電圧は1.8Vで動く模様。

１万円出せば標準デバッガ（JTAGツール）が購入でき、Cの統合開発環境（MSP-CCE430/Eclipsベース）が利用できる。コードサイズ16KBまで無償で利用できるため大抵は間に合ってしまう*1。オンラインでＣソースレベルデバッグが可能で、これを知ってしまうとPICでちまちまアセンブラを書くのがあほらしくなってくる。命令コードはC言語に最適化されている。*2

ZigBeeや無線タグなどを強く意識した製品シリーズ。1命令サイクル=1クロック

*1 : 製品版を買っても７万円なので良心的

*2 : アセンブラで利用しても比較的素直な命令セットなのでそんなに不便ではない。

DCDC

LTC1878

降圧型高効率DCDCコンバータ。データシートによれば1mA以下でも80%程度の変換効率を持つ*3。

コイル外付け。動作電流10uA。2.65～6Vで動作。

*3 : 一般に高効率DCDCコンバータと呼ばれるICは、1mA以下の低消費電流領域では効率が著しく低下する

電圧レギュレーター

TPS797xx／TPS782xx

TIの超低消費電流（＜1.2uA）レギュレータ。後者はTI自らMSP430用を謳っている。TPS797xxとTPS782xxを両方使い分けると、1.8V～3.3Vまで一通りの電圧がそろう。

最大入力電圧5.5V。

パワースイッチ

FPF1004-1006

Hiサイドパワースイッチ。MOS-FETとMOS-FETドライバを一体にした電源スイッチ。1.2～5.5Vで動作し、50～250mΩといった低いON抵抗、動作電流／シャットダウン電流共に1uA以下、ターンオン時間10us（0.1uF）といった驚異的なスペック。

スイッチデバイスは低消費電力アプリケーションでどうしても電力を食うもの（MicroSDカードとかDACとか）を動作させる必要があるとき、非使用時に電源を切断する目的で使用します。

加速度センサー

ADXL330

180uA@1.8Vのセンサー。Wiiでも使われている加速度センサー。アナログ出力。ADXL345というデジタル接続のより低消費電力のセンサーもありますが、また入手できません。


1.8V駆動じゃないと消費電流が増えるので注意。


メモ

これらをごにょごにょって組み合わせると、個人レベルでも驚異的な低消費電力アプリケーションが作れます。


もっといいデバイスがあったら教えてください。

コメント（0件）

2008/05/22(木)Linuxでmdadmを使ったソフトウェアRAIDの構築・管理メモ

はてブ数 Linux

Linux（Ubuntu 10.04 LTS Server）で mdadm を使用してソフトウェアRAIDを構築・管理する方法について述べます。特に既に稼働中のLinuxにHDDを追加してあとからRAID1を構築する方法を述べます。

続きを読む

コメント（2件）

2008/05/21(水)ML115 G1/Ubuntu 8.04 LTS Serverセットアップメモ

はてブ数 Linux

C3サーバからまともなサーバに変更するため、ML115 G1を導入してセットアップをしました。そのときのメモです。

続きを読む

コメント（0件）

2008/03/28(金)Subversionの設定メモ

はてブ数 メモプログラム

リポジトリ管理にもっぱら Subversion を使っているのですが、管理方法などを細かいことを忘れてしまうので、備忘録メモです。

Apacheの設定

svn のリポジトリを http で管理する場合、Apacheにモジュールを組み込む必要があります。

LoadModule dav_module         libexec/mod_dav.so
LoadModule dav_fs_module      libexec/mod_dav_fs.so
LoadModule dav_svn_module     libexec/mod_dav_svn.so
LoadModule authz_svn_module   libexec/mod_authz_svn.so

svnを動作させたいディレクトリを指定し、次のように記述します。

<Location /repo-dir>
    DAV     svn
    SVNPath /var/www/svndata/repo-dir
</Location>

このとき、/repo-dir/ がsvnリポジトリとして扱われ、/repo-dir/ 以下の管理情報はすべて /var/www/svndata/repo-dir に置かれます。

また /repo-dir/ という実ディレクトリ（www内）が存在すると問題が起こります。

SVNPathで指定したディレクトリに実際にリポジトリを作成します。このリポジトリデータは www 権限で読み書きできる必要があります。

# svnadmin create /var/www/svndata/repo-dir
# chown -R www:www /var/www/svndata/repo-dir

リポジトリのディレクトリ分け

これまでの設定により http://svn.duummy.dom/repo-dir は１つのSubversionリポジトリとして機能します。Subversionによって /repo-dir の仮想的なファイルシステムがすべて作られるようになります。

ずっと勘違いをしていたのですが、あるプログラムを開発するとき、/repo-dir 自体を１つのプログラムソース全体として管理していました。

  • repo-dir/
    • Makefile
    • main.c

しかし、この状況ではブランチといったプロジェクトの分岐が不可能になってしまいます。

これを次のような形で行えば、この中には自由にディレクトリやファイルを作ることができ、コピー等も自在に行えます。

  • repo-dir/
    • prog-current/
      • Makefile
      • main.c
    • prog-stable/
      • Makefile
      • main.c

リポジトリというのは単なる管理単位で、その中のいかなるサブディレクトリでも、そのサブディレクトリ単位でチェックアウトやインポートなどが実効できます。実際、複数のプロジェクトからなる大きな１つのプロジェクトは、このようなディレクトリ分けをうまく使うことで管理されます。

補足

これはリポジトリの概念を解説しただけで、コメントで頂いたとおり下のようにするのが一般的です（必ずしも従う必要はありませんが）。詳しくは参考資料をご覧ください。

  • trunk ……現在開発中のもの
  • branches ……ブランチを納めるディレクトリ
    • branch1
    • branch2
  • tags ……タグをつけてリリース版などをおく場所*1
    • Version 1.xxxx

*1 : 実体はブランチと同じ、ある時点でのディレクトリのコピー

リポジトリの登録とコピー

登録は（通常）手元にあるファイルを import によりリポジトリに登録します。

$ svn import local-dir http://svn.duummy.dom/repo-dir/prog-current

今登録したリポジトリをマスターとして使用しますので、（面倒でも）一度リポジトリから手元のディレクトリにコピーする必要があります。

$ svn checkout http://svn.duummy.dom/repo-dir/prog-current

リポジトリを分岐（ブランチ）させたいときは、同一リポジトリ内でコピーします。

$ svn copy http://svn.duummy.dom/repo-dir/prog-current
           http://svn.duummy.dom/repo-dir/prog-stable

クライアント側の操作

一度チェックアウトしてしまえば、あとは簡単です。チェックアウトしたディレクトリに移動し（prog-current/等）て操作します。

最新のソースに追従
$ svn update
変更箇所をリポジトリに反映
$ svn ci -m "チェックインのメモ"

特定ファイルの変更を破棄
$ svn revert file.c
ファイル/ディレクトリを削除
$ svn delete file.c
ファイル/ディレクトリを追加
$ svn add file.c

差分表示
$ svn diff
リビジョン指定して差分表示（13とローカルのもの）
$ svn diff -r13
リビジョン指定して差分表示（11と12）
$ svn diff -r11:12

作業コピーのブランチ切り替え
$ svn switch http://svn.duummy.dom/repo-dir/prog-stable

参考資料

コメント（2件）

2008/02/24(日)フラッシュメモリは何日で壊れる？　ウェアレベリングの仕組み

はてブ数 PC::ハード

一昔前はLinuxマシンにCFディスクをCF→ATAPI変換して使うということもありました。SSDをはじめ半導体不揮発メモリが盛り上がりつつある時代、寿命について考えてみたいと思います。

なお、SSDのいわゆるプチフリーズと呼ばれる現象の正体は、このウェアレベリングに他なりません。*1

資料：SanDiskのCF仕様書、SanDiskウェアレベリング（ホワイトペーパー）

SanDiskのCFについて考察しますが、他社製の半導体メモリでも同様の機構があります。

*1 : このような書き込み中に数秒とまるという現象は、SSD登場以前のCFでも既に起こっていました。

半導体メモリの寿命

ほぼすべての半導体メモリには構造上の寿命があります。これは書き込み回数の制限で、一般的に10万回（多くて30万回）と言われています。しかしこれはSLCタイプと呼ばれるメモリの話で、現在主流となっている安価なMLCタイプ*2では１万回程度と言われています。（この記事では30万回を寿命として計算していますので、普通のSD等では1/30だと読み進めてください。）

30万回ならば到底問題ないじゃないかと思うかも知れません。

しかし、例えば30万回だとして、１秒に１回データを書き込んでいたとすると

3600(秒)×24(時間)＝86400
86400×4日＝345600

となり、たった４日で壊れる計算になります。同じファイル（の同じ場所）をそんなに書き換えないと思うかも知れませんが、ファイルシステムというものが存在するので、ログディレクトリ内で１秒１回書き込んでいると、常に同じ場所に存在するログディレクトリ（ディレクトリファイル）は１秒に１回書き換えられることになります。*3

デジカメの写真なら30万枚撮らないと壊れませんが、パソコンのディスクとして使用すると結構簡単に壊れることが分かると思います。

*2 : この回数は１セルに2bit以上記録する。

*3 : Windowsは、ファイルに触るたびにファイルへの最終アクセス時刻をファイルシステムに記録するのでもっと酷いことになります。レジストリを操作すればオフにできますが。

SanDisk製コンパクトフラッシュの故障防止機構

SanDisk製CFにはウェアレベリングという故障防止機構が搭載されいてます。

ディスク容量などによって大きさは変化しますが、CFは16KBごとの物理ブロックに分割されて内部管理されています。またディスク全体は4MBごと*4にゾーンとして切り分けています*5。各ゾーンは約3%（128KBぐらい）の余剰領域（通常はアクセスできない）を持っています。

waer_leveling.png

CF内のアドレス（CHS/LBA）はそれぞれ4MBごとに物理ゾーンと対応しています*6。各ゾーンは「Erase Pool」と呼ばれる空き領域の線形リストを持っています。データの書き込まれていないブロックはすべてErase Poolに置かれます。

ゾーン内への書き込み命令があったとき、対応する物理アドレスを直接書き換えるのではなく、「Erase Pool」から１ブロックを取り出しそこに内容を書き込み、それを（内部的に）書き込んだ論理アドレスに対応させます。今まで論理アドレスに対応していた物理ブロックは消去した上で「Erase Pool」に移動されます。こうすることでゾーン内での書き込みを分散させます。

しかしこのままでは、各ゾーン（に対応する論理アドレス）に書き込みが集中したときあっという間に壊れてしまいます。そのためゾーンに対する書き込みがある一定数に達すると「対応ゾーンの変更処理」が行われます。ゾーンＡとゾーンＢのデータが入れ替えです。入れ替えといっても、ディスク内部でデータを互いにコピーしているだけですので少々時間がかかります。実際、CFに対して連続書き込み*7を行うと、一定回数書き込みむごとに動作が２～３秒停止します*8。このときゾーン間のコピーが発生しているようです。

このようなゾーン内の分散処理とゾーン自体の入れ替え処理により、書き込み負荷はディスク全体に分散され、ディスクに空き領域があればあるだけディスクの寿命が伸びます。半導体メモリ各社で実装には色々な違いや特徴（特許）ががりますが、このようなディスクの機構をwear leveling（ウェアレベリング）といいます。

*4 : ディスクによって異なります

*5 : 書き込みや読み込みは、通常ページやセクタ単位(512byte等)で行われますが、消去（空き領域管理）はゾーン単位です

*6 : メモリのページング機構みたいなもの

*7 : 同一ファイルの上書きアップデートとF_SYNC

*8 : SSDで言うところのいわゆるプチフリーズ現象です。

ウェアレベリングの実際

かなり秀逸な機構……に見えますが、実際はそうそう上手く行きません。この機構が正しく働くためには、書き込みを行うディスクに空きゾーン領域がたくさんなければなりません。

例えば、CFディスクを結構使い動作も遅くなってきたので、一度フォーマットして全領域を一度開放したいと思ったとします。ここで、WindowsなどからCFディスクをフォーマットすると（クイックフォーマット除く）どうなるでしょうか？　空き領域（空きブロック/空きゾーン）を増やすつもりが、逆にCFディスクの全領域が使用中にマークされてしまいます。空き領域（空きブロック等）を増やそうとファイルを削除してもまったく増えません。

なぜなら、ディスクはファイルシステムの空き領域を知ることはできないからです*9。ディスク側は１度でも何か書き込まれれば、そのブロックは使用済領域とみなします。

もし、ディスクの空き領域（空きブロック等）を増やすのであれば、ディスクに対してそのブロックが既に使用されてないことを教える特殊なコマンドを発行してあげる必要があります。実際、CFにはそのようなコマンドとして「CF ERASE SECTORS」が規定されています。しかしながらIDEディスク代わりやUSBメモリとして使っている場合、このコマンドは発行されません。*10

要するに全く未使用の状況ならともかく、使っているうちに実際のディスク使用率（ファイルシステム上の空き領域）に関わらず「Erase Pool」はどんどん減少していきます。うっかり通常フォーマットやエラーチェックでディスク全体の書き込み検査でもしようものなら、「Erase Pool」は最初から余剰分として用意された3%しか無くなります。

*9 : ディスク自体にファイルシステムの機能があるのではなく、OSがファイルシステムを持っているのだから当たり前です

*10 : OSとデバイスドライバに依存しますが、OSがディスクを普通のHDD等とみなしている限り無理でしょう。ZPOOL(ZFS)なんかだと、ディスクまで開放命令（ERASE SECTORS）が発行されるみたいです。あとここ最近のSATA接続のSSDとかも開放されるらしい。

3%の余剰セクタで何日使える？

例えばディスク容量が2GBとすると、2048MBの3%で62MBの余剰領域となります。16KBの消去ブロックで考えると62MB/16KB＝約4000となります。理想通り効率的にディスク全体に書き込みが分散されるとしたら、１秒１回書き込むとして

4000（ブロック数）×300000（寿命）／86400＝13653日

となります。書き込み回数が１秒２回（各16KB以内）ならば、この値は半分になるし容量が半分になっても半分になります。

用途によっては秒間10回（または160KB/sec）の書き換えというのは、それほど非現実的ではありません。このときたった136日でCFは壊れます。もちろんこれはウェアレベリングが理想的に動作したときで、実際はもっと前にエラーが起こるでしょう。

CFのエラーマネジメント機構

ちなみにCFには（HDDにも）エラーマネジメント機構として、エラーのあった場所を代替セクタで置き換えるシステムがあります。HDDのエラーは一度起これば広範囲かつ致命的に起こるのですぐに発見できますが、CFのエラーは局所的にしか発生しないため、エラーマネジメントによって置き換えられ隠蔽されます。*11

よってCFのエラーの発生を調べるのはかなり大変です。

*11 : 仕様書には記載されていませんが、この置き換えにはさきほどの3%の余剰ブロックが使われていると思われます。

まとめ

半導体メモリを使用する際は、構造的な有限寿命であることを考慮の上、書き込み回数をよく見積もってから使うべきです。ユーザー環境なら構わないでしょうが、サーバや組み込み系システムで（HDDよりもいいだろうと思って）安易に半導体ディスクを使うと大変なことになります。

今回行った計算はあくまで例です。寿命はセルあたりの書き込み回数寿命、ウェアレベリングの方式、zoneサイズ、全容量が大きく関係しますが、それは製品によって異なります。

コメント（4件）