Wiznet makers

What the Project Does

This project modernizes the development workflow for WIZ750SR, WIZnet’s Serial-to-Ethernet module based on the W7500P chip. The official WIZ750SR repository describes the product as a WIZnet Serial-to-Ethernet module compatible with WIZ107/108SR, and the README lists the firmware projects as Keil IDE for ARM version 5 based source code.

The problem is not the WIZ750SR hardware itself. The hardware is already a useful embedded networking module: it combines serial interfaces with Ethernet conversion, and the W7500P integrates an ARM Cortex-M0, embedded PHY, and hardwired TCP/IP support for protocols including TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE.

The actual bottleneck is the developer workflow. A Keil-centered firmware tree is workable for an internal product team, but it creates friction for outside contributors, students, community maintainers, and CI-based verification. This project addresses that by moving the firmware build system to GNU ARM GCC + CMake + VS Code, making the development cycle easier to reproduce without a commercial IDE license.

In practical terms, the project changes WIZ750SR firmware from a “source-available but hard to build” model into a workflow that external developers can actually use: clone the repository, install an open ARM toolchain, configure CMake, build the Boot/App firmware targets, and review changes through normal Git-based collaboration.

Where WIZnet Fits

The WIZnet product at the center of this project is WIZ750SR. It is not an add-on peripheral in a third-party project; it is the target product whose firmware workflow is being improved.

WIZ750SR is built around the W7500P, a WIZnet SoC that combines an ARM Cortex-M0 class MCU with WIZnet’s hardwired TCP/IP core. The official README states that the W7500P supports TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE through the hardwired TCP/IP stack.

That matters because WIZ750SR firmware is not just generic Cortex-M firmware. It controls a Serial-to-Ethernet product where the network stack, serial data packing, configuration commands, bootloader behavior, firmware update flow, and product compatibility all interact. The official WIZ750SR repository separates the firmware into Application and Boot projects, and its update history includes changes related to AppBoot behavior, firmware update mechanism, DHCP behavior, TCP retransmission settings, PHY initialization, and configuration tools.

A GNU ARM GCC and CMake port is valuable because it makes that firmware lifecycle more transparent. Instead of relying on project settings hidden inside a proprietary IDE workspace, the build assumptions can be expressed as text: compiler flags, linker scripts, memory layout, include paths, startup files, boot/app targets, and post-build artifact generation.

Why This Project Matters

The strongest point of this project is that it improves participation, not only compilation.

Many embedded firmware projects are technically open but practically closed. The source exists, but building it requires a specific IDE version, a licensed compiler, undocumented workspace settings, or a developer’s local machine configuration. That limits bug reports, pull requests, reproducible testing, and long-term maintenance.

Moving WIZ750SR firmware to GNU ARM GCC and CMake changes the development model in five concrete ways.

First, it lowers the license barrier. GNU ARM GCC is an open toolchain for Arm targets, and Arm provides GNU toolchain releases for multiple host platforms. Developers can build and test firmware without first obtaining a commercial Keil setup.

Second, it improves platform independence. A CMake-based project can be configured on Windows, Linux, or macOS more easily than an IDE-only project. That does not remove all embedded complexity, but it makes the build process easier to document and repeat.

Third, it makes code review more meaningful. When include paths, compiler definitions, linker scripts, and target outputs are stored in CMakeLists.txt and toolchain files, reviewers can inspect build behavior in the same pull request as source changes.

Fourth, it improves CI readiness. A command-line build is easier to run in GitHub Actions, GitLab CI, Jenkins, or a local pre-release test script. That is important for firmware with Boot/App compatibility constraints, because a small build-setting mistake can produce a binary that compiles but does not boot.

Fifth, it reduces maintenance risk. Keil projects can work well for a stable internal team, but they are vulnerable to tool version drift and undocumented local settings. CMake does not solve all porting problems, but it moves key assumptions into version-controlled files.

Implementation Notes

No source repository for the GNU ARM GCC/CMake port was provided, so the following notes describe the expected architecture of the port rather than verified project code.

A good WIZ750SR open build system should not be a single flat “compile everything” target. It should preserve the product’s firmware model:

WIZ750SR Firmware Build
│
├── Boot target
│   ├── startup code
│   ├── bootloader sources
│   ├── boot linker script
│   └── boot binary / hex output
│
├── App target
│   ├── Serial-to-Ethernet application logic
│   ├── configuration command handling
│   ├── network and socket logic
│   ├── app linker script
│   └── app binary / hex output
│
├── Shared code
│   ├── W7500P device headers
│   ├── ioLibrary / network support
│   ├── board configuration
│   └── common utilities
│
└── Toolchain layer
    ├── arm-none-eabi-gcc
    ├── CMake toolchain file
    ├── linker map generation
    └── size / objcopy post-build steps

