IoT device to check if doors and windows are closed or open https://cgit.xengineering.eu/iot-contact/atom?h=mdns 2025-05-24T09:20:08Z 2025-05-24T09:20:08Z xengineering me@xengineering.eu 2025-05-24T09:20:08Z urn:sha1:fc3b3cbf7fecee7226f249f7b62cf36aa82a545a This automatically creates `build/artifacts/factory-image.bin` with the Meson build system. The resulting file can simply be moved to the virtual file system of the `nucleo_f767zi` board to flash bootloader and application making the board ready for operation and remote updates. 2025-05-24T09:18:38Z xengineering me@xengineering.eu 2025-05-24T09:18:38Z urn:sha1:caf416218623d6778b3d0c2fe12ee08135c2d126 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. 2025-05-24T09:17:46Z xengineering me@xengineering.eu 2025-05-24T09:17:46Z urn:sha1:b1838d1c5b6bd27757d50d784543ea0ae16c1769 This was used since flashing was complex. Thus the build system should help making it easier. The new approach is more to provide artifacts by the build system which are easy to flash / remote-update. A `factory-image.bin` and `update-image.bin` should be provided. 2025-04-12T09:33:07Z xengineering me@xengineering.eu 2025-04-12T09:33:07Z urn:sha1:ddcf8559d4fbb9bd6942ac46d5c4970ef08b16d1 These targets are added: - fw/erase - fw/app/flash - fw/btl/flash They make it easier to perform a mass-erase, flashing of the bootloader and flashing of the application for development. 2025-04-07T19:36:41Z xengineering me@xengineering.eu 2025-04-07T19:36:41Z urn:sha1:4ee031182475464fe0ecb052882fd50520e6defc A static site generator is currently not really required. A static index.html is currently sufficient. 2025-04-06T16:43:28Z xengineering me@xengineering.eu 2025-04-06T16:43:28Z urn:sha1:7fc6bc84609022992e1827a07b95c427208e7289 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. 2025-04-06T15:59:06Z xengineering me@xengineering.eu 2025-04-06T15:59:06Z urn:sha1:867755129e5c50f4e35bc34d5818c2397f3f09db This makes them re-usable for the application and native_sim firmwares. 2025-04-06T15:33:13Z xengineering me@xengineering.eu 2025-04-06T15:33:13Z urn:sha1:84ab791be78c4f2014a78b09305c5c332b5383e3 2025-04-06T15:27:49Z xengineering me@xengineering.eu 2025-04-06T15:27:49Z urn:sha1:e78341079228b135bee65deb8e0d4e2b4385cf94 This allows to re-use these scripts. Since they are currently used to build Zephyr builds and three are intended (application, bootloader and application as native_sim build) this makes sense. 2025-04-06T12:24:06Z xengineering me@xengineering.eu 2025-04-06T12:24:06Z urn:sha1:5376b67a9df63d2b30cac415cb827e6b4c1674e9 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. 2025-04-06T11:41:42Z xengineering me@xengineering.eu 2025-04-06T11:41:42Z urn:sha1:e28796985d5f605fbdb1f5043618b1f570e747af 2025-04-06T11:39:29Z xengineering me@xengineering.eu 2025-04-06T11:38:24Z urn:sha1:9f75ad79c0df9035bcdfd11011ba475cc80ad50a To use a more readable scripting language and keep portability the POSIX shell script for Zephyr configuration is replaced by Python. 2025-04-06T11:28:53Z xengineering me@xengineering.eu 2025-04-06T11:28:53Z urn:sha1:28576b0bdb6b6e08b186c2919bbed4393b38bb7f 2025-04-05T13:33:09Z xengineering me@xengineering.eu 2025-04-05T09:10:12Z urn:sha1:82fa02bcac5e278586cb2e3c9cc597699f6f640d CMake ExternalProject creates a pretty confusing build tree. Since the rest of the project anyway starts moving to Meson the bootloader is configured via Meson as a first step. 2025-03-26T20:18:23Z xengineering me@xengineering.eu 2025-03-23T17:33:19Z urn:sha1:1fcf9bd0d1af10c57a67d90496b5406244ca25ba The mcuboot Git submodule used to be located in `fw/btl`. Nevertheless since it is also a Zephyr module it should go to `fw/rtos/modules`. This makes sure all Zephyr modules are at the same place. 2025-03-22T21:30:41Z xengineering me@xengineering.eu 2025-03-22T20:39:13Z urn:sha1:62be0c0585b147686ad3a41fdce181c8a7e95cd1 The directory structure should be less nested and with shorter paths. This is a first step.