「組み込み向けソフトウェア移植作業の注意ポイント」

ソフトウェア移植の際に必ず注意しなければならないのはint型のサイズの違いです。ソフテックだより第31号の「3.intの弊害」でも紹介させていただきました。
int型変数は、16ビットCPUの場合は16ビットの領域が確保され、32ビットCPUの場合は32ビットの領域が確保されます。
基板Aおよび基板Bは16ビットCPUから32ビットCPUに変更となりましたが、使用したコンパイラ（CS+ for CC V4）には図 2の赤枠の設定があり、この設定を有効（「はい」を選択）とすることで、プログラムを変更しなくても、int型の変数をshort型（16ビット）として動作させることができました。

図2. コンパイル設定

基板Aおよび基板Bのソフトウェア移植では、この設定を有効とすることで、特にint型のサイズの違いに困ることなく移植することができました。
この設定がない場合は、1つ1つ移植前のint型変数と同じサイズの型に置換していくことになりますが、int型はよく使われる型であるため置換作業も大変です。
コンパイラによっては、ソフトウェア移植を考慮したコンパイル設定が設けられている場合がありますので、コンパイル設定には一通り目を通した方が良いと考えます。

変数の型には、負の値を扱える符号付きのsigned型変数と、正の値のみを扱う符号なしのunsigned型があります。
この開発では、signed型とunsigned型の比較文で、移植前の動作と異なってしまう動きがありました。

図3のソース1への引数が-1（0xFFFF）の場合ですが、if文で0xFFFFと比較したとき移植前CPUではif文の真条件に入りましたが、移植後CPUではif文の真条件に入りませんでした。

アセンブラレベルで確認したところ、32bitCPUなのでshort int numの-1（0xFFFF）は符号拡張されて0xFFFFFFFFとなり、0x0000FFFF（unsigned型）と比較していることで偽条件となっていました。
この場合はソース2のように明示的に-1と比較しないと、変数の中の値が0xFFFFだとしても正しく処理されません。

/* ソース1 */ 
 /* 例：引数numが-1の場合 */
void sample(short int num) 
 {
　　if(num == 0xFFFF) 
　　{
　　　　/* ここに入らない */ 
　　　　return; 
　　}
 }

/* ソース2 */ 
 /* 例：引数numが-1の場合 */
void sample(short int num)
{
　　if(num == -1)
　　{
　　　　/* ここに入る */ 
　　　　return;
　　}
}

図3. signed型変数とunsigned型変数による動作の違い

例はshort型で説明しましたが、signed/unsignedの型があるchar型/int型/long型などでも同じです。また、固定値との比較だけではなく、signed型とunsigned型の変数比較でも同じです。
この開発ではsigned型変数を使用しているすべてのコードをチェックし、問題がないことを確認しました 。signed型とunsigned型の変数比較箇所はエディターの検索機能で簡単には見つけられないので、1つ1つチェックしていく必要があり大変でした。
CS+ for CC V4ではこのような動きになりましたが、コンパイラによってはソース1でも真条件と判断され、問題ないこともあります。
コンパイラによって動きが変わるので、事前に確認が必要な部分です。

タイマやシリアル通信など同じような機能でも、CPUによっては動作タイミングが異なることがあるので注意が必要です。
シリアル通信の送信割り込みを例に説明します。
基板A−基板B間は9600BPSのシリアル通信を行っています。

表2の通り、移植前CPUの送信割り込みは1種類ですが、移植後CPUの送信割り込みは2種類あります。

表2. 送信割り込みの相違

移植後CPUの送信割り込みを、送信終了割り込みの1種類で対応しようとすると、移植前CPUの割り込みタイミングは「ストップビットの送出の直前」であったのに対し、移植後CPUの割り込みタイミングは「ストップビットの送出の後」となります。この割り込み発生タイミングの違いによりシリアル通信の1バイト−1バイト間に空きが出てしまい、通信の動作に違いが出る結果となります。

本開発の送信割り込みは送信データエンプティと送信終了割り込みの両方を使用する設計とし、移植前と通信動作の違いが出ないようにしました。

ハードウェアとのI/F部分の移植に問題がなくても、システム全体で動作させると問題が発生することがあります。
本開発でも、処理速度が速くなったことで基板A−基板B間の伝送タイミングが変わり、通信異常が発生するということがありました。
影響の少ない対策方法を検討し、通信タイムアウト時間を調整することで対応しました。ソフトウェア移植前後の基板組み合わせで問題のない通信タイムアウト時間としなければならないため、お客様とも連絡をとりながら慎重に通信タイムアウト時間を検討しました。

このように、本開発ではソフトウェア移植前後の基板の組み合わせによる問題がないかにも注意して確認しました。
また、ソフトウェア移植前のシステムと1つ1つ動作比較を行いながら試験を実施し、移植前のシステムと動作の相違がないことを確認しました。

本開発のデバッグや試験中に仕様書と異なる動き（不適合）が見つかることがありました。調査したところ、ソフトウェア移植前からある問題でした。
不適合なのでこの機会に仕様通りの動作に修正するのが適切と考えがちですが、既存の動きから変えてはいけないこともあるので注意が必要です。
本開発の場合は基板A〜Dの接続の組み合わせがあるため、1つの基板の動きを変えることで他の基板の動きへ影響するということも考えられます。また、基板交換後に動作が変わってしまうとユーザーが困惑することになります。

本開発では、不適合が発生する条件、修正した場合の影響範囲などを見極め、どのように対応するのかお客様と詰めました。
仕様書と比較すると動きが違うが、運用上は問題にならない内容であるため、お客様と相談してソフト修正ではなく仕様書修正で対応した内容もありました。

よかれと思ってソフト修正しても、その修正がシステムへ影響を与えることがありますので、お客様と認識をあわせながら対応する必要があると考えます。