艦長日誌・私的記録 DS9

　先日，WEBサイトを巡回してたら，ちょっと作って見たくなるような作例を見つけました。PIC32MXを使った工作で，バイナリも配布されています。

　幸い私はPICkit4も持っていますし，MPLAB IPEも問題なく使えていますので，これはさっさと作って見ようと部品を集めて作って見たのが，3月中頃の話です。

　しかし，ここですんなり動かないのが私です。全く動作しません。クロックは発振していますし，各部の電圧も正常です。書き込みもベリファイまで済んでいますので問題ないはずです。

　ソースが公開されていないので，回路の問題（配線の問題ですね）しか確かめることが出来ないのがもどかしいのですが，簡単な回路ですのでもう確かめようがありません。

　電源が汚いとか，周波数が少しズレているとか，そういうところまで疑い始めましたが，それらに対策を施しても解決しません。そうなるともうソフトを疑うほかなくなります。

　そこで意を決して，ソースを提供して欲しいと作者にお願いをしました。回路のミスがあるんじゃないのか，という疑いの目がチクチク刺さりましたが，こちらの意図を察して下さって，プロジェクト丸ごと提供頂けました。これはありがたい。

　とてもご親切に，ビルドの環境まで教えて下さったので，MPLAB X IDEにC32を組み込んで，元のMPLABのプロジェクトをインポートします。

　ビルドはあっけなく通ったのですが，出来上がったバイナリを書き込んでみてもやはり動きません。基板に問題があるかもと，ブレッドボードでも回路を作って試してみましたが，やはりダメです。

　実際に動いているものが私だけ動かないというのは納得がいきませんが，違いはMPLAB Xあることと，PICkit4を使っていることで，作者の方はMPLABとPICkit3を使ってらっしゃるそうなのです。

　私が同じ環境を使えれば問題は解決しそうなのですが，いまさらPICkit3を買うようなことはしたくありませんし，それに純正の後継ツールなんだから，そこは信じていいだろうと思っていました。

　しばらく試行錯誤を繰り返したのですが，動くとされるバイナリは動きませんし，私が自分でビルドしたバイナリも動きません。せっかくソースも頂いたわけですし，こういう時こそなにが起きているかを徹底的に調べるために，PICkit4を活用しようと，インサーキットデバッグを行う事にしました。

　Debug buildを行い，深呼吸していざステップ実行，と思ったのですが，なんとステップ実行をするまでもなく，あっさり正常に動作してしまいました。

　もしかすると治ったのかも，とProduction build（MPLAB X IDEではリリースビルドのことをこう呼んでいるようです）をして書き込みますが，やっぱりダメでした。

　こういう場合は原点に戻り，出来るだけ単純なソフトで試してみる必要があります。定番のLチカを組んで試したところ，これは通常のビルドでもインサーキットデバッグでも問題なく動いています。

　うーん，どこにバグがあるかを確かめるインサーキットデバッグで動いているものが，通常の書き込みで動かないなんてことがあるのは，すでにインサーキットデバッガの存在意義がないだろうと首をかしげるわけですが，実際に目の前で起きていることは疑いようがありません。

　これって，バグ地獄から抜け出るためにICEを使ってデバッグして動くようになっても，リリースでは動くかどうか分かりませんよと言われていることと同じですので，こんなツールはプロは怖くて使えませんよね。そう考えると，もう何が何やら・・・

　で，悩んで1ヶ月が経過し，書き込み環境を変えてみようかと，PIC32MXのライタを探していたところ，気になる情報を手に入れました。なんでも，PICkit3では書けるが，それ以外の自作ライタではベリファイ出来ているのに正常に書き込めていないという問題が出ていると言うのです。

　その原因を見て，私は驚きました。

　PIC32MXでは，CONFIGRATIONビットのDEVCFG0のDEBUGビットが，通常の動作時は11bでなくてはならないのに，場合によっては10bになっていることがあるのだそうです。

　これは，ソースにCONFIGRATIONビットの設定を記述することで行うのですが，通常は，

#pragma config DEBUG = OFF

と記述します。

　しかし，この書き方では場合によっては11bではなく，10bと書き込まれることがあるらしく，もし10bと書き込まれてしまうとICEを使う設定になってしまうようなのです。

　これがまた不思議な話で，本来ならICEを使う設定は00bか01bで，10bでも11bでも問題なく動くはずなのです。これはデータシートのバグか，チップのエラッタでしょう。

　不幸はさらに重なります。

　PICkit3で書き込む時はDEBUGビットを11bに自動的に変換して書き込みます。これがまたくせ者で，PICkit3以外のツールで書き込むと10bのまま書き込まれるため，ICEが繋がっていないと動作しないというわけです。

　まとめると，DEBUG=OFFとソースに書いて設定し，かつPICkit3以外のライタを使う場合には，ICEを使う設定で書き込まれてしまうため，動かないという事が起きるというわけです。

　対策は，DEBUGビットを11bに強制的にすればよいので，

#pragma config DEBUG = 3

とすればOKです。これでPICkit3以外のライタでも正常に動作します。

　さて，PICkit4は純正ですし，PICkit3の後継ですので，いいものも悪いものもPICkit3でやってたことは継承されると思っていました。ですがこの問題で起きることはまさに私の目の前で起きていることです。しかもソースにも当該箇所の記述がありました。

　もしかしてこれが原因ではないかと試してみることにしました。DEBUG=OFFをDEBUG=3と書き直してビルド，しかしおかしな設定されたとエラーを出してビルドが通りません。

　ここで詰んだかと思ったのですが，ものは試しとDEBUG=OFFをコメントアウトしてブルドをしたところ無事に通りました。書き込みを行ってみると，なんと動いてくれました。

　これから分かることは2つ，1つ目はPICkit4とMPLAB X IDEの組み合わせでは，自動的にDEBUGビットを11bにしないということです。MPLAB X IDEとPICkit3の組み合わせではどうかを試していませんが，どちらにしても最新の環境はかつての純正環境であるMPLABとPICkit3の組み合わせとは異なる動作をするということです。

　もう1つは，DEBUG=OFFと書くと，ICEを使わないビルドでも10bと書かれてしまうが，これを宣言しないと，ICEの有無で自動的にDEBUGビットを書き込んでくれるという事です。

