STM32の開発環境について

STM32CubeIDE(以下CubeIDE)のインストをしている中での気づきですが、Mac OS特にTahoeになってしまうとCubeIDEがまともに動かない、結局Mac OSの特にセキュリティ強化対応にCubeIDEが全く追い付いていないらしい

特にアプリ起動がCLIから起動しないとST-LINKツールが動かないのは結構致命的、それ以外もこの先いろいろありそうだからVMware上のUbuntu、実はこれも24系列だと32ビットの必要なドライバがインストできないから、結局22系列を別にインストしてこれから構築するところ

でUbuntuの領域拡張、滅多にやらないと忘れるけど記録を残しとく、前回の記録はこちら

VMware上のUbuntu24.04のファイル領域拡張

① VM停止状態で仮想マシン – 設定からSSD領域拡張

② sudo gpartedで物理領域拡張する(実際の設定はGUI)

③ LVMに認識させるために、物理ボリューム確認後にpvrisize実行する

$ sudo pvdisplay
--- Physical volume ---
PV Name /dev/nvme0n1p3
VG Name ubuntu-vg
PV Size <47.32 GiB / not usable 1.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 12113
Free PE 0
Allocated PE 12113
PV UUID mEG8kz-Asbe-u3j6-Y8fM-qbbC-vkgs-x7EIjC

chat@ubuntu:~$ sudo pvresize /dev/nvme0n1p3
Physical volume "/dev/nvme0n1p3" changed

④ LV拡張のためにLVを確認する

$ sudo lvdisplay
  --- Logical volume ---
  LV Path                /dev/ubuntu-vg/ubuntu-lv
  LV Name                ubuntu-lv
  VG Name                ubuntu-vg
  LV UUID                jZdlBx-ScuT-uXjS-HQhE-gGla-B9UU-c6UUu4
  LV Write Access        read/write
  LV Creation host, time ubuntu-server, 2025-11-21 04:40:56 +0000
  LV Status              available
  # open                 1
  LV Size                <47.32 GiB
  Current LE             12113
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

⑤ LV領域拡張

$ sudo lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

⑥ ext4領域拡張

$ sudo resize2fs /dev/ubuntu-vg/ubuntu-lv

こんな風に拡張されました、デフォルトのインストールは20GBしかないからほぼほぼ足りなくなる、ディスク拡張してもその時点でVMwareに割り当てはされず、実際に使われなければMacからは未使用領域は使用可能(LVMの効用だろうけど)だから大きめにとっておくのが良さそうである

$ df
Filesystem                        1K-blocks    Used Available Use% Mounted on
tmpfs                                400508    1672    398836   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  48716684 6726048  39866328  15% /
tmpfs                               2002528       0   2002528   0% /dev/shm
tmpfs                                  5120       4      5116   1% /run/lock
/dev/nvme0n1p2                      1768056  131812   1528112   8% /boot
/dev/nvme0n1p1                       973952    6468    967484   1% /boot/efi
tmpfs                                400504     100    400404   1% /run/user/1000

まだ先は結構長そうだ、

P.S. 2025/11/22

なんだCubeIDEにarm版Linuxのバイナリ存在しないよ、無為な作業であった、さて古いIntel Mac、当然OSも古い、にインストしてみるか

 

admin

MacのTahoeではNAS(Q-NAP TS-230)のtimemachineがコケる

世の中でも同じ問題は出ているんだろうけど、M4 MacBook-ProをTahoeにアップデートしてtimemachine実行すると失敗する

原因は生成A.Iの回答によるとSMBまわりがTahoeでかなり変更が入っているようで、低消費電力型のNAS(TS-230)では通信が失敗するらしい

—————————————–

P.S. 2025/11/22

本件は以下のリンクの記述がまとまっていると思う

https://hireido.blogspot.com/2025/11/timemachine-macos-tahoe-261.html

—————————————–

バックアップ取れない(復旧もできない)のは怖すぎだから、急遽USB SSD(SunDiskの1TB)を購入依頼した、Mac OS側のパッチ出るまではそれで凌ぐ

手持ちは2.5インチタイプかM.2で容量も少ないから、汎用でポータブルタイプ用途にもちょうど良いタイミングかもしれない

アプリはともかく、データ領域でバックアップできるところはM.2 SSDにバックアップを取っておいた

P.S. 2025/11/19

SSD入手できたのでバックアップ取ってみた、SSD使用領域450GB超えてるぐらいだけどおよそ30分でバックアップ完了、ディスクを複数記述しておけば交互にバックアップ取るらしいから、いずれそういう使いかでも良いかもしれない

気持ちもう少し短めのケーブルでも良さそうに思う

 

admin

PlateauのデータをUnityにインポートしてみる(ヘビー級)

