iot-contact/web, branch mdns

Add opt-in for nucleo_f767zi firmwares

2025-08-07T19:36:49Z

This partially reverts commit ce098756d79d8e4240bedc2bd74ff9a3a77fcedb. The reverted commit dropped the build logic for all nucleo_f767zi-related artifacts and thus for everything except the native sim firmware. Instead this commit reverts this change but comments out the `update_image` and `factory_image` targets from the `artifacts` variable in the top-level `meson.build`. This allows to build these two targets explicitly with `ninja -C build ` but does not include it into the deploy tar archive. Since this archive is the only target of the project with `build_by_default: true` this effectively disables the build with minimal code changes.

fw: Remove nucleo_f767zi firmwares

2025-07-27T20:57:21Z

The bootloader and application firmware resulting in the factory- and update-image are removed from the build. The reason is a planned first release of this project with hardware design files for a first `iot-contact` board. The release is required to build this board with matching version specifiers. Since the release should contain a consistent set of hardware and firmware the firmware targeting the development board is removed. Handling firmware for multiple boards is also an option but has no use since the biggest part of the firmware features can be developed using the simulation only which should stay in long term.

Same structure for source, build and deploy trees

2025-07-26T17:02:33Z

This commit removes the path transformations apart from project-prefixing from the deploy tree / artifact file archive. This gives the source tree, build tree and deploy tree the same directory hierarchy. The advantages are simple implementation and maintenance and a common structure for all parties (users, developers, producers, ...). The disadvantage is obviously that the deploy tree structure cannot be customized on its own. At least for now the approach "there is one right structure to rule them all" is taken.

Move HTML copy to root Meson file

2025-07-26T17:02:33Z

web: Remove unnecessary .gitignore

2025-07-26T17:02:33Z

web: Deploy iot-contact.kicad_pcb

2025-05-24T10:01:44Z

This can be used to order the PCB depending on the manufacturers software capabilities.

artifacts: Provide `{factory,update}-image.bin`

2025-05-24T09:20:28Z

This presents only the `factory-image.bin` and `update-image.bin` for MCU firmware. A separate bootloader image is not available. The reason is that the `factory-image.bin` is used during production once (flashing at default boot address) to set up the device. Later only the `update-image.bin` of future versions would be required to remotely update devices.

Remove installation step

2025-05-24T09:18:38Z

Using the installation step to copy selected artifacts into one folder was anyway a hack. This commit shows that the complexity can be reduced by adding copy targets. The `build/artifacts` folder contains the selected artifacts, they are always up to date, the user does not have to call the install step separately and the target definitions do not require install-related keyword arguments.

web: Fix layout

2025-04-10T19:02:19Z

simple.css requires to use the `

` tag for the main page content. Otherwise the spacing between page elements is way too large.

Simplify website structure and drop Hugo

2025-04-07T19:36:41Z

A static site generator is currently not really required. A static index.html is currently sufficient.

web: Structure index page

2025-04-06T17:48:20Z

fw: app: Add image signing to Meson build

2025-04-06T17:11:20Z

This automates signing the application firmware image for the MCUboot bootloader.

fw: sim: Integrate into Meson build

2025-04-06T16:43:28Z

This adds a build for the native_sim board of the application firmware to the default Meson build. The resulting Linux binary is also added to the webpage.

fw: app: Build with Meson

2025-04-06T16:04:25Z

Build bootloader and add to website

2025-04-06T12:24:06Z

Meson makes this relatively easy. The current approach is nevertheless a bit hacky. For the first attempt it is still way better than CMake ExternalProject.

web: Replace file copying by Meson installation

2025-04-05T13:28:04Z

This makes the build system code way less hacky and more modular.

Deploy schematic and BOM to website

2025-04-05T10:26:17Z

These important design files should be deployed with the website.

web: Depend on schematic and bom targets

2025-04-05T08:47:44Z

This triggers a website rebuild when schematic files are updated.

web: Remove CMake

2025-04-05T08:46:23Z

Trying meson worked so well that CMake is no longer needed.

web: Add simple.css to website

2025-04-03T19:50:55Z

This uses meson to copy the simple.css file to the build dir and references the CSS file in the HTML code.

web: Add meson build system

2025-04-03T19:17:23Z

CMake has some disadvantages when building subprojects like with `ExternalProject`. Furthermore the language is sometimes hard to read, hard to write and not so much appreciated. This is a little test if meson might perform better. If successful this project might switch to meson for all parts except the Zephyr builds.

web: Fix dependencies in CMake

2025-04-02T19:06:18Z

This makes sure incremental builds work properly for the web page.

web: Embed into CMake build

2025-04-01T19:30:33Z

The website should be part of the regular CMake build for convenience. Later the dependencies might be set up in a way that the site automatically and incrementally updates with a ninja call.

web: Add minimal Hugo-based site

2025-04-01T19:07:07Z

Hugo [1] is a common static site generator. It should be used to generate a site where build artifacts of this project can be presented and deployed. [1]: https://gohugo.io

web: Add CC-BY-SA as LICENSE.txt

2025-04-01T18:08:46Z

The generated website should contain everything which will be deployed to the user. This site contains material based on multiple licenses to meet the matching domain like software, hardware or documentation. All the content of the website which is not installed from other directories is licensed via the given license. This keeps the usual folder-based licensing scheme for the source repository. Mixing the licenses in the deploy tree seems to be necessary at the moment.