　とはいえ，このプロプロセッサ用の宣言は明記することが普通ですし，MPLABのCONFIGURATION設定ツールでも生成されるので，これをコメントアウトするというのは通常思いつくことはないと思います。

　これが，DEBUG=OFFと記述した結果が10bでなく11bと正確に反映されればなにもんんだいはなかったでしょうし，PICkit4でもPICkit3と同じように，リリースビルドではDEBUGビットを11bと自動的に修正してくれるなら問題は発生しなかったでしょう。さらにいうとデータシート通りに11bでも10bでもICEを使わない設定になるのであれば，やはり問題はなかったはずです。

　こうしてみると，今回の問題は，Microchipの複数の部署にわたるバグが引き起こしたものと思われてなりません。DEBUG=OFFの結果が11b以外になるのはコンパイラのバグですし，純正ライタであるPICkit4でDEBUGビットを11bに自動的にしないという仕様変更も思いつきで行われてるように思います。

　最後のデータシートの問題は，データシートの記述がおかしいのか，それとも実チップのエラッタなのかはわかりませんが，どっちにしてもデータシートとチップの間の不一致が起きていますので，これも検討不足でしょう。

　そしてその結果起きることは，インサーキットデバッグで動くものが，リリースビルドでは動かないという，ICEの信頼性や存在意義を根底からひっくり返すようなトラブルなわけです。

　コンパイラがバイナリを生成した時点ではすでにDEBUGビットは設定済みですから，ベリファイが通ってもそもそも動かないバイナリを書き込めば，そりゃ動くわけがありません。つまり，我々ユーザーは，なにを信じていいやらわからない状態に置かれたと言うことです。

　いやまて，開発ツールというのは，いわば測定器であってマザーツールです。これが信用出来ないと，そこから生まれるものはすべて信用出来なくなるので，特に信頼性を高めておかねばならないはずです。

　いくら無償で配布しているとはいえ，実質的な選択肢としてこれ以外を選べないなら，信頼性は高めておかねばなりません。もっといえば，コンパイラは有償でないと最適化オプションを使えず，PIC32MXのようなMIPS系のCPUでメモリサイズの小さいPICでは，無償版のコンパイラで出来る事はかなり限られてきます。

　Microchipはその辺の意識がどうも緩くて，私は以前にも似たような問題でバグ地獄を這いずり回っていたことがあります。

　それでもMicrochipが好きな人がたくさんいるようですが，私はどうも好きには慣れません。肌に合わないとでもいいましょうか，だからAVRに流れたという感じです。

　惜しいのはそのAVRも今やMicrochipの製品になり，ATMEL Studioに起源を持つMicrohip StudioもいずれMPLAB Xに切り替わります。私はAVRがMicrochipカラーに染まることを望んでいません。

　ということで，一応目的は達成しました。いい勉強にもなりましたし，PIC32MXという安価なのに強力なマイコンに慣れたというのは本当だと思います。しかし，こんな目に遭ってしまえばわざわざPICを使う気はしません。やはり私はPICとは相性が悪いんでしょう。

 

 

　先日，セールの終わったamazonをだらだら見ておりますと，10999円でポータブルオシロが出ておりました。ああ，よくある自作キットに毛の生えたやつね，と思っていたのですが，よく見ると帯域120MHz，500Msps/sと，ちょっと気になる記述が。

　詳しく見てみると，1chしかないとはいえ，本当に120MHzの帯域で最大500Msps/sとあります。BNC入力で付属品に1:10のプローブが1本ついてきますし，もちろん今どきのポータブルですのでリチウムイオン電池内蔵でバッテリー駆動です。

　これが1万円？ほんまかいな？

　ついでいうにと，違う業者からだと思いますが，派生品と思われる120MHz，300Msps/sのものが3万円で同じページに出ています。

　私は，これまで，オシロスコープなどの測定器は結局入力のフロントエンド部分のアナログにお金とノウハウが必要で，ここが適当で済むものなら安くなるが，ここをきちんと作らないといけないものは値段が下がらない，と信じて生きてきました。

　実際，今でも200MHzと500MHzの価格差は大きいですし，2chと4chの価格差も大きいです。お金をかければ性能アップ，逆にある程度の性能を期待するならお金をかけずに済ませられないのがアナログ回路で，これは今も昔もそれほど変わりません。

　ですが，120MHzで1万円です。これ，本当だったら価格破壊もいいところですよ。仮に中古でも安いと言えるでしょう。

　1chというのが惜しいですが，この帯域を持っていればアマチュアの作業の大半はこなせます。20年前なら10万円以上の出費は必要だったでしょう。（私は30年前，100MHzの2chのオシロに20万円の予算を組みました・・・）

　同型機はAliexpressでも売られているようですが，それでも日本円で11000円以上します。一体どうなっているのかわかりませんが，こういうものは買って試してみたくのが，これ人情というもの。無駄遣いと分かっていますが，意識が戻ったら手元に届いておりました。

　先に書いておくと，面替えを含めた同型機はすでに2019年頃から出回っており，アメリカあたりでは$70程度で手に入っていたようです。現在のレートなら9500円ほどですから，この金額は別に誰も損をしていないようです。

　さらにいうと，当時からすでに評判は悪かったみたいで，後述する私の指摘はすでに過去に散々語られたものであることも付け加えておきます。

　・・・さあ，開封です。

　まず，小さいです。もっと大きなものを勝手に想像していましたが，本体も画面の大きさもゲーム＆ウォッチくらいのものでした。ただ厚みは3cmくらいはあります。質感は低く，1万円でも高いと思わせるものでした。

　動かす前に，さっと仕様の確認をしておきましょう。帯域幅120MHz，500Msps/sのサンプルレートを持つ，1chのオシロスコープです。垂直感度は50mVとありますので，なんと以前購入したHO102の100mVよりも良好ですが，一般的なちゃんとしたオシロスコープが10mVであることを考えると，まだまだです。（しかもあとでわかったことですが，レンジとしては100mVで，50mVというのはソフトで処理しているらしく，実力は100mVです。なんじゃそりゃ）

　起動は下部にあるスライドスイッチで電源をONすることで行います。電源OFFもこのスイッチで行いますが，特に終了処理を行うものではなく，本当に電源をカットするものだと思います。

