2021年1月5日火曜日

ESP32をW5500で有線LAN接続してmDNSしてみた

 最近はESP32で遊んでいますがWi-Fiの環境が不安定な場合、有線LANで接続できるとうれしいかなということでW5500を積んだボードを見つけて早速やってみました。

ESP32にセンサーをつないでMQTTでサーバへデータを投げるんですが、Wi-Fiでつなげた場合はmDNSを使ってサーバーのhostnameで接続できるんですが、有線LANでちょっとトラブったので覚書としてアップしておきます。

開発環境


Windows10
VSCode + PlatformIO
ESP32-DevkitC

platformio.iniは
[env:esp32doit-devkit-v1]
platform = espressif32
board = esp32doit-devkit-v1
framework = arduino


有線LANの接続


W5500についてはAmazonでW5500イーサネット ネットワークモジュールを購入しました。W5500は3.3V駆動なんですがこのボードは5Vでも動くようにDCDCコンバータが搭載されているのが特徴でしょうか。
  • 5V = 5V
  • GND = GND
  • RST = GPIO4
  • MISO = GPIO19
  • MOSI = GPIO23
  • SCS = GPIO5
  • SCLK = GPIO18 

ネットで検索するとESP32でW5500を使って有線LANを行っている記事は多数みうけられますが、基本はSPI接続をすればライブラリがあるのでそれ程戸惑うことはないと思います。
ポイントとしてはEthernetライブラリではなくEthernet2ライブラリを使用することでしょうか。
後、多くの記事ではリセットピンについては接続していないようですが、ESP32がリセットされた場合にW5500側もリセットした方がいいかなと思い接続してみました。

プログラムはこんな感じです。
    byte mac[] = { 0xDE0xAD0xBE0xFE0xFE0x01 };    
    pinMode(4OUTPUT);
    digitalWrite(40);
    delay(25);
    digitalWrite(41);
    delay(500);
    Ethernet.init(5);
    Ethernet.begin(mac);
    Serial.print("IP address: ");
    Serial.println(Ethernet.localIP());

後はMQTTライブラリでサーバに接続すれば完了です。


mDNSでサーバーのIPアドレスを取得する


ここまでは問題なかったのですが、Wi-Fiで接続しているときはサーバーのIPアドレスはESPmDNSを利用して取得していました。問題はESPmDNSはWi-Fi接続を前提として作成されているのでW5500(Ethernet2 )では利用できません。
そこでW5500でmDNSを利用できるMDNS_Genericを使用することにしました。
PlatformIOでライブラリをインストールすればサンプルにResolvingHostNamesもあるので簡単かなと・・・

まずはREADMEのLibraries' Patchesの「4. To fix Ethernet2 library」の指示に従いEthernet2のソースにパッチ(ファイルの置き換えと追加)を当てます。
後はサンプルを参考にソースをちょいちょいと作成してコンパイルすると「beginMulticast」の未定義エラーになってしまいました。
ソースを眺めてみると確かにパッチを当てたEthernetUdp2.cppにbeginMulticastはあります。

問題はMDNS_Generic.hにありました。

MDNSクラスのプライベート変数として_udpがUDPクラスの変数として定義されていますが、beginMulticastはEthernetUDP2.hで定義されているEthernetUDPクラスのメソッドとして定義されています。サンプルでもEthernetUDPクラスのインスタンスをMDNSのコンストラクタで渡しています。EthernetUDPクラスはUDPクラスを継承しているのでエラーになりませんが、beginMulticastメソッドを使うところでUDPクラスでは未定義になってしまいます。

ということでMDNS_Generic.hの以下の2か所の修正を行います。

class MDNS
{
  private:
    EthernetUDP*              _udp;

  public:
    MDNS(EthernetUDP& udp);

さらにMDNS_Generic_Impl.hも以下の2か所の修正を行います。

//#include <Udp.h> <-コメントアウト
#include <EthernetUDP2.h>

MDNS::MDNS(EthernetUDPudp)
{

これで無事にコンパイルは通りました。


hostnameの長さが固定?


コンパイルも無事に通り実行してみると、なぜかリブートを繰り返します。
仕方がないのでソースを眺めてみると、検索に失敗した場合に発生しているようです。

検索結果を返すコールバック関数を呼び出すメソッド_finishedResolvingNameメソッドでアドレス例外が発生しているようです。検索できなかった場合、IPアドレスがNULLで_finishedResolvingNameが呼び出されるのですが、それが原因でした。文字列のIPアドレスをIPAddressクラスのインスタンスに変換してコールバックを呼び出していますが、ここで文字列がNULLなのでアドレス例外が発生していました。

    this->_nameFoundCallback((const char*)nameipAddr == NULL ? INADDR_NONE : IPAddress(ipAddr));

これでリブートは収まりましたがまだ検索できていないようです。

    #define _MDNS_LOGLEVEL_ 4
    #include <Ethernet2.h>
    #include <MDNS_Generic.h>

とするとデバッグログをSerialに出力してくれるのでログを確認すると、アドレス解決ははできているようですが、なぜか解決不可となってしまいます。

またソースを見る羽目に・・・
本当にデバッグしてあるのかな?

                  //KH, to report name Resolve only UDP packet has corect size of 48
                  if (48 == udp_len)
                  {
                    // KH debug
                    MDNS_LOGINFO1("::_processMDNSQuery: to report IP, buf ="String((uint8_tbuf[0]));
                  
                    this->_finishedResolvingName((char*)this->_resolveNames[0], (const byte*)buf);
                  }

とudp_lenが48バイト固定の判定している部分が原因でした。
応答のUDPパケットのサイズを48バイト固定にしているので、hostnameの長さが14バイト(ドメインは.localで固定)でないと駄目なようです。

ということでパケットサイズのチェックは以下のように修正しました。

                  uint16_t l = sizeof(DNSHeader_t) + (strlen((const char *)this->_resolveNames[0])+2) + 4 + 6 + dataLen;
                  if (l == udp_len)
                  {
                    // KH debug
                    MDNS_LOGINFO1("::_processMDNSQuery: to report IP, buf ="String((uint8_tbuf[0]));
                  
                    this->_finishedResolvingName((char*)this->_resolveNames[0], (const byte*)buf);
                  }


ちなみにdataLenはIPアドレスの長さですが、これも4バイト固定(この部分の少し上でチェックしていました)になっているのでIPv4限定となります。いまのところIPv4も割り当てているのでこれで良しとしました。

0 件のコメント:

コメントを投稿

MicroSDカードアダプタでWindows10がクラッシュ

事の初め  Raspberry Pi 4のスタータキットをAmazonで購入したところ、MicroSDカードをUSB-TypeAとTypeCで利用できるようにするアダプタがついてきました。非常にコンパクトで良さげです。 TypeAの方ではチョコチョコと使っていましたが、特に問題は...