R&D daily

暫くぶりに、疲れた感じがあるな....

夜、ちゃんと、どうにも眠くなって
良く寝られる。
回復に数日かかる感じ。


何時の頃からか、仕事とかで
”疲れる” 感じを受けなくなって
いるのだけど。

時々は、頭と手をぐるぐる回す、
こういうの無いと、
感覚を忘れてしまいそうだね。


まあ、まだ全然終わっては
無くて、それなりに続いていく
ようなんだけど。
満期？まで到達できれば
また一つ面白ネタが積めるので
なんとか頑張りたいところ。

かかった、ヒット！


まあ、オールクリアって
のからは程遠いし、
実質、勝負はこっからなんだけど。


それではあんまり時間も無いことですし、
巻いていきますか....

みんな逃げんなよ？

ようやく順番が回ってきたのかな？

相変わらず直前までバタつくのは
お約束ではあるのだけど。

万事、固有の適正なストレスを掛けないと
軸が定まらない、ってことの裏返しだと思うね。

さて、何が出るかな？

今週は秦野

都心からは電車で１時間ほどだけど、
丹沢山系の入り口ということもあって、
自然も豊か？だ。

駅は、山歩きの利用客も多いせいか、
ちょくちょくヤマビルなんて
落ちてたりするようだ。
駆除された後なんてのも
見たりする。

------

晩飯後、駅の前の川のふちを
歩いていると、カジカの
声がする。
結構にぎやかだ。

普通に護岸されてるし、
渓流て感じでも無いんだけど、
こんなの居るんだなあ、
と驚いたり。

自己評価が高いとか
低いとか、適正とか。
まあ、（概念は）分かるような
気もするけど....

思春期の頃なら、
だれしもそういう事、
気にするように思うし。

なんなら自分もそうだったと思う。

------

でもまあ、振り返ってみて、
人生、何時までも、
そんなことにかまけていられる
ほど、ヒマはなくて。


上手く行かないことを
あれこれ悩んだり、
分析している（風）のに
飽きてくる。

こんなの、どうせ結論出ないし
実際、上手く行かないことを
なんとかするのに、全く役に
立たないのははっきりしている。

で、いつの頃からか、
自己評価とか、自己肯定感なんて
そもそも、思考の対象に
ならなくなった。



自分のこと、良く言われりゃ、
そりゃ素直にうれしいけど、
悪く言われても、弁明することすら
面倒ですらなくて、興味ない、
という感じが近いかな。


弁明とか、どうせ時間の無駄だから
別のことやるよ....

自分の力がどうの、なんて
昔は気にしていた気もするけど、
今はもう、どうでもいいんだよな。


あと、この場合の弁明って、
たとえば、悪く言ってる相手とか、
第三者に向けて、じゃないよ。
自分自身に対する弁明を
放棄している、ってこと。


この状況、自己評価高い、とか
低いとか適正とか言われると違和感ある。

自己評価、判定不能、あるいは
対象外というのが一番近い。



ちょっと違うかもしれないが、
多分、こういうのが、
皆が言う、うまく自己肯定出来てる
ってことのような気もする。

だとしたら、そもそも
自己肯定がどうの、と言ってるうちは
自己肯定不可能なのでは...？


-------

なので、自己肯定感が
どうのという話題を見るに、

まあ、当人にとっては
人生の一大事なんだろうけど、
全然そっちじゃない
んだろうになあ、という印象。


でもこういうの、生死が掛かる
ような状況になったら、
吹っ飛ぶんじゃないの？
まあ、生死までは言い過ぎだけど、
それにしても、適正な負荷、もしくは
バイアスが掛かって無いのかもなあ、
と思う。



自己肯定感が低い、の対義語は
自己肯定感が高い、でもなければ
自己肯定感が適正、でもない。


そんなものは自己肯定感が低い、
という気持ちに囚われている
状態での思考だよな....

