C.A.Mのブログ一覧

モーモニM5が動いたので、
CANモジュールを準備。
既製品はアイソレートされていたりして高級そうなんですが、


単純にCANトランシーバと3.3Vレギュレータのみでいいかな。


PROTOというモジュール基板に収めました。


動作オッケー。
すっきりした♪


ブレッドボードご苦労様。




おまけ_______

最近は乗る回数より充電する回数の方が多いようなのに
充電器故障。。。。

AC100VーDC19V　1.6A スイッチング電源がダメ？

プラの円筒形のヒューズがとんでました。
ここを短絡してみたらトランジスタ？FET？から火吹きました。
ご臨終。

なので、
ここに

秋月19V3.15A ACアダプターを入れます。


電線の取り回しがよくないので分解、付け替え。

入りました。


充電テスト。
オッケーみたいです。

電源の出力電流値が大きくなったので、充電回路の定数調整して能力上げようか？
現在、充電電流最大2A弱みたいです。

このNJM723って、なかなか難しかったような。。。

一息ついたら、思いついたので忘れないうちに。








通信の受信は相手次第でいつ入ってくるのかわからない。
数値の表示は各項目毎に更新周期を調整した方が処理落ちを防げる。

なので、
受信と表示を分けます。
どちらかをメインループで、他を割り込みでやるように考えます。
BlocklyではCAN受信割り込みは無いみたいなので、、、、
表示をタイマー割り込みでやることにします。
とすると受信をメインループでやることになります。

setup〜メインループ

受信メッセージのうちのデータの部分8バイトは
8文字分の文字列（canMessage[3])なので、
ID数分（今回は1600〜1607なので8個）を並べたリスト(canData)とします。

受信したら該当部分(canData[x] x：0~7はcanID：1600〜1607と対)の文字列を
最新の受信データに書き換えるという処理をメインループで行います。

少し余力があるようだったので、メッセージの受信ステータスの表示処理など追加してみました。



2秒受信がないとNo message表示となります。

2バイトデータから16ビットデータを計算するサブルーチンは、IDとデータ番号（1〜4）を渡し、16ビットのデータが戻ります。
（前回のものにIDが加わりました）


表示ルーチンは0.1秒ごとにタイマーで呼び出されます。
n（0〜9）のカウンタ値によって、表示する項目を選びます。


一回の呼び出しで2〜3項目の表示に抑えました。
（計算中の％は割り算の余り。）


Pythonでの表示





モーモニCAN（PIC）のときは、受信を割り込みでやって、表示をメインループでやった気がする。。。
その前のモーモニ（無印、シリアル通信）の時はシリアルのデータが遅いから読み取りに時間がかかってしまうため、通信と通信の隙間で表示をする、みたいなアルゴリズムだったような。

ハードの仕様に合わせてソフトを考えていかないといけないのでおもしろいんです。


ここ2〜3日、ツイッターのようなブログになってしまっていて申し訳ないです🙇‍♂️

昨夜のプログラムで動作は良いようなので、
表示更新周期を調整して、とりあえずの処理落ち回避しました。

更新早いものも5Hz程度に抑えて、
排気温度はちょっと早めな3Hz程度。
他温度は1Hzほどに。


nに1たす は変数の方のを使うと、テキストか数値かの判定コードが入る(前回ブログの80行目)ようなので、
数学の方を使ったところ、シンプルにn=n+1のコードが生成されました。(↑画像の79行目)

プログラム書く時はBlocklyは手間がかかるのですけど、
読む時はpythonコードよりもBlocklyの方がずっと見やすいみたいですね😀

Blocklyで書いたものは、pythonのコードで見ることもできます。

pythonは去年の夏頃からやってたので、こっちの方がピンとくる。
python見ながらブロック修正している感じ😅
変数や数式のとこはブロックのほうがかえってわずらわしく感じます。

Blocklyのメリットは画面への表示が簡単なところですね。←これ大事

モーテックからのデータストリームは20Hzじゃなくて33Hzでした。










nのカウントを0〜32として、ID1600受信の時に＋1することにしました。
rpmやMAPの更新も4回に一回くらいにまでおとしました。
それでも8Hzくらいなので十分はやいです。



ほかには、2バイトデータの16ビットへの計算をサブルーチン化。
データの読み取り方法を簡略化しました。

CANの受信バッファは64バイトしかないようです。4メッセージ分くらい。
表示がたくさんあるとバッファフルで後半のCANデータを取りこぼしてしまうようで、後ろの方のIDのデータの更新がされていないようでした。
ID1600にrpmやMAPの更新が速いデータがあるためかな？

表示の負荷を減らすことでデータの読み取りに支障が無くなってよくなったようです。




よいみたいです♪
（まだExGTの更新は遅れてるような。。。）


なかなか手間取っています。。。