Nos últimos dias, depois de longas hesitações, fiz uma tentativa séria e bem-sucedida em fazer funcionar a rede Ethernet cabeada dos módulos DTWonder que estou empregando na automação residencial. O Wi-Fi tem funcionando bem para mim, mas é prudente ter um plano B, que está disponível "de graça".
A problemática: esses módulos vêm com o chip de rede JL1101, que não é suportado nativamente pelo MicroPython. O fabricante desenvolveu um driver PHY para ESP-IDF, útil para quem desenvolve em C. Sempre evitei ativamente lidar diretamente com o ESP-IDF e com o processo de build do MicroPython, mas para tirar esse coelho da cartola, não havia outra saída.
No final das contas, não foi realmente difícil. Basta adicionar o driver PHY ao ESP-IDF e adicionar a referência ao novo driver no MicroPython. Se interessar a alguém, aqui está a imagem do MicroPython 1.22.2 para ESP32/DTWonder com suporte a JL1101. Mas o que gostaria de ressaltar aqui é o quanto ajuda um bom padrão de indústria.
O chip ESP32 tem suporte a Ethernet cabeada. Isto não quer dizer que todo ESP32 vem com uma porta de rede. A rede Ethernet tem duas camadas: MAC e PHY. MAC é a camada de enlace, o "cérebro" do protocolo. PHY é a camada física, a tradução da informação digital de/para sinais elétricos analógicos. O ESP32 contém apenas a camada MAC. Outro chip, de outro fabricante, vai fazer a camada PHY.
O padrão Fast Ethernet (100Mbps) inclui a definição de uma interface elétrica padronizada entre MAC e PHY, denominada MII (Media Independent Interface). O IEEE anteviu que MAC e PHY seriam delegadas a chips separados, e que é desejável que chips de quaisquer fabricantes sejam compatíveis entre si. Uma variante do MII é o RMII (Reduced MII), que usa metade dos fios. O chip ESP32 implementa o RMII, e qualquer chip PHY com interface RMII pode ser pareado com ele.
O chip PHY não é uma commodity completa; ele pode ter alguns recursos a mais ou a menos, a configuração interna é definida pelo fabricante, então ainda é necessário haver um driver escrito em C para cada chip PHY. Mas o ESP-IDF faz o trabalho pesado e o driver tende a ser bem simples (se comparado e.g. a um driver de rede do Linux). No meu caso, não escrevi o driver, apenas reaproveitei um do projeto ESPHome.
É interessante o quanto facilita a nossa vida e barateia os nossos produtos um padrão que a) existe, b) enxergou longe, e c) é completo sem ser barroco.
O MII/RMII é para interfaces Fast Ethernet ou 100Mbps, embora suporte o fallback para 10Mbps. Padrões semelhantes existem para Gigabit e 10 Gigabit: GMII, RGMII, XGMII, QGMII, etc. mas não espere que seu microcontrolador favorito suporte um desses, pelo menos não hoje. Nas antigas placas de 10Mbps, existia um padrão denominado AUI (Attachment Unit Interface).
Quem é macaco velho na profissión deve lembrar das placas de rede NE2000, usadas em redes Novell. Elas possuíam a saída coaxial e também um conector de 15 pinos que parecia uma porta de joystick e ninguém sabia para que servia. Descobri incidentalmente que eram portas AUI quando fizemos um link de fibra ótica e quem nos vendeu a solução conectou os transceivers nessas portas (usar servidores Novell como roteadores era muito mais barato que adquirir switches de fibra).
A interface AUI é mais "burra" que a interface MII, mas a ideia é basicamente a mesma. Na verdade, os arquitetos da Ethernet original imaginavam que a placa de rede e o transceiver seriam sempre adquiridos separadamente. As placas de rede NE1000 e NE2000, desenvolvidas pela Novell, foram as primeiras a vir "prontas para usar" com um transceiver coaxial embutido.
Apesar de tecnicamente medíocres, as placas NE2000 eram baratas e faziam o seu trabalho. A placa era barata de propósito, e a Novell permitia que se fabricassem clones sem pagar royalties. A intenção final era difundir a tecnologia Ethernet e vender mais cópias do Novell Netware, suplantando concorrentes como Token Ring e ARCNet.
O meio físico selecionado pela NE2000 original era o cabo coaxial RG-58, velho conhecido dos técnicos de rádio, e os conectores BNC são encontráveis em qualquer lugar. A rede Ethernet coaxial tem ainda a vantagem de não precisar de hub.
Não é um exemplo de altruísmo, mas é um exemplo de bom direcionamento da indústria. Não tem um mercado para seu produto? Construa um mercado então, oferecendo os indispensáveis acessórios de forma acessível ao cliente, tanto no preço quanto na facilidade de instalação.
Apesar do "R" do RMII significar "Reduzido", ainda é notório que precisamos muitos fios para fazer a conexão RMII entre um chip ESP32 e um chip Ethernet PHY. São 10 pinos do controlador que deixam de estar disponíveis para outras tarefas.
O outro detalhe é que o clock do RMII é 50MHz. Só é possível usar RMII no ESP32 porque há suporte de hardware. Não existe a menor chance de usar RMII num Arduino convencional de 8 bits. Além disso, há a pilha TCP/IP que não caberia na memória de um Arduino.
Mas existem chips Ethernet que a) comunicam-se com o controlador via SPI e/ou b) implementam a camada MAC Ethernet e/ou pilha TCP/IP por si mesmos. A interface SPI é um padrão da indústria para comunicação entre chips de qualquer natureza. A parte boa é que, além de ser uma interface genérica, ela só precisa de 3 fios que ainda são compartilháveis com outros periféricos SPI.
No caso do Arduino de 8 bits, um "breakout" Ethernet SPI com pilha TCP/IP própria é a salvação da lavoura para conectar o controlador à Internet. Chips como o W5100 e o W5500 são espécimes bem conhecidos dos makers. Este arranjo é bom para comunicação de pequenos volumes de dados, pois nem o Arduino nem o SPI conseguiriam manter comunicação na velocidade de 100Mbps.