2024年4月21日日曜日

QMC5883Lは不安定?

ーーーーーー
2024/05/08追記:やはり原因はQMC5883Lだった。他は全て同じコードで、I2Cで地磁気を読む部分のみセンサおよびコードをLSM9DS1に置き換えると、少なくとも12時間連続動作させても問題ないことを確認。安物、コピーでもよい用途と、ダメな用途があるという学びになった。
ーーーーーー

GPSと方角ベースのナビを作るべくトライし続けているが、地磁気センサとのI2C通信が安定しないので、いつまで経っても先に進まない。
症状としては、起動後すぐは安定した速度で動作しているのだが、10分?60分?以上経過すると、徐々に地磁気センサからのX,Y,Z軸の磁気情報の読取が遅くなるというもの。

最初はプログラムのミスや外付け回路の不良を疑い、プログラムを書き換えたりI2Cのプルアップの値を変えたりして戦ってきたが、どの方法でも解消しない。

そもそもチップが悪いのではと考えて検索したところ、似たような症状の方を発見。
https://shinshu-makers.net/shinshu_makers/2019/10/02/%E3%80%90%E3%83%91%E3%83%AF%E3%83%BC%E3%83%A1%E3%83%BC%E3%82%BF%E3%83%BC2019%E3%80%91qmc5883l%E4%B8%8D%E8%AA%BF%E3%81%A7lsm9ds1%E3%81%AB%E4%BA%A4%E6%8F%9B%EF%BC%9Cimu%E3%81%A7ok/

やはり格安チップではダメということか?
似たり寄ったりだが、aitendoで買ったHMC5883Lで再トライすることにする。

2024年4月20日土曜日

RP2040でR-2R DACを試してみる

I2Sの勉強をしていたら、R-2RというDACのことを知った。
せっかくなので、試しに作って遊んでみる。

参考文献はこちら→https://www.mech.tohoku-gakuin.ac.jp/rde/contents/course/mechatronics/anadigi.html

上記サイトの上のほうの回路図にあるように、正確な抵抗のセットが2n本と、n個のDOがあれば、n bitのアナログ出力が作れるということ。
今回はDO4つ+R 3つ+2R 5つで、4bitを作ってみる。
Rの値は電源とマイコンの電流入出力能力を超えない範囲で選べばよいが、今回はわかりやすく1kΩと2kΩで作ってみた。

お行儀はよくないがGP18をLOWにしてGND代わりとしている。
GP21-24がDOで、A0で結果を読み取っている。

結果は以下のようになった。
ガタガタしているのは、抵抗のバラつき起因と思われる。
オーディオ用途で拘って作る人々は、チップ抵抗で16bit, 24bitを作って、抵抗器をやすりで削って微調整しているらしい。
一度トライしてみたい。

今回作ったものの精度はともかく、こんな簡単な回路でアナログ出力ができるというのは本当に面白い。


オマケで、結果の取得に使ったThonnyのコード。
汚いけどそのまま貼ります。
整数0~15を2bitの01の0埋め文字列に変換する部分、もっといいやり方がある気がするけど動けばいいやの精神。

import time

LED = machine.Pin(25, machine.Pin.OUT) # GP25をLEDとして出力端子に設定
GND = machine.Pin(18, machine.Pin.OUT)
GND.off()
bits = [
    machine.Pin(24, machine.Pin.OUT)
    ,machine.Pin(23, machine.Pin.OUT)
    ,machine.Pin(22, machine.Pin.OUT)
    ,machine.Pin(21, machine.Pin.OUT)
]
VIN = machine.ADC(0)
conv = 3.3/65535
conv = 1

print("start")
print("----")

def v(order):
    print(order, end="")
    print(": ", end="")
    for i in range(4):
        if order[i] is "0":
            bits[i].off()
        else:
            bits[i].on()
    time.sleep_ms(10)
    print(VIN.read_u16()*conv)

for i in range(2**4):
    t = ("000" + str(bin(i)).replace("0b", ""))[-4:]
    v(t)  

2024年4月13日土曜日

トランジスタ2石とDO 1つでマイコンの電源自己保持

待機中のマイコンの消費電力を極限まで下げるため、トランジスタ2石とDOを1つ使い、電源に自己保持回路を加えることを考えてみる。

何か動作させるときは、モメンタリスイッチなどでワンショットの入力を受け付ける。マイコンが起動すると、電源用のDOをHIGHにして、電源をONにしつづける。
仕事が終わったら、電源用のDOをLOWにして、自己保持を解いて電流を消費しないようにする。

マイコンにもスリープモードがあるのでそちらで十分な時は無駄に部品が増えるだけだが、うまく作ればスリープモード以上の省電力化ができるのでは?

考えた回路がこちら。
2つのスイッチが、マイコンのDO相当。右端の100Ωがマイコンの電源部分。

この回路は、NPNのベース抵抗の反対側にHIGHが印加されると電源ONで、LOWもしくはハイインピーダンスだと電源OFFになる。

シミュレータは以下のサイトを利用。

