C.A.Mのブログ一覧

いまさらなんですが、
お家の中でばっかり使っていたので、
お外でどのくらい届くのかを確かめていませんでした。








stack M5でやってみます。


送信側


受信側

送信側から3秒ごとに送信回数を送信。
受信側は受信した送信回数を返信。
送信側は返信を受けたら、音を鳴らして、表示。
正常受け取り回数をカウント。


受信側を

脚立に固定。

送信しながら小路を歩く。

30mくらいまでは、安定。

40mくらいで一度返信来なくなったので、止まって受信機の方へ向くと
再受信。安定。


裏通りを渡って70〜80m。
見通せていればOKのよう。
遮蔽物が入るとダメっぽい。




帰還。

送信55回に対して、正常に返信を受けた回数が49回。
みとおし距離では80mでもオッケーでした。



stack M5とESP32WROOMではアンテナ形状が違うけど、どうなんだろ？

やっぱりまだよくわかっていなかった！

関数にポインタ渡しをする時にキャストしてやれば良い、
という超シンプル。


floatで宣言したtmp[0]〜tmp[2]に浮動小数点数値が3つ入っているのを
関数サブルーチンに渡す際に（uint8_t*）つまり1バイトの配列として渡します。
配列を渡すというのは収納先頭アドレスを知らせるだけなので、渡す時に型を指定してやればよいみたいです。
関数サブルーチンでは、uint8_t*と1バイト配列として受け取るので、
1バイトデータとして扱えるようになっています。
I2C通信で1バイトごと送れます。
この時、配列の長さはsizeof()だとうまくないみたいなので、データ長さを別の変数lenにて渡すことにしました。
ここではfloatの変数の数にしましたけど、

ああ、
関数サブの汎用性を上げるようにするには、バイト数にした方が良いみたい。



さっそく修正！

すごくシンプルになりました♪

しかし、あとで見た時になにやってるのか思い出せるのだろうか？
簡単すぎてわからないかも。。。

大昔の記憶だと、
Z80ニーモニックにHLというのがあって、
メモリ空間を16ビット(=64キロバイト)で扱えるように8ビットのレジスタ2つをつなげてHLとして使えるようになってました。

で、(HL)というのが、そのアドレスのメモリに入っているデータを表してました。
(カッコ)がポインタですね、たぶん。
LD A,(HL)とかLD (HL),Aとかでメモリの内容とAレジスタ(アキュームレータ)の間のやり取りの命令で、
コレによって画面にドット打ったり(V(ビデオ)RAMに描画)、計算結果をメモリに収納したり(変数の保存)。


BASICだとpeek、pokeでメモリにアクセスできました。

Cは言語レベル的にはアセンブラとBASICの中間にあると思うのですが、直接メモリにアクセスしづらいですよね？？
変数の型のせいだと思う。bit_tとかbyte_tとかあったらどうなんだろ？って無いんだからきっと必要ないんだかな？

で、
アセンブラはまだ頭がスポンジのような10台の時に覚えたので、イメージがスッと入りましたが、
Cは40台に初めて取り組んだので、頭が硬くてなかなか概念を理解できなくて、モヤモヤしてます。
というか、すぐに綺麗さっぱり忘れてしまいます。


んで、今回やっとのことでメモリーへのアクセスがうまくできたので、忘れないうちに書き留めておこうと。

ポインタは配列で考えるといいみたいです。
uint8_t data[10];
uint8_t* a;と宣言して、
a=&dataとするとaにはdata[0]のアドレスが入ります。
ここでaはa[x]とは宣言していませんが、a[1]というのがありなんですね！
そしてこのa[1]はa[0]の一つ後ろのアドレスを示すんですね。
コレはaをuint8_t*として宣言しているからで、
もし、uint16_t* a;と宣言していれば、a[0]の2バイト後ろのアドレスを示します。

なので、a自体はメモリ上にはアドレスが入っているわけで、uint8_t*でもuint16_tでも同じ4バイトです。(PIC32の場合)
このポインタ宣言の型は、添え字をつけた時のアドレスのすすむ量を明記するためにしているのですね。

このアドレスの進み方が宣言の型によって決まるというところがやっと理解できました。

今までは、
c = *(&data[0]+1)とかやってコンパイラに拒絶されてました。。。。

と書きながら、コレだとなんで悪いのかがわからないので、
まだいまいちわかってないんですけど。。。

今まではI2C言うと
マイコンをマスターにして、
スレーブのセンサーを設定したり、
センサーからデータを読み込む、
といった操作でした。

今回は、
2つのマイコンのデータのやり取りに使おうかと。

2つのマイコンと言っても、
片方をスレーブとしてセンサーのように振る舞わせれば良いのかな？


としても、
スレーブぽい方のマイコンからもセンサのデータを採ったりできた方が良さそう？
という操作は想定されているようで、
マルチマスターと言う考えがあるようです。
I2Cバスにマスターが複数存在しても良いということです。

I2C通信はマスター側がクロック線(SCL)を駆動してそれに合わせてデータ線(SDA)でデータを送受信する仕掛けなので、クロックを駆動する機器2台が同時にクロック線を駆動してしまった時のエラー処理の方法はきちんと確立されているようです。
クロック周波数が違っていることもあったりするみたいのなので、ケッコー複雑？

なので、
使う側としては、ライブラリにお任せで良いのかな？


とりあえず、
ESP32を2つ用意して、マスタ1台、スレーブ1台としてみました。


iP5306電源モジュールもつながっていたので、

スレーブが2台スキャンされました。

ライブラリとサンプルは動きましたが、
ESP32スレーブからの返信に違和感。。。

ま、いっか、と、
PICマスターとESP32スレーブを組んで実験です。


今まで使ってきたセンサ類だと、
まずマスターからレジスタアドレスが送信されてきて、
そのレジスタアドレスによってスレーブは要求に合ったデータを用意して、
(たとえば0x00だったら初期設定の値とか、
ROMだったら、そのアドレスに収納されているデータとか)
次にマスターからのデータの送信要求に対して、
スレーブはマスターのクロックに合わせてデータを出していくと言う手順なので、
マスターであるPIC側ではwriteRead()という関数を使っていました。

ところがこれだと、ESP32側でマスターからwriteされたレジスタアドレスが拾えないみたいでした。
arduinoのサンプルでは意味のない文字メッセージを返すようなプログラムなので、何かの要求に対しての返信になってなくて一律の同じ返信内容でした。


いろいろ試してみたのですが、
スレーブ側のESP32のarduinoでは、
onRequest()関数内で返信しないと、変なデータがマスターに送られてる？
イヤ、どっちから出てるのか不明。。。
とにかく意図しないデータをマスタが受信したことになってしまいます。

なんで？？


onRequest内でレジスタアドレスをどうやっても読めないので、
I2Cプロトコルの勉強をやり直し。

。
。
。

マスター側を、まずwriteして、スレーブ側はonReceiveでデータを受け取り、
これをレジスタアドレスと理解して、返答を準備する。

次にマスターからreadして、スレーブ側は返答データを送信する。
としたところ、イイようでした。

まぐれかもしれないので、もうちょっとお勉強。。。。。。

つづく