2023年3月21日火曜日

Thonny & MicroPython

Raspberry Pi Pico。こちらは MicroPython です。

Thonny で SDカードライブラリを扱おうとしたのですが、どこにも見当たりません。

先輩にチャットしたら、ChatGPT の 回答混じりで何が正解かわからない。直接聞いたら、先輩の環境ではThonny のインストールだけでライブラリは入っていたようです。

試行錯誤の結果、以下の正攻法で sdcard.py を得ることができました。

・MicroPython のソースを GitHub から落とし、コンパイル。

Ubuntuでコンパイルした後にできた py は Windows でも利用できました。


ESP-IDF FreeRTOS その2

FreeRTOS で分かり難かった点です。

裏を取っていませんので「のよう」が多いのですが、ひとまず意図した動作にはなっています。今後、多様な条件で組んでいく中で確認できればと思います。

1. Queue size
文字列のバイト数ではなく、ポインタのバイト数を指定。sizeof で取得可。大き過ぎても小さ過ぎてもダメ。
https://stackoverflow.com/questions/67346516/using-queue-of-string-in-freertos
// Queue size
xQueue = xQueueCreate(1, 16);
//Check Queue size
Serial.println(sizeof(data)); 

2. Core と WDT
今回、priority, core, WDT の組み合わせは、なんとなく、でうまく動作しました。早々にテストに進みましたが、後日、要調整箇所です。
https://lang-ship.com/blog/work/esp32-freertos-l03-multitask/#toc6
Core1: APP_CPU_NUM without WDT
Core0: PRO_CPU_NUM with WDT 

3. loop
loop にも priolity があるとのこと。今回は1秒毎に実施するよう指定しました。
void loop() { //priolity 2, APP_CPU_NUM:Core1
  delay(1000);
}

4. tick
ESP-IDFでは、1tick = 1msec のようでした。
vTaskDelayUntil( &xLastWakeTimeSend, 1000 / hz / portTICK_RATE_MS );

5. Queue の送受信
送信はすぐに実施。受信はSDへの書き込み間隔で待機。
別の変数に格納。
xQueueSendToBack(xQueue, &accData, 0);
xQueueReceive(xQueue, &recData, SDWriteTime*1000 / portTICK_RATE_MS);


2023年3月20日月曜日

ESP-IDF FreeRTOS

引き続き MKR + IDE を実装しようかと思いましたが、一旦寝かせて SPI 2系統の M5Stack Tough に戻りました。

こちらは SPI 2系統を ESP32 の 2コアで扱えます。これを意図して購入した訳ではなかったので、とても lucky。実装の仕方によっては、センサーとの通信を邪魔せずにSDカードへの書き込みが可能となります。

そこで登場するのが ESP-IDF FreeRTOS。
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/freertos.html
https://shop.m5stack.com/products/m5stack-tough-esp32-iot-development-board-kit

  • Fully compatible with with Arduino, ESP32-IDF, and other mainstream development platforms
  • Executing Dual-core processor on FreeRTOS to run multiple tasks for better performance.

全く読まずに購入していました。2コアが必要になるとも思っていませんでしたし、コアを指定してマルチスレッドで実装するような知識もありませんでした。

調べてみると、意外と簡単。と思ったのですが、そこそこ時間がかかりました。
流れは、以下の通り。

  • センサーとの通信タスク、SDカードとの通信タスクを別に作る。
  • それぞれにコアを割り当てる。
  • タスク間のデータの受け渡し用に Queue を作成。
  • センサー値を Queueに投入し、SDカード側のタスクで取り出す。
  • 取り出した値をSDカード側で書き込み。

設定に多々ハマりましたが、それはまた後日。60秒に一度書き込みを行う設定にしたので、 他の演算やLCDへの表示もできそうです。

まだおかしな表示になる部分や、時刻の欠損を取り切れていないのですが、最低限、電源を与えると 100Hz でデータをとり続け、MicroSD に保存するプログラムができました。明日から外でテストしてみましょう。