　トリガはオートとノーマルとシングルなのでこれはごく普通。トリガのレベルは設定可能ですし，スロープも立ち上がり/立ち下がりどちらも設定可能なので，これはまあそれなりでしょう。トリガは機能や仕様もそうなのですが，実際の使い心地を決めるのはその切れ味です。先人の解析によるとトリガはソフトウェアで行っているそうで，切れ味は期待出来ません。

　なにより問題なのは，使ってみると分かるのですがトリガのかかる条件がちょっと特殊です。ソフトウェアでトリガをかけるからだと思うのですが，1画面分の取り込みの中で，トリガレベルを横切ったものを表示する仕様になっているらしく，1画面内でトリガレベルを横切らないような場合にはトリガがかかりません。

　これはもう論外で，もし私の推測が正しいなら，トリガがなんたるかを全く理解していません。切れ味云々以前の話です。トリガがまず最初にかかって，その後に画面に表示されるからこそ，波形の変化部分を拡大して見ることが出来るわけで，それが出来ないというのは話にならないと思います。

　測定はあらかじめ設定しておいた電圧や周波数は表示されますが，なんとカーソル測定がありません。これも言語道断です。立ち上がり時間や特定のパルスの幅を測定出来ないなんていうことになると，オシロスコープとしての使い道が極端に狭まります。

　さらに致命的なのは，設定の記憶です。画面の明るさやBEEP音などの初期設定は覚えておいてくれるのですが，x10やDCカップリングといった設定や，垂直軸のオフセットやレンジといった操作上の設定が電源を入れ直すとリセットされます。せめてユーザーセッティングのセーブとロードがあれば毎回の起動時にロードする手間をかけても設定が復帰出来るのでまだましなのですが，スカッと消えてしまわれれば，実使用上かなり厳しいです。

　付属品ですが，100MHzでも1本1000円という激安プローブで知られたTP6100という中国製のプローブの，さらにコピーと思われる素性の分からない程度の悪いプローブがついてきました。

　一応矩形波による調整は出来たので故障はないと思いますが，本当に100MHzの帯域を持っているのかどうかは怪しいです。

　さて，問題の周波数帯域です。一応内蔵された発振器による1MHzの矩形波は綺麗に見えましたので，10MHzくらいの帯域はあるようなのですが，先人の解析によると30MHzがいいところだそうで・・・

　私が実際にSGから入力を入れて確認してみると，-3dBになる周波数は36MHzでした・・・

　まあ，そりゃそうか，1万円で本当に120MHzだったらすごいなと思いましたが，そんなはずはあるわけなく，実力は35MHz程度ということでした。もうここまで嘘だとすがすがしいですよね。

　しかしこれも考えようによっては，100MHzのオシロでも20MHzの帯域制限を設けて低い周波数の観測を行いやすくする機能があるくらいですから，もともと30MHzで帯域制限されたオシロスコープだと思って使えば，5MHzくらいのクロックの古いシステムだったら十分にデバッグ出来るのではないでしょうか・・・

　この時気が付いたのが，周波数表示の誤差の大きさです。10MHzを入れたら10.8MHzと測定値が表示されるのですが，これって8%もの誤差があります。これだと40MHzを突っ込んだら43.2MHzとなるわけで，もう違う周波数を示しているといっても言い過ぎではありません。消費税かいな！

　スペックで規定された誤差は6%で，これもかなり大きいなあと思う訳ですが，そのスペックさえも満たしていないというのは話にならんという感じです。

　そうなると垂直軸の誤差も気になります。5Vを突っ込んでみたところ，表示された電圧は4.75Vでした。誤差5%ということで，一応スペック内に入っていますが，5Vで4.75Vというのはちょっと現実的には厳しい感じがします。

　そして500Msps/sというスペックですが，これも嘘っぽいです。波形の取り込みをSTOPしてから波形を拡大する機能がない（これはこれで話にならない）ので直接確かめる方法がなくはっきりしないのですが，先人の解析でも使われているADコンバータがAD9288のクローンなので最高でも100Msps/sが限度で，ICのランクによっては80Msps/sや40Msps/sというものもあるので，最悪40Msps/s程度の可能性もあると思います。

　しかし，説明書に「ソフトウェアによる500Msps/s」とありますので，等価サンプリングを行っているのは間違いないと思います。実際，50MHzの正弦波も正弦波として表示出来ていましたから，100Msps/s以下でのサンプリングということはないと思いますし，一方で12MHz程度の矩形波も矩形波っぽく表示されているので，60Msps/s程度の実サンプリングが行われていると考えて良いように思います。

　ということで，まとめてみると，帯域幅は35MHz程度，誤差は大きい，波形そのものは35MHzの範囲であれば意外にまとも，でした。

　しかしトリガは全然だめで，1画面取りこんで変化する部分があればそこでトリガ，という仕組みでは掃引速度を上げて取り込むことで変化部分を拡大するというアナログオシロスコープのころから当たり前のように出来た事が出来ませんし，かといって取りこんでから拡大というデジタルオシロで当たり前のことも出来ないのでは，変化部分を見ることが出来ないオシロスコープということになってしまっています。

　さらにいうと，強制同期でとにかく波形を出すということも出来ず，波形が全然出てこないということになると，波形が出ているかどうかもはっきりしない訳ですから，これはもう強制同期式の昔々のオシロ以下，ゴミレベルです。

　それでも，ファームウェアのアップデートがあれば改善されてるかもと期待したのですが，先人の解析によるとMCUがロックされており，ファームウェアの書き換えは出来なくなっているとのこと。それでも彼はオープンソースのファームウェアを作って公開するという強烈な仕事をやってのけていますが，これも新品のMCUに載せ替えるという作業が先に必要です。

　よって派生機種やコピー機種が多数あるにもかかわらず，ファームウェアのアップデートは出来ず，大改造をしない限りはこのまま使うことを余儀なくされます。

　これは，大失敗かも。1万円を本当に無駄遣いしたかも知れません。

　正直に言って，途中でやる気が失せて評価や確認作業を一度打ち切ってしまいました。これは3000円でもいらないです。

　そんなことを言っていても仕方がないので，なんとか使い道を考えます。まず電池駆動で小型ですので，フィールドで使える事は間違いないでしょう。帯域はそれでも35MHzほどありますからクロックで5MHzや8MHzくらいならなんとか見えるでしょう。ただし波形の拡大は出来ないので，立ち上がり時間などは観測出来ませんが，よく考えたら帯域が30MHz程度では立ち上がり時間の測定など最初から出来ないので，そこは割り切りです。