低い、の対義語が、高いor適正
だと思っているのが不幸な誤解
を生んでる気がする。


正しい対義語は、そんなものには
そもそも意識がいかない、
か、あるいは
それは君の意識が作り出した
幻想、あたりが適切なんだと思う。

いわゆるMILのコネクタも良く使うんだけど。

注意したいのは、この業界では
MIL SPECか？、と見せかけて
実はMIL準拠、とか称する
安物コネクタが幅を利かせている....

この業界、、何かにつけて
超短納期ばかりなので、
まぁ、物に多少難があっても
安くて（納期が）早くて、
ありがたいのは分かるんだけど。

こういうの、新品でも、
普通に使ってるだけで、
部品がぽろぽろ取れたり、
そもそも、人間の力では
付け外し不能なくらい
カタかったりする。

バヨネットの外周が
ローレットになっているので、
手でつかんで回せ、って
事だと思うんだけど....

ポンププライヤとかで、ガシッと
掴んで、グリッとやらないと
付け外し出来ない...

機械的精度は不良品レベル、が普通。

この力なら、逆方向に回しても
ガイドピンを吹き飛ばして
回せそうだよなあ....
とか思ったり。

あんまりひどいので、
代理店にクレーム入れると、
なんだか、次の納品から
直ってたりして、笑う。
直るんかい！

で、数年すると、またいつの間にか
死ぬほど固くなったりして、
また笑う。
直ってるぞｗ


どういう基準で物が出来てる
のかは不明...

クレーム一発で出荷基準が、
ころっと変わったり
暫くすると元に戻ったり
MIL準拠とは？MILに怒られるよ....

こういうの、MIL準拠じゃなくて
MIL不適合、と大きく書いてほしい。
そっちの方が重要な情報だよ。


こんななので、この業界でしか
コネクタ扱ったことの無い人は
かなり意識が偏ってるので
要注意ｗ


本物のMILは、そんなことないよｗ

見た目では分かんないけど、
一回さわると、すぐわかるね....

------

ODUはあまり触る機会が無かったかな。
過去に、一回だけロボット用の奴を
使ったかな？
自動脱着工具なんかに使うやつ。


LEMOは大体いい感じなんだけど、
一つだけ言えば、抜き差しするときの
質感があんまりよくない。

頻繁に付け外ししない所に使うのが
良いかな、と思う。


人が頻繁に操作して、しかも、
緊急時、ワイヤーが引っ張られた時に
ある程度の処で外れてほしい
（安全のため）ってものには
fischerを使ってたかな。

https://www.fischerconnectors.com/japan/jp/products/brass

付け外しの節度感は、
これが別格によかったと思う。


------

でもまあRJ45も、最近のは
そこまで大きくないとは思うんだけど。
物を選べば。



左は比較用 USB type-Cケーブル

------

小さい系のUSBは、
ジャック側コネクタの
堅牢性がちょっと気になる....

機器に刺さってる処に
たまたま一撃もらって、
壊れはしなかったんだけど、
ユルくなってしまった。

その後、稼働中ぽろぽろ
外れるようになってしまい、
変形したのがジャック側で、
もうどうにも
ならなくなったことが。

人間が直接扱う機器なら
良いけど、フィールド向きでは
無いよなあ、と思っている。

標準サイズのUSB コネクタは、
大きさはいいけど、節度感が....

そりゃ学問とかの成果が、
膨大な無駄や、試行錯誤の上に
ようやく成り立ってるのは、
身にしみてるけどね....

でもそれを国とかの公共で
資金出すのは、大分、スジが
おかしいだろう？と思う。

掘れば無尽蔵に石油が出るとか、
極端に安い労働力を
使い捨てる、とかできない限り、
公共ってのは、そんなことにお金を
出すべきではない、と思う。


そういう国（家庭でもいいね。
そっちの方がわかりやすいか？）
の例をみて、ウチもああしよう！
とか、子供みたいなこと
言ってるのか？