****************************
20231230 試作品をGitHubに公開
https://github.com/T40O0/ADXL355_SPI_M5_SD_FIR.git

2023年3月11日土曜日

Azure RTOS

Azure RTOS というモノを触りました。

電子工作入門者ですので詳しい仕組みはわかりませんが、並列化には RTOS が必要とのことでした。で、探すとあったのがコレ。Free RTOS とかAzure RTOS などが検索で引っかかり、sample が目に留まった後者を選択。

まず戸惑ったのが、tx_thread_sleep() のスリープ時間。引数に10を入れると100ms、1を入れると10ms止まります。入力がmsecではないのか?と調べてみると、、、違っていました。

このサービスによって、呼び出し元のスレッドは、指定したタイマー ティック数だけ中断されます。 タイマー刻みに関連付けられている物理時間の量は、アプリケーション固有です。 
(´・ω・)ん?
TX_TIMER_TICKS を入力することはわかりましたが、物理時間がアプリ固有って、どういう意味でしょう?1TICK = 10ms がデフォルトのようですが、きっちり10msとは限らないってことでしょうか?

Azure RTOS を使用すると millis() など時間に関する関数が効かなくなります。tx_time_get()で代用すると、TX_TIMER_TICKS が効いてくる。10msec単位の制御だと、上記から1msec単位の精度が担保されているのか不安。では、ticks/secを1msecに変更するしかない。この定義は tx_api.h の中に定義がありました。

/* Define the common timer tick reference for use by other middleware components. The default value is 10ms, but may be replaced by a port specific version in tx_port.h or by the user as a compilation option.  */

#ifndef TX_TIMER_TICKS_PER_SECOND
#define TX_TIMER_TICKS_PER_SECOND       (100UL)
#endif

1tick = 10ms は、RTOSの標準みたいですね。これを1000ticksに変更してコンパイル。

が、ダメ。1tick = 10msから変更されません。ココ以外に定義されているのか?TX_TIMER_TICKS_PER_SECOND を検索すると、tx_user_sample.h でも定義できるようでした。コチラも1000に変更してコンパイル。

が、ダメ。変更されません。もともとコメントアウトされていましたので、当然といえば当然。ですが、これら以外に検索で引っかからないため、これ以上手を出せません。

またしてもココでやむなく放置。
MKRへの実装では、ブレッドボードに指すだけでセンサー取得値が不安定になる、SPI2系統を区別できていない、並列化できていない、といった具合に解決すべき点が多く残っています。PICOはセンサー値取得すら至っていませんので、それに比べるとまだマシですが。
今の能力での解決は難しそうです。

*********************************
20230316追記
そもそも MKR には SPI が1系統しかないとのこと。HPを見ると、確かにそのように書いてありました。
とすると、この機種では I2C + SPI しかないですね。

2023年3月10日金曜日

3次元の利用

入社後5年くらいの方が GEORAMA を使いたい!と言うので、一通り説明しました。

何でも吸収していく頃なのか、2日である程度はモデル化できるようになりました。
で、結果を見て「ナニコレ」。

いえ、モデル化が悪いのではなくて、与えられた 2D 図面の推定精度が悪かっただけです。それを忠実にモデル化したのでナニコレな3次元モデルができました。よくある困った話です。

今回は入社後約30~40年の方々が書かれた 2D 地質断面を後追いで 3D 化しました。この世代の方々、なかなか 3D モデルから2D 図面を切り出す発想に至りません。で、御自分のできる(と思われている)2D 地質図面の作成を先行し、CIM用に3D化を若い世代に投げるという逆順を取られるようです。で、ナニコレが出来上がります。