　クロックが発振しているか，PWM出力が出ているか，GPIOが動いているかなどの確認は出来そうですが，これまで散々述べたように，トリガの制約からキャプチャされない理由が信号が来てないからなのかトリガをかけ損なっているからなのかがわかりませんので，確認には使えません。うーん。

　カーソル測定が出来ないので周期的な波形の観測に限定されるとして，それだともうオーディオ帯域の観測にしか使えません。つまり3000円ほどで売っているキットのポケットオシロか，PCのオーディオ入力を使ったソフトオシロで出来る事しか出来ないでしょう。

　テスタ代わりに電圧や時間の測定に使おうと思えば誤差が大きすぎるのでこれもアウト。

　うわー，これはホントにゴミですわ。私が買う前に残り7台，その後ずっと6台残ったままになっていることからも，そのゴミっぷりがうかがえます。みんなよく知っていますねぇ。

　ちょっと小さめの扱いやすいサイズで帯域が35MHzというあたりをメリットと考えて使い潰すしかありません。

　ということで最後に，実測した波形です。Si5351Aを使って作成した12.288MHzを，比較的まともなオシロスコープであるHO102と比較してみました。左側が今回のオシロスコープ，右側がHO102です。

 

　HO102は帯域制限なしで，オーバーシュートもアンダーシュートも比較的良く見えています。周波数測定も波高値も十分実用になる精度だと思います。

　これに対して今回のオシロスコープはというと，波形そのものは30MHz程度で帯域制限がかかっていると考えればそれなりに頑張っていると思いますが，周波数表示は13.3MHzと8%もの誤差があります。

　ただ，12.288MHzでちゃんと矩形波っぽいものが出ていると言うことなので，実サンプルレートはその4から5倍くらいはありそうです。このあたりを頭にいれて使う分には，結構使い道があるかも知れないです。

 

　PC-386BookLの最後の改修を行いました。バッテリバックアップの電池を，これまでの単4から単3にしました。

　先日，PC-376BookLを立ち上げようとしたら，起動しません。原因はメモリスイッチが初期化されてしまったからで，このマシンはIDEからのブートでは，セクタサイズをデフォルトの256バイトから512バイトに変更しないといけません。

　バッテリが切れるとメモリスイッチが初期化されてしまい，セクタサイズが256バイトに戻ってしまうので，起動できなくなってしまうのです。なんと面倒な。

　こういうメモリスイッチは低消費電力でバックアップされるものなので，下手をすれば何年も無事なものなわけですが，PC-386BookLではなんと500uAも消費し，しかも電圧が6Vと破格のものが必要です。バックアップに3mWもの電力が必要ってなんなのよ。

　しかもこの電力をカバーするための大きさを持つNi-Cd電池から派手な液漏れがあって（サイズがでかいと当然中野電解液もたくさん入っていますのでね）基板は壊れるしで，ろくなことがありません。

　一般的なマシンは3.6Vの小型のNi-Cdか，コイン電池を使うことが多いバッテリバックアップの電池ですが，PC-386BookLの場合はおそらく，5Vのマイコンを常時動かしているのではないかと推測しています。PC-386BookLではなんと当時としては画期的なレジューム機能を搭載しているのですが，これのために単なるCMOS-SRAMではなく，マイコンを使っているんじゃないかと思っています。

　当時のマイコンは低消費電力のC-MOSでも5Vが当たり前でしたので，6Vということになったんじゃないのかな，と思います。そうなるとマイコン内蔵のRTCがまた結構な電力を食うので，500uAというのもあり得るかなと言うのが私の結論です。

　それはまあいいとして，問題はそんなでかい電池をどこに格納するのかという問題です。もともとバッテリでの駆動はあきらめていますので，駆動用の電池のスペースに入れればそれで済むと言う気もするのですが，それはちょっと美しくありません。

　なので，これまではLスロットの空きに押し込めるサイズとして単4のNi-MHを5本しまい込んでいました。700mAhの電池ですので，ざっと1400時間のバックアップが可能です。だいたい2ヶ月です。

　しかし，歳を取ると2ヶ月なんてのは2週間くらいに感じるものです。あっというまに切れてしまい，起動不能になったというわけです。

　この問題を解決するには，さらに大容量のバッテリを使うしかありません。そこで考えたのが単3への換装でした。これだと2400mAhですので4800時間，実に半年以上もバックアップ可能です。

　考えてみると，駆動用電池でさえもこれ以下の容量しかありませんでした。もちろん数時間しか使えないものでしたが，それをバックアップ用にあてがうというのですから，そりゃ長持ちするでしょう。

　さらにいうと単4のNi-MHは劣化が早く，すぐに充電出来なくなります。これが単3だと長く使えるのでありがたいです。

　問題は収納場所ですが，電池ケースを工夫すると元の場所に上手く格納出来る事もわかりました。さっと分解して問題なく改造が済みました。

　当然ながら起動も日時も正常で，これが最後の改造になると思います。

　しかしながら，200日というのは，長いようで短いような・・・

 

　1月の下旬に，ある展示会の「にぎやかし」として，電子工作を行っている人の作品を展示する企画に偶然声がかかって，急遽展示品を用意することになりました。

　知人からの声かけだったので，他の出展者はすでに知っている人ばかりで，その実力も行動力も十分に知っているだけに，私のような引きこもりで自分のためにしかやらない（＝困ってなければなにもしない）工作を趣味をする人間は，正直困ってしまいました。

　そう，今や電子工作もプログラミングも，人付き合いが上手で明るく人間的に素晴らしい人でなくては，務まらない時代です。

　私が若い頃はですね，こちらにその気があってもむしろ向こう側が避けて（以下略）

　てなわけで，人から逃げるようにこの趣味に閉じこもってきた私にとっては，ちょっとした災害レベルの出来事です。これは困った。

　一応主催者は「なんでもいいですよ」「これまでに作ったものでもOKです」「自分のための工作？いいじゃないですか」とニコニコと全肯定してくれるわけですが，今どきの若い人のコミュニケーション術を言葉通り鵜呑みにすると，年寄りは痛い目に遭います。

　ただ，私も電子工作をはじめたのが10歳の頃，以来40年にわたって続けてきた歴史があります。この中でも「これなら十分使えるな」と思えるものをいくつか，出してみることにしました。