------

しかし、無駄？なものは
いらないのか、というと
そんなことはなく。

じゃあ誰がやるべきなのか？
と言えば、そりゃ個人とか
私企業がやることだよ、
と即答する。

そういうことやるために、
組織も個人も稼いでるんだよ？
しっかり稼いで、研究や、
趣味と言ってもいいね、
こういうものに時間やお金を
かけるんだよ。



稼いでさ、何する？
いくら収入があった、と
満足に浸るわけ？

みんな、何のために稼いでるか
分かんなくて、しまいにゃ
自分探しとかに出ちゃうのか。



------

国とか、公共がやると
やる方の責任もあるけど、
利権、既得権の巣窟になるの
目に見えてる、というか
実際そうなる。

なので、そういうのさんざん
見ちゃった納税者としては
そういった補助金関連、
止めていただきたい。


それで研究？続けられない
ようであれば
それまでのことだし。
自分で稼げないなら、
買ってくれる金持ち見つけりゃいいし。

もちろん公金で生活保護を
現物支給、とかは大賛成なんだけど。


ねじれた世論を誘導する
なんか研究とは関係なさそうな
自称研究者とか、多すぎるよなあ。
と思ったり。

個々の資金源から資金を
引っ張るのは効率が悪い
（というか、じっくり見られて
アラがばれる）ので、
公共の仕組みにしてしまって、
効率よく、一気に資金を得ようと
してるだろ？とか感じる。


------

昔から、稼いでから、
自分の好きなことするのが
学問とか諸々（F1参戦とかね）
のことだと思うんだがな。

なんで、金もらうための
方便になってるんだ？という気持ち。

冷静に考えて、RJ45がインピーダンス整合
取れてるとは思えないし、
信号レベルや、シールド構造考えても
そういう信号じゃない、と思っているので、

ある程度ちゃんと？しているコネクタ使えば
好きにやってるけどね。

まあ、スペックや高級感求めるなら、
これとかね。
https://www.digikey.jp/product-detail/ja/lemo/FGG-00-304-CLAD27Z/FGG-00-304-CLAD27Z-ND/3797496

街中で見ることは、まず無いけど、
どこでよく見るかと言えば、
TVクルーが使ってる中継用の
カメラとかにはいっぱいついているのを
見かける。

安くはないけど、防水構造のも
選べるし、フィールドで使うなら
この辺から選んでいる。

コスト優先とか言ってる通信規格、
時代が下れば下るほど、そのことが枷になって
多大なリソースが食われることになって、
コストとは....というお気持ちになってしまう。

さっさと死に絶えてくれるといいのだけど、
そういうのに限って、なんやかんやと
生き延びちゃうんだよなあ。

------

最近では、素早く差すとUSB3.0とか
話題になっていたけど、
逆に、みんなUSBのコネクタの構造すら
大して見てなかったのかよ！
という気持ちになったり。

端子の配列見りゃ、
あー、とか言う気持ちに
なりそうなもんだけど、今頃話題になるとは
正直、そっちがオドロキではある。

------

CANとかも、コストダウンのために
差動を捨ててるとか、安い電線を
適当にツイストした状態で、
特性インピーダンスが合うように、
規格の方が物に合わせてあったりとかね。


....そんな規格で大丈夫か...？


そこまでして、電気的にはどうよ？
という規格でスタートしたのに。

いつの間にやら、
絶縁CANドライバとか専用IC
作られたり、それが大絶賛実装
されていたりするのを見るにつけ、
阿保もここに極まれり....という
お気持ちが強い。


そりゃそうなるの、
分かり切ってるけどさあ....

最初っからトランスで受けるように
しとけよ、このアホンダラｗ、とか

で、16ビットを超えるタイマーイベント、
インプットキャプチャ部門だけど。


これ、まあ。
ペリフェラルの機能として
一つのタイマーのオーバーフローを
別のカウンターの入力クロックに接続、
なんて設定があるので、これを使えば
良さそうなもんだけど。

