Darkside（https対応しました）

　走行用モーター制御用のＰＷＭも、期待通りに発振できるようになった。

　だが、ＳＰＩ受信はできない。原因は、どんどん絞られる。遂に、ＳＴＲＢ信号が来ていないことに気付いた。
　オシロが２チャンネルなので、重要な CLOCK と DATA だけチェックしていた。それは両方とも、正常に来ていた。まさか STRB だけ来ていなかったとは！
　ＭＣＣの別名定義で、SPI_STRB SPI_CLOCK SPI_DATA と命名してある。
　SPI_CLOCK_LAT = 1 とやればクロックがＨになる。SPI_DATA_LAT=1 なら、データーがＨになる。ところが、SPI_STRB_LAT=1 と記述しても、なぜかＳＴＲＢはＨにならないのだ。訳が分からない。例えばＭＣＬＲのような例外的ピンにＳＴＲＢが割り当ててあるなら、そういうこともあるかもしれない。しかし、そうではない。

　MCC_Generated Files の記述を見てみると、pin_manager.h が意味不明である。

#define SPI_CLOCK_LAT LATAbits.LATA1
#define SPI_CLOCK_SetHigh() do { LATAbits.LATA1 = 1; } while(0)

　SPI_CLOCK_LAT=1 と、SPI_CLOCK_SetHigh() は違うのか？効果を持たない無駄なコーディングが行われているようにしか思えない。
　だが結論として、SPI_STRB_LAT に代入していた部分を SPI_STRB_SetHigh() および SPI_STRB_SetLow() に置換すると、ＳＴＲＢ信号が出力されるようになった。ＭＣＣは正しかったが、LAT に代入しても動かなかったのは、これが初めてである。これまですべて、LAT 代入だけで動いていた。しかし今後は、LAT 代入をやめるのが無難なようだ。
　無効コードに見えるがＸＣ８が何か重要なことをやっているのかもしれない。て言うかコンパイラーの最適化が働いたらアウトじゃないのか？

　まあいい。MCC_Generated Files 内に記述はしばしば参考にさせて貰っているが、基本的にブラックボックスとして扱う方針だ。内部のコードには絶対に手を加えない。参考にしたコードも、可能である限りは外部で利用しない。ＭＣＣ任せの部分の独立性を確保し、ＰＩＣの機種使い分けを容易にする。

　こうして遂に、自作プロポでラジコン戦車を走行させられるようになった。まだ砲塔旋回や主砲発射はできないが、走行ラジコンとしては大きな山を越えた。
　送信機のスティックを送信機内でＡＤ変換したあと、通信をデジタルデーターで行い、受信側でもモーター制御ＰＩＣにデジタル転送。ＰＷＭのＤＵＴＹまでデジタル値のまま処理する。フルデジタル処理。

　しかも最後のＰＷＭは分解能１６ビット。超低速から最高速までスムーズに操作できるよう、ＰＷＭのＤＵＴＹ比は対数曲線で変化するようになっている。
　対数なのは昔からだが、これまではソフトでＰＷＭ波形を生成したいたせいで分解能が７ビット以下だった。だから、速度変化の滑らかさはイマイチだった。しかし１６ビットＰＷＭになると、対数曲線が俄然威力を発揮する。ハードＰＷＭなのでＤＵＴＹ１００まで、モーターの性能をフルに発揮できるようにもなった。
　実際に、ゲームパッドという必ずしも微妙な操作には向かない入力装置で、実にスムーズに速度を制御できると感動的だ。秒速数ミリから秒速数十センチまで、自由自在に操れる。

　バッテリーもモーターも以前のままなのに、性能は圧倒的に向上。そして、テレメトリーによるバッテリー電圧や電波強度の確認がもたらす、これまた圧倒的な安心感。
　現実世界の兵器においては、「近代化改修」という用語が良く登場する。古い兵器を買い換えるのではなく、改良したりＩＴ化したりして性能を上げることだが、なるほどこういうのが近代化改修か。

　調整の結果、ＰＷＭのＤＵＴＵは１％以下からスタート。また、周波数は３０ヘルツで確定。６０ヘルツを試したところ、超低速での滑らかさは若干良くなったもののＰＷＭノイズがかなり気になった。戦車という属性を考えたとき、ノイズの基本周波数が３０ヘルツと６０ヘルツでは、全く違う。３０ヘルツが超低速でややぎこちないことも、許容範囲内だ。
　ぎこちないと言っても、３０センチ四方ぐらいしかない極端に狭い場所で、ミリ単位の位置変更を行うこと・・・ぐらいは楽々と可能。