PCをグレードアップしたおかげで、開発環境も快適度が向上してますが、ESP32系のコンパイル、アップロードはまだまだ時間がかかります。(というより、どんなに速くなってもそれに慣れると満足しなくなる、という性)。
RamDiskの使用やアップロード速度Upを試した覚書です。
2022/6/1更新
内容はESP32-WROOM-32Eについでです。
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は7年前BTOPCを購入。当時割とハイスペックなcore i7-4790、16GB、グラボRTX720(後にRTX1060)。2年前にSSD1GBを起動diskに換装。
今でもわりとサクサク動きますが、シミュレーションや複数開発環境開くと重い時があるので、心機一転CPU・MBごと交換することに。
観葉植物アンスリウムは直射日光を嫌いますが、でも、暗すぎてもダメだと言う。
生育例では「明るい窓際」と書いてありますが、なかなか難しい。
我が家の窓際は込み入っていて、すこし奥まった場所のアンスリウムには、
たぶん適当な日照は無いようです。
他にも直射日光に弱いもの多数。
そこで・・・
12V のアダプタでドライブし、Amazonで購入したスマホアームスタンドに格納
回路はブレッドボードに組んでそのまま搭載
メリハリを利かすため、日中のみ補助し、夕方は消灯するようにCDSでON/OFF
このパネルは発熱するので、一応温度確認。
上昇は25度以下に収まっている
~~~3/1更新~~~
1時間ほど放置すると、室温15℃で55℃になりました。上昇は40℃です。
夏場の35℃では75℃かぁ、壁際で40℃超すと80℃越えですな。夏は消すとしますか。
結構明るいでしょ。
部品をストックしているペール缶の保守作業です。
過去の再生作業のページ
数か月に一度のシリカゲル再生作業。今回は予備のシリカゲルもピンク化してたので、一気に再生することにしました。
夏季に行うと湿度が高いので難易度が上がります。乾燥のこの時期にやるのが一番効率良い!
うーん、シリカゲルだけでは湿度証明にはならないですけど、自主的に管理です。
とはいえ、やってみないとコツはつかめません。
せっかく温めても粗熱とるときに吸湿してしまう・・・らしい
というわけで、相対湿度40%アンダーの今日は最適の日です。
「インジケーター」とも呼ぶらしいが、塩化コバルト添加粒の色を「青」にしたい
今回は量が多いので2分→3分に増やしました
一回加熱するごとに高温になってるので、その都度粗熱をとります。
この時、下の粒が放出した蒸気が上の粒に吸湿するのを出来るだけ防止するようにファンであおりながらかき混ぜました。
へたこくと、またピンクに戻ってしまうのです。
繰り返しやったおかげで、なかなな良い色です。
あまり時間をかけるとピンクに戻るので、三回目のレンチン後、うちわとファンで思いっきり仰いで冷ましたのちに、袋詰めして完了!
ちなみに、袋には目打ちで穴をあけておく。水切りゴミ袋と同じ原理です。
とりあえずコンパイラは通るんです。いままで大丈夫だったのが急にエラーがでたり、突然直ったり頭痛いです。
この現象、メジャーなMPLAB Xの不具合らしいです。
通常はこのように補完が効きます。おかげでこれに頼り切りです。
こうなる規則性がわかりませんが、日をあけてプロジェクトを開くとこうなってることも・・・
というわけで、個別のチップ定義ファイルを(今回の例はpic16F1459.h)を自力でインクルードして解決しました。
むむっ、気のせいか以前のXC8とフォルダ構成が違うような? \procなんてあったっけ?
IO定義ファイルのパスの問題かな?とうすうす感じていますが確認はしてません。いちいちコンパイラパスを入れるのも面倒だしXC8のバージョン変わったらと思うと・・・。ならまずは目につくソースで埋め込んだほうが楽、と判断しました。
どなたか成功した方いらっしゃいましたら、ぜひご教授お願い致します。
深く追求しませんが、一度読込まれるとプロジェクト内に固定されるのかしら?
定義ファイルを毎回インクルードして私の環境では弊害はなさそう。日にちをあけて沼にハマるのもいやなので、ソースにIO定義ファイルを読込む習慣をつけることにします。
この内容は、間に合わせ対策の単なる覚書ですので、内容についての正確性・信憑性は全くないのでご容赦ください。
VSCODE+pymakrではフォルダ(下位フォルダ含む)内のソースは自動でアップロードできる反面、データファイル(例えば.CSVや.txtなど)は同じフォルダに入れていてもパッケージ化しないとターゲットにロードできないようです。
したがって、インタープリタでファイル読込部分でエラーが出ます。これはターゲットの中には該当するデータファイルがロードできてないので存在しないためです。
with open(’データファイルパス’, 'r') as f: #OSError: [Errno 2] ENOENTがでる
間に合わせの対策として、データファイルの拡張子を.pyにすることでとりあえずターゲットへロードさせることが可能です。データファイル内容が、ほかのソースコードと被らないことが条件ですが。