「DRAM 72-bit ECCは、1bitのエラー訂正と2bitのエラー検出ができる」
これぐらいは、一般的に知られているけど、さて、じゃあ、どういうレジスタ持たせてるんだろうって気になっていたところ、Linuxに実装されているEDACモジュールのソースコードが参考になった。ECC関連の統計レジスタ仕様が、とてもありがたい。

EDACモジュールを斜め読みしたところ、「え！？こんな機能までハードウェアで実装されとったの？」という機能が2つ有った。みんなに、ご紹介しておこう。

- Memory Scrub機能
普通にOSが走っている状態では、ほとんどアクセスされない不遇な物理アドレスもある。せっかくECCがあっても、アクセスされない領域は、エラー訂正の対象にならない。アクセスせずに放置しとくと、メモリセルが自暴自棄になって、エラーをこじらせ、そのうち訂正不可能なレベルまでデータが壊れてしまうかもしれない。こんな状態を防ぐために、定期的に全物理メモリにアクセスする機能がMemory scrub機能。人間社会でも似たようなことあるような。。。今年はちゃんと年賀状書くかな。

- Error Injection機能
実際には、メモリは滅多に壊れないのでデバッグをどうするかという問題がある。メモリとメモリコントローラの間にデバッグ環境を仕込むというのは、けっこう厳しい。この解決策として、メモリコントローラ側にError injection機能がついてたりする。システム全体の信頼性を上げるという意味で有用。

OpenStreetMapに入ってるコンビニの位置情報をPostGISに取り込んでみた。

日本フランチャイズチェーン協会によると、
全国のコンビニ店舗数は48908件らしい。(2013年10月時点)

OSMのXMLから抽出できた国内のコンビニ店舗数は12,466件だった。
趣味で使うだけだから、これでも楽しめるのだけど、
網羅性1/4ほどだから、もうちょっと網羅してるデータを使いたい。

自由に使えそうなコンビニの位置情報って、どこかにないかな？

一番びっくりしたプレゼンは、
マイコンのGPIOを10BASE-Tとしてパタパタ動かして、UDPパケットを送るというやつ。
その発想はなかった。

EthernetのMACもPHYも使わずに、
GPIOの力技で通信できることに衝撃を受けた。

OpenStreetMapの地図データをダウンロードして、地図をレンダリングできるようにしてみました。
フォントを変更するだけでも、公式サイトのレンダリングに比べて、よい感じに仕上がります。

OSMの生データは、地球全体だと、320GBのXMLファイルになります。(2012/8/22時点）
この生データを、データベースに入れて索引付けする処理に、なんと、まる3日もかかってしまいました。
22nmのCore i7 + DRAM 32GBのPCで処理したのですが、ストレージのHDDがボトルネックだったようです。
SSDで処理すると、1日ぐらいで索引付けが終わるらしいです。圧倒的じゃないかSSDさん！

一方、地図データの品質ですが、ボランティアさんが作成したデータなので表記ゆれが目立ちます。
ただ、一般的な用途としての地図としては、かなり実用的なレベルに達していると思われます。

ソフトウェアの世界では、もう10年以上前に流行った話のようなので今更ですが、
職場で、１年ぐらい前から、XSLTという仕組みを試しています。

XSLTは、XMLデータベースと雛形から、テキストファイルを作る仕組みです。
最初は、自分の趣味ぐらいだったのですが、今では、うちのチームで担当している
ハードウェアのソースコードやら検証環境を自動生成できるようになりました。

XSLT環境はフリーソフトで整いますし、汎用性も高いので、活用できる場面は多いと思います。
共感できる人は少ないかもしれませんが、データベースを自由自在に
操れるようになると、つまらない仕事も、そこそこ面白くなります。

#ちょっと使い方を説明するだけで、XSLTを自由自在に使いこなしてくれる
#うちのチームメンバーは、みんな、ほんまに優秀なエンジニアです。
#こういう人たちと一緒に仕事ができることに改めて感謝しています。

今更ながら、国土交通省が無償でデータ公開してる基本地図情報で遊んでみた。
相当なお金を投入して作られたデータと思われるのだけど、無償公開されているので、
難しいことはあまり考えずに、ありがたく使わせてもらっている。

データ構造も公開されており、さらにXML形式なので、マシン可読性が高い。
これは、日曜データマイニンガーにとって、遊びがいのあるデータやでえ。
世間がどう言うか知らないが、少なくとも俺は、国交省が、いい仕事してると思った。GJ！

地図情報の吸い上げにRubyのREXMLを使っているけど、REXMLがピュアすぎて重い。
こういうリアルな巨大データ（といっても数MB/1ファイル程度）を使うにはまったくの不向き。
libxml-rubyは、名前空間の実装の問題なのか、うまく動かないので諦めた。
REXMLで時間かけて吸い出して、そいつを、PostgreSQLに突っ込んでおこうかなあ。

最近、mbedというホビイスト向けローエンドARM ( CortexM3 )ボードを使ってみました。
Aruduinoもそのお手軽さに驚かされましたが、mbedはさらに進んだ感じでしょうか。
開発環境がクラウド上で構築されており、時代の変遷を感じます。

クラウド上のコンパイラなどが使える分、
値段設定はちょっと高めで、ボードとソフトウェア代セットで5000円ぐらいです。

mbedは、ユーザーがライブラリを公開するスペースも用意されています。
世の中に一般に出回っているセンサやらのライブラリは、かなり揃っている感じで、
他人のライブラリを借用して、さらに、お手軽に目的のものを作れる仕組みです。
エコシステムですね。

自分も試しに、ASCIIのフォントデータをドットから作って、
LCDのドライバ的なものを書いてみました。