Import用のテキスト列。
$ 1 0.000005 10.20027730826997 50 5 43 5e-11
r 384 272 384 208 0 1200
s 208 256 272 256 0 1 false
v 144 336 144 160 0 0 40 3.7 0 0 0.5
r 464 160 464 336 0 100
w 320 160 368 160 0
w 208 160 320 160 0
w 144 336 208 336 0
w 400 160 464 160 0
w 384 336 464 336 0
t 352 288 384 288 0 1 -3.161620436472443 0.20923865338699582 100 default
t 384 208 384 160 1 -1 3.370856126826202 -0.32914051091822083 100 default
w 384 336 208 336 0
r 272 288 352 288 0 1200
w 208 160 208 256 0
w 256 192 320 192 0
w 144 160 208 160 0
w 384 336 384 304 0
s 208 288 272 288 0 1 false
w 272 256 272 288 0
w 208 288 208 336 0
o 0 64 0 4099 0.0000762939453125 0.00009765625 0 2 0 3
o 3 64 0 4099 0.0000762939453125 0.00009765625 1 2 3 3
38 0 F1 0 1 101 -1 Resistance


2024年3月24日日曜日

RP2040にてarudino-picoでWireを使うときの注意点

まず、ArduinoでRP2040を動かすにはMbed OS RP2040という公式系と、arduino picoというphilhowerさんが作ったバージョンがある。少なくともI2Cの使い方がそれぞれ違う。

公式版は、I2Cで任意のピンを使うのが難しいらしい。なので、arduino-picoを選ぶ。

そして、Wire/Wire1は、setup()やloop()のスコープ中でしか使えない。
グローバルスコープで使おうとすると、未定義となりうまくコンパイルできない。
RP2040-ZeroにてArduino IDEでI2Cを使うとき、micropythonの感覚で書くと失敗する。
こんなのにハマるのは私だけかもしれないが、誰かの役に立つかもしれないので一応公開しておく。

■OKのとき

#inclue <Wire.h>
void setup(){
  Wire1.setSDA(14);
  Wire1.setSCL(15);
}

■NGのとき

#inclue <Wire.h>
Wire1.setSDA(14);
Wire1.setSCL(15); void setup(){ }
ちなみに、NGのときは次のようなエラーが出る。
<ファイルパス>:18:3: error: 'Wire1' does not name a type
   18 |   Wire1.setSDA(14);
      |   ^~~~~
<ファイルパス>:19:3: error: 'Wire1' does not name a type
   19 |   Wire1.setSCL(15);
      |   ^~~~~
<ファイルパス>:20:3: error: 'Wire1' does not name a type
   20 |   Wire1.begin();
      |   ^~~~~
exit status 1
Compilation error: 'Wire1' does not name a type
Wire1が定義されていない、となっている。

thonny+micropythonからarduino-pico c++へ

これまで、RP2040関係はthonny+micropythonで動かしてきたが、arduno-picoとc++に移行することにした。

というのも、今回GPSナビを作るにあたり試行錯誤しているのだが、フリーズが多発し実用的なデバイスが作れそうにないため。
私の回路技術およびプログラミング技術の低さによるものなのか、そもそも無謀なことをやろうとしているのか、他に原因があるかは判別できていないが、このままでは埒が明かないので新しいやり方を試そうと思う。
特に、SPI液晶+I2Cセンサ+UARTのGPSという異なる3種類のバスをタイマ割り込みも交えつつ動かすというのがよくないのかもしれない。
リンクを見失ってしまったが、ピン割り込みとタイマ割り込みを高周期の設定で併用するとクラッシュするというようなブログの記載があった気がする。

今までCで書かれたライブラリを頑張ってmicropythonにポートしていたが、技術向上という意味では無駄ではなかったと思いたい。

2024年3月20日水曜日

gc9a01pyで円、楕円、三角を簡単に書けるようにする

gc9a01pyは大変有難いライブラリだが、四角と直線と点しか描けないのが弱点。
さすがに不便なので、円、楕円、三角を足した。
https://github.com/matsuura-h/gc9a01py/tree/main
以下は、ランダムに三角を表示している例。

効率のよい描画ロジックを1から作るのは大変なので、LovyanGFXのコードを参考にした。
CからPythonへの移植だが、すべてを手打ちすると大変なので、https://www.codeconvert.ai/c-to-python-converterで自動変換し、自動ではうまく動かない部分を手直しする。
ほとんどのコードはうまく自動変換できるけど、以下の2パターンだけはNGだった。

  1. do-while
    1. 対処方法:while Trueに書き直して、条件文を末尾にif not <condition>: breakとして追加する
  2. 入れ子になったインクリメントやデクリメント
    1. 対処方法:インクリメントやデクリメントを前出しもしくは後出しにする
