Cohesive Firmware Pattern for W55RP20 Rack Controllers (HTTP + Telnet, Unique MAC & Static IPs)

[clearpaint]

Hi all,

Apologies upfront for the long message, but I'm trying to be thorough in my initial message as to not waste anyones time!

We’re building a rack of test‑equipment “blades” around the W55RP20‑EVB‑PICO using the Arduino W55RP20lwIP.h approach.
Each board must expose HTTP and Telnet control while booting with its own
static IP and factory‑assigned MAC. We have almost every feature working on its own,
but haven’t found a single, maintainable firmware structure that ties it all
together. The examples for the newer W55RP20 are minimal and piecing together what will actually work together from previous versions of HW has been a bit of a nightmare.

---

✔️ Proven in Isolation

• Ethernet : lwIP + W55RP20 driver boots, DHCP Works can ping in both directions(But not static IP on local usb/ethernet)
• LittleFS : mounts, reads files..
• HTTP : minimal GET handler on port 80
• Telnet : CLI on port 23 that echoes commands
• Serial : SPI / I2C/ UART / GPIO loopbacks etc basic stuff works.

---

📂 Assets on Hand

• Spreadsheet of unique MAC addresses and static IPv4s
• /rack.json template:
  {
  "mac": "02:00:00:00:00:01",
  "ip": "192.168.10.41",
  "netmask": "255.255.255.0",
  "gateway": "192.168.10.1"
  }

---

❓ Where We’re Stuck

1. Project structure
   • Best pattern to keep HTTP, Telnet, and LittleFS in one tree without
   #include spaghetti? Understating what "WiFi" libs work as expected seamlessly with W55RP20lwIP.h.

2. Static‑IP provisioning
   • How do you flash unique MAC/IP to dozens of boards without recompiling
   each one?

3. Concurrency
   • Safer to poll both services in loop() or dedicate separate Wiznet
   sockets and multiplex?

4. Example scarcity
   • Any public repos, gists, or blog posts that combine W55RP20 + LittleFS +
   multi‑service networking?

5. Control‑protocol choice
   • Long‑term, would you drop Telnet and go all‑HTTP/REST or WebSockets?

---

🙏 What I'm Asking

• Show‑and‑tell:
  • If you’ve shipped or prototyped a multi‑service W55RP20 project,
  how did you organize the sources?

• Provisioning tactics:
  • Scripts, DFU tricks, LittleFS images—what worked best for bulk MAC/IP
  flashes?

• Gotchas:
  • Memory pitfalls, socket limits, re‑entrancy issues when mixing Telnet and
  HTTP on lwIP?

Napkin sketches, war stories, or repo links all welcome.

Thanks for any pointers!

— Derrick (San Diego)

[earlephilhower]

Not really sure what the issue you're expecting with (1) is, but anything that runs with WiFiClient or WiFiServer or WiFiUDP will run with the W55RP24 LWIP stack. It's just a dumb Ethernet adapter for the core, same as everything from the 3 WiFi chips or the other 4 wired Enet ones.

Reading between the lines, though, you cannot mix WizNet socket API with LWIP, however, so if you're using sockets for things like telnet and LWIP onboard for WebServer, that's not going to end up well. Feel free to use the WizNet hardware sockets, but don't do any LWIP on the core. Just use their proprietary libs and their own examples.

For (2) if you really don't want DHCP ever to distribute the info, seems to me that you'll need to send it in as part of the programming. Rebuild and upload a custom LittleFS w/that info in a file for every board (trivial shell scripting and fast, not like recompiling source code) or rewrite a custom EEPROM flash sector as part of the upload process. There are probably also some ways of repeating the final link stage in a script and injecting different blobs per device (i.e. what's done w/OTA here).

My $0.02 for (5)...it's 2025 and anything using raw unencrypted telnet is just asking for trouble. TLS-encrypted, custom CA signed REST interfaces with appropriate access controls on top of that (i.e. using both server and client certs) feels like something more from this millennium. MQTT over TLS is common for these kinds apps as well, but again has encryption and authentication baked in.