このブログでは主に以下の内容を記載しています（自分の記録用）。
記事が渾然一体となってカオス状態ですが、マイコンのプログラムも、ちゃりで走るのも、料理するのも、自分の中ではそれぞれが繋がっているので、カオスな日常をそのまま反映させています。リンクや引用はご自由にどうぞ。質問等ありましたらコメントに書いてください。微力ながら自分の分かる範囲で回答します。
とにかく、、人に「あほやなぁ」と言われる事に精進するのが我が人生。へこんでも創造の力で進みたい
*1:音楽にも絵にも失礼だろうか。。自分
要約：ESC32-C3を買った。MicroPythonのファーム(esp32c3-usb-20220618-v1.19.1.bin)を焼くと動いた
詳細：
RISC-Vを動かしてみたいと思い、手頃な価格のESP32-C3を購入した。（seeed studioのXIAO-ESP32-C3）
USB-Cに接続するとシリアルで繋がったが特にコンソールに表示もされず、初期ファームが何なのかよくわからない。
MicroPythonを焼いてみようと思い、esptool.pyでesp32c3を指定したが、エラーになった。自分が使ってるesptoolは古いせいか、デバイスを認識できないようだ。autoで走らせてもエラーになる。
$ esptool.py --chip auto --port /dev/ttyS8 chip_id esptool.py v2.8 Serial port /dev/ttyS8 Connecting... Detecting chip type... A fatal error occurred: Unexpected UART datecode value 0x03700000. Failed to autodetect chip type.
esptoolをpipで入れてみたが、ビルドでエラーになる。Python.hが無いと怒られる。なぜか？？
gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -DFFI_BUILDING=1 -DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE -I/usr/include/python3.9 -c c/_cffi_backend.c -o build/temp.cygwin-3.3.6-x86_64-3.9/c/_cffi_backend.o
c/_cffi_backend.c:2:10: fatal error: Python.h: No such file or directory
2 | #include <Python.h>
| ^~~~~~~~~~
compilation terminated.
error: command '/usr/bin/gcc' failed with exit code 1
[end of output]Python.hをPCに入れないといけないのかもしれない。調べるのに時間がかかりそうなので、Esp用テストツールのファーム書き込み機能で代用してみる。
適当にやってみたが、COMポートは接続されるものの、応答がない。ちゃんと調べないとだめか。。
MicroPython - Python for microcontrollers
MicroPythonの代わりにCircuitPythonを落として入れてみる
Luatos Core ESP32C3 Download
CircuitPythonは起動できた。
オートリロードがオンです。ファイルをUSB経由で保存するだけで実行できます。REPLに 入ると無効化します。
Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 8.0.0-beta.6 on 2022-12-21; Luatos Core-ESP32C3 with ESP32-C3
>>> help('modules')
__future__ collections neopixel_write terminalio
__main__ digitalio nvm time
_asyncio displayio onewireio touchio
_bleio dualbank os traceback
_pixelmap errno ps2io ulab
adafruit_bus_device espidf pulseio ulab
adafruit_bus_device.i2c_device fontio pwmio ulab.numpy
adafruit_bus_device.spi_device framebufferio rainbowio ulab.numpy.fft
adafruit_pixelbuf gc random ulab.numpy.linalg
aesio getpass re ulab.scipy
analogio hashlib rgbmatrix ulab.scipy.linalg
array i2cperipheral rtc ulab.scipy.optimize
atexit i2ctarget sdcardio ulab.scipy.signal
audiocore io select ulab.scipy.special
audiomixer ipaddress sharpdisplay ulab.utils
binascii json socketpool uselect
bitbangio keypad ssl vectorio
bitmaptools math storage watchdog
board mdns struct wifi
builtins microcontroller supervisor zlib
busio micropython synthio
canio msgpack sys
Plus any modules on the filesystem
>>>ESP32C3用のファームとして、ESP32-C3 with USBというバージョンもある。何が違うのかビルドオプション等を調べないと分からないが、、これを焼いてみる。
MicroPython - Python for microcontrollers
こっちのバージョンだとCOMポートで通信ができた。
>>>
MPY: soft reboot
MicroPython v1.19.1 on 2022-06-18; ESP32C3 module with ESP32C3
Type "help()" for more information.
>>>
>>>
>>> help('modules')
__main__ framebuf uasyncio/stream uplatform
_boot gc ubinascii urandom
_onewire inisetup ubluetooth ure
_thread math ucollections uselect
_uasyncio micropython ucryptolib usocket
_webrepl neopixel uctypes ussl
apa106 network uerrno ustruct
btree ntptime uhashlib usys
builtins onewire uheapq utime
cmath uarray uio utimeq
dht uasyncio/__init__ ujson uwebsocket
ds18x20 uasyncio/core umachine uzlib
esp uasyncio/event uos webrepl
esp32 uasyncio/funcs upip webrepl_setup
flashbdev uasyncio/lock upip_utarfile websocket_helper
Plus any modules on the filesystem
>>>RAMは121KB空いているようだ。起動後のクロックは160MHz
>>> gc.mem_free() 121536 >>> machine.freq() 160000000
ESP32-C3のRISC-Vはシステムクロックが最大160MHzらしいので、これ以上は上げられない。RISC-V上でMicroPythonを動かしてRISC-Vを使ったといっていいのか。。多分だめだろう。RISC-Vの手触り感とか言いたいのなら、アセンブラのレベルまで降りないとダメなのでは・・自問自答
複素内積空間の説明（木田 雅成氏）
https://www.rs.tus.ac.jp/kida/hermite.pdf
量子フーリエ変換につながる正規行列のスペクトル分解についても書かれている
https://www.math.nagoya-u.ac.jp/~yamagami/teaching/linear/linear2016.pdf
背景：来るのか来ないのか分からないが、量子コンピュータが気になる
目標：ブラ-ケット記法による重ね合わせ、もつれ、演算を理解して、プログラミングできるか、他人のコードをなんとなく分かるようになる。AWSでも量子コンピュータを提供しているようなので、時間借りして動かしてみたい。とりあえず、数独を量子コンピュータに解かせる(量子アニーリングによる解法はInterface誌に掲載されているのだが、ゲート型で解かせたいのだが、可能なのだろうか？？その程度も分かっていない)
取り組み：アホなりにも量子力学をうわべだけ勉強して、量子の重ね合わせって何なのかを薄く理解する。量子コンピューティングの本を読む、Pythonによるシミュレータを動かす
読んでいる本
これから読むつもりの本
YouTubeにも頼りたい
量子コンピュータ授業 #1 量子ビットと量子ゲート - YouTube
最初、量子論をすっ飛ばして、ブラケット記法で演算が分かればいいかと思ってたけど、そもそも重ね合わせって何か分かっていないと、基本的な所でつまづくのでは？と思い、うわべだけでも量子力学を薄く分かっていないといかんのでは？と思い、ブルーバックス等の分かりやすいはずの入門書を読んでいるところ。本当は自分の手でシュレディンガー方程式を展開して？定理を追いかけないとダメなんだろうけど、、普通の人間にそんなことできるはずもなく・・
MacBookのキーボードは極限までストロークを減らしつつ、機構の工夫でクリック感が実現されている。これはこれでありかもしれないが、どうも慣れない。Macを使う時間も増えてきたのでKeychronのキーボードを買った。
選んだのは Keychron K2 のUS配列、茶軸。茶軸の位置付けとして、クリック感の強い青軸、静かな赤軸の間ということらしいが、茶軸でも結構カチャカチャと音が出る。だけど、しっかりと底打ちしている感じが伝わってくるので打っていて気持ちがいい。キーボードの底板がしっかりしてるから剛性感がある。このキーボードで打っていると、しみじみと幸せな感じになる。ただ、、ちょっと残念に思うのは、スペースキーの動き。英数キーはカチカチ打てるけど、いまいちスペースがカシャーンと打てる感じがない。スペースキーの中央部以外を押下すると、若干捻れながら降りる感じがする。US配列は幅広いスペースキーが特徴なので、スペースキーのどの部分を叩いても平行に降下して欲しい。
伝統的なキーボードだと、スペースキーを上限させる機構として、パンタグラフというのか、水平を保ちつつ上下動させるための針金（車でいうとスタビライザーみたいなの）が入っていて、キーボードが垂直に動作するようになっているのだが、Keychronでは水平を保つための針金は入っておらず、スペースキーの支持は、スペースキー用のスイッチと上下動きを助けるシャフトの３パーツで実現されている。まぁ、針金方式は針金方式で、爪が欠けるとスペースキーが降りなくなったりして故障しやすい欠点があるかもしれない。
カシャーンと打てないスペースキーが気になるものの、比較的安価で、打ち心地がよく、MacBookの横幅とほぼ同じサイズで収まりが良いのでかなり気に入りました。Buletooth接続なので、ケーブルも不要。
Keychronのおかげで打ち心地が良くなりタイプミスも大幅に減って、これでサクサクプログラミングするかと思いきや、マイクラに没頭しているという*1。。
*1:[shift]+[w]で、がけ等から落ちずにギリギリまで進めるので、確実にshiftが押せることが重要
組み込みでTinyGoを使うとして、Go言語自体を理解できていないとパッケージ(ライブラリ)の使い方とか、エラー処理とか、細かい所がよくわからない。Go言語は言語仕様がコンパクトで学びやすいとは言われているけど、実はクセ強な言語と思っています。というわけで、、Go言語を理解すべく、「初めてのGo言語」という本を買って、解説を読みながらサンプルコードを走らせて勉強中。４００ページ以上の分厚い本なので、全部読むのにかなり時間かかりそうですが、、一つの言語をじっくり勉強したことが無いので*1、今回はきっちり理解したいと思っています*2。
この本のスタイルとして、イディオム（書き方の型？）に注目して理解するというアプローチなので、解説に示された書き方の型を学べばGo言語らしい一定の品質のコードが書けるだろうと期待。本では、なぜこのような仕様になっているのか？のレベルから解説がなされているので、GOという言語の思想も少しは理解できるだろう。Go言語を初めて見た人は、なぜ例外処理がないのか？？と言うらしいが、この本にも仕様に入っていない理由が書かれている。*3
Go言語は新しいソフトウエア設計思想を盛り込んだ最新の言語というわけではなく、シンプルな言語を作るという設計者の強い思いで、必要な機能を厳選したミニマムな言語と思いました。だから、、Go言語の特性を活かしたコードを作るには、どのように記述するが最適なのかを理解している必要があると思っています。シンプルな言語なので好きになれそうで、MicroPythonで速度が問題になるときはTinyGoで組んでみたいと思っています。なぜCを使わないのか？？自分でも分かりませんが・・ワクワクしないから？？ARM等はライブラリが盛りだくさんでワケ分からないから？？ コーディングの観点では、Go言語ではMAP型とかfor rangeとか使えるし、メモリ管理も処理系でやってくれるのでCよりは楽にコードが書けるのではと思っています。
課題：Ubuntu 上にtinygo開発環境を構築して、gdb+OpenOCDを動くようにしたい
取り組み：Ubuntu 上にtinygoの開発環境をインストール、gdbの最新版をパッケージでインストールする
結論：gdb+OpenOCDによるシンボリックデバッグが可能となった
作業内容：
普段使ってるCygwinにtinygoの環境を入れようとしたが、パスの問題やら、gdbのバージョン不整合の問題が出た。標準的なUbuntu上で環境構築するのが無難ではと思い、Ubuntu に入れなおす
ビルド、gdbを起動してみる。
$ tinygo build -target pico blinky1.go
$ tinygo gdb -target pico
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/tinygo9732039/main...
warning: Section .debug_aranges in /tmp/tinygo9732039/main entry at offset 0 debug_info_offset 0 does not exists, ignoring .debug_aranges.
:3333: Connection timed out.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
(gdb)gdbが起動してOpenOCDと通信するところまで進んだ。エラーが出なかったのは、別件のためすでにgdbとOpenOCDがインストール済みだったため。gdbのバージョンは以下(9.2)
$ gdb-multiarch --version GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2
"monitor" command not supported by this target. というエラーが気になるが、、この状態で、RPi上でOpenOCDを起動してgdbから接続してみる。
以下のコマンドでRPi上のOpenOCDを起動
$ /usr/local/bin/openocd -c 'bindto 0.0.0.0' -f /usr/local/share/openocd/scripts/interface/raspberrypi-swd.cfg -f /usr/local/share/openocd/scripts/target/rp2040.cfg
Open On-Chip Debugger 0.11.0-g228ede4-dirty (2022-12-10-18:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
Info : Hardware thread awareness created
Info : Hardware thread awareness created
Info : RP2040 Flash Bank Command
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : BCM2835 GPIO JTAG/SWD bitbang driver
Info : clock speed 1001 kHz
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x00000001
Info : SWD DPIDR 0x0bc12477
Info : SWD DLPIDR 0x10000001
Info : rp2040.core0: hardware has 4 breakpoints, 2 watchpoints
Info : rp2040.core1: hardware has 4 breakpoints, 2 watchpoints
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/33333333ポートで待ち受けになっているので、Ubuntuのgdbから接続に行く。接続まではできてターゲットはHALTになった。リストコマンドを打つと、Drawf Errorになっている。なぜだろうか。
(gdb) target remote 192.168.10.100:3333 Remote debugging using 192.168.10.100:3333 0x10001a4c in runtime.scheduler () (gdb) b main Function "main" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (main) pending. (gdb) l Dwarf Error: DW_FORM_strx1 found in non-DWO CU [in module /tmp/tinygo9732039/main]
なお、OpenOCD側では以下の警告が出ている
Warn : Prefer GDB command "target extended-remote 3333" instead of "target remote 3333"
少しぐぐると、、Dwafのバージョンとgdbの整合性の問題のようで、Dwarf5を使っている場合はgdb10を使えということらしい。gdb9のままとする場合はdwaf4に落とせと。
Gdb < 10.1 can't read clang's DWARF v5 - Common Infrastructure - LLVM Discussion Forums
Ubuntu環境のgdbは特にこだわりないので、、最新版にあげてみる。
上げようとしたが、自分のUbuntuは20.04 LTSで、このLTSで入れられる最新版gdbは9.2のようであった。だから、、もっと新しいgdbを入れたかったらUbuntuのバージョンを上げないといけない様だ。あるいは、ソースからコンパイルか。
Ubuntuを24LTSにあげた。おおよそ以下の手順
1605 apt update 1606 apt upgrade 1607 apt full-upgrade 1608 apt autoremove -y 1609 apt autoclean -y 1610 reboot 1612 do-release-upgrade
参考にした記事
Ubuntu 20.04 LTS を 22.04 LTS にアップグレードする - Uzabase for Engineers
改めて、、RPi側は以下でOpenOCDを実行中
/usr/local/bin/openocd -c 'bindto 0.0.0.0' -f /usr/local/share/openocd/scripts/interface/raspberrypi-swd.cfg -f /usr/local/share/openocd/scripts/target/rp2040.cfg
RPiのIPが192.168.10.100なので、tinygo gdbでGDBを起動して、192.168.10.100:3333で接続する
$ tinygo gdb --target pico
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/tinygo942108089/main...
warning: Section .debug_aranges in /tmp/tinygo942108089/main entry at offset 0 debug_info_offset 0 does not exists, ignoring .debug_aranges.
:3333: Connection timed out.
"monitor" command not supported by this target.
You can't do that when your target is `exec'
"monitor" command not supported by this target.
(gdb) target extended-remote 192.168.10.100:3333
Remote debugging using 192.168.10.100:3333
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
0x10001a4c in runtime[scheduler] ()(gdb) info sources
*略*
/usr/local/lib/tinygo/src/runtime/scheduler_any.go, /usr/local/lib/tinygo/src/runtime/time.go,
/usr/local/go/src/time/format.go, /usr/local/go/src/time/time.go, /usr/local/go/src/time/zoneinfo.go,
/usr/local/go/src/time/zoneinfo_read.go, /usr/local/go/src/time/zoneinfo_unix.go,
/mnt/c/cygwin64/home/<user_id>/lang/tgo/test/blinky1.go
(gdb) info func
*略*
0x10001c94 main.mainソースの情報やシンボル情報は読み込めている。
HardwareBreadkpintを main.mainに設定する
(gdb) hb main.main Hardware assisted breakpoint 3 at 0x10001c96 (gdb) i b Num Type Disp Enb Address What 3 hw breakpoint keep y 0x10001c96 <main.main+2>
実行してみる。止まるには止まったが、ソースと一致しないようだ。
(再ビルドしたので番地が違っている？)
(gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /tmp/tinygo942108089/main target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x00000184 msp: 0x20041f00 [New Thread 1] [Switching to Thread 1] Thread 2 hit Breakpoint 3, 0x10001c96 in main.main () (gdb) l 1 <unknown>: No such file or directory.
適当に走らせてCtrl-Cで止めるとソースを参照できる
(gdb) l
171 // will be executed soon.
172 if sleepQueue != nil && now-sleepQueueBaseTime >= timeUnit(sleepQueue.Data) {
173 t := sleepQueue
174 scheduleLogTask(" awake:", t)
175 sleepQueueBaseTime += timeUnit(t.Data)
176 sleepQueue = t.Next
177 t.Next = nil
178 runqueue.Push(t)
179 }
180想像するに、、main.mainで止めずに、main内の有効な行で止めないといけないのでは（スタックがまだ積まれていないから。。とか。。）
blinky1.goの12行目にhardware breakを設定してみる
(gdb) list blinky1.go:10
5 import (
6 "machine"
7 "time"
8 )
9
10 func main() {
11 //led := machine.LED
12 led := machine.GP15
13 led.Configure(machine.PinConfig{Mode: machine.PinOutput})
14 for {
Warning: the current language does not match this frame.
(gdb) hb blinky1.go:12
Hardware assisted breakpoint 1 at 0x10001cb6: file /home/<user_id>/lang/tgo/test/blinky1.go, line 16.
(gdb) i b
Num Type Disp Enb Address What
1 hw breakpoint keep y 0x10001cb6 in main.main at /home/<user_id>/lang/tgo/test/blinky1.go:16
(gdb)ソース行内のコードに対して、ブレークポイントを設定すると、停止してリスト表示も行えた。*1
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/tinygo3924727989/main
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000138 msp: 0x20041f00
[New Thread 2]
Thread 1 hit Breakpoint 1, main.main () at /home/<user_id>/lang/tgo/test/blinky1.go:16
16 time.Sleep(time.Millisecond * 500)
(gdb) l
11 //led := machine.LED
12 led := machine.GP15
13 led.Configure(machine.PinConfig{Mode: machine.PinOutput})
14 for {
15 led.Low()
16 time.Sleep(time.Millisecond * 500)
17
18 led.High()
19 time.Sleep(time.Millisecond * 500)
20 }
(gdb)まとめ：RPi上でOpenOCDを走らせて、ノートPC上のWSL上のUbuntu でtinygoの開発環境を構築して、その中でgdbを走らせて、gdbからRPi上のOpenOCDとリモート接続することでシンボリックデバッグが可能となった。
[gdb on Ubuntu on WSL]
[Windows10] <--------------LAN----> [OpenOCD on RPi]<------SWD--->[Pico]
以下の写真はRPiとPicoをSWDで接続して動作確認しているところ
■追記
うまくいったといっても、Ubuntu上ではOpenOCDが起動された空振りしている状態なので、これはあくまでもWorkaroundのレベルだ。以下はプロセス一覧を確認したところ。ローカル環境でOpenOCDを走らせるのではなく、リモートのOpenOCDと接続できるように作込みが必要
$ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 904 532 ? Sl 18:04 0:00 /init root 8 0.0 0.0 904 96 ? Ss 18:04 0:00 /init root 9 0.0 0.0 904 96 ? S 18:04 0:02 /init xxx 10 0.0 0.1 9276 5516 pts/0 Ss 18:04 0:00 -bash xxx 998 0.3 2.4 1014888 115516 pts/0 Tl 19:52 0:10 tinygo gdb --target pico xxx 1099 0.0 0.0 0 0 pts/0 Z 19:52 0:00 [openocd] <defunct> <<<< 無駄に走っているOpenOCDプロセス xxx 1100 0.0 0.9 395864 42404 pts/0 Tl 19:52 0:02 gdb-multiarch /tmp/tinygo3924727989/main -ex target ext xxx 1108 0.0 0.0 10456 3168 pts/0 R+ 20:48 0:00 ps aux
gdb起動オプション
gdb-multiarch /tmp/tinygo3924727989/main -ex target extended-remote :3333 -ex monitor halt -ex load -ex monitor reset halt