互換チップが次々と生まれる中国、半導体業界の新たな潮流という記事を読んで、少しびっくりした。STマイクロのMPUの互換チップが出ているのだそうだ。記事を読む限り、ライセンスに基づく正規の互換チップという訳でもないようだ。
　最近のMPUは、ハードウエアよりも、それを支えるコンパイラ、ライブラリー、デバッガ、評価ボードなどの開発環境が決め手の部分がある。たぶん、かなりの開発コストがかかっているはずである。互換チップだと、この開発環境にただ乗りできるのだ。うまいやり方である。

　PIC32でソフトウエアをせっせと書いている。自分が設計したハードウエアの上で動く、ハード寄りの関数を揃えて、アプリを作るメンバーから使えるようにする必要がある。
　実装設計で、意外に難しいのが、ファイルの単位をどうするか、である。関数のスコープが、ファイル単位に限定されるstaticか、グローバルか、の2つしかないからである。前にも書いたが、私は、組み込みでC++を使うのは、懐疑的である。移行コスト(内部の技術者教育も含め)に比べ、得られるメリットが明確でないからだ。だが、このスコープの問題は、C++がうらやましい。名前空間が使えるからである。
　とはいえ、このスコープの問題だけでC++に移行する気にもなれないので、がんばって、同種の関数群を1つのファイルにまとめ、その関数群から使われる補助的な関数をstaticにして、アプリ屋が組む関数の名前と衝突することがないようにする。関数群で共通に使うグローバル変数も、static宣言して、アプリ屋が組む変数の名前と衝突することがないようにする。まあ、ハード寄りなので、UART関係の関数群、SPI関係の関数群という単位でまとめればいいので、マジメにやっておけば、困ることはないのだが。

　アマゾンアップルグーグルの「Connected Home over IP」がスマートホームをつなぐを読むと、メーカーの枠を超えた接続プロトコルが世の中にはないような表現になっている。だが、実際には、日本にはECHONET Liteというプロトコルがある。まあ、普及しているとはいえないが。
　結局は、GAFAがからんだプロトコルでなければ、デファクトにはならない、という構造なんだろう。

　Interface(インターフェース) 2020年 03 月号の特集は、「飛行・走行・航行 ドローン＆ロボ制御 」。飛ばしてみました、動かしてみましたという特集ではない。ちゃんとモデル化を扱った特集なのである。
　たとえば、ドローン。モデルベース設計ということで、まずはモデルの式が出てくる。当たり前だが、モデルの式は、行列のオンパレードである。そして、このモデルを、MATLAB/Simulinkでシミュレーションするのである。解説は、うまく端折られているので、何となく理解できる（というか、できた気にさせてくれる）。ソフトウエアの実装も、PID制御のソースコードが解説される。
　走行の方も負けていない。位置の推定などにカルマン・フィルタを使うということで、こちらも行列のオンパレードである。
　数式ぎらいの人にはお勧めできないが、式そのものはそんなに難しいわけではないので、概要を知るには、面白い特集だ。技術雑誌にしかできない特集といえる。

　今でも組み込みの現場の開発言語はC言語である。C++を使っている現場もあるかもしれないが、私自身は、C++を全面的に採用するのは積極的ではない。C++にしたからといって、開発効率がどこまで上がるのだろうか？という疑問があるからだ。
　それよりも、処理速度を重視しなくていい現場で、スクリプト言語を使うと言う方が、あり得る話だと思っている。Rubyがマイコンで違和感なく動く、「mruby/c」は新バージョンで実用段階へは期待したい。

　この世はプログラミング言語の戦国時代、乱戦のさなか「赤丸急上昇」の言語とはという記事でプログラミング言語の人気ランキングが出ていた。C言語は9位である。組み込み屋である私の主戦場は今でもC言語だ。C++に乗り換えようと思いながらも、どこまで利点があるのかを考えると、乗り換える気になれない。どちらかといえば、補完的にスクリプト言語が使えないかなあ、という方向に考えが向かっている。
　今、現場でC言語が必要なところは、組み込みくらいだろう。PCアプリなら、迷わずC#を使う。

