いったものを行いたいという欲求は、早すぎる最適化を呼んでしまいます。いった手段は、最後の奥の手です。最適化をしなくても動くのであれば、最適化などする必要がありません。汎用性を失うだけです。設定する変数A、B、Cがあり、A,Cが隣り合うアドレスだったとしましょう。このとき、「A=1;B=2;C=3;」よりも、「A=1;C=3;B=2;」の方が上手い具合に最適化される可能性が高いですね。コンパイラが信用できないなら、こう書けば完璧です。1;*(p+1)=3;B=2;さて、このコード、使用しているマイコンの次バージョンを使用するときにも使えるのでしょうか?ソースコードレベルでの後方互換があったとしても、アドレスまでは完全に同じとは限りません。なると、このコードは再利用は出来ない在庫コードとなります。省メモリ、小ステップは確かに大切なことですが、クリティカルな問題にならない限りは、最初は放っておいても良いのです。大切なのはバランス感覚です。数値はdefineで名前を付けましょうマジックナンバーと言う言葉をご存じでしょうか?マジックナンバーとは、処理を知っている人だけが理解できる、プログラム中に現れる他人から見たら謎の数値のことです。組み込みではこのマジックナンバーが大量に現れます。0x71;さて、この0x6c,1234,0x71って何でしょうね。意味が分からないですね。これを理解するには、マイコンの仕様書を片手に各ビットが何なのかを調べなくては、読むことが出来ません。それを回避するためにこんなコメントが書かれてたりします。MODULE0の結果転送先を~~に切り替え。MODULE0をイネーブル。割り込みOn確かに少し読めるようになりました。根本的に何も解決していません。MODULE0の結果転送先を変えたいとき、0x6cはどう数値を弄れば良いのでしょうか?なに?仕様書をみろ?バカじゃないの?マイコンの仕様書とか分厚いのに、ちょっと数値弄るためだけに何度も見直すなんて。いう場合は、数値の意味を分解します。クロックを決定しているのが、上位2bit(7,6bit)、Event設定がその次のビット(5bit)、4bitは例えばモード切り替えで、下位4bitが転送先設定としましょう。すると、次のように意味単位で数値を分離できます。転送先は~~別にこの場合は+(加算)でも構わないのですが、|(ビットor)を良く使います。組み込み屋はビット演算からは逃げられないので、諦めてビットorに慣れてください。これらの数値にdefineで名前を与えると次のようになります。MODULE_TRANSER_C;随分わかりやすくなりました。モジュールからイベントを送りたくなくなった場合は以下のように変えれば良いだけです。MODULE_TRANSER_C;ちなみに、このように分離することで、無駄な処理が入るから使えないと思うかも知れませんが、0x6cと各コードとこのコードは全くコンパイル結果は同じです。定数式は最適化オプションを切っていてもコンパイラが勝手に計算してくれます。え、マイコン対応コンパイラがガチで計算してくれないドマイナー糞コンパイラだって.........?どれほど安いのか知りませんが、そのマイコン使うの辞める事を提案するところから始めませんか?コメントを書く様にするコードを書いた時点ではわかっていることでも、3日もすればすぐに分からなくなるものです。明日の自分は他人です。何も知らない人に優しく説明するように、明日の自分のためにコメントと言う名のドキュメントを残しましょう。グローバル変数や関数などには、使い方などを残しておくのが吉です。呼び出し条件は?この引数の意味は?引数に渡して良い値は?渡してはならない数値は?などはキッチリ残しておかないと、絶対後悔します。Javadocの様に後でドキュメント化する場合は、Doxygenを使うと良いでしょう。モジュールの再初期化をする。モジュールが既に動作しているときのみ呼び出すこと。それ以外で呼び出した場合の動作は保証しない。