国交省の進めているプロジェクトにPlateauという、都市データを三次元データ化して例えば防災などに役立てようというものがありますが、三次元データは色んなアプリにインポートできるというのでやってみた

メジャーどころはBlenderとUnityかと思うけどUnityでやってみた、ただしSDKがUnity6は扱えないから、それ以前のバージョンで

手順は(https://scrapbox.io/lecture-nakayasu/PLATEAU_SDK_for_UnityによるCityGMLからOBJ変換を参照)、

① Plateau SDKをUnityにインストールする

https://github.com/Project-PLATEAU/PLATEAU-SDK-for-Unity/releases

② 三次元データをインポート

https://www.geospatial.jp/ckan/dataset/plateau-14212-atsugi-shi-2023/resource/fb7ea888-8d6a-43d5-a3c3-1557007bfce9

近隣で厚木市のデータをインポートしましたが、データサイズが巨大で狭い区画指定じゃないと、Unityがハングしてしまいます

こんな感じで相模川の中洲が見えているところになります、遠方にはビルが見えるから厚木駅方向ですかね

但しこの程度でも、

モデルの精度が高いとメモリは大量に消費するから、相当範囲を限定しないと使えなさそう

 

admin

STM32を使ってみる

表示含めて基本のロジックは組み込み(ラズピコスペアナ)

でラズピコ2使ったオーディオ帯域のスペアナとオシロスコープ作ってみたけど、ラズピコではいくつかの制限あって、中でも大きなのはDMAがちゃんと使えない、ADCの実効精度が出ないなど、イマイチなのでペリフェラルの制御機能に優れたSTM32シリーズを使ってみようと思う

部品は以下を秋月に発注したけど、F4シリーズならオーディオ帯域のFFTには能力的にかなり余裕ありそうだ

・Nucleo

https://akizukidenshi.com/catalog/g/g107723/

・BNCコネクタ

https://akizukidenshi.com/catalog/g/g105362/

・オペアンプ

https://akizukidenshi.com/catalog/g/g100069/

・ユニバーサル基板(95*72)

https://akizukidenshi.com/catalog/g/g103232/

・パスコン(0.1μ, 2.2μ, 10μ)

https://akizukidenshi.com/catalog/c/ccapacitr/

・三端子レギュレーター

https://akizukidenshi.com/catalog/g/g111299/

 

開発環境は最初はCubeIDE使うんだろうね、その後はVScodeの拡張機能かな、ラズピコの環境構築に似てはいる、但し言語は基本的にはCになるね、組み込み向けのアプリケーション考えれば当然と言えば当然だけど

CubeIDEだけインストしてみたけど、利用実績多いだろうから洗練された見かけと、サンプルコードも非常に多い

 

admin

ソーラー充電のログ取ってみた結果

ソーラーシステムの電圧ログを取ってみる

この記事のフォローになります

8日間程度のデータですが、

 

こんな感じです、ソーラー電圧は日中の光を受けて電力発生している時間帯にはピークが見えます、この先継続しても12.4V程度は下回りそうにないので十分に効果はあると言えそうです、発電量が一番低下するのは太陽の高度から冬至の頃だからその頃に再度ログ取ってみようかと思う

但し真夏の太陽と違って、晴れてもバッテリーを満充電にするようなパワーはない模様

 

admin

Visual Scripting(VS)の存在意義それほどないかもね

Unity解説本も生成A.I前提で書籍が記述されてるよ

この本一通り実行してみましたが、別にUnityだけじゃないけど、生成A.I標準の世界では、タイトル通りのことが言えると思う

VSも結局のところ、ブロック機能の種類が多いからそれらを覚えるよりも直接C#のコード書いた方が開発速度も速いと思うよ

あと気づいた点は、今のUnityのtutorialはTextMeshPro使っているけど、現在の最新はUI ToolKitだろうから、現状は併存なのだろうけどtutorialはちょっと古めかもしれない

いずれにしてもUnity6になってゲームエンジンとしてはコードを書くことはそれほど比重がないとも言える、ゲームオブジェクトのコンポーネントの多くは設定やエディタあるいはshader graph(見た目)やanimator(動き)のようなVSライクな記述方法で解決がつく割合が増えているから、コードはロジックの記述に限定とも言える

 

admin

ソーラーシステムの電圧ログを取ってみる

車のバッテリー上がり防止用のソーラー充電器のログ取るために多少の改造

① 電池電圧、バッテリー電圧、ソーラーパネル電圧の3チャネルのデートを取得するようにした

② 取り回し改善のために最低限の構造変更

・配線保護のために同サイズの基板をネジで浮かせて取り付ける、電池は浮かせた基板に両面テープで貼り付け

 

 

で、パワコンのところで接続したところ

これでしばらくデータ取ってみる

 

admin