C.A.Mのブログ一覧

けっこういろいろ作った気がするのですが、
ほとんど1対1通信、
送信のみとか、受信のみとか
だったので、
いろんなところが
わかってません。





まず疑問1、
現状、MoTeCからID0x640〜647で送信したメッセージを
モーモニで受信して、
データをあれこれ表示させています。

ここに、
今作っているフューエルミクスチャコレクションを追加でつないで
同じID0x640〜647のメッセージを受信させたら、
メッセージの取り合いになったりしないの？

答え1、
大丈夫でした。
CANのメッセージはID(宛先番号)がついていて、
目的の相手に向かって送信はされるのですが、
受け取る側は、とりあえずID関係なしに全てのメッセージの受信をして、
ACK(受け取り応答)を出すようです。
受け取ってからIDをフィルタにかけて、
自分に必要なメッセージだけを
バッファに格納して選別しているようです。


なので、
送信側はACKを確認することで、誰かが受信したということしかわかりません。
目的の相手に届いたかどうかはわからないんですね。
受け取り手が一つもいなかった場合には、ACKが立たず応答無しということで、
ACKが立つまで同じメッセージを繰り返し送信する仕様のようです。

そんなふうなので、同じIDデータを必要とする受信機が複数あっても
全部の機器が同じメッセージを受信することができるので大丈夫です。

追記－－－－－－－
ACK(受け取り応答)は送信側がローにて送っている信号自体に
受信側がハイを重ねてくるような仕様なので、
複数の受信機が同時に応答してきても
ハイはハイ以上にはならないのでオッケーと言うことみたいです。

リスンオンリーモードというのは、ACK(受け取り応答)をしないので、
もし、このモードの機器だけしかCANバス上にいなかった場合には、
送信した側は受け取り応答無しということで、メッセージを再送することになります。
いままでCANバスモニターをリスンオンリーモードで使っていましたが、
ノーマルモードで良さそうです。→ 未検証。
ー－－－－－－－

ということで、
MoTeCからは今までと同じようにモーモニ用のデータメッセージを出せばよく、
モーモニもフューエルミクスチャコレクション(仮称)も2つともに
データを受け取ることができます。
(アクセル開度変化分とフューエルベースPWのパラメータの2つを追加しましたけど)






疑問2、
pic32mzでメッセージ受信の割り込みが働きません。

答え2、
今までの8ビットマイコンのCANモジュールでは、
受信用に1〜2つのバッファがあって、
バッファにメッセージが入ると、割り込みが発生していました。


32ビットマイコンのCANモジュールでは、
まず、
C1INTレジスタのRBIE=受信バッファ割込を有効にしますが、

これだけでは、割り込みが発生しませんでした。

受信バッファは32ケのFIFO = First In First Out (先き入れ　先き出し)バッファを設定できるため、それぞれのFIFOバッファ番号ごとに割込有効の設定をしないといけません。
今回のものではFIFO1を受信バッファに設定しているので、
C1FIFOINT1レジスタの設定をします。

受信バッファが空ではなくなった割込(=受信バッファに何か入った割込)=>RXNEMPTYIEを有効にします。

これで、
CAN1のRBIFの割り込みが働くようになり、
メッセージを受信したら即優先して、データ用変数に代入しておくという処理ができるようになりました。


また、ハーモニーで初期設定を行なうと、
割り込みを有効にする設定はされないようなので、
(マルチタスク推奨のためかな？)
IECレジスタを設定して、割り込みを有効にしました。

IEC4レジスタのを1にします。
コードではIEC4bits.CAN1IE = 1;

こんな感じに設定して、やっと割り込みが有効になりました。

途中、
ハードの故障で、デバッガでは動作オッケーなのに、
プログラム書き込むと起動しなくなるとか 妙な現象があったりで、
何週もかかりましたよ😔