キャプチャとオーバーフローが
重なったときにそれぞれの
レジスタが、正しい値で
整合しているという保証はない。

内部ロジックで、キャプチャの
ロジックが接続されているわけでなく、
信号をそれぞれのタイマーに
個別に　入力する関係で、
こういうクリティカルパスが
発生する。


まあ、ごくまれにしか発生しないけど、
それゆえ、検出と対策が難しい。

まあ、素直に32ビットタイマ使っとけ、
という案件ではあるのだが....



------

なので、これも、コンペアマッチと
同様にソフトウエアで上位ビットを
あれこれやって、機能を実現してみる。


タイムアウトに使っている
インターバルカウンタの値を、
カウンタの上位データ
（の指標）として使う。


当然、そのまま上位データ
としては使えないので一工夫。

データとして使うのは
あくまでタイマーのキャプチャ
レジスタの値。

------

説明しやすくするために
インプットキャプチャは1MHzで
カウントしていて、タイムアウト用
の別タイマは1msecインターバルで
動いているとしようか。

とあるタイミングでキャプチャされた
値と前回キャプチャされた
値の差がNとなった場合、
この時の真のパルスの間隔は、

N+65536*M(usec)

となる（Mは０～）

値として分かるのはNだけなので、
ここからMを推測する。

ここで、1msecインターバルで
ソフトウエアカウンタを回し、
1msecでのパルス間隔も
（大まかに）計測する。

こっちは、C(msec)としようか。



この２つのデータを合わせ、元のMを計算する。

N + 65536 * M ≒ C * 1000

なので、

M ≒ (C * 1000 - N) / 65536

と変形して、Mの概算値を求める。
計測されたCの値は、正確ではないけれど、
概ね整数値の近くに寄ってくる。

整数計算で四捨五入すれば、Mが求まるので

M = (C*1000 - N + 32768) / 65536

で、Mが確定し、

N + 65536 * M

で目的のインターバル(usec)が求められる。

タイムアウトのインターバルは、
元のクロックやオーバーフローから
一桁くらい離れていれば問題なく
機能するはず。


これで、16ビットタイマーで
長ビットでのインプットキャプチャが
実現できる。

ちょっとややこしいけれど、
この方法を使うようになって、
タイマー周りのクリティカルパスは
大体回避できるようになったと思う。


コード例としては

#define TIMEOUT 1000

unsigned long interval;   //  計測した時間間隔
int timeout;　　　　　　　//　タイムアウトカウンタ


void SysTick_Handler(void){ //　　1msecインターバル

　　if (timeout > 0 ){
　　　　timeout--;
　　　　if (timeout == 0){
　　　　　　interval = 0xffffffff;　　// タイムアウト
　　　　　　}
　　　　}
　　}
}

void TIM2_IRQHandler(void) {　　// ch1でインプットキャプチャ

　　static unsigned short last;
　　unsigned short us;


　　if (TIM2->SR & (1 << 1)) {　　//インプットキャプチャ

　　　　us = TIM2->CCR1;

　　　　if (timeout > 0){
　　　　　　　interval = ( (unsigned long)(32768L + (TIMEOUT - timeout)  * 1000 - ((us - last) & 0xffff) ) & 0xffff0000) + (unsigned long)(us - last);
　　　　}

　　　　last = us;　　　　 //　今回の値を保存
　　　　timeout = TIMEOUT;　　　//　タイムアウト初期化
　　}
}



これもそうだけど、
こういったプログラム、
何をやろうとしているのか、
コードだけから読み取るのは
かなり難しいね...

今度はインプットキャプチャネタ。

入力信号の周波数を計測するのに、
実際のパルスの数をカウントして、
1秒ごとに集計する、ってのは、まあ
原理に沿っているのだけれど、
一秒間待たないとデータが更新できない
とか、1Hz以下の信号が計測できないとか、
数百Hz以上のオーダーにならないと、
あんまり使い勝手の良いものではない。