(1)歪率計

　2011年3月に完成とありますので，もう12年も前に作ったものです。子どもが生まれる前のものですから，彼女にしてみれば自分の知らない父親が作ったもの，ということになります。

　当時オーディオ機器を作る事を積極的にやっていましたが，電圧電流，として波形とくると，次は歪みが数値化したくなります。他の測定器ではどんなに工夫してもきちんと測定できず，とても重要な評価項目なのに，でもその測定器は簡単には手に入らないというラスボスが，歪率計です。

　一般的ではないのは，高価であり，汎用性がないからでしょう。原理そのものは簡単で，歪み率の定義に従った回路が組まれているだけのものですが，規模がとにかく大きいのです。

　歪みのない正弦波をある回路に突っ込み，波形が変わったとします。波形が変わったと言うことは，単一の周波数を持つ正弦波に別の周波数が加わったことになるわけですから，出てきた波形から正弦波の周波数だけをカットするフィルタを通してやれば，増えた余計な周波数成分だけが抽出できます。

　その電圧を測定して，元の正弦波の電圧との比が歪み率です。仕組みは簡単ですよね。

　しかし，例えば0.1%の歪率を測定しようと思ったら60dBものフィルタを用意しなければなりません。

　それだけではだめで，元々の正弦波に歪みがあったらアウトですから，フィルタの性能よりもずっと歪みの少ない正弦波の発振器が必要です。

　当然ですが，正弦波の周波数とフィルタのカットする周波数は完全に同調しないといけませんし，さらにこれを任意の周波数で行えなくてはなりません。

　正弦波の発振器はまだどうにかなるとしても，特定の周波数をカットするBEFと呼ばれるフィルタの周波数は可変出来ないといけないし，しかも60dBのフィルタというのは単一では難しいので実際には何段かにするわけですが，それらもすべて同じ周波数に一致させねばなりません。

　これはあかん，絶望的に難しい。

　こういう特殊な測定器ゆえに代用が利かず，高価とくれば，ラスボスの名にふさわしいものになりますわね。ということで，歪率計を持つことは，その人がどれくらい本気でアンプ作りをやってるかを見る，試金石になるわけです。

　当時の私は，歪み率を測る道具としてどうしても歪率計が欲しくて仕方がなかったのですが，新品は50万円から100万円でとても買えず，程度のいい中古品（それでも20万円近くした）も何度も買い逃し，よくよく縁がないと入手をあきらめていました。

　ある時トランジスタ技術に製作記事が載っていたことを思い出し，中古品を買う予算があれば部品にお金をかけたよい歪率計が作れるはずと，部品集めを始めました。

　この記事では，20dBのフィルタを3段繋いで60dBを実現したもので，0.1%レンジでフルスケールの1/100まで読める電圧計を用いれば0.001%の分解能を誇るものです。ただし測定可能な周波数は10kHz，1kHz，100Hzの3点だけ。

　だけど普通はこの3つで十分アンプの性格はつかめますし，仮に任意の周波数の歪率が測定出来ても，結局のこの3つだけ測定しておしまいになることも多いです。

　発振器は別に作る必要がありますので，やはりトラ技の過去記事から0.0005%までいけそうなウィーンブリッジ発振回路を作る事にしました。もう1つ重要なミリバル（ミリボルトメーター）は手持ちの高感度のものがありますので，これは大丈夫です。

　部品はコツコツと揃えたのですが，なにせ規模が大きく，しかもデリケートなアナログ回路です。なかなか最初の1つがハンダ付け出来ないまま時は過ぎていきましたが，意を決して組み上げて，完成したのが2011年の春だったというわけです。

　思った以上に消費電流が大きくて電源電圧が下がってしまい，仕方がなく電源トランスを一回り大きくしたら今度はレギュレータへの入力電圧が上がって，パスコンの耐圧を越えて焼損，と言う情けない事故を起こしたことも良い思い出になりました。

　出来上がった歪率計は，想像以上に高性能で，私自身も驚きました。これなら十分表に出せるデータが取れます。原理的にこの測定器では，実際よりも良い数値は出てきません。現在測定された歪率がとてもよい値だったとしても，それは決して嘘ではなく，実際はもっと良い数値の可能性だってあるのです。

　分解能である0.001%も真空管アンプには十分過ぎるもので，これまで波形の観測と視聴で決めていた負帰還の抵抗も，きちんと数字で議論出来ます。

　もちろん欠点はたくさんあって，まず3点の周波数しか測定出来ないこと。そして発振器の性能が今一歩で，半導体アンプの測定にはもうちょっと歪みの小さなものが欲しいと言うことと，さらに100Hzでは安定した発振状態に収束するのに時間がかかるという問題がありました。

　加えて致命的だったのは，出力がGNDから浮いている場合，例えばBTLの場合は測定不可能であるということです。この測定器はあくまで入力と出力のGNDが共通である回路の歪率を測定するものであり，対GNDではない電圧を測定することはできません。

　そしてその後少しして，VP-7722Aを手に入れます。中に泥が詰まっていて，電源すら入らない，まさに産業廃棄物を3万円で買った私は，悔しさから心血を注いで修理して，復活させることに成功しました。

　そうなると，この自作の歪率家の出番はなくなり，引退することとなりました。短い期間でしたが，そこでの経験はとても印象的なものでした。

　低周波アナログ回路の集大成となる歪率計を実用レベルで完成させたことで，私は十分な自信を持つことができました。音質云々は別にして，低歪み，低ノイズの回路設計と実装の技術を，それなりに手に入れたと思っています。

(2)Si5351Aを使った任意周波数発振モジュール

　これは昨年末に基板を作ったやつです。Si5351Aという便利なPLL ICを使って，異なる3つの周波数をTCXOの精度と安定度で作ることのできるモジュールです。

　ミソは3つ，Si5351Aでは不可能なはずの外部クロック入力，Si5351Aでは許されていないはずの26MHzを源発振にすること，そして起動時に一度だけ使われる設定用のマイコンに米粒AVRことATTiny10を使っていることです。

　外部クロック入力は水晶発振器の端子のうち入力端子に突っ込めばよく，26MHz入力は設定値を計算するソフトがはじき出した設定値の一部をマニュアルで修正して対応しました。なぜ26MHzなんだ，ですか？それは秋月で安く売っているTCXOだからです。