The key technical work is the linker and memory layout, not just the compiler command. The official README warns that Boot and App memory areas must be checked for firmware after Boot 1.3, and the update history includes boot/app compatibility notes. A serious CMake port should therefore define separate linker scripts for Boot and App targets and document which firmware versions or memory maps they correspond to.

A minimal conceptual structure would look like this:

# Conceptual structure only, not verified project code

add_executable(wiz750sr_boot
    boot/startup_w7500p.s
    boot/main.c
    common/system_w7500p.c
)

target_compile_definitions(wiz750sr_boot PRIVATE
    WIZ750SR_BOOT
)

target_link_options(wiz750sr_boot PRIVATE
    -T${CMAKE_SOURCE_DIR}/ld/wiz750sr_boot.ld
)

add_executable(wiz750sr_app
    app/main.c
    app/s2e_config.c
    app/serial_data_handler.c
    common/system_w7500p.c
)

target_compile_definitions(wiz750sr_app PRIVATE
    WIZ750SR_APP
)

target_link_options(wiz750sr_app PRIVATE
    -T${CMAKE_SOURCE_DIR}/ld/wiz750sr_app.ld
)

The value of this structure is clarity. Boot and App are separate firmware products with separate memory assumptions. Treating them as separate CMake targets makes it easier to review changes, generate artifacts, and prevent accidental mixing of bootloader and application settings.

The second key area is artifact generation. A practical embedded workflow should produce .elf, .map, .bin, and .hex outputs, plus a size report. That lets maintainers check whether a change fits the target memory region before flashing.

The third key area is VS Code integration. VS Code should be treated as a front end, not as the build system itself. The reproducible build should still work from a terminal with CMake and GNU ARM GCC. VS Code then becomes a convenient editor/debugger configuration layer rather than a hidden dependency.

Practical Tips / Pitfalls

• Keep Boot and App linker scripts separate. WIZ750SR firmware has boot/application compatibility concerns, so a single generic memory layout is risky.
• Do not hide critical flags inside VS Code settings. Compiler options, definitions, include paths, and linker scripts should live in CMake files.
• Generate map files on every build. Map files make flash/RAM usage reviewable during pull requests.
• Match the original Keil output before changing behavior. The first goal should be build equivalence, not feature development.
• Document the exact GNU ARM GCC version used for release builds. Open tooling improves access, but version drift can still affect binary output.
• Add CI only after the local command-line build is stable. CI should verify the same CMake workflow that developers use locally.
• Treat Boot/App update flow as a release-critical path. The official WIZ750SR history includes multiple firmware update and AppBoot changes, so build-system changes should be validated against update scenarios, not only normal flashing. 

FAQ

Q: Why is this project important for WIZ750SR?
A: It changes WIZ750SR firmware development from a Keil-centered workflow into a reproducible open-toolchain workflow. That makes it easier for outside developers to build, review, test, and contribute firmware changes.

Q: How does this relate to the WIZ750SR hardware?
A: WIZ750SR is the target module. It is based on WIZnet’s W7500P chip, which integrates an ARM Cortex-M0 class MCU, embedded PHY, and hardwired TCP/IP core for Serial-to-Ethernet operation.

Q: What role does WIZ750SR play in this project?
A: WIZ750SR is not just a supported board; it is the product whose Boot and Application firmware build workflow is being opened. The port makes its firmware easier to build and maintain with GNU ARM GCC, CMake, and VS Code.

Q: Can beginners follow this project?
A: Beginners can benefit from the easier setup, but this is still embedded firmware work. Developers should understand ARM cross-compilation, linker scripts, startup code, flash memory layout, and Boot/App firmware separation.

Q: How is this better than staying with Keil?
A: Keil can be productive in a controlled internal environment, but it creates license and IDE-version dependencies. GNU ARM GCC with CMake is easier to reproduce, easier to automate in CI, and easier for external contributors to review because build settings are stored as text in the repository.

Source

• Official WIZ750SR repository: WIZnet Serial-to-Ethernet module based on W7500 chip, with firmware projects originally described as Keil IDE for ARM version 5 based. 
• Official WIZ750SR product information: WIZ750SR is a Serial-to-Ethernet module powered by W7500P. 
• Provided project description: GNU ARM GCC, CMake, and VS Code porting effort for a more open WIZ750SR firmware development workflow.
• License of official WIZ750SR repository: Apache-2.0. 

Tags

#WIZ750SR #W7500P #WIZnet #SerialToEthernet #GNUARMGCC #CMake #VSCode #EmbeddedFirmware #OpenSource #Bootloader #FirmwareBuild #AEO