R&D daily

えー、CANなんて使ってるの？

CANて、スペックはいいことばっかりだけど、
実際に難しい環境で使うと、
全然ダメっていう印象なんだけど。

クロックの品質で謎のバスエラーなんて
割と定番だ。（スペックは守っていてもね！）

なんだよ、CAN BUSってエラーに
強いんじゃないのかよ！
と叫んだことは数知れず。

------

CANバスの通信エラー って、
組み込み系の、どうにもならないもの
（本質的に対策できないもの）
ランキングのかなり上位だと思っている。
（その次辺りにI2Cがくる）

いったん止まると、復旧のために
全ノードのリセットが必要だったり、
（動作状態で、原因が特定できない。
動き続けている！ノードが原因を
作っていたりする）

なんか止まったときは
近くにいる人（運転手とか）
に電源スイッチ、入れなおしてみて！
って頼めるくらいな
ところで使う印象。

絶対に止めたくない物には
使わない覚悟で臨んでるけど。

------

現実には使わざるを得ない状況
もあるので（確率的に）トラブルを
回避するために、
CAN BUSの規約にはない、
経験則からの、かなりきつい
設計ルールが有ったりする。

例えば、1:1しか使っちゃダメとか。
その結果、各ユニットが
ものすごい数のCANポート持って
個別のケーブルで繋がってたりする。
（これ通信にせず直接、信号
乗せた方が...？とか）
こんな（アホな）ものが設計
推奨されるくらいだから、
みんな苦労してるのは
間違いないんだけど。

確かに、机上でちょっと試す分には
無理させても動くように
見えたりするのが、またなんとも．．．

------

あとね、障碍時の原因特定が
すごく難しいのもCANの特長かな。

プロトコルの構造にも起因するから
根本的に回避できない。

誰かがヘマこくと、全然関係ない
ノードが突然落ちたりする。
現象から原因を特定するのは
ほぼ不可能。

------

でね....原因特定、対策できた、と思うでしょ...
実は、問題が他に行ってるだけでさ
（注目してないから別レイヤの問題に気づかない）

とかの怖い話ネタもいくつもあるしね。


”精度のいいオシレーター”も、
本当に使う環境で精度を保ってるか
ちゃんと試験した方がいいと思うよ。

発振器もすごく奥が深い。



まったく、CANなんてもんが無かったら、
もうちょっと仕事楽なんだけどなあ。

多分、ロケットも落ちなかったと
思うよ。（無責任な同情）