CAN ネットワークに複数モジュールを入れてミッションコントロールを繋いだところミッションコントロールからのメッセージを取りこぼすモジュールが出始めました。調査したところ、モジュールの CAN メッセージ処理が追い付いておらず、では FIFO を伸ばしたら？ということで調べたら、使っている STM32C0 シリーズについている FDCAN では FIFO 長は3と固定であることがわかりました。ここが前回まで
これは深刻、STM32C0 を使うのは無理かな？と思ったのですが、まずは慌てず、今ネットワークに何が繋がっていてどういう状況か整理してみました
- ミッションコントロール：MCP2518FD で実装 – 取りこぼさない。サインイン時に立て続けにメッセージを送る
- MIDI/CV – PSoC5 で実装 – 時々取りこぼす
- VCA – STM32C092KB で実装 – 頻繁に取りこぼす
- EG – STM32C092KB で試作中 – まだ軽いせいか取りこぼさない
ということで、落ち着いて考えてみると問題は STM32 だけではなくPSoC 側にもあり、そちらも調査しました。一号機の MIDI/CV には以下のように多数のコンポーネントが入っていますが
CAN は今までは問題なく動いていたので設定はほぼ PSoC Creator にお任せで詳細は確認していませんでした。とりあえず FIFO の設定を変えたいんだけど、見つかりません。一番近かったのが以下のメイルボックスという概念ですけれども
データシートを読んだり AI に聞いたりメイルボックスの設定を変えたりしてわかったのは、1メイルボックスには1フレーム分の CAN メッセージのみが格納されるのでメイルボックスは FIFO ではないこと。データシートには「複数メイルボックスをつなぐ linking 機能は疑似FIFO」と書いてありますがかなり異なるもので、どちらかというと複数CANフレームで1メッセージを成すような用途で威力を発揮する仕組みであること、などです。説明が長いですけど要は PSoC で CAN Rx の FIFO を構築する方法は見つかりませんでした。STM32 がダメなら PSoC か？と思ってましたが CAN 内蔵という点では PSoC の方が問題が大きいです。
ここ数日じたばたしてわかってきたのが、メッセージの取りこぼしはどうしても起きる。リアルタイム性よりも通信の確実性が重要だったらデータを送ったら受信側から ACK をもらい ACK が来なければ再送が必要だということ。これ TCP の基本原理ですね。いやはや CAN ってイーサネットとほんと似てるよなとよく思うのですが、ますます似てきました。今やっている開発はプロトコルの再発明みたいな感じですが 1 Mbit/s 程度の通信速度で安定性を確保するためにひいひい言ってます。イーサネットはその 1000 倍の桁の速さでやっているわけですから、デバイスが高くなっても仕方ないよな、とは思います。でも値段は 1000 倍までは行かない(それが驚異的)。Analog3 プロジェクト、ここまで CAN に手間かけて、でも結局イーサネットが良いという結論になる可能性も無きにしもあらずです。
話が脱線してしまいましたが、ここから先進むには方針を選ばないといけません
- メッセージの取りこぼし絶対ダメ、処理が追い付かなければ FIFO を長くする -> 外付け CAN コントローラ
- メッセージの取りこぼしダメ、処理が追い付かなければもっと処理を速くする
- メッセージを取りこぼすなら再送すればいいじゃない
- そもそも FIFO にメッセージがたまるほど情報を突っ込むなよ
と、リストしてみたら選ぶというより全部やれば良い感じです。決断は外付け CAN コントローラを使うかどうかだけみたいです。
あ、でも PSoC の CAN コンポーネントはちょっと厳しいかもしれません。それを使うには送信側の協力も必要で Analog3 のように誰が何をするかわからないネットワークには向いていません。通信のバーストを避けるのが困難だからです。今は、取りこぼしは起きていますがデータ再送のため通信は機能していますけれども。どうせ取りこぼしても重要な情報は再送されるから良い。リアルタイム性が要るときに受信側が追いつけないほどメッセージを押し込んではいかんでしょう、と割り切って FIFO を持たない、という選択肢も Analog3 ではアリかもしれないですけれども。
STM32 の CAN を使えるようにするために何をしているのか記事にしようと思ったのですが前置きだけでこんなに長くなってしまったのでまた後日。