一つ困っていることとして、gc9a01pyはMITライセンスだが、LovyanGFXはFreeBSDライセンスになっている。
こういうとき、どうやってライセンスを処理すればよいのだろうか?
また、私が移植した部分と元のコードは一体どのように扱うとよいのだろうか?
下手にpull reqestを送ってrusshughesさんやLovyan03さんの迷惑になったら申し訳ないので、とりあえず自分のリポジトリにforkを作って公開してみた。
よい方法をご存知の方がいたら、是非教えてください。

2024年3月18日月曜日

RP2040-ZERO+gc9a01pyの実描画速度を調べてみる

 gc9a01pyはmicropython派にとって大変有難いライブラリだが、どれくらいの速度で描画できるのかが気になる。

Timerと組み合わせて、簡易的にFPSを調べてみる。

サマリは以下の通り。

関数 1回のdot数 fps
line 240 tft.line(0, 0, 240, i, color565(i,255-i,count&255)) 5fps
line 10 tft.line(115, i, 125, i, color565(i,255-i,count&255)) 106fps
pixcel 1 tft.pixel(30+i, 30+j, color565(i,255-i,j)) 948fps
fill_rect 1 tft.fill_rect(30+i, 30+j, 1, 1, color565(i,255-i,j)) 868fps
fill_rect 100 tft.fill_rect(30+i, 30+j, 10, 10, color565(i,255-i,j)) 755fps
fill_rect 240*240 tft.fill_rect(0, 0, 240, 240, color565(i,255-i,j)) 18fps

line, pixelはdot数律速で、だいたい1秒1000dotが限界。
fill_rectは、SPIの命令送信と液晶内部処理の2つが律速。SPIの命令は最大1000回/s発行できる。
液晶内部での描画は、3パターンという少ない試行数からの試算なので意味があるかは怪しいが、今回の結果からは1dotあたり0.94usかかっていると推測される。
SPIの命令発行にかかる時間が変わらないとして、総塗り替えのときは1dotのときに比べ、54.4ms余分にかかっているので、1dotあたりに直すと0.94usとなる。
この結果を100dotに当てはめると803fpsとなり、実際のfpsに近い値になる。
試してみればいいことではあるが、fill_rectの速度推定にある程度役立つ。

以下は、実際に測定に使ったコードと結果の詳細。

■line:240dot
コードはこのような感じ。

  # Timer、計測部分
  from machine import Timer
  def showFPS(t):
      global count, count_prev, tft
      fps = count - count_prev
      tft.text(font,"FPS: {0}".format(fps),40,120,WHITE,BLACK)
      count_prev = count
  
  tim = Timer(period=1000, mode=Timer.PERIODIC, callback=showFPS)
  # 描画部分
  count = 0
  count_prev = 0
  while True:
      for i in range(240):
          count += 1
          tft.line(0, 0, 240, i, color565(i,255-i,count&255))
この例は、直線描画の速度を調べている。
結果、ほぼ5fps。ごくまれに6になるときもあるが、無視してよいレベル。


■line:10dot
今度は、線分の式を「tft.line(115, i, 125, i, color565(i,255-i,count&255))

」に変えてみる。
結果、106fpsくらいまで性能向上する。

lineの中身を見てみるとわかるが、これって結局pixelで1dotずつ描画指令を送信しているので、pixel数の多さで速度が決まるということだ。
このライブラリに限らず、なるべく1点ずつ打つのを避けないと、どんどん描画速度が下がってしまう。

■pixel
じゃあ、今度は1秒に何点打てるのか?を測ってみる。
while True:
    for i in range(180):
        for j in range(180):
            count += 1
            tft.pixel(30+i, 30+j, color565(i,255-i,j))
見てみると、948点/s行けるようだ。
lineで10点ずつ打つと100fps→1000点/sで、240点ずつだと5fps→1200点/sなので、lineの結果ともマッチする。



■fill_rect:1dot
次は、fill_rectを試す。vline, hline, rectも内部でこの式を呼び出している。
fill_rectは、液晶に対し開始終了地点と色を送るだけなので、実はpixelに比べてSPIで送る指示は2byteしか変わらず、送信回数は同じ。
もしSPIの送信がボトルネックとすれば、pixelと遜色ない速度が出せるはず。
while True:
    for i in range(180):
        for j in range(180):
            count += 1
            tft.fill_rect(30+i, 30+j, 1, 1, color565(i,255-i,j))
結果、868fps前後となった。pixelに比べ、8.4%の性能低下で済んでいる。
これは1点ずつの描画だが、次は1回の描画面積が広くなっても変わらないか、試してみる。

■fill_rect:100dot
縦横を10ずつにして、1度に10dotずつ描画させてみる。
while True:
    for i in range(180):
        for j in range(180):
            count += 1
            tft.fill_rect(30+i, 30+j, 10, 10, color565(i,255-i,j))
この場合は755 or 761fpsとなった。RP2040⇔GC9A01の間のSPIは変わらないが、液晶内部の描画が増えた分でこれだけ遅くなったということ。とはいえ13%の性能低下で、1回で更新できるdot数ベースならlineに比べて圧倒的に速い。

最後に、240x240全て塗り替えにすると画像は無いが18fpsくらいだった。さすがに全消去は遅い。

以上。