　ATTiny10は今回初めての試みでしたが，これもなんとか突破して，生まれて初めて基板を中国の会社に発注しました。

　結果，14ピンのDIPという一般的な水晶発振器と同じサイズ，同じピン配置で，好きな周波数をTCXOの精度で得ることが出来るようになりました。TCXO精度でなくても，好きな周波数の水晶発振器を手元で作れるというのは夢のような話ですが，それがTCXOという高精度なものなのですから，中学生の頃に夢見た欲しい部品をやっと手に入れたということです。

(3)006P Ni-MHチャージャー

　これも先日書きました。006Pの充電器です。定電流回路を長時間タイマでON/OFFするだけのものですが，10年前に作ったものに2種類の充電プロファイルに対応するための改造を今回おこないました。

　難しかったのは長時間タイマで，ATTiny2313のRAMが足りずに，不意に変数を壊してしまうというバグが発生，再現性がないこともあって解決に苦労しました。なにせ128バイトしかRAMがありませんから，スタックを小さくするしかありません。でもスタックは管理出来ないわけで，十分なゆとりをRAMに取ることしか解決しません。

　結局，足りないRAMはUSARTとGPIOのレジスタに置く事にして回避したのでした。

(4)Nutubeを使ったヘッドフォンアンプ

　一世を風靡したコルグのNutube，待望された一般販売が2016年の末だったので，2017年にはいくつかの作例が世に出ました。その後ブームは下火になってしまいましたが，唯一無二の部品として現在も独特の存在感を放っています。

　そのNutubeをふとしたことから手に入れた私は，無色無臭のダイヤモンドバッファを組み合わせてヘッドフォンアンプを作りました。2016年のことでした。

　面白いのはバイアス切り替えスイッチの搭載です。Nutubeはグリッドバイアスの電圧によって，大きく特性が変わります。そこで，300Bや2A3のような直熱三極管らしいソフトディストーションの特性と，低歪みをねらったハードディストーションの特性をスイッチで切り替えられるようにしてあります。

　どちらも楽しい音で，積極的に切り替えて使うものという位置付けをしていますが，個人的にはソフトディストーションが心地よく，良いヘッドフォンを使えば，直熱三極管のあの音が耳元で再現出来ます。

 

　他にも手作りDCCデコーダやら，ピポっと起動時にあの音が出るSDカードとか，485系や583系でおなじみの車内アナウンスのオルゴールをATTiny85で再現したりと，いろいろ用意はしたのですが，どれもぱっとしないのでやめました。

　また，TCXOなどは実際に12.288MHzと11.2896MHzと8.192MHzの3つを同時に生成するデモを行う予定だったのですが，電源を入れっぱなしで放置するのも気が引けるということで，今回は見送ります。

　先にも書きましたが，今どきの電子工作は見栄えのするものでなければなりません。きらびやかに光ったり，派手な音がしたり，奇抜な形をしていたりというわかりやすさが大切で，どちらかというと何の役に立つか，と言う実用面での評価は今ひとつ重視されていないように感じています。

　決して実用性をおろそかにしていると感じているわけではないのですが，私は動機さえも実用的なところから始まっていて，目的の達成こそが最重要なので，見た目は二の次になりがちです。

　もっとも，そういうアマチュアの工作がプロにかなわないのが見た目であり，それはもう戦前から言われてきたアマチュアの弱点だったのですが，最近は3Dプリンタやら中国での加工やら，良い素材や特殊な塗料も手に入るようになり，随分工作の可能性が広がってきたのは事実で，これまでやりたくても（あるいは出来るんだけども）材料や工作機械の関係であきらめていたことが出来るようになってきたことは，本当に素晴らしい事だと思います。

　しかしながら，かつてのアマチュアの弱点は「中身はプロ顔負け」という枕詞が必ずつくもので，もっと見た目に興味を持てよ，と言う指摘でもありましたから，中身が伴わなかったり，実用性がなかったりするのは，私の中ではちょっと違うかな，と思うところがあります。

　アマチュアですから，やりたいことをやりたいようにやればいいので，同じアマチュアの私があれこれいうのは当然間違っています。間違っているのですが，ゴールが単なるうけ狙いになったりお金儲けになってしまうと，自分は同じ電子工作趣味人に含めて欲しくないなと，そうしたところから距離を置くことを考えてしまいます。

　いかに電子工作が簡単に，手軽になったとはいえ，そこは物理と数学が横たわる世界です。いい大人が「習ってないから知らない分からない」なんてのは体のいい言い訳で，出来なくてもいいから，好きであって欲しいと思います。

　そしてこれから物理や数学を学ぶ子どもたちは，初めてそれらに触れた時に「あーこのことだったのか」とポンと膝を打って欲しいと思うのです。

 

　年明けにちょっとしたイベントにこれまでに工作したものを作例としていくつか展示することになってしまい，何を出そうか，出すものをそのまま出すか改良して出すかなど，いろいろ考えて年末年始を過ごしました。

　出そうと思ったものに，006Pのニッケル水素電池の充電器があります。

https://g-shoes.net/blog/index.php/view/553

　もともと自分のためだけに作ってきたものですし，見栄えも良くありませんので，少し体裁を整えてからと思っていたのですが，ところで今って006Pのニッケル水素なんて手に入るのか？と疑問に思い，調べてみました。

　結論から言うと入手は問題なく，私が入手していた秋月のGP製も（値上がりしてるけど）大丈夫ですし，ありがたいことに東芝が販売するようになったことから，ヨドバシなどの量販店でも普通に手に入るようになっていました。しかも安い。

　入手性から考えると，006Pのニッケル水素と言えばこの東芝のものをさすことが多くなった昨今，これが充電出来ないと意味がないなと充電プロファイルを追加して，Version2への改造を行うことにしました。

　秋月のGP製（以下GP）も東芝のものも7セルで8.4Vであることには変わりはないのですが，前者は250mAh，後者は200mAhと結構な違いがあります。

　充電の方法も，GP製は0.3C（つまり75mA）で4.5時間に対し，東芝のものは専用充電器の仕様から推測すると0.2C（つまり40mA）で6時間の充電です。

　充電電流も時間も異なりますから，結構手の込んだ改造を覚悟しますが，まずは充電電流の対応からです。

　この充電器はトランジスタを2つ使った定電流回路で，エミッタ抵抗で電流を決めています。75mAを流すために，最終的にはカットアンドトライで8.32Ω（実測）としてあります。

