Azure RTOS

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

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

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

https://learn.microsoft.com/ja-jp/azure/rtos/threadx/chapter4#tx_thread_sleep

このサービスによって、呼び出し元のスレッドは、指定したタイマー ティック数だけ中断されます。 タイマー刻みに関連付けられている物理時間の量は、アプリケーション固有です。 

(´・ω・)ん?

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 が１系統しかないとのこと。HPを見ると、確かにそのように書いてありました。
とすると、この機種では I2C ＋ SPI しかないですね。

3次元の利用

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

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

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

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

個人的には、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+ を使用せずとも、属性付与ができるようになれば、ありがたいですね。

AWS のストレージ

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

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

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

ストレージ	EC2（Win）	オンプレ
EBS	〇マウント可	〇RDP
FSx	〇マウント可	×理解不足
S3	×	〇転送可

EBS は Linux EC2 に WinSCP でアクセスしていましたので、深く考えずに試しました。で、ダメでした。RDPでの転送（コピペ）は途中で止まります。数百ＧＢだと、なかなか難しい。ローカルドライブを共有する設定で繋いでコピーすると転送できました。

FSxはオンプレからも繋がるようですが、理解不足で give up。会社の Active Directory のドメイン管理者だったら簡単だったかな？

S3 は WinSCP でアクセスできますが、EC2 でマウントできません。いくつかツールはあるようですが。

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

ChatGPT

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

先日、ChatGPT に CSV の書き換え手順を示し、C++ & Python コードを作成してもらいました。

何度か書き直してもらい、また指示を修正することで、そこそこのモノを出してくれました。何度か書かせてみると、時として別人が書いたようなコードを出してくるのが面白い。web 上でのコード例が多いのでしょうか。

OpenMPを指示すると、Python では multiprocessing を提案して書いてくれました。この辺りも理解していますね。

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

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

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

SD ライブラリ

MicroSD カードへの書き込みも、ボードにバンドルされるライブラリによって差がありました。

SAMD21 (Arduino MKR Wifi 1010)
書き込みモードで新たにファイル作成。その後、同じコマンドを繰り返して追記。
SD.open("/Log.txt", FILE_WRITE)

ESP32(M5 Stack Tough):
書き込みモードで新たにファイル作成。
SD.open("/Log.txt", FILE_WRITE)
その後、追記。
SD.open("/Log.txt", FILE_APPEND)

MKR で SD.open("/Log.txt", FILE_WRITE)　を繰り返し、追記していたのですが、それをM5に持ってくると前の書き込みが消える。同じ SD という名前のライブラリなのに、紛らわしい。

この辺り、初心者が通る道なのでしょうね。覚えました。

M5Stack VSPI + HSPI

ここ数週間、M5 と Arduino の SPI 通信にハマっています（現在進行形）。

M5Stack Tough や Arduino MKR wifi 1010 に加速度センサーを付けて波形を取れるようになりました。それをロギングするのに MicroSD を使用しようと目論見。

まずは M5。 こちらには TF カードモジュールが実装されています。SD.begin()に TF が使用している４番を割り振ってから、そこにカードを突っ込むだけ。ではダメでした。コンパイル直後は正しい値を示すものの、電源を入れなおすと加速度値が 0.00 になります。これが改善せず、放置。

次に MKR。 こちらも TF カードモジュールを加えるとダメ。取得値の桁が変わります。SDに書き込めるのでCSピンは正しく機能しているはず（と思いたいがダメなのでしょう）。コチラはブレッドボードに指していたので、TF モジュールやワイヤー順にを取り除いてみました。結果、MKR ボードに指すだけでも値が不安定になります。接触抵抗抵抗？電流不足？速度？
ブレッドボードを使用しない場合も試してみましたがダメ。で、放置。

似たような症状でしたので、少なくともSPIは干渉しているのでしょうと想像し、センサーを HSPI に、TF を VSPI に切り分けてみることにしました。M5 の接続は I2C と GPIO ポートを利用し、TFと物理的に分けました。

この段階でようやく理解したのが、SPI ライブラリが M5 と MKR で異なっている点。M5 は SPI.begin()にピン番号を引数として指定できたのですが、MKR ではダメ。M5 では SPIClass hspi（HSPI） が通るのに、MKR ではダメ。どちらを使うかはボードを選択したときに決まるようですね。esp32 と SAMD21 の違いでしょうね。

その後、Google先生や ChatGPT師範に教わるも進展なし。時間を溶かしながらも、ようやく M5 だけ通信ができました。以下の手順です。

・I2Cポート、GPIOポートに接続
・M5.In_I2C.release() で I2C をリリース。
・ピンを割り振って起動
 //spi2.begin(sckPin, miPin, moPin, csPin);
 spi2.begin(26, 36, 32, 33);
 pinMode(csPin, OUTPUT);
 digitalWrite(csPin, HIGH);

M5 では SPIClass hspi（HSPI） は通りますが不要でした。これ、ハマりどころでは？https://forum.arduino.cc/t/esp32-spi-accelerometer/1004705

web 上に情報がたくさんあるので素人でもなんとかなるでしょう、と軽い気持ちで始めたのですが、それは間違いでした。同じ名前のライブラリでも機種によって異なる、たくさんあるコードや情報には新旧玉石が混在。欲しい情報がなかなか見つかりませんでした。想定に反し、苦戦しそうです。

この先、M5 もディスプレーを begin すると TF と干渉するのでしょうか。うーん。
放置していた Raspberry Pi Pico へ進みましょうか。

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