IoTという名前だけが一人歩きして、実際の成果はなかなか報告されていない。IoTプラットフォームによるアプローチは間違いというのは、同感である。IoTというバズワードにITベンダーが飛びつき、いろんなプラットフォームを作ってきた。誰もがプラットフォーム商売こそが儲かると思って、むらがったわけだ。
　でも、現状のIoTでできることは、最適化によるコストダウンだけである。付加価値の向上などは、できていない。つまり、大事なのは、かけるコスト以上のコストダウンメリットを受けられるかどうかで、この世界に、大げさなプラットフォームは似合わない。

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

　ノーベル賞を受賞した吉野さんは、企業の研究者である。企業出身で大学に移って研究を続けた人は多いが、企業にそのまま留まったのは、田中さんと吉野さんくらいではないだろうか。
　吉野氏らノーベル賞受賞の「リチウムイオン電池」という記事を読んで驚いたのは、基本特許を取得し、そのライセンス収入で自分が所属した企業を儲けさせたということである。企業の研究者の鏡とでもいうべき人だ。でも、企業が儲けた分の中から、どれだけの報奨金をもらえたのだろうか？知財は本来、個人のものだ。職務発明ということで、企業に権利を譲渡するのだが、その知財によって儲けたお金は、個人にも還元されるべきである。
　青色LEDの中村さんも企業を儲けさせたのに、その見返りの少なさに嫌気がさして大学へ移った。技術の優位性は、すぐに失われ、同じようなものをより安い国で作られてしまう。結局、技術を正当に守るためには、知財しかない。

　この世はプログラミング言語の戦国時代、乱戦のさなか「赤丸急上昇」の言語とはという記事でプログラミング言語の人気ランキングが出ていた。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も比較表には入れられるか、というレベルになったと思う。
　でもまあ、組み込み屋は保守的だから、実際に、乗り換えるには、よほどのコストメリットが重要だろうけど。

　正月休みも終わって、今日から仕事である。ブログも今日から、少しづつ書いていこう。