Wiznet makers

Project overview: what PDKSFirmware actually does

msuzer/PDKSFirmware describes a practical access-control device architecture: RFID decides “open or deny,” SD card records everything, and the cloud is a sync target—not a dependency. The README emphasizes reliability properties that matter in real installations: it should operate offline, recover from power loss, then synchronize once connectivity is back.

Key features called out by the author include:

• RFID-based access control using MFRC522 (SPI)
• Local, append-only SD logging on FAT32
• Cloud synchronization over Wi-Fi
• DS3231 RTC + SNTP for timekeeping
• FreeRTOS + ESP-IDF (explicitly “no Arduino”)

Where WIZnet fits?

This project does not currently show WIZnet W5500 usage as an implemented feature in the visible documentation—W5500 is listed as “planned.” 
Also, while I can view the README reliably, GitHub did not serve the repository’s source file contents cleanly in this session (so I’m not going to invent code snippets or claim file/line-level W5500 integration).

What you can write about with confidence is that the project’s stated hardware + architecture decisions are already aligned with a later W5500 add-on: shared SPI bus, manual chip select, and network layer decoupled from logging.

Technical analysis: why this architecture makes sense?

PDKSFirmware targets an ESP32-S3 module (N16R8: 16 MB Flash, 8 MB PSRAM) and combines peripherals typical for door controllers: relay/LED/buzzer outputs, an SPI RFID reader, and an SPI SD card for persistent logs.

The most meaningful engineering choice here is the offline-first “SD is source of truth” stance. A door must unlock (or refuse) even when the internet is down, and audit logs must survive brown-outs. That’s exactly what append-only logging is good at: you avoid rewriting earlier records, reduce corruption surface area, and can replay/sync forward later. The README explicitly states “SD card is the source of truth,” “append-only binary logs,” and “network layer decoupled from logging logic.”

So why add W5500 Ethernet at all if Wi-Fi already works?

Wi-Fi is convenient, but for access control it can be the least deterministic part of the system (RF noise, AP roaming, captive portals, weak RSSI at metal doors). The repo’s roadmap calls out “Ethernet (W5500) … planned” and “Wi-Fi and Ethernet coexistence,” which is a strong hint that the author wants deployment flexibility: install Wi-Fi where it’s easy, but fall back to wired Ethernet where it must be stable.

W5500 specifically is attractive because it’s a single-chip Ethernet controller with:

• SPI up to 80 MHz
• 32 KB internal packet buffer
• 8 independent hardware sockets and a “socket programming” model
• Low-power features like Wake-on-LAN and Power Down mode

In short: W5500 gives this project a clean path to “same firmware behavior, different network transport,” which is exactly what “network layer decoupled” is supposed to enable.

Architecture and W5500 integration plan?

Because PDKSFirmware already expects multiple SPI devices (MFRC522 + SD, and later W5500), the integration challenge is less about “adding Ethernet” and more about SPI arbitration + clean interface boundaries. The README calls out “shared SPI bus with manual CS control,” which is the right baseline for three SPI peripherals.

A practical integration flow looks like this:

Two realistic approaches for W5500 on ESP32-S3

1. ESP-IDF Ethernet path (recommended for this repo’s current stack):
   Espressif publishes a W5500 Ethernet driver that plugs into ESP-IDF’s esp_eth layer. It’s explicitly documented that the W5500 has a hardwired TCP/IP stack, but the ESP driver does not use that offload stack—it integrates W5500 as an Ethernet interface underneath the normal ESP-IDF networking.
2. WIZnet ioLibrary path (socket-style, WIZnet-native):
   WIZnet’s ioLibrary_Driver provides Berkeley-socket-type APIs for WIZnet TCP/IP chips including W5500. 
   This can be a good fit if you want to lean into the W5500 “socket device” model, but it’s a bigger architectural fork if the rest of the firmware already assumes ESP-IDF networking services.

FAQ

1) Why use W5500 for an access-control system instead of relying only on Wi-Fi?

Door controllers benefit more from predictable connectivity than from peak bandwidth. The repo’s design goal is “reliably offline + recover + sync later,” and W5500 supports that by enabling a wired fallback when RF conditions are poor. With SPI up to 80 MHz and internal buffering, W5500 can sustain stable LAN comms while keeping your core access logic independent from the network state.

2) How would W5500 connect to this project’s hardware stack?

PDKSFirmware already uses SPI peripherals (MFRC522 RFID and SD in SPI mode) and explicitly notes a shared SPI bus with manual CS control. Adding W5500 typically means placing it on the same SPI bus with its own CS line, plus optional INT (interrupt) and RST (reset) GPIOs for robust bring-up. This matches the project’s “modular/extensible” hardware plan.

3) What role would W5500 play in the firmware architecture (specifically)?

W5500 should be treated as just another “transport” for the Sync Task. The core loop stays: RFID event → append-only SD log → later upload. The network layer is already described as decoupled from logging, so Ethernet can slot in as an additional interface for the same cloud sync codepath. That’s exactly the type of separation that makes field deployments easier.

4) If ESP-IDF has a W5500 driver, do you still benefit from W5500’s hardware TCP/IP offload?

It depends on the integration choice. Espressif’s W5500 driver documentation explicitly notes that although W5500 includes a hardwired TCP/IP stack, the ESP driver does not use that offload stack; it integrates W5500 under the ESP-IDF Ethernet abstraction. 
If you want the more WIZnet-native socket model, WIZnet’s ioLibrary_Driver provides Berkeley-socket-type APIs, but that’s a different software path.

5) How does W5500 compare to ENC28J60 for a project like this?

At a high level, W5500 is commonly positioned as a “more integrated” Ethernet controller: it combines MAC+PHY and supports a socket-oriented model with multiple hardware sockets, plus fast SPI and internal buffering. 
ENC28J60 is another popular SPI Ethernet option (also supported in Espressif’s driver collection), but the practical differentiator for many teams is ecosystem maturity and which driver path best matches their firmware stack (ESP-IDF esp_eth vs third-party libs).