------

なので、現実的な実装は、
外部からの入力パルスのエッジで
イベントを起こして、パルスの間隔を計測。

これをもとに信号の周波数を計測するって
方法を使うんだけど。

これをやるときに必要な技が存在する。


計測値が更新されるのは、
パルスが入力された時なので、
逆にパルスの入力が途絶えると
値の更新が止まる。

つまり、そのままでは
0Hzが計測できない


まあ、0Hz見なくてよければ
そのままでいいけど、たいていの場合、
ある程度の時間監視して
パルスが止まっているのも検出したい。

あと、入力パルス間隔が広くなって、
タイマーがオーバーフローすると
正しい時間間隔が計測できないので、
これも対策しないとマズい。


ただ、これを実装するのに、
当該のタイマー自身のオーバーフロー
イベントを使うと、
前述のコンペアマッチと
同じような理由で、作動が怪しく
なるタイミングが出来てしまう。


なので、ちょっと煩雑だけど
別のインターバル割り込みをを使って、
インプットキャプチャで計測できる
（カウンターが前回の値に到達しない）
時間の範囲を大まかに測って
タイムアウト処理をする。


よくやるのは、16ビットインプット
キャプチャを、1MHzでカウント。

別途1msec毎割り込みを使い、
入力の間隔が64msecを超えたら、
(65.535msecがデッドライン)
計測オーバーフローにする。
なんて組み合わせとか。



全体としてはこんな感じ


unsigned short interval;   //  計測した時間間隔
int timeout;　　　　　　　//　タイムアウトカウンタ


void SysTick_Handler(void){ //　　1msecインターバル

　　if (timeout > 0 ){
　　　　timeout--;
　　　　if (timeout == 0){
　　　　　　interval = 0xffff;　　// タイムアウト
　　　　　　}
　　　　}
　　}
}

void TIM2_IRQHandler(void) {　　// ch1でインプットキャプチャ

　　static unsigned short last;
　　unsigned short us;


　　if (TIM2->SR & (1 << 1)) {　　//インプットキャプチャ

　　　　us = TIM2->CCR1;

　　　　if (timeout > 0){
　　　　　　interval = us - last;　　//　前回との差を時間間隔とする
　　　　}
　　　　last = us;　　　　 //　今回の値を保存
　　　　timeout = 64;　　　//　タイムアウト初期化

　　}
}



今回もARRは0xffffとして、
カウンター自体は0~0xffffの
フリーランカウンタとする。

こうしておけば、ch0~3で別々の
パルスを計測できるし、
なんなら、別のチャンネルは
コンペアマッチでパルス生成に
使ってもいい

これを使うと、入力パルスに
位相を合わせた、パルスが出力できたり、
簡単な逓倍波形を出力できたりする。



つづく

動的にコンペアマッチの値を操作することで、
いろいろ柔軟なことができるネタ。

固定の定数では割り切れない分周比でも
有理数で表すことのできる分周比なら
ソフトウエアで実現できる。


サンプルコード

void TIM2_IRQHandler(void) {
　　static int rot = 0;

　　if (TIM2->SR & (1 << 1)) {
　　　　TIM2->SR = ~(1 << 1);

　　　　rot++;
　　　　if (rot > 2){
　　　　　　rot = 0;
　　　　　　TIM2->CCR1 += 3334;
　　　　}
　　　　else {
　　　　　　TIM2->CCR1 += 3333;
　　　　}
　　}
}

なんてやると、例えば10MHzのベースクロックから、
”正確な” 3KHz インターバルが生成できたりする。
（デジタル処理由来のジッタはあるが、
トータルでは正確なタイミングになる。）

上の例では、インターバル周期3333.3333 ..... となる。




例えば、最近ではあまり見ないけど、
ビデオ信号のカラーバーストの4fc、
14.31818MHzから、正確な1msec
インターバルを作ったりできる。