　40mAを流すにはこれに8Ωほどの抵抗を直列に繋ぎ，75mAに切り替えるときにはこの8Ωをショートすることで出来そうです。心配な事は100mA近い電流が流れるのでスイッチが大丈夫かという話と，0.1Ωで大きく電流値が変わる世界なので，スイッチの接触抵抗が影響してこないか，と言う点です。

　まあ，素人の工作ですので，セルフクリーニングを期待出来るスライドスイッチで，ちょっと高価な信頼性の高いものでとりあえずやってみます。

　実験はとりあえず成功，スイッチの切り替えで電流が75mAと40mAで切り替わります。スイッチの接触抵抗もそうですが，どっちかというと電池スナップの接触抵抗の方が影響が大きいみたいです。

　で，このスイッチに2回路のものを使い，位置によってHとLをマイコンに伝達するようにしておきます。それで充電時間を切り替えれば良いだけですので，超簡単！なはずでした。

　突っ込まれると思うので先に言い訳しておきますが，電流の切り替えもマイコンで行えば綺麗なのですよ，それにスイッチに直接充電電流を流すというのも気持ちが悪く，正しくはリレーを使うべきでしょう。

　0.1ΩオーダーですからトランジスタやFETはオン抵抗が見えてきますし，温度変化もありますのであまり使いたくありません。リレーは信頼性もありますし，電流も流せますから，こういう用途にはぴったりです。

　しかし，今回あきらめたのは基板の面積でした。定電流回路の基板は小さく，もう空きスペースがありません。リレーなど全然無理です。

　なのでギリギリのサイズとして小型のスライドスイッチを使うことにしたというわけです。

　さて，ハードウェアの改造が済んだので，あとはマイコンのソフトの修正です。この時はATTiny2313Aを好んで使っていましたが，幸いなことにPD2が1つ使われずに余っていました。ここを充電電流の設定検出に使いましょう。

　ソースをさっと修正，やることは簡単で，スイッチの状態を内部で持っておき，これと実際の状態が変わっていたら状態を更新して，状態にあわせて充電時間をプリセットしたり表示を変えたりするだけの話です。

　なにせもともと動いていたソフトです。それも，タイマで1秒ごとに割り込みをかけ，グローバル変数に確保してある時分秒を1秒ずつ減らしていき，ゼロになったら充電完了にするだけのもので，今回はこの部分には手を入れませんから，楽ちん楽ちん。

　しかし，そうは問屋が卸しません。

　実際に動かしてみると，突然20秒くらい減ったり，1時間ずつ減ったりして，あっという間に充電が終わってしまいます。さらにボタンが効かなくなったりして，もう散々な結果です。

　元は10年も前の作品ですし，もしかしたらコンパイラのバージョンが変わったとか，いろいろ考えてみたのですが，元のコードをコンパイルしてみれば問題なく，新しいコードではひどい結果になります。

　違いはどこにあるかと調べてみると，RAM使用容量が違っていました。これまでは103バイト，新しいコードは109バイトで，6バイトの違いがありました。しかし使用率は80%台ですし，これがこれほどの違いの原因とは思いませんでした。

　しかし，違いは違いです。ちょっと細工をしてRAMを2バイトほど減らしてみると，問題の発生頻度が激減しました。しかし，時間が大きく変わってしまうことは少なくなったとは言え起きてしまうので，使い物になりません。

　でも，なんとなく原因はつかめました。対策の効果もあります。ならばその方向に突き進むだけです。と意気揚々と作業を始めますが，もともと128バイトしかないATTiny2313Aですから，空きRAMを数バイト増やすことも至難の業です。

　例えば，スライドスイッチの状態を保持する変数は，スイッチの変化を知るには必ず必要な変数です。スライドスイッチそのものが1ビットのメモリだと思えばなんとかなりそうな気もしますが，変化をつかまえるには過去の情報を持つしかなく，それにはメモリが必要です。

　1ビットのために1バイト割り当てていたのはもったいないので，ほかのフラグとバインドを試みますが，どうも上手くいかないばかりか，頑張ったところで1バイト減るだけですから，6バイトにはほど遠いです。

　そこでスイッチの状態を監視することはやめて，スイッチの状態をなにかのきっかけで調べ，これで充電時間を変えるという割り切りを行いました。スイッチを動かしただけではだめで，起動時かリセット時に取りこまれる仕様にしましたが，これもなかなか使い勝手が良くありません。

　関数の呼び出しをやめて直接埋め込むとか，そうした血なまぐさい努力でなんとか106バイトまで減らした結果，上手く動いていそうだったのでこのまま長期試験に突っ込んでみました。すると，20分ほど経過すると充電が終わっています。やっぱりまだダメみたいです。

　そもそも，これは時分秒を3つのグローバル変数に割り当ててあり，これが何かの拍子に壊されることで起きている問題です。ならばと，充電のON/OFFを保持している変数を減らすため，タイマのカウントをON/OFFするレジスタを使って充電のON/OFFの状態を確認することにします。

　当然ですがなにも問題はなく，1バイト減りました。これでかなり安定してきましたが，それでも時々時間が書き換わってしまいます。

　やっぱりもとの103バイトまで減らさないとまずそうです。この段階で105バイト。

　ここで私は閃きました。タイマのレジスタで充電ON/OFFを保持出来るなら，他のグローバル変数だってどっかのレジスタで保持出来ないか？

　試しに，スライドスイッチの状態を使っていないPORTAのレジスタに書き込んでみました。PORTAは3本しかないので3ビットのメモリとしてしか使えませんが，もともと1ビットあれば十分なフラグですので問題ありません。

　これが実に上手く動き，メモリを消費せずに割り切った仕様が復活したので，長期テストにかけました。しかし，やっぱり時々時間が変わってしまいます。

　ですが，私はすっかり気をよくしました。他に空いたレジスタを探してみましょう。

　時間は最大でも6時間ですので，3ビットあれば十分。ならばUSARTのボーレートの設定レジスタのうち，上位4ビット（UBRRH）使いましょう。分は60秒まで必要ですから下位の8ビット（UBRRL）にします。

　残念ながら秒は割り込みハンドラで減算する変数ですので，volatileのグローバル変数でなければならないですから，これはこのままとします。それでも一気に2バイト減っています。ということはもとの103バイトに届いたということです。やったー。

