知らなきゃヤバイ 基礎ほど奥深い Cプログラミングの当たり前!? 邑中雅樹
の連載が始まりました。
第1回は「意外と制約が多い!識別子の名前の付け方」
大事なことが,たくさん書いてある。
自分たちの仕事でどうしているかを思い出しながら読むとよい。
使用できる文字種,文字数については,ISO/IEC 9899:1990(C90), ISO/IEC 9899:1999(C99)
で一つの目安を規定しています。個別には処理系ごとに仕様書を読むとよいでしょう。
自動車業界を中心に,良く用いるコーディングガイドにはMISRA-Cがあります。
MISRA-Cでは,文字種・文字数以外の命名規則は範囲外で,命名規則をしっかりしている事業と,命名規則がばらばらの場合があるかもしれません。
時々演習で,プログラムのファイル名などでCOM, AUXなどMS-DOSのデバイス名と同じ名前にして,プログラムが動かないことなどの不具合に遭遇することがあります。
OSの上での開発,OSの上での実行は,OSの予約語を検討するとよいかもしれません。
リンカが警告を出す場合もあるかもしれません。
---
リアルタイムOS「TOPPERS/SSP」誕生!の記事,第三回(最終回)があります。
「コラム3 SSPカーネルが待ち状態をサポートしない理由」
について考察しました。
sspがタスクの”待ち状態”を持たない理由の候補を3つ記録します。
1,記憶容量の節約。(空間的制約)
タスクの「待ち」がないと,待ちに必要な記憶領域が不要。タスクの切り替えのための領域を固定的に利用すればよい。タスクの「待ち」のための処理が不要なのでプログラムの記憶容量が必要ない。
2,状態遷移を単純にする。(試験制約)
システムの試験の網羅性を上げる。
前提条件として,
2.1 タスクの数が優先順位の数より少ない。
2.2 同じ優先順位に割り当てる必要のタスクはない。
2.3 資源の管理が単純で,複雑なことをする予定がない
場合などの制約条件がある。
どんな場合でも「待ち」があるといい,ないといいという分けではない。
「必要な要件を見極めて」の見極めるとよい点の例示です。
3 割込み中心処理(時間制約)
角速度制御のような,時間あたりに発生する仕事の頻度が大幅に変化する事象を考えます。割込みで処理して,タスクにしないことによって,時間の無駄を避けるようにできます。自動車向けのOSであるISO OSEKでは,一番小さい仕様が「待ち」がありません。
主たる処理は割込みで,タスクは記録(log),診断(diag)など,緊急度が制御よりも小さいものだけでよい場合に「待ち」がなくても対応できるかもしれません。通信が「待ち」がなくても設計できる場合が鍵になるかもしれません。