PCをグレードアップしたおかげで、開発環境も快適度が向上してますが、ESP32系のコンパイル、アップロードはまだまだ時間がかかります。（というより、どんなに速くなってもそれに慣れると満足しなくなる、という性）。
RamDiskの使用やアップロード速度Upを試した覚書です。
2022/6/1更新
内容はESP32-WROOM-32Eについでです。
Thread.Sleepの代わりにTask.Delayを使おうとしたら、エラーがでて使えない。
同じVS2019でも、Task.Delay使えているプロジェクトもあるので、なにが違うのか解消するのに時間をとられたので、その顛末の覚書。ひょっとしたらそのプロジェクト製作時も悩んだかもしれないので、しっかり記録しておこう。
ターゲットESP32をESP-IDFで使う覚書です。I2Cマスターなので目新しいことは無いですが、dsPICやSTM32と混在して開発していると混乱しやすいので、ESP32用のひな形としてコーディングしました。
PlatformIOで開発で、シリアルポートが複数ある場合はアップロードのポートが自動で割り振られてしまい、またシリアルモニターを毎回選択しなければならない、というのを避ける方法の覚書。ESP32以外のターゲットはわからないので限定です。
ESP32-WROOM-32はDevkitCで使う分にはオート書き込みができて快適ですが、単体や3rdパーティのブレークアウトボードではIO0をLOWにしたままENをチョン、とやらなければロードできないのが多くて面倒です。
そこで秋月のUSBシリアル変換を改造し、オート書き込みができるようにしました。
とりあえずの対象は同じく秋月のAE-ESP32-WROOM-32E-MINIです。
※注）AE-ESP32-WROOM-32E-MINI単体で書き込むときはボードの改造も必要。
メインPCは７年前BTOPCを購入。当時割とハイスペックなcore i7-4790、16GB、グラボRTX720（後にRTX1060）。２年前にSSD1GBを起動diskに換装。
今でもわりとサクサク動きますが、シミュレーションや複数開発環境開くと重い時があるので、心機一転CPU・MBごと交換することに。
観葉植物アンスリウムは直射日光を嫌いますが、でも、暗すぎてもダメだと言う。
生育例では「明るい窓際」と書いてありますが、なかなか難しい。
我が家の窓際は込み入っていて、すこし奥まった場所のアンスリウムには、
たぶん適当な日照は無いようです。
他にも直射日光に弱いもの多数。
そこで・・・
日中の日差しを補助するランプを作ることにしました
秋月の太陽光ＬＥＤモジュールを二個使う
１２V のアダプタでドライブし、Amazonで購入したスマホアームスタンドに格納
LM358Nでウインドコンパレータを組む。CDSで日中のみ点灯。
回路はブレッドボードに組んでそのまま搭載
メリハリを利かすため、日中のみ補助し、夕方は消灯するようにCDSでON/OFF
LEDはアルミt1.5に熱伝導テープで張り付け。温度も確認する
このパネルは発熱するので、一応温度確認。
上昇は25度以下に収まっている
～～～3/1更新～～～
1時間ほど放置すると、室温15℃で55℃になりました。上昇は40℃です。
夏場の35℃では75℃かぁ、壁際で40℃超すと80℃越えですな。夏は消すとしますか。
完成！
結構明るいでしょ。
部品をストックしているペール缶の保守作業です。
過去の再生作業のページ
数か月に一度のシリカゲル再生作業。今回は予備のシリカゲルもピンク化してたので、一気に再生することにしました。
夏季に行うと湿度が高いので難易度が上がります。乾燥のこの時期にやるのが一番効率良い！
除湿庫もたない場合の最低限の対処
うーん、シリカゲルだけでは湿度証明にはならないですけど、自主的に管理です。
電子レンジでできる
とはいえ、やってみないとコツはつかめません。
せっかく温めても粗熱とるときに吸湿してしまう・・・らしい
というわけで、相対湿度40％アンダーの今日は最適の日です。
センサー粒が全部ピンク
「インジケーター」とも呼ぶらしいが、塩化コバルト添加粒の色を「青」にしたい
６００W３分を４回繰り返す。
今回は量が多いので２分→３分に増やしました
一回加熱するごとに高温になってるので、その都度粗熱をとります。
この時、下の粒が放出した蒸気が上の粒に吸湿するのを出来るだけ防止するようにファンであおりながらかき混ぜました。
へたこくと、またピンクに戻ってしまうのです。
繰り返しやったおかげで、なかなな良い色です。
粗熱取って格納
あまり時間をかけるとピンクに戻るので、三回目のレンチン後、うちわとファンで思いっきり仰いで冷ましたのちに、袋詰めして完了！
ちなみに、袋には目打ちで穴をあけておく。水切りゴミ袋と同じ原理です。
とりあえずコンパイラは通るんです。いままで大丈夫だったのが急にエラーがでたり、突然直ったり頭痛いです。
この現象、メジャーなMPLAB Xの不具合らしいです。
IO定義にエラーマークが付き補完が効かない
IO定義補完きかないのはきついです
通常はこのように補完が効きます。おかげでこれに頼り切りです。
ある日、突然こうなる。【Unable to resolve identifire】ｷﾀｰｰｰｰ
こうなる規則性がわかりませんが、日をあけてプロジェクトを開くとこうなってることも・・・
自力で個別のチップ定義ファイルをインクルードで脱出！
【xc.h】インクルードしてるのに
というわけで、個別のチップ定義ファイルを（今回の例はpic16F1459.h）を自力でインクルードして解決しました。
むむっ、気のせいか以前のXC8とフォルダ構成が違うような？ \procなんてあったっけ？
セッティングでコンパイラパスを指定してみるのも手か？
IO定義ファイルのパスの問題かな？とうすうす感じていますが確認はしてません。いちいちコンパイラパスを入れるのも面倒だしXC8のバージョン変わったらと思うと・・・。ならまずは目につくソースで埋め込んだほうが楽、と判断しました。
どなたか成功した方いらっしゃいましたら、ぜひご教授お願い致します。
不思議なことに一度パスすると、インクルードコメントアウトしてもエラーはでない
深く追求しませんが、一度読込まれるとプロジェクト内に固定されるのかしら？
定義ファイルを毎回インクルードして私の環境では弊害はなさそう。日にちをあけて沼にハマるのもいやなので、ソースにIO定義ファイルを読込む習慣をつけることにします。
この内容は、間に合わせ対策の単なる覚書ですので、内容についての正確性・信憑性は全くないのでご容赦ください。
VSCODE＋pymakrではフォルダ（下位フォルダ含む）内のソースは自動でアップロードできる反面、データファイル（例えば.CSVや.txtなど）は同じフォルダに入れていてもパッケージ化しないとターゲットにロードできないようです。
したがって、インタープリタでファイル読込部分でエラーが出ます。これはターゲットの中には該当するデータファイルがロードできてないので存在しないためです。
with open(’データファイルパス’, 'r') as f: #OSError: [Errno 2] ENOENTがでる
間に合わせの対策として、データファイルの拡張子を.pyにすることでとりあえずターゲットへロードさせることが可能です。データファイル内容が、ほかのソースコードと被らないことが条件ですが。
