なぜプラットフォーム化するのか

っていうと、 アプリを変えたくない から。

デバイスが変わっても、「アプリはいじってません。デバイスが変わったので、ドライバ(とプラットフォーム)は変えざるを得ませんが、それだけです。 従ってテストは変更した部分の再検証のみでOKです。 」と言いたいから。

例えば、

I2Cになるので割とドラスティックな変更ですね。

ここで、アプリに、

/* 送信する */
ST16C2552_Send(send_data, send_len, ...);

と書いてあったら、デバイスが変わったら、

/* 送信する */
SC16IS740_Send(send_data, send_len, ...);

に変えないとダメでしょ？そこ変わってるんだったら、再検証しないとダメでしょ？

でなくて、

/* 送信する */
UART_Send(send_data, send_len, ...);

という、「アプリから見たら、具体的なデバイスはともかく、UARTっぽい何かに送信してるだけ」になっていれば、自信をもって アプリ変更してません(ドヤッ) と言えるでしょ？

……というのが、プラットフォーム化の理由だと思ってます。

抽象化しないと意味ないが、うっすらでいい

Linux、Windowsなどは、I/Oを「ファイル」にまで抽象化しているが、組み込みだとそこまでする必要はないと思います。分かりづらくなるし、処理時間や必要メモリが大きくなってしまう。

とはいえ、当然だが、ある程度は抽象化しないとプラットフォームの意味がない。

例えば、「DIO」(デジタルI/O、パラレルI/O)、「UART」(UART、シリアルI/O)程度でよいが、デバイスの名称そのままでなく、うっすら抽象化する。デバイスの匂いを消す。程度で良いと思います。

とあるデバイス固有で検出可能な異常などは、インターフェースに出さない。というか出せない。出そうと思うと、共通のインターフェースに出来なくなる。

SC16IS740になったら、I2Cなのだから、当然通信エラーとかの概念が入ってくるが、アプリから見たらそんなの知らん。

ひとまずインターフェース設計はこれでOK。
例えば以下。

/**
 *  @brief UART送信
 *  @param data 送信するデータ。
 *  @param len 送信するデータの長さ。
 *  @return 送信したデータ長。
 */
int32_t UART_Send(const void *data, int32_t len);

とはいえ、検出可能な異常なのであるから、検出して活用したい。
結論として、異常な状態を 記憶・取得するだけの モジュールを準備し、プラットフォームやドライバの処理で検出可能な異常はそこに記憶しておく。

で、アプリ側で、必要なら記憶された異常を取得できるようにしておく。「何の異常だかよく知らんが、なんか出てるので出力できるようにしておく」程度の対応をしておく。
Windowsのイベントビューアーをイメージ。

経営者 は、コスト削減をしたい。
だからプラットフォーム化しろと言う。

被雇用者 は、自分の仕事が増えるのを嫌う。なるべく労働時間を減らしたい。(ただし、給料変わらずに)

通常、アプリを作るのは被雇用者だし、プラットフォームやドライバを作るのも被雇用者。

プラットフォーム設計者は、適切な設計をすればするほど、自分たちにしわ寄せが来てしまう。頑張り損。基板改変があると、 自分らだけ仕事が増えて(なのに給料変わらず) 、アプリ開発者ずるい。

アプリ改変にかかったはずの費用を、プラットフォーム化して削減できたなら、全部でなくとも、プラットフォーム開発者に還元する仕組みを作らないと、この問題は解消しない。

ちなみに、プラットフォーム化により削減される費用は永続的なので、ボーナスではなく、基本給に反映されるべき。

うまくいったら基本給増えるとなれば、そら頑張るわな。

大事なことなのでもう一度。

進まないのは、技術的な問題じゃない。技術なんて、上記で示したごく単純なテクニックだけ。

これは経営的な問題であり、変えられるのは経営者だけ。

あるいは、仕事が増えて喜ぶ人にプラットフォームを任せる。
具体的に言うと、 被雇用者でない外注業者。 (自分のことで恐縮)
設計自体は社内でやるとしても、実装を任せる。

うまくオチた？そうでもない？HAHAHAHA!