つづく

自分もそこまでUSBと付き合ってる
わけじゃないのだけど。
まあ、いくつかあって。

まず、D+、D-、どっちか片っぽだけ
電源にプルアップされてるんだよね....

まあ、インピーダンス的には
一桁以上大きいから、
まあ気にスンナ、といえばそうなんだど。

伸ばせる距離5m、なんてもの、
まあそうなるわな、という印象。
動作のボトムは、みんな大好き
I2Cと同じレベルなんだよな。

------

あと、もうひとつ、
こっちもペリフェラルいじるレベルでは、
まず気づかないと思うけど。

各パケットの最後にEOPなんてものが
あって、これのおかげで、
信号がGNDと分離できないじゃん！
これじゃ絶縁USBなんてものも、
作れないじゃん！
となっている。

昔々、試作機器のusbが外部ノイズで
落ちまくるので、対策しようとして
ひっくり返った....
きっぱりUSBを捨て、Etherへの移行を
誓った瞬間だった。

------

差動っぽいけど差動じゃない、て通信規格。

コストとか色々事情はあるんだろうけど、
差動として扱うと、きつい地雷になるよ？
ってのは、明記してほしいものだ。

16ビットを超える処理は32ビットタイマーを使え、って
ことでもあるけれど。実際stm32あたりでも、32ビットまで
実装されているタイマーは限られている。

まあ、lpcみたいにどれもこれも32ビットタイマー、
なんて実装のもあるし。
チップの設計思想なんだろけどね.....

stm32に関しては、沢山タイマーがあっても、そのうち
32ビット実装は1～2個なので、st的にはタイマーの
物理カウンタは16ビットあれば十分でしょ？と言いたいのか。
それ以上の事は、ソフトウエアでどうにでもなるよね？って
メッセージの気もする。。

まあ....まあ、そうなんだけど。

-------

ざっくり、だいたい動く（ときどきおかしい値が出る）んなら
簡単にコーディングできるけど、
ちゃんと動かすには、かなり考えないと出来ないよね....

適当な実装で、ときどきズッコケるタイマー処理コード
に付き合うことになると、流石にメンタル削れたりもするけどね。

現実的に、普通は16ビットの範囲で処理できるように、
プリスケーラーで動作クロックを落として、
タイマーレジスタを素直に設定できる範囲に
持ってきて処理をする。

原理的に時間分解能は下がってしまうが、その辺はさじ加減。

例えば、連続的に1Hz～20KHzとかの矩形波を作ろうとすると、
ソフトウエア処理は十分できても、タイマーの
分解能の限界が先に来て、
1Hzを設定値0xffffまででカバーできるように設定すると、
20KHz付近では設定できる周波数が、非常にとびとびになる。
このあたりで考えると、実質28ビットくらいは欲しい処。

では、と、プリスケーラ―の値を動的に書き換えると、
その瞬間に、一発だけ変な周期の割込みが発生したりとか、
これまた　上記の”まあ、だいたい動く” 一例となる。

これでもいいですよね？とねじ込む技術（キレたり、ゴネたりとか）
の方がお手軽ではあるのだが....

諸々コストを考えると、ねじ込む技術も大いにアリだけど、
ねじ込むばかりだと、段々行き詰っていくのも確か。

------

16ビットタイマーがオーバーフローするのを
ソフトウエアでカウントして、目的のタイミングだけで、
処理を回すようにするとよいのだが。

#define TIMERCONST 200000;

static unsigned long buff = TIMERCONST;

