Wiznet makers

Apache Mynewt is a modular RTOS platform for microcontrollers, built around a preemptive kernel, package-based builds, and remote device management tools. In current mainline mynewt-core, WIZnet’s W5500 appears as a new net/ip/wiznet package that pulls in the external ioLibrary_Driver, so its role is not “another Mynewt Ethernet MAC driver,” but a hardware-offloaded socket and TCP/IP path exposed through Mynewt’s package and configuration system.

What the Project Does

apache/mynewt-core is the core operating-system repository for Apache Mynewt. The project is aimed at embedded systems where power and cost matter, and the official documentation describes it as an OS for devices such as connected locks, lights, and wearables. At the kernel level, Mynewt provides a multitasking, preemptive RTOS with mutexes, semaphores, memory pools, watchdog support, time management, and networking buffers.

What makes Mynewt distinct is its project model. The official concepts page centers the workflow on project, package, target, and configuration, and the platform also ships newtmgr for remote device management. In practice, Mynewt is more than a scheduler: it is an embedded build and deployment framework with an RTOS underneath.

Compared with FreeRTOS, Mynewt feels more integrated. FreeRTOS officially presents itself as a kernel plus libraries, with an emphasis on reliability, ease of use, tiny footprint, and wide device support. Mynewt, by contrast, foregrounds package composition and target-based builds, so it behaves more like a curated embedded platform than a kernel-first toolkit. Compared with Zephyr, Mynewt is lighter in workflow complexity but also smaller in ecosystem scale; Zephyr’s official build model is explicitly built around CMake, Devicetree, and Kconfig, which is powerful but heavier than Mynewt’s project/package/target approach.

From a market perspective, Mynewt looks maintained but niche. Apache’s site lists Apache Mynewt 1.14.0 as released on December 19, 2025, and the public repo remains active, but its visible ecosystem footprint is much smaller than the main public hubs around FreeRTOS and Zephyr: apache/mynewt-core shows about 882 stars, while FreeRTOS-Kernel is about 4k and Zephyr about 14.8k. That is not a market-share measurement, but it is a useful public signal that Mynewt is a serious, smaller ecosystem rather than a dominant one.

Where WIZnet Fits

The WIZnet product relevant here is the W5500. Official WIZnet documentation describes it as a hardwired TCP/IP Ethernet controller with integrated 10/100 MAC and PHY, SPI connectivity up to 80 MHz, 8 hardware sockets, and 32 KB of internal memory. In a Mynewt design, that makes the W5500 a good fit when the MCU should spend its cycles on application logic and RTOS work rather than on a full software IP stack.

In current mynewt-core, WIZnet support is present as a package-level integration. The commit 2e42672 adds net/ip/wiznet and explicitly says it adds a reference to an external repository for W5500 chips with IP stack accessible over SPI. The package metadata identifies it as an SDK package for W5500 devices and points to WIZnet’s external ioLibrary_Driver repository.

The important limitation is that this is still not a finished end-to-end reference application. The net/ip/wiznet directory currently contains only pkg.yml and syscfg.yml, while the repo README still lists sample applications such as slinky and bleuart, not a W5500 bring-up example. So the upstream tree now contains the integration hook, but not yet a polished board-level guide.

Implementation Notes

The first useful code signal is in net/ip/wiznet/pkg.yml, where Mynewt declares the WIZnet integration as an external SDK package:

pkg.name: net/ip/wiznet
pkg.type: sdk
repository.wiznet-iolibrary:
  vers: v3.2.0-commit

The second signal is in net/ip/wiznet/syscfg.yml, where feature selection is exposed through Mynewt configuration:

WIZNET_W5500:
  description: Enable support for W5500
WIZNET_DHCP:
  description: Enable support for DHCP

This is the practical boundary of the current upstream integration. Mynewt gives you build-time switches for the W5500 path and for optional protocol blocks, but it does not yet give you a complete board-support example that binds SPI, chip select, reset, and interrupt handling into a ready-made application.

It is also worth noting that Mynewt’s existing net/ip package is still described separately as an “LwIP adaptation to Mynewt.” That means upstream Mynewt currently carries two distinct networking directions: the traditional lwIP software stack path, and the new WIZnet package path that leans on W5500 offload through ioLibrary.

Practical Tips / Pitfalls

• Treat net/ip/wiznet as an SDK bridge, not as a complete Ethernet solution. The upstream directory only contains package and config files, so board glue is still your job.
• Keep the W5500 path and the lwIP path conceptually separate. In current Mynewt, net/ip is the lwIP adaptation, while net/ip/wiznet is a separate package that imports WIZnet’s own driver stack.
• Start with the smallest useful configuration: W5500, socket API, and optionally DHCP. Enabling every protocol module at once makes bring-up harder than it needs to be.
• Budget around 8 hardware sockets and 32 KB internal buffer. That is well suited to control nodes, telemetry endpoints, and small gateways, but it is not the same design target as a large software network stack on a bigger MPU.
• Plan the SPI side carefully. The W5500 is attractive because it moves networking off the MCU while staying on a simple SPI interface, but that also means your SPI timing, chip-select handling, and reset sequence need to be solid before you debug higher-level protocols.
• Use Mynewt’s RTOS services for recovery. Link monitoring, DHCP renewal retries, and watchdog-backed reconnect logic belong in Mynewt tasks and timers, even though the packet engine itself lives in the W5500.

FAQ

Q: Why use W5500 with Apache Mynewt instead of relying only on a software IP stack?
A: The W5500 brings its own hardwired TCP/IP engine, socket resources, MAC/PHY, and internal buffering, so the MCU can stay focused on application code and RTOS tasks. In Mynewt, that is especially relevant now that upstream has added a package path for WIZnet ioLibrary alongside the existing lwIP path.

Q: How does the W5500 connect to the Mynewt platform?
A: Architecturally, it connects as an external SPI Ethernet controller. Mynewt provides the OS, package system, and board abstraction, while the new net/ip/wiznet package pulls WIZnet’s ioLibrary; the developer still needs to bind SPI, GPIO chip select, reset, and related board-level details.

Q: What role does W5500 play in this specific project?
A: In apache/mynewt-core, W5500 currently plays the role of an integrated external networking SDK option. The repo does not yet ship a finished application around it; instead, it exposes package metadata and config switches so a Mynewt project can import ioLibrary_Driver and build around it.

Q: Can beginners follow this integration today?
A: A beginner can study it, but it is not yet a beginner-friendly path. The current upstream tree lacks a full W5500 sample app, so you need at least a working understanding of Mynewt packages, targets, syscfg, and MCU SPI bring-up before this becomes comfortable.

Q: How does this compare with using lwIP on Mynewt, FreeRTOS, or Zephyr?
A: lwIP on an RTOS gives you a conventional software network stack under the OS’s control. W5500 takes a different path: it offloads sockets and core TCP/IP handling into dedicated hardware, which can simplify smaller MCU designs. The OS choice then becomes a workflow question: Mynewt offers a tighter package model than plain FreeRTOS, while Zephyr offers a much larger ecosystem and a heavier build/config model.