マジックコード、ただしバイト順が逆

今日は出勤して作業していた。

作業自体はわりと短時間で終わる話だが、実機を使うとなると出勤してやらないとね。

無事に完了して、作業完了後にハードウェアを他の担当者に引き渡して、

なんともなければこれでいけるはず。


今回はプログラムに簡単なチェック機能を組み込むものである。

コマンドを送ると、チェックして、判定結果を格納するというもの。

判定結果は0と1でもいいのかもしれないが、偶然OKに見えてしまうと嫌だなと思い、

OKの場合は0x900DDA7Aという値を格納することにした。

“gOOD DATA”ってことですね。Tはちょっと無理がある気がするけど。

NGの場合は明確に別の値を格納するし、チェック結果の格納前に読んでしまっても偶然OKになる確率は極めて低い。

(手順を守ってやればそんなこともないはずだけど、視覚的にわかりやすいのはよいことである)


それで実行したら、なんか変な値が格納されていて、初期化ミスでもしたか?

と思って、よく結果を見たら “7A DA 0D 90” というデータ列で、

これリトルエンディアンで見れば 0x900DDA7A ってちゃんと格納できてるなと。

そうだ、マイコンは4byteのところにリトルエンディアンで代入しているけど、

判定する側はビックエンディアンで見ている(他の部分も大半そうなっている)から、こうなるのか。


というわけで、これ自体はわりとあるあるなので、バイト順を入れ換える処理を追加しようかと思ったのだが、

よく考えたら代入する値は定数なんだから、

0x900DDA7Aのバイト順を入れ換えて代入する処理を書くのも、0x7ADA0D90という値を代入するのも意味は変わらない。

というわけで代入する定数の定義を 0x7ADA0D90 に書き換えて、

「ビックエンディアンでの0x900DDA7A」というような注釈を入れておいた。

こうして期待値通りの結果が得られるようになってめでたしめでたし。


しかし、本来は視覚的にわかりやすいという理由でこういうマジックコードを使っているのに、

そのマジックコードのバイト順を入れ換えた、一見よくわからない値を代入するのはちょっと納得感のないところはある。

そういうもんなんですかね?


というわけで実にしょうもない話でしたとさ。

チェック処理も過去に作った処理の転用で非常にシンプル。

ただ、これを作り込むことで製造上のメリットがあるということでやることにした。

姑息というのはこのことだが、製造時にしか使わない機能なので姑息でもいいかなと。