トランジスタ技術 2019年 12 月号の特集は、「74ロジックで超入門　FPGA×RISC-V開発DVD」。74ロジックというのは、昔のデジタル技術者であれば、必ず使ったであろうロジックICのデファクトスタンダードである。昔のデジタル技術者であった私は、主要な品番は今でも覚えているし、中には、ピン配置まで覚えているモノもある。
　この時代に、74シリーズでロジック回路を入門するというのは、さすがに時代錯誤だろうと思ったが、昔のデジタル技術者である私は、懐かしさのあまり、本屋で特集名を見ただけで、中身も立ち読みせず、そのまま買ってしまった。
　記事を読んで思ったのだが、言語による設計は、自由度が高すぎて、何をどうすればいいかわからない。その点、74シリーズというよく使われるロジックブロックで設計する方が、実はわかりやすいのかもしれない。このあたりは、さすがに初心者ではない私にはよくわからない。
　DVDには、74シリーズの規格表も収録されている(紙の本をスキャンしたようで、見づらいのが欠点だが)。この規格表ではないが、74シリーズの製造元であったTIのデータシートはよくできていて、トランジスタの等価回路も掲載されていた。デジタル出身の私は、このデータシートの等価回路を見て、トランジスタ回路を勉強したものだった。

　リチウムイオン電池搭載製品の廃棄で火災発生、NITEが注意喚起を読んで、電池を可燃ゴミで捨てるバカがいることを知った。リチウムイオン電池は特に危険なだけで、電池一般は、絶対に可燃ゴミで捨ててはいけない。電子工作で言うと、電池をハンダ付けするのも危険きわまりない。
　電池は日常に存在する。そして通常は危険性はない。それは、エネルギーを蓄積している電池というものを安全に使えるようにしているというだけで、間違った使い方をすると、そのエネルギーが放たれる。昔、リチウムイオン電池の信頼性試験で爆発する動画を見たことがある。本当に危険なのである。

　運用時に起こる「AIモデルの陳腐化」への対応という記事を読んで、AIもやっと運用フェーズに入ったのか、と思った。新しく作ったシステムが華々しく報道される。でも、本当に重要なのは運用フェーズである。運用では、いろんなことが起きる。その中で、かなり大きな課題は劣化問題である。ハードウエアの劣化はもちろん、利用者増による性能劣化や、最近の最大の課題であるOSのパッチへの対抗、新しいセキュリティ問題への対応など、いろんなことが、全て、当初想定していたシステムを劣化させる原因になる。
　AIの場合は、モデルの陳腐化という劣化現象があった、ということだろう。こうした劣化問題にどう対応するかは、ケースバイケースだが、対応手段は、設計時に考慮しておかないと、にっちもさっちもいかなくなる。新しい技術だけに、こうしたノウハウの蓄積が重要なんだろうなあ。

　量子技術の研究後押し　自民議連が年内に提言を読んで、政治家の技術感度の低さに驚かされた。蓮舫のスパコン発言を筆頭に、技術政策はいつも後手に回るのが日本の常だ。でも、この予算は、本当に必要な基礎研究にはまわらずに、応用関係にまわるのだろうなあ。
　でも、応用にまわるだけでもましかもしれない。内閣府の革新的研究開発推進プログラム（ImPACT）、インパクトという名前だけ立派なプロジェクトがある。過去、「チョコで脳若返り」みたいな、明らかに無駄遣いと思われるような研究にも予算をつけているからなあ。

　前回、組み込みソフトウエアのテストにCppUTestを使っているという話を書いた。これで重宝しているのが、CppUMockだ。というか、これを使えるので、CppUTestを使うことにした、といってよい。
　CppUTest+CppUMockで組み込みテストhttp://park11.wakwak.com/~nkon/homepc/cpputest/に情報がある。ただ、注意事項は、この例は、テスト本体のモックをC言語で記述する場合の例で、インクルードするファイル名の後ろに_cをつける必要がある。
　私は、テストするソースはC言語だが、テスト本体は、C++でも問題ないと思っているので、C++で記述している。PIC32のSPIドライバーのモックの例を下記に示す。

include “TestHarness.h”
#include “CppUTestExt/MockSupport.h”

#include “system_config.h”
#include “system_definitions.h”

DRV_SPI_BUFFER_EVENT DRV_SPI_BufferStatus ( DRV_SPI_BUFFER_HANDLE bufferHandle ) {
    return (DRV_SPI_BUFFER_EVENT)mock()
            .actualCall(“DRV_SPI_BufferStatus”)
            .withLongIntParameter(“bufferHandle”,(long int)bufferHandle)
            .returnIntValue();
}

　上の2行が、CppUMockを使うためのインクルード。次の2行がPIC32のドライバー特有の部分(たとえばSYS_MODULE_INDEX型の定義など)のインクルードである。
　あとは、MockSupport.hを眺めていると何となく使い方がわかると思う。
　時間があれば、もう少し丁寧な紹介をしてみたい。

　組み込みソフトウエアのテストにCppUTestを使っている。そもそもは、テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計という本に触発されてのことである。
　例にあるような、LEDドライバーなどのテストを、この手法でやるのは大変だし、結局、実機でしかテストできないことも多く、実行には移せなかった。
　しかし、世の中が変わり、ハードウエアに近いレベルのドライバーは、マイコンメーカー提供のものを使うようになって、少しテスト戦略を変えた。ドライバーそのものは、やはり、従来通り実機でテストする。しかし、このドライバーを使ったソフトウエアは、CppUTestを使うことにした。
　メーカー提供のドライバー関数をモックでシミュレートし、PC環境でテストするのである。
　最近の組み込みのコンパイラは、大抵、GCCなので、PC環境で同じソースをコンパイルしても、コンパイルエラーが出ることはほとんどない。そんなに凝ったソフトウエアも作らないので、機能試験なら十分にPC環境でテストできる。

　転職前の会社は、フレックスで比較的自由だったので、金曜日の夕方、夜間開館していた美術展などに年10回ほど行っていた。ところが、転職してから、フレックスでなくなり、あまり時間に余裕がなく、ほとんど美術展に行く機会がなくなった。
　土曜日にわざわざ出かけていく価値のありそうなものだけ選択して行くことになる。東京国立博物館で開催さえている正倉院の世界は、土曜日に出かけ、かつ30分ほど入場を並んでも、十分に満足のいくものだった。
　大阪へ単身赴任していたときに、2回ほど,、奈良の正倉院展にも行ったことがあるのだが、今回は、それより素晴らしいものだった。これだけ古いものが、これだけ丁寧に保存されているというのは、本当に驚きである。

　えっ？分数計算でなく引き算もできない社会人がいるの？は、衝撃だった。大学生が分数の計算をできないということが大きな話題になったことがある。でも、今度は、引き算だぞ・・・。大手銀行の新人が、小数のかけ算ができない？？？いくらなんでも、にわかには信じがたい。電卓を叩けばOKという次元ではないだろう。

　ドコモがFOMAとiモードを終了へ、6年半先の2026年3月にというニュースを読んで、私と同じ感想を持った人も多いだろう。キャリアというのは、一旦始めたサービスをやめるのは容易ではない。採算とかの以前の部分がある。
　楽天がキャリアを始めているが、本当に、こんな覚悟はあるのだろうか？