void TIM2_IRQHandler(void) {

　　if (TIM2->SR & (1 << 1)) {
　　　　TIM2->SR = ~(1 << 1);

　　　　if (buff == 0){
　　　　　　buff = TIMERCONST;
　　　　　　// ここでインターバル処理など
　　　　}

　　　　if (buff > 0x10000){
　　　　　　buff -= 0x10000;
　　　　　　// ここでタイマー出力禁止（コンペアマッチで出力をする場合）
　　　　}
　　　　else {
　　　　　　TIM2->CCR1 += buff;
　　　　　　buff = 0;
　　　　　　// ここでタイマー出力許可（コンペアマッチで出力をする場合）
　　　　}
　　}
}

とまあ、こんな感じで記述すると、16ビットを超える
タイマー定数でのインターバル処理を実現できる。

この記述にも問題があって、buff値が
非常に小さくなると、CCR1の更新が間に合わなくなり、
カウンタ１ループ分、処理が遅れるタイミングが
できてくる。
（例えば初期値0x20001とか）

これはハードウエアの割込み処理応答に起因するので、
このままでは回避できず、処理間隔として上手く動かない
値が存在しているということになる。

簡単にソフトウエアで処理するとすれば、
この付近の値が設定されないように
事前にチェックし、近くて安全な値に変更する、
などが考えられる。

割込み応答や、優先順位の高い処理がどの程度あるか
によって、うまく動かない定数の範囲が変わっていくのだけど
DMAなんかも動かしているようなシステムだと、
どの程度まで余裕を見ればいいかの判断が難しい。

絶対安全、だからと言って、ハードウエアで
動かしているタイマーが数msecもズレる
ようだと、流石に意味をなさない。

長周期で動かしているインターバル処理を
成立させるために、
許容できる応答時間が非常に短いとか、
システムとしてはかなりダメな気がする。


------


なので、もう一工夫して、

TIM2->CCR1 += buff;　

のbuffの値が小さくならないような処理を追加する。

void TIM2_IRQHandler(void) {

　　if (TIM2->SR & (1 << 1)) {
　　　　TIM2->SR = ~(1 << 1);

　　　　if (buff == 0){
　　　　　　buff = TIMERCONST;
　　　　　　// ここでインターバル処理など
　　　　}

　　　　if (buff > 0x10000){
　　　　　　if (buff < 0x20000){
　　　　　　　　buff -= (buff / 2);
　　　　　　　　TIM2->CCR1 += buff;
　　　　　　}
　　　　　　else {
　　　　　　　　buff -= 0x10000;
　　　　　　}
　　　　　　// ここでタイマー出力禁止（コンペアマッチで出力をする場合）
　　　　}
　　　　else {
　　　　　　TIM2->CCR1 += buff;
　　　　　　buff = 0;
　　　　　　// ここでタイマー出力許可（コンペアマッチで出力をする場合）
　　　　}
　　}
}

こんな感じにして、最後の引き算の結果が
小さくなりすぎないようにしてやる。

これで、タイマーが誤作動するような危険なタイミングを回避しつつ
必要な割り込み処理の応答も、シビアではなくなる。
（割込み処理の間隔が、0x10000以上から始めた場合、
0x7fff以下にはならない）

この記述で、めでたく16ビットタイマーで、
16ビット超のイベント間隔と時間分解能を両立できる。

つづく

USBのD+とD-、差動信号と思ってる？
違うんだな....これが。

これのおかげで、USB、もろもろ
電気的対策できないんだよ....
コモンモードノイズ対策なんかしたら、
全く通信できないよ？

まあコスト優先の規格だ（った）から
仕方ないんだろうけどね

人生なんて、過ぎちゃえば、あっという間だよ？


実際やってみたけど....保証するよ。

CPUはSTM32にて。
他のプロセッサでも、まあ大体同じ。

ある間隔で処理をしたいときなんかに、
タイマーを使ってイベント（割り込み）にて
処理を起動するんだけど。

一定間隔だったら、systickなんかを使って、
定数でカウンタをリセットして、
そのタイミングでイベント起動する。
通常のタイマーだと、ARRを使う。

普通のタイマーだと、イベントと同時に
信号出力もできる。
これを使うと正確な矩形波信号が作れたりする。

