WireForge 0.4.1

WireForge 0.4.1 takes the tutorial onto a microcontroller and against a real autopilot.

Tutorial

• New chapter 5, On a microcontroller: the C vehicle runs as bare-metal firmware on a Cortex-M4 (QEMU's mps2-an386, no board needed), MAVLink 2 over the UART, against the same pymavlink ground station. About 22 KB of flash and 14 KB of RAM, nothing allocated at run time. The later chapters move up by one.
• Chapter 4, the same in C and against ArduPilot: the vehicle in C99, and a C ground station built from the import of the whole ardupilotmega.xml that talks to the ArduCopter simulator (SITL). With ArduCopter 4.7.2: every frame decoded, none rejected, commands acknowledged, the whole parameter list received.
• Chapter 3 imports a whole MAVLink dialect with wireforge import-mavlink.
• Chapter 8 shows the dissection tree of a frame.

CMake

wireforge_generate(<target> PROJECT <dir> LANGUAGE c) generates C99 and gives a static C library without the C++ runtime, so a C-only cross build (for example arm-none-eabi) works.

Fixes

The MAVLink 2 Wireshark hook reads the CRC_EXTRA bytes from the project's crc_extra.h, so a message added to the model is verified too (VFR_HUD from the tutorial showed a checksum mismatch before).

Details: Tutorial · On a microcontroller · Generated C code

GitHub Action: uses: oguzhankynk/wireforge@v0.4.1. Free for development, evaluation and CI; the generated code and its runtime are yours under MIT.

v0.4.0

WireForge 0.4.0 reads MAVLink's own XML message definitions.

Import MAVLink dialects

pip install --upgrade wireforge
wireforge import-mavlink common.xml mavlink --name mavlink        # every message of the dialect
wireforge import-mavlink ardupilotmega.xml apm --name apm --message HEARTBEAT --message ATTITUDE
wireforge test mavlink -o build/mavlink                           # C++17 (or --language c) and its tests

• Every message and enum of a dialect and the files it includes: common.xml (210 messages), ArduPilot's ardupilotmega.xml (301), or your own dialect. --message picks a subset.
• The fields come in MAVLink's wire order, extension fields last, char and numeric arrays included; the CRC_EXTRA byte of every message is computed from its definition.
• The project has the frame of the published MAVLink 2 model: the 24-bit message id, payloads without trailing zero bytes, the Wireshark hook that verifies the checksum.
• Checked against pymavlink: all 19 dialects it ships import with the same CRC_EXTRA bytes and field order, and every message of common.xml encodes to the same bytes, with and without trailing zeros.

Not covered: message signing (signed frames are refused) and MAVLink 1 frames from XML.

Details: docs/IMPORT.md · How it compares · Tutorial

GitHub Action: uses: oguzhankynk/wireforge@v0.4.0. Free for development, evaluation and CI; the generated code and its runtime are yours under MIT.

v0.3.0

WireForge 0.3.0 brings MAVLink 2, a tutorial that runs in CI, and a new web UI.

Highlights

• MAVLink 2 (wireforge init --protocol mavlink2): the frame with its 24-bit message id, HEARTBEAT, GPS_RAW_INT and COMMAND_ACK with extension fields, ATTITUDE, GLOBAL_POSITION_INT and COMMAND_LONG. Checked byte for byte against pymavlink, including frames whose trailing zero bytes are left out. A Lua hook lets the Wireshark dissector verify MAVLink's checksum.
• Payloads without trailing zeros for any interface (trim_trailing_zeros): generated C++ and C, the reference codec, the Wireshark dissector, the layout report and the compatibility check all know the rule.
• Tutorial (docs/tutorial): ten chapters around one drone link, from the model to a vehicle that talks to a pymavlink ground station, tests, CI, Wireshark and AI agents. Its commands run in CI with the released wheel.
• Web UI: light and dark themes, the logo, and Generate in C++17 or C99 with the download of code and tests.
• How it compares: docs/COMPARISON.md, next to protobuf, nanopb, Kaitai Struct, mavgen and cantools.

Also

• wireforge test uses the project's own checksum plugin, so a project from init --protocol tests without --plugins.
• Header bit-fields of whole bytes are generated as fields of their own width (Encoder::write_width).
• Long fuzzing runs weekly as four parallel jobs.

Install

pip install "wireforge[server,mcp]"
wireforge init drone --protocol mavlink2 && wireforge test drone -o build/drone

GitHub Action: uses: oguzhankynk/wireforge@v0.3.0.

Free for development, evaluation and CI; the generated code and its runtime are yours under MIT.

v0.2.1

What's Changed

• Version 0.2.1; shorter action description, wiki entry layer by @oguzhankynk in #35

Full Changelog: v0.2.0...v0.2.1

v0.2.0

What's Changed

• Import CAN databases (DBC); fields get a scale and an offset by @oguzhankynk in #25
• Published protocol library: wireforge init --protocol; u-blox UBX by @oguzhankynk in #26
• J1939 protocol model, checked against cantools by @oguzhankynk in #27
• MAVLink 1 protocol model, checked against pymavlink by @oguzhankynk in #28
• CRSF protocol model, checked against crsf-parser by @oguzhankynk in #29
• C runtime: header-only C99 codec support with the semantics of the C++ runtime by @oguzhankynk in #30
• Generate C99 code for the model: wireforge generate/test --language c by @oguzhankynk in #31
• C99 interfaces: framing, dispatch and link for generated C by @oguzhankynk in #32
• List the WireForge check action on GitHub Marketplace; CI use is free by @oguzhankynk in #33
• Version 0.2.0; document C99 next to C++17 by @oguzhankynk in #34

Full Changelog: v0.1.0...v0.2.0

v0.1.0

What's Changed

• Add user_types: opaque, user-owned C++ field types by @oguzhankynk in #1
• Server: OIDC bearer-token authentication by @oguzhankynk in #2
• Requirements and low-level requirement traceability by @oguzhankynk in #3
• Lifecycle documents: requirements, design, test and traceability by @oguzhankynk in #4
• Requirement test vectors as an independent oracle by @oguzhankynk in #6
• Coding-rule coverage map and an advisory MISRA run by @oguzhankynk in #5
• Test results, runtime coverage, stack use and toolchain in the documents by @oguzhankynk in #7
• Runtime requirements dossier by @oguzhankynk in #8
• Process integration: stable ids, ReqIF and CSV exchange, permalinks by @oguzhankynk in #9
• Fuzz targets in parallel, and a nightly long fuzz run by @oguzhankynk in #11
• Runtime line coverage from 83 % to 92 %, gate at 91 % by @oguzhankynk in #12
• Run CI push workflows only on master by @oguzhankynk in #14
• Architecture matrix: aarch64, armhf and powerpc, unsigned char on the host by @oguzhankynk in #13
• Coverage of generated code for any model: feature matrix, random models, SR-23 by @oguzhankynk in #16
• Operating-system matrix: Windows, macOS, Android and FreeRTOS by @oguzhankynk in #15
• wireforge init: a working first project from a template by @oguzhankynk in #17
• wireforge ci: one check for every CI system, a GitHub action and a GitLab example by @oguzhankynk in #18
• Distribution: reproducible wheel, complete sdist, Python 3.10 to 3.13, release workflow by @oguzhankynk in #19
• Modbus RTU and TCP from their specifications, checked against pymodbus; receivers check constants and checksums by @oguzhankynk in #20
• Package metadata declares both licenses (BUSL-1.1 AND MIT) by @oguzhankynk in #22
• Coverage points: the model decides what the generated tests must exercise by @oguzhankynk in #23
• Release: upload only the wheel and the source distribution to PyPI by @oguzhankynk in #24

New Contributors

• @oguzhankynk made their first contribution in #1

Full Changelog: https://github.com/oguzhankynk/wireforge/commits/v0.1.0