追記ーーーーーーーー
MCLRピンを壊してしまったようでした。
起動しないのは、MCLRピンがプルアップしているにも関わらず0Vになってしまっていました。
静電気とか過電圧とかが原因のようですが、特定できていないので、ちょっと心配。

なぜかpickit4のデバッグモードでは、2.4Vになっていました。
本来は3.3vのはずなので、ちょっと低いんですが、リセットはかからないようで、動いたみたいです。
pickit3では、まったく接続すらできませんでした。

pickit4はPICが壊れててもデバッグできるなんて、
スゴイのか？マギラワシイのか？
サイシンガサイコートーゼンデショ？

世の中というのはよくわからんものです。







トップ画像は、
表示数値が合っているのかを確認するため、
GoProでLCDモニターを撮影している様子です。



帰ってきてからお部屋でMoTeCのログと比べています。

新参パラメータ、アクセル開度変化分は瞬く間に変化するので、
こういう方法をとりました。

8ビットも32ビットもおんなじ　なんて言ってる矢先に
罠にかかりまくりです😭



CANからのデータの読み込みをやってたのですが。。。

受信したらC1FIFOUA1で示されるアドレス0x00000c50のメモリから読み出すということなので、該当収納先を見てみると

たしかにデータメモリ上にデータが入っているのが見えますけど、
なぜかうまく変数に読み出しできません😧

まぁ、ポインタとかいまいちよくわかっていないので、
その辺を勉強しなおしながら頑張ったのですが？？？？
できません。



この自動翻訳風な日本語をなんとかかんとか解釈しても、？？

どうやら、
そのままのアドレスでは該当メモリへはアクセスできないようで、
PA_TO_KVA1()とかいう関数で、物理アドレス？に変換してやらないとイケナイようです。
まぁ、これはこのPICマイコンのメモリの仕様の話かな。

追記＊＊＊＊＊＊＊＊＊＊＊＊＊
0x00000c50が物理アドレスで、
0xa0000c50が仮想アドレス？みたいです。
プログラムから見る時は仮想アドレスを使うみたい？？
マルチタスク用にアドレスの設定が8ビットのとは違っているみたい。
アタマが時代遅れになってます😅
＊＊＊＊＊＊＊＊＊＊＊＊＊



無事に変数に代入できるようになったのですが、
なんだかデータの並びがムチャクチャです。
これまた、ポインタとか、変数の型(データ長)だとか、
いろいろややこしくて？？？だったのですが、

これはどうやら32ビットの罠でした。

今までは8ビットマイコンだったので最小単位的な1バイトで考えればよかったのですが、32ビットマイコンでは4バイトを一度に扱えます。

なので、
変数に0x11223344と代入したときは、
メモリ上には　0x44 0x33 0x22 0x11と逆順に並んでいるのですね。

CAN IDデータの00000641のところASCIIでは"A．．．．．．．"です。
4番目のバイト0x41が、メモリ上では先頭バイト"A”となっています。
そんななので、32ビットいっぺんに読み出すとCANメッセージのデータバイト順が3210、7654になっちゃうんですね、納得。


つづいて、
CAN ID 0x640から0x647までの8メッセージを受信するために
フィルタを0x640に設定し、
マスクを0b11111111000として、下位3ビットをフリーにします。

いままでの8ビットマイコンでは、
たしかスタンダードID（11ビット）と拡張ID（29ビット）では設定が分かれていたような気がして、拡張IDを意識しなくてもよかったはず。

でも、今度のは32ビットのせいなのか、標準IDが拡張IDの一部のような位置付け？
拡張IDの方が基準みたいな感じになってる。


なので
スタンダードsIDのマスク=0x7F8の後ろに
拡張eID18ビット分のマスク=0x3FFFFをつないで、
29ビットの数字
0b111 1111 1000 11 1111 1111 1111 1111
= 0b1 1111 1110 0011 1111 1111 1111 1111 (区切りを整理)
= 0x1FE3FFFF (16進数に変換)
をハーモニーの設定欄に書き込んで、