------

でもこのやり方だと、一つの信号を作るのに、
一つのタイマーを占有してしまう。

stm32と言えども、そこまでたくさん
タイマーがあるわけではないので
別の方法を使わないと、タイマーが
足りなくなる。

そこで、一つのタイマーに複数付いている
CCRを使って、それぞれ独立した間隔での
イベントを発生させる。

------

まずカウンタのARRは0xffffにして、
フリーランカウンタとする。

タイマー割り込みは、ARRだと更新イベントだけど
CRRxなので、コンペアマッチになる。

CCRの割り込みハンドラ内で、
自身のCCRの値に必要な（欲しい時間間隔の）
定数を足していく。

次の割り込み時刻を自分で更新していく感じ。


void TIM2_IRQHandler(void) {

　　if (TIM2->SR & (1 << 1)) { // CH1
　　　　TIM2->CCR1 += 10000;

　　　　TIM2->SR = (1 << 1);
　　}
}


こんな感じ。これで、CCR１～４までで
別々の周期や位相のずれた波形が作れるようになる。

足していく値を定数でなく、変数とすると
周波数を連続的に変えたりもできる。

------

当然そのままだと、設定できるのはカウンタが
一周する時間の間だけに制限される。

そういう場合は別の方法を考える。

つづく

公私とも、日々ワンチップマイコンと
付き合っているのだけれど。

ワンチップマイコンを使う、と言った場合、
大体、コアのアーキテクチャがどうの、なんて
ことはあまり重要ではなくて。
周辺機能。ペリフェラルをどう使うか？
ってことに集約されることが多い気がする。

で、日々、色々なペリフェラルを
使っているのだけど。
その中で一つ特筆するとすれば、
タイマーかな、と思う。

------

タイマー、
PWM波形出力だの、インターバル
タイマー割り込みなんかで
よく使われるんだけど。

その為だけにしては、やたらと
機能、設定が多い気がしてこないか？

実は、設定次第でかなりの処理？が出来るように
設計されていて、つらつらと考えていると
たまに新しい使い方を思いついたりして、
これはなかなか楽しい。


いくつかタイマー芸みたいなものがあるので、
簡単なもの含めて、つらつら
書いてみようかと思う。

まあ、芸と言えるほど志が高くないので、
実用性が有ったり無かったりするのだが....

芸というからには、実用性があるのは
ちょっとダメな気もするｗ


つづく

今どきのブリッジ構造のモータードライバを
色々試している。

おなじみTIの、DRV8xxx～あたりなんだけど。
以前よく使っていたころの、
DRV88xxあたりだと、
まあ使えるんだけど、いまいち
微妙だな....なんていう感じだったけど。

DRV8912、DRV8908なんて、
これ、なかなかいいな。
DRV8932なんてのも
良い感じだ。
最近のDRV89xxのあたり、
よくできてるなあ....

非常に機能豊富で、
機能のレイアウトも、痒い所に
手が届く感じで実にいい。
こういうのが、欲しかったんだよな
感がある。

------

でもこれ、自動車用に振ってあるっぽいな。
保護機能とかが、電源電圧12V/24Vを
想定しているな。
まあ、それならそれで
構わないけど....

でも、あまりにも便利すぎて、
これで製品作ってて、
ディスコン食らったら、
即死モードだな...

休みではあるのだけど、
近場以外にあちこち
出かけるわけにも行かず。
結局、色々調べ物を
したりするのだけど。

通信規格など諸々、
ちょっと分野が違うと、全然
知らなかったりするものが
あるんだな....と今更
気づいたり。

色々勉強している。

単体でグダグダに
見えている物。
やっぱりこういう
上位？規格が使われて
いるんだね....

まあ、これで万事解決、
ってことは無いんだけど、
うっかりミスで大惨事
とかの危ない所は、
それなりに回避できそうに
思えたりする。

どこまで行っても、
勉強する物は尽きないね....