　テストを行うと，もう問題は出ません。ちゃんと4時間30分なり6時間までカウントしてくれます。ボタンの操作も問題はありません。

　ちょっとしたバグをいくつか潰して完成です。いやー，3日もかかってしまいました。

　機能的にはあきらめることなく，思った通りの動作がプログラムできました。

　しかしですね，RAMの使用量が103バイトならOKで，105バイトなら何でダメなんですかね，103バイトでもダメな場合だってあるんじゃないか，そもそも原因は何なんだ，というのが，ずっと引っかかっています。

　それで，真面目に調べてみました。

　まず，ATTiny2313AのRAMはわずか128バイトです。ここに変数やらスタックやら確保されます。使われているRAMのサイズというのは.dataと.bss（と.noinit）の合計ですから，スタックは含まれていません。

　更に調べていくと，当たり前の事ですが，スタックはRAMのお尻の方から使われていきます。もしスタックがバンバン使われると，変数の領域を上書きしてしまうでしょう。

　mapファイルはリンクマップファイルなのでどのグローバル変数がどのアドレスにあるかはよく分かりません。そこでelfファイルを使って，以下の呪文を唱えます。

avr-nm -fsysv -n hoge.elf

　こうすると，変数のアドレスが出てきます。素晴らしい。

　RAMは0x00800060からですので，時分秒やフラグをグローバル変数に取って109バイトを使ってしまったケースでは，

__data_start        |00800060|   D  |            NOTYPE|        |     |.data
hour                |008000c6|   D  |            OBJECT|00000002|     |.data
min                 |008000c8|   D  |            OBJECT|00000002|     |.data
__bss_start         |008000ca|   B  |            NOTYPE|        |     |.bss
__data_end          |008000ca|   D  |            NOTYPE|        |     |.data
_edata              |008000ca|   D  |            NOTYPE|        |     |.data
mode                |008000ca|   B  |            OBJECT|00000002|     |.bss
sec                 |008000cc|   B  |            OBJECT|00000001|     |.bss
__bss_end           |008000cd|   B  |            NOTYPE|        |     |.bss
_end                |008000cd|   N  |            NOTYPE|        |     |.stab

　となります。secという秒を保持するグローバル変数は0x008000ccに取られていますし，0x008000cdまではスタックが迫ってきても大丈夫とわかります。

　一方で，秒以外のグローバル変数をすべてレジスタに追い出し103バイトに収めたケースでは，

__data_start        |00800060|   D  |            NOTYPE|        |     |.data
__bss_start         |008000c6|   B  |            NOTYPE|        |     |.bss
__data_end          |008000c6|   D  |            NOTYPE|        |     |.data
_edata              |008000c6|   D  |            NOTYPE|        |     |.data
sec                 |008000c6|   B  |            OBJECT|00000001|     |.bss
__bss_end           |008000c7|   B  |            NOTYPE|        |     |.bss
_end                |008000c7|   N  |            NOTYPE|        |     |.stab

　となり，secのアドレスが0x008000c6に下がり，確かに6バイト分だけ減っています。

　それでも，128バイトのRAMのうち109バイトを使っているだけですから，スタックは19バイトも確保出来るはず。これが25バイトになったからといって，どれだけ助かるかという話は，スタックがどれだけ使われるのかを考えないといけなくなります。

　しかし，スタックの使用量というのは簡単には計算出来ないものです。関数を再帰的に呼び出せばそれこそ無限にスタックが使われますし，どんな関数でいくつスタックを使うかを知るのはコンパイラだけです。

　ただ，割り込みを使うとレジスタの待避でスタックをたくさん使うことは想像できるわけで，gccが吐き出したアセンブルリストを眺めてみました。

　まず，気になっていた割り込みハンドラです。やってることは本当に最小限度で，secというグローバル変数をデクリメントしているだけです。

ISR(TIMER1_COMPA_vect)
{
 338:    1f 92           push    r1
 33a:    0f 92           push    r0
 33c:    0f b6           in    r0, 0x3f    ; 63
 33e:    0f 92           push    r0
 340:    11 24           eor    r1, r1
 342:    8f 93           push    r24
    sec--;
 344:    80 91 cc 00     lds    r24, 0x00CC
 348:    81 50           subi    r24, 0x01    ; 1
 34a:    80 93 cc 00     sts    0x00CC, r24
}
 34e:    8f 91           pop    r24
 350:    0f 90           pop    r0
 352:    0f be           out    0x3f, r0    ; 63
 354:    0f 90           pop    r0
 356:    1f 90           pop    r1
 358:    18 95           reti

　こんな感じです。スタックの消費量は4つですね。割り込みはこれ以外にないので，多重割り込みは発生しません。

　これなら問題ないはずと言いたいところですが，実はこの充電器，LCDに4ビットパラレルの古いものを使っています。しかも悪いことに，LCDの表示に関係するコードは，様々なAVRに対応出来る用に作られたもので，私が作ったものではありません。

　ここも確認してみたところ，低レベルの書き込み部分で4つ，これをコールする上位が2つずつで計4つ，合計で8つ使っている感じです。

　もしLCDになにか文字列を書き出すときに割り込みがかかったら，12バイトのスタックが詰まれてしまうがわかります。これでも19バイトには届きませんが，なにかあったらアウトになるくらいギリギリです。

　正確なところはもう追いかけるのをあきらめましたが，残り105バイトでも異常動作をしたこと，そして103バイトでは正常だったことを思うと，どうもこのあたりに境界があると見て良いでしょう。

　結局103バイトで大丈夫という確証を得るのは無理だったわけですが，そこは実績で納得することとし，境界線が105バイトにあるということで，納得することにしました。

　AVR，特にRAMが64バイトや128バイトしかないtiny系ではよく問題になることのようで，Cで書くことに慣れてしまうと，ついついこういうミクロな部分を見落としがちになります。

　結果が甚大なものになるだけに，小型のマイコンを使う時には気を付けないといけないポイントだと，今さらながらに思った次第です。

　アセンブラで書けばまだ意識するんですが，私がAVRを使っている理由はCで実用的なコードが書けるからで，今から全部をアセンブラで書くと言うのもちょっと勇気がありません。

　詰まるところ，アセンブラ的にCを使い，十分なテストで乗り切る事が，AVRとの付き合い方かも知れないと思います。