オッケーです。
sIDのところに必要なマスクの数字が入りました♪

追記ーーーーーーーーーーーーーーーーーーー
もしかしたらeIDの18bit分のところは0にしておいた方がいいかもしれません。
拡張🆔混在ってのは試してないのでわかりませんが。
ーーーーーーーーーーーーーーーーーーーーー



sID 640〜647のメッセージだけが読み取れています。


これで、やっと思ったようにMoTeCのCAN custom data set 1の
32項目の16ビットデータを読み込むことができました。

とりあえず、リアルタイムミクスチャフューエルマップコレクションに
必要となるデータをLCDに表示させてみました。


まだ　アタマがこんがらがってるので、
とりあえずはここまで。

PICマイコンの初期設定ソフト、
8ビットのMCC(Microchip Code Configurator)に相当するものが
32ビットのでは、MPLAB Harmony V3。
これがけっこうクセモノで、
SPI通信のカラーグラフィックLCDを使おう　と言われるがままに、していくと

周辺モジュールやらライブラリ、ドライバーてんこ盛り😓
んで、使い方のコードの書き方ややこしすぎてわからないので、
コンパイルするとエラーの山。
まったく使える気がしない😵

RTOSってなんですか？
と調べてみると
Real Time OSとある。
OS Operating Systemなんですね。

32ビットともなると、いろんなことを同時並行処理的にしたくなるので、
マルチタスクのためにオーエスを使うということみたいです。

そんなのパソコンじゃないか😤
そういう重たいややこしいのがイヤだからシンプルなマイコン使いたいのに😑

なので、ハーモニーはほとんど無視して、

8ビットの時と同じようにシンプルに自前のコードを書けば、


できました♪
速っ、さすが32ビット。描写10倍くらい速いかも。


8ビットだろうが32ビットだろうが、
CコンパイラはCコンパイラなんだから
同じに書けば同じに動く道理なわけで😀

ただ設定に使う、周辺モジュールのレジスタ名とかは
いちいち違っているので、データシートを見て翻訳しなくてはいけません。

何とかなりそうに思えてきましたよ。

試運転。



近所をひとまわり。



ノックセンサーの出力が大きすぎたよう。

ノックモジュールのゲインを下げて、最大値を60％くらいにしなくては。



今回からモーテックでログ採りながらパソコンへノックセンサー出力を録音できるようにしたので、2つを比較。


1分20秒あたりのspectrogram。


1分35秒あたりのスペクトログラム。


どちらもバックグラウンドノイズが強いせいなのか、
ノックしてないからなのか、
8.5kHz付近にあるはずのノック信号は見つかりません。
2倍音の17kHzにも高いレベルの音は無いみたい。


絶対ノックしないような点火進角を思いっきり遅らせたセットを作って、
それで高回転まで回してみて、バックグランドノイズを測ったらいいかな？
今のセットだとビミョーにノック出てる気もするので。。。

8ビットから一気に32ビットへ。

（16ビットはとばしました）










PIC32MZ2048EFH064

Lチカ＆printfできました♪


ちっさいパッケージの64ピンのICなんですが、
ブレッドボードに合わせようとしたら

こんなにデカくなってしまいました。

右側のDIP28ピン8ビットのほうがずっとコンパクトに使える。


変換基盤の裏側は、

このとおり😆
ぐちゃぐちゃです。

最初はトップ画像のお絵描きソフトのようにやり始めたのですが、
無理。

ポリウレタン線を

ソケット裏側に立ててハンダ付けして、
ブレッドボードに差すピンヘッダまで取り回しました。
開発テスト用なので、これでもいいかと思うんですが、
もし何かに作ろうと思ったときにはどうやればいいんだろう？？？


8ビットでのMCCに相当する初期設定ソフト、Harmonyが、なんのことやらさっぱりわからずで苦戦してます。
慣れないコンピュータの画面ってホントどうやったらいいのかトッツキが悪いですよね😔