ESP32 Devkit C での疑問点

 前回の投稿から放置状態にあった当ブログですが、再び何かしら作ろうということで、スマートコンセントもどきに取り組んでいます。

回路なども一応動作するものができたのですが、ブレッドボードから移行するために基板に用意しておいたピンソケットにESP32を取り付けたところ、なぜか動作しません。

ESP32を一旦ブレッドボードに戻し、基板上のピンソケットへジャンパーワイヤーで接続したところ、きちんと動作しました。

そんなわけで改めてブレッドボードと基板を比較してみると、GNDの結線に違いがありました。

Devkit C モジュールの 3v3を一番ピンとして半時計回りにピン番号を振っていく形で記述すると、

14:GND ブレッドボード：結線、基板：未結線

18:CMD/GND? (Devkit Cのロットにより記載揺れあり） ブレッドボード：未結線、基板：結線

32：GND ブレッドボード：未結線、基板：結線

38:GND ブレッドボード：未結線、基板：結線

という具合になってまして、ブレッドボードは唯一14番のGNDのみ接続して有る状態で動作し、他方基板側は14番を除いて全GNDを結線してある状態で動作しません。

このボードはその他にも怪しいところがありまして、USB-シリアルチップの表記がなかったり、3.3Vレギュレータの表記を削ってあったりするので、正規ルートの商品ではないのかもしれません。あるいは正規の製品の検査落ちボードを別の業者が実装したとか、そんな感じのものなのかも。

【18番ピンについて】

18番ピン(5Vピンの隣）は表記が揺れていて一番あやしい。国内店舗、もしくは秋月の通販から入手すると18番ピンのシルク表記は「CMD」なのですが、AmazonのWavesという販売者から買った5個セットはいずれもシルク表記が「GND」（ひょっとすると「CND」なのかも）となっています。写真を取ったので下に貼り付けておきます。

18番ピンにどのような機能が割り当てられているかネットで調べてみたのですが、CMDの他にSPICS0が割り当てられていて、内部のSPIフラッシュに接続されているため使用は推奨されない、とのこと。使えないならピン出しとくなよ、とは思うのですが。なので18番ピンは「結線しないのが正しい」です。

【対応】

CND?ピンについては未接続とし、14番pinはGNDに繋ぎました。

→正常動作しました。

【余談】

ちなみにですが、Devkit Cに搭載されているESP32は、2019年にマルツの店頭で買ったものはESP32-WROOM-32、2020年購入分は秋月購入分も含めてESP32-WROOM-32Dとなっています。

LinuxでSloeber+Arduino core for ESP32環境で作業していてぶち当たったこと

電光掲示板もどきプロジェクトは一応形になったので、渋々使用していたArduino IDEからSloeberへ移行してみようと思い立ちました。コンパイル時にArduino core for ESP32のファイルでコンパイルエラーが発生したのでひとまずほったらかしにしてたんですよね。

※SloeberとArduino-core-esp32のインストール方法については他所に情報がありますので割愛します。

ところで、windowsのホームディレクトリに日本語が含まれるていることに気が付かず、何気なくgithub経由でArduino core for ESP32をSloeberに適用したところ、日本語を含むパスのおかげでコンパイルエラーになったことに業を煮やし、Linux Mintに移行しました。

というわけで、以下の情報は

OS:Linux mint 19.1 Tessa
Sloeber:ver4.3.1
Arduino core for ESP32:ver1.0.2

であることを念頭に置いてください。

Arduino+74HC595+8×8nマトリクスLED（8.3）

３．RTC（Real Time Clock）がない

単純なうっかりで、ハードウェア的に時刻を保持する仕組みを作っていませんでした。
こういう場合にはRTCモジュールを使って、コイン電池でバックアップすると完璧らしいです。

しかしながら、WiFiを介してインターネットにつながるんだから、NTPで時刻取得しちゃえばいいじゃない、ということで以下のリンクを参考にNTPで取得した時刻を文字列にする関数をこさえました。

Arduinoで遊ぶページ -SimpleTime

数時間使用したときにどれくらいズレがあるのか、ということについては未確認です。基本的に時計的に常時使う感じではなくて、気が向いたときに起動する、外出するときは電源切る、という運用ですので、起動時にNTPから時刻が取得できれば気になるズレは生じません。スクロール表示する以上は必然的に表示時に秒レベルでずれてしまいます(^^;;
time.hをインクルードするとNTP周りの実装が使えるようになるのですが、先に挙げたリンクを読んだ限りでは、getLocalTime()の度にgetConfig()で指定したNTPサーバーにリクエストが飛ぶのか、といったあたりがよくわかりません。


Arduino にしても Arduino Core for ESP32 にしても何かやろうとしていることが明確なら、まず使えそうな標準ライブラリなり外部ライブラリを探すことから始めると効率が良いですね。ライブラリ自体に豊富なサンプルがついてきますし、多分作例もググれば誰か作って公開してくれているとおもいます（笑）

１．データどこから取得する？
２．データの取得と解析はどうする？
３．RTCないけどどうする <--- 今ここ

Arduino+74HC595+8×8nマトリクスLED（8.2）

２．駅別時刻表をHTTP経由で取得・解析する

マイコンのメモリは限られていますので、大規模な文字列解析はやらないほうがよさそうです。

そこで、LAN上にWEBサーバーを立ててCGIを利用することにしました。①公式サイトのデータ取得→時刻表データファイルを作成するスクリプトと、②時刻表データファイル→直近１列車を表示するスクリプトがあれば要件を満たせます。
スクリプトを分割したおかげで、それぞれの機能のみ考えればよいのでコーディングも楽になりました。時刻表のデータそのものの更新頻度はせいぜいダイヤ改正ごと、つまり長期に渡って更新されないので①については、都度手動で取得・整形する形でもなんとかなります。

ESP32からは②直近１列車表示スクリプトからHTTPでゲットする形なので、固定の形式で取得できることが保証され、名鉄公式サイトが大規模改修したとしてもESP32側の解析ロジックを書き直す必要がなくなります。

①・②とも20年くらい前に遊んでいたperlで書くことにしました。当時はperlのcgiでBBS作るの流行りましたね。perlで作る掲示板なんて本まで出版されたような記憶が。
とはいえ、ど忘れしていて別の言語で書いても良かったんではないかと後悔(^^;;
今時の動的htmlってどんな言語を使うのかしら？

Arduino+74HC595+8×8nマトリクスLED（8.1）

１．名鉄公式サイトにAPIが存在しない

駅すぱ〜とに代表される時刻（というより乗り換え）検索系サービスと公共交通機関が契約、そのサービスのAPIを利用して公式サイトを構成している様な雰囲気なので、当然お金が絡みます。APIがあるはずだけど先の理由で公開されていない、と判断しました。名鉄の場合は駅探というサービスが挟まっています。
法的にはグレーですが、商用利用ではなく個人で閉じた利用ですので大丈夫でしょう。

Arduino+74HC595+8×8nマトリクスLED（8.0）

電光掲示板もどきプロジェクトの状況です。

さんざん同じネタで引っ張っていますが、行側制御部の方式検討はひとまずおいておくとして、ソフトウェア側を作り込むことにしました。
またLEDマトリクスで遊び始めた頃より、WiFi経由で最寄り駅の直近の列車を表示したいという願望がありましたので、Arduino に追加する WiFiモジュールを検討していたところ、ESP32というマイコンといいますかWiFiチップといいますか、多機能なものがあり、Arduino IDEで開発できることからESP32 DevKitC を 秋月さんから入手して、こちらに移行してしまうことにしました。

Arduino+74HC595+8×8nマトリクスLED（6.5）

「行側制御にシフトレジスタ使うのもったいなくね？」問題の第五回です。

手持ちのICで行側制御（スキャン側）ロジック（仮）を作成して動作させてみたところ、ラッチクロックを拾ってスキャン対象自動進段するという主要な機能は実現できていましたが、クリア時の挙動に問題があることが発覚しました。

Arduino+74HC595+8×8nマトリクスLED（6.4）

「行側制御にシフトレジスタ使うのもったいなくね？」問題の第四回です。


前回はデコーダとシンクドライバの間にNORゲートを挟む方向で実装しようかな、というところまででした。

それはそうと、きちんとロジックおよびIC間の連携をチェックしていないので、簡単にシフトレジスタ＋カウンタ＋デコーダを接続し、シフトレジスタとデコーダの出力にLEDバーをつないで出力の様子をチェックすることにしました。

Arduino+74HC595+8×8nマトリクスLED（6.3）

「行側制御にシフトレジスタ使うのもったいなくね？」問題の第三回です。

前回（6.2）の末尾【今後の展開】に書いた、負論理出力でシンクドライバIC的な増幅ってどうやるの？の調査をしてみました。

手っ取り早くGoogle先生に質問するのが定番ですので「74HC138 LEDマトリクス」とベタに尋ねたところ、色々と答えてくれました。

何かしらのマイコンと74HC138を使ってLEDマトリクスを駆動する場合、74HC138をスキャン側に使い、マイコンのIOピンでパターンを指定することになります。
74HC138は3to8デコーダで、8つある出力ピンのうち入力された3bitに対応するピンを選択するという機能になりますので、当然パターン選択はできませんからスキャン側にしか使えません。

主に画像を見ながら興味を引いたものについて実際にリンク先の記事など読んでみる、という手法で色々と探って以下の解決策が有望な感じ。できれば手持ちのシンクドライバ（TBD60283）を使えたらいいな～。

【解決策その１：74HC138の代わりに74HC238を使用する】

74HC238というロジックICがありまして、機能的には74HC138と同じ3to8ラインデコーダなのですが、出力が反転・つまり正論理になっています。これを使えばシンクドライバのTBD60283を駆動できます。なんだか一番手っ取り早そうな解決策です。

【解決策その２：74HC138の出力にNORゲートを接続する】

74HC138は負論理出力ですので、GNDとのNotORをとれば74HC138の出力がLOWの時にHIGHにすることができます。ということはNORゲート（74HC02）を接続して出力をシンクドライバに接続すれば、その１と同じことができます。

【解決策その３：74HC138の出力にMOSFETを接続する】

そもそもMOSFETが何者なのかよくわからないのですが、トランジスタと同じような増幅作用を持つ代物のようです。※自分の知識不足ですので、この解決策は採用しないことにします。

【解決策その４：74HC138の出力にトランジスタを接続する】

まず検討すべき方策がこれで、適合するトランジスタはいくつかあるようです。しかしながらハンダ付け箇所がIC利用の場合よりも８か所余分に増えるので面倒くさい、という理由で採用しません（笑）

手持ちの74HC138を使うとすれば、その２：NORゲートを使うの一択ですね。

来月は74HC02を調達することにしよう。

【参考】

ピカリ館の単色LEDマトリクスパネルをRaspberry Piで光らす

流れるLED回路 改良版

32x16 LED Matrix Panel and Arduino 4953って多分MOSFETだよね？

【いろいろとヤバそうなモノ】

16×128 LED dot matrix screen 74HC138に全部直結しちゃって大丈夫なの？

Drawing on 8x32 LED matrix with 74HC154 74HC154は4to16デコーダですのでこれ動かねーわ（笑）

Arduino+74HC595+8×8nマトリクスLED（7）

ケーブルの量が多くなりＬＥＤマトリクスを整列させることが難しくなってきました。
そこでＬＥＤマトリクスを基板に固定してしまうことにしました。

オーソドックスなヘッダピンを使ってコネクタを作ることにしたのですが、作業中に無理そうなことが発覚して、急遽手持ちにあったＬ字のヘッダピンを使ってマトリクス側にコネクタを作ることになりました。この辺は電子工作の経験不足がモロに露呈した形になりました(^^;;

裏側でマトリクスのピンを曲げたうえ、ヘッダピンとマトリクスのピンの隙間は半田ブリッジでつなげるという力業でねじ伏せました。動かせれば勝ち(^^;;

それから在庫していたＬ字のヘッダピンがちょうどマトリクス３個分だったため、１個分未実装となっています。しかし今月の予算は使い切ったので、筐体ともども来月持越しです。


全体を接続してみたのですが、ケーブル長をもっと余裕持たせたほうがよかったかな、と今更思いました。きちんと検討してから作れよ、という指摘があるでしょうが、まったくごもっとも。

まぁ、この通り動作はします。マトリクスとその制御、とっても楽しいですね。専用ドライバをググるより先にシフトレジスタとかデコーダが掛かってしまったので、ずいぶん面倒くさい展開になりましたが、こちらのほうが断然面白いんじゃなかろうか。制御方式もまだまだ向上の余地があるので骨の髄までしゃぶれそうなプロジェクトになりつつあります。


【問題点】
全体のボリュームが予想よりずっと大きいので、筐体を大げさなものにしないと収まりません。たかだか2.5cm角のマトリクス4個に、ATX電源くらいの筐体を用意する必要がありそう。自分で言うのもなんですがアホっぽい（笑）

もう一点。
この基板の行スキャン制御側は、制御基板の方で一つのシンクドライバに接続されています。ということは、この基板で行側の端子をそれぞれまとめてしまえば、行スキャン制御部との接続ケーブルは一つで済んでしまいます。なんというポカをやらかしてしまったのでしょう(^^;;

まぁまだまだど素人ですから、この辺は知識と経験則でカバーできないのです。しょうがないしょうがない。

Arduino+74HC595+8×8nマトリクスLED（6.2）

「行側制御にシフトレジスタ使うのもったいなくね？」問題の第二回です。

前回(6.1)は74HC4040の動作確認でしたが、今回は74HC4040を二段接続して、その後ろに74HC138をつないで行スキャンっぽい動作が可能かどうか実験していきます。