個人的には、2D の世界のみに生きている地質屋さんの地質断面図をあまり信じていません。それは私も含め、2D だけでは作図を誤りやすいからです(経験上、そうして作られた図面のどこかに誤りがあります)。それは、3D の世界に飛び込まないと気づきません。そして何度も誤りを見つけることを繰り返す内に、己の能力の限界を知り、3D のツールを手放せなくなります。3D で 2D をチェックしながら図面を作っていく。このトライ&エラーの過程でミスをなくせること、それをツールが簡単にしてくれることに気づいてしまうからです。
もちろん、トライせずエラーに気付かないまま成果を作り続けて40年過ごしても、土木工事は成立してきました。それはそれで幸せなのかもしれません。その方々から見ると、3D 化は手間と費用のかかる作業にしか見えないでしょう。だから本来の手順とは異なる「後追い 3D 化」を選択しつづけるのだと思います。

30年以上、地質調査を担ってこられた方の図面を見て、地質の分布がおかしいと気づく5年生。きちんとした仕事をしたいなら、早めに己の限界を知り 3D を利用するなど対応を考えるべきでしょう。


Navis+ 2023

ここ数日、CIM対応のお手伝いで、Navis+を触りました。

Ver.2023 になってから GEORAMA で 属性付与用の csv を吐き出せるようになりました。それを Navis+で読んで属性付与、といった手順です。

が、うまくいきません。単に読むだけなのですが、ダメ。

試行錯誤の結果、GEORAMA から吐き出した dwg データを編集し保存した時点で、属性付与のためのキーが消える事がわかりました。吐き出し直後のデータにしか付与できないようです。しかし、編集しないと柱状図のハッチングが Navis で表示されません。GEORAMA の柱状図の吐き出し方が Navis に対応していませんでした。

最終的には2Dの柱状図とソリッドボーリングを別に書き出し、前者のみ編集する(ハッチングを分解する)、後者に属性を付与する、といった対応で済ませました。

次年度の CIM 関連基準では属性付与作業が軽くなるようです。Navis+ を使用せずとも、属性付与ができるようになれば、ありがたいですね。


2023年3月2日木曜日

AWS のストレージ

久しぶりに AWS EC2 を使用することになりました。

今回は Windows Server。と言っても、インスタンスの立ち上げ方は Linux と同じ。以前よりも簡単になっていました。

ストレ-ジは大量、高速が必須。試用したのは以下の3種類です。

ストレージ

EC2Win

オンプレ

EBS

〇マウント可

RDP

FSx

〇マウント可

×理解不足

S3

×

〇転送可


EBS は Linux EC2 に WinSCP でアクセスしていましたので、深く考えずに試しました。で、ダメでした。RDPでの転送(コピペ)は途中で止まります。数百GBだと、なかなか難しい。ローカルドライブを共有する設定で繋いでコピーすると転送できました。
FSxはオンプレからも繋がるようですが、理解不足で give up。会社の Active Directory のドメイン管理者だったら簡単だったかな?
S3 は WinSCP でアクセスできますが、EC2 でマウントできません。いくつかツールはあるようですが。

少し触っていないと新たなサービスが増えます。適切な選択ができるよう、時々触っておかないと。

2023年3月1日水曜日

ChatGPT

ChatGPT を新人君に教えてもらったのが数か月前。
TV でも取り上げられるほど有名になりました。 

先日、ChatGPT に CSV の書き換え手順を示し、C++ & Python コードを作成してもらいました。
何度か書き直してもらい、また指示を修正することで、そこそこのモノを出してくれました。何度か書かせてみると、時として別人が書いたようなコードを出してくるのが面白い。web 上でのコード例が多いのでしょうか。
OpenMPを指示すると、Python では multiprocessing を提案して書いてくれました。この辺りも理解していますね。

ChatGPT の登場で、コードを吐かせてて、それを修正するといった作り方が選択肢として出てきました。一方、どこのコードを覚えて吐き出された内容なのかがわかりません。もし、丸々コピペなどされていたら、著作権侵害になりそうです。

英語への翻訳も、専門的な内容がよくわかる文章になります。情報分野など参照例の多いものは翻訳サイトよりも納得できる文章をだしてくれるるのではないでしょうか?

Midjurney や ChatGPT、それぞれが進化し、組み合わさってまた新たなアイデアが生まれるのでしょう。本邦産が出てこないのは残念ですが、面白い時代になりました。