HIPC設計において何を重視したのか、そしてそれが結果としてどのような仕様に結びついたのかを簡単に記す。
そもそもは、「マイコンで走らせるコード量を減らし、その分パソコンに多くの処理を行わせる」という開発アプローチの有効性(他のアプローチと比べた開発コストなど)を検証したいという動機があった。そこで、このアプローチで必要となるマイコンとパソコンの間の通信処理をライブラリにすることで、似たような機能を繰り返し開発することを避け、開発コストを低減させることを考えた。
堅苦しく書けば「制約が多い開発(マイコンを使った組み込み開発)において、通信を通して別の汎用的で制約の少ないシステム(汎用OS・汎用CPU)を積極的に活用することで、総合的な開発コストを低減する試みのための、多くの開発対象に共通して利用できるライブラリの開発」が目標ということになるのだろう。
リアルタイム性が必要なシステムや計算リソース(メモリや演算能力)が少ないシステムで利用できるライブラリを目指すことにした なぜなら、こういった制約が何ら無いシステムでは汎用OSの利用が選択肢に入り、汎用OS同士で通信するだけなら既存またはその直系の技術とライブラリで対応可能であると考えたからである。
リアルタイムシステムや少ない計算リソースしか持たないシステムで最も良く利用されているプログラム言語は、自分の知る限りC言語なので、マイコン側の言語はC言語にすることにした。
組み込み開発だと、使える通信路はハードウェアによって大きく違うし、用途から有線もしくは逆に無線が前提になることもある。特定の通信路でしか使えないとなると、利用可能範囲が大きく狭まるように思えたので、通信路にはあまり依存せず異なる種類の通信路で利用できる方向性を模索することにした。
直列化(シリアライズ/デシリアライズ)は、プロトコルスタックの下の層に含まれていないし、多バイトの整数値や配列、構造体などを通信したいという需要はあると考えた。エンディアンが違うと変換も必要なので、そういう処理を受け持つライブラリがあっても良いのではないかと考えた。
また、マイコン側の処理を減らすこと突き詰めて、マイコンのメモリイメージをそのまま送受信することにした。変換処理を全てパソコン側で行えば、マイコン側の変換処理は一切不要になるはずである。C言語ならば、いくつかの情報(オフセットやサイズ)が事前に分かっていれば、マイコンのメモリイメージの解釈や作成はパソコン上でも可能である。
Last modified: 2015/07/27 08:00:59 +09:00