　組み込み開発でCppUTestを使っている話は、以前書いた。実機でテストする前に、せっせとMOCK関数を作って、PC上で試験している。目的は、開発時間の短縮なので、何でもかんでもやっているわけではない。数行の、どう考えても問題なさそうな関数はやらないし、MOCKを作るのがあまりに大変そうなら、これもやらない。
　1関数20行を超えるあたりで、できる限り単体試験をやろうと思っている。
　単体試験をやらずに、実機でテストしていたら見つからなかっただろうなあ、というケースがあった。ある関数の引数を、構造体のポインタ渡しにすべきところを、値渡しにしていたのである。
　私は、関数での副作用を防ぐため、たとえ構造体でも、値渡しにしている。構造体を値渡しにすると、メンバー文のコピーが発生し、性能に影響を与えるので、昔ならやらなかった方法である。でも、今では、マイコンの性能があがって、速度は十分に速いので、引数のコピーとか、関数のオーバーヘッドとかは、気にしない。安全第一である。
　ところが、その構造体に、ある事情で、ワーキングの変数を格納することにした。これは、まあ、よくあることだ。そのワーキング変数が、関数の中で変更され、それを維持する必要があるので、当然、構造体はポインタ渡しにするか、構造体を関数の返値にするかしないといけない。それを忘れて、引数の値渡しにしていたので、構造体の中のワーキング変数が、毎回、初期化されてしまうのである。
　簡単なバグだったのだが、もともとは、ワーキングなんぞを含めていなかったので、純粋に、値渡しで動いていた関数なのだ。コメントにだって、この引数は、入力と記載してある。
　単純なバグなのだが、わかるまでに、半日悩んだ。でも、これを実機でデバックするとなると、1週間かかるバグだったかもしれない。PC環境だったので、カバレージ機能が使え、何度呼び出しても、通らないパスがあって、それで、バグだということが分かったからだ。できる限り、PC環境でロジックのバグは取ってしまうことが、結局は、開発期間の短縮につながる。急ばが回れである。

　Armコア一辺倒だった組み込みマイコンの対抗馬として、RISC-Vが登場した。当初は、FPGAで試してみるという程度の話であったが、最近では、面白いデバイスも登場している。
　でも、開発現場としては、ハードウエアだけあっても、使えない。開発環境が重要だ。その中でも、RTOSが占める役割は大きいだろう。今さら、他のRTOSには乗り換えられない、という現場も多いだろうからだ。RTOSでソフトウエアの互換性を担保できそうなら、安いマイコンに乗り換えるという選択肢はあり得る。
　TOPPERSが64ビットRISC-Vに対応、リアルタイムOSカーネルを公開という記事を読んで思ったのは、これで日本でもRISC-Vの採用を検討できる足がかりくらいはできたのではないか、ということである。いろんな君で、日本の組み込みでTOPPERSが果たした役割は大きい。TOPPERSが対応するなら、RISC-Vも比較表には入れられるか、というレベルになったと思う。
　でもまあ、組み込み屋は保守的だから、実際に、乗り換えるには、よほどのコストメリットが重要だろうけど。

　今、開発現場で熱による手戻りが頻発している理由を読んで、かつて熱設計で大変だった開発案件を思い出した。
　その昔、LAN関連の部品にはNMOSが多かった。CMOSと比べて、熱対策が重要で、ファンが必須だった。でも、作っていたのはPCではなく、組み込み機器である。組み込み機器で、ファンをつけるというのは、本当に嫌がられる。
　そもそも電子機器で最も故障の確率の高いのは電源である。でも、その電源よりも故障の可能性の高いのはファンである。メーカーによって、ファンをなくすというのは、大きなメリットがあった。
　でも、そのための放熱が難しい。当時も熱に関するシミュレータはあったが、使いこなすことができなかった。結局は、試作しては、評価するというサイクルであった。