賢い EEPROM デザイン

組み込み製品では、電源を切った後も記憶させたい情報の保存先として、大抵 EEPROM が使われます。ですから、製品を開発しようとするとき、ソフトウェア開発者はこの EEPROM 内部のデータ構造を設計する必要があるわけです。

組み込み屋の悲しい性か、こんなとき私はつい、極力サイズに無駄が出ないよう、敷き詰めるようにデータを並べてしまいます。ちょうど C の構造体をそのまま EEPROM に転写するように。

しかし、バイト当たりの単価がタダ同然の今日、このような古典的なデザインに執着する必要が本当にあるのでしょうか。今回は、あえて冗長なデータ構造を採ることで、その後の開発を有利に進めることができるという提案です。
“賢い EEPROM デザイン” の続きを読む

Haskell が教えてくれたこと

Haskellハスケル というプログラミング言語をご存知ですか? 関数型プログラミングという、近ごろ主流となりつつあるパラダイムの先駆けともいえる言語です。

日本では2006年頃にちょっとした Haskell ブームがありましたが、その潔癖な言語仕様ゆえに万人には受け入れられず、今のところ既存の言語を置き換えるまでには至っていません。私も少し勉強したことがありますが、あまりに難解で、結局マスターすることはできませんでした。

しかし Haskell を勉強したことは、私の C++ の書き方に良い影響を与えてくれました。今回はそれについての話をしますが、Haskell のコードは一切登場しませんのでご安心を。
“Haskell が教えてくれたこと” の続きを読む

地蔵インスタンス

過去の記事「動的メモリを使ってはいけない」で説明したように、組み込みで動的メモリを使う場面はほぼ皆無です。そして動的メモリを使わない限り、デストラクタは必要ありません。結果として組み込みプログラムでは、コンストラクタを持ち、デストラクタを持たないというクラスがほとんどを占めることになります。

ところが実は、C++ の仕様である「スコープを抜けたときには必ずデストラクタが呼ばれる」という仕組みだけを利用することで、コードをよりスマートに書き換えられる場合があります。その典型が割り込み禁止処理です。

やり方は簡単で、コンストラクタとデストラクタしかないクラスを定義し、そのインスタンスを置くだけです。私はこの種のインスタンスを「地蔵インスタンス」と呼んでいました。もちろん造語です。置いておくだけで効力が生まれることから、この名前があります。
“地蔵インスタンス” の続きを読む

プログラミングと「職場の安全」は似ている

ある職場で、「リスクアセスメント」というものを習ったことがあります。建設現場や工場など、作業者の身に危険が及ぶような職場で、安全を保つためのメソッドとして広く採り入れられているものです。

そこではまず、職場に潜む危険源を皆で列挙し合ってから、次のような順番で対策を打つことを考えます。

  1. 本質的対策 …… 危険源そのものを除去する
  2. 工学的対策 …… 危険源に近づけないような工夫を施す
  3. 管理的対策 …… 安全のための表示・ルール・マニュアルを設ける

上に行くほど、より安全な対策です。私はこの考え方が、「よいプログラミング」の概念とまったく同じであることに気づきました。そして、もともと漠然としていたアイデアがこのように体系立てられたことで、自身のプログラミングの品質は確実に高まりました。今回はその考え方についてご紹介します。
“プログラミングと「職場の安全」は似ている” の続きを読む

動的メモリを使ってはいけない

組み込みソフトウェアは動的メモリと非常に相性が悪いです。

一方で、今日では常識となりつつある設計やプログラミングの技法の多くは、動的メモリの使用を前提としています。

このギャップは、意識しなければいけないところです。あなたが組み込みプログラマーなら、こういった技法は使わないか、動的メモリを避けるようにアレンジして使う必要があるかもしれません。
“動的メモリを使ってはいけない” の続きを読む