| Age | Commit message (Collapse) | Author |
|---|
|
TODO: Check if the bootloader install target is still usable.
Using the installation step to copy selected artifacts into on 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.
|
|
This adds the HTTP GET /settings.json API. Writing settings is only
supported via the Zephyr shell.
|
|
This disables compiler optimization and allows easier debugging.
|
|
|
|
|
|
|
|
|
|
|
|
From now on the mixed format with IP and port is not supported. The
settings system should keep them separate and first only the IP is
configurable.
Supporting this Kconfig option too is annoying and not necessary.
|
|
The old format contained `[<ip>]:<port>`. Nevertheless the format should
be as strict as possible. Thus only the IP is used in the setting.
|
|
|
|
|
|
|
|
This got lost during development but is an important option to
compensate the hardware issues present on Nucleo F767ZI.
|
|
This enables simple.css also for the device-hosted website and
restructures the HTML a bit.
|
|
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.
|
|
This allows to call `deploy.py` without any arguments in most cases.
|
|
This makes debugging easier and safer.
|
|
This makes it easier to deploy the installed artifacts to a remote
server as part of the deployment.
|
|
simple.css requires to use the `<main>` tag for the main page content.
Otherwise the spacing between page elements is way too large.
|
|
|
|
A static site generator is currently not really required. A static
index.html is currently sufficient.
|
|
|
|
Building a website to structure and deploy the artifacts was planned and
requires a well set-up build system to handle all the file paths targets
and dependencies.
Since multiple CMake Zephyr builds are required for the application
firmware, bootloader firmware and the native_sim application firmware
simulation CMake external project was used.
Since this generates a build tree with a confusing structure Meson was
evaluated.
Finally the Meson build system was a good fit as top-level build system
and allows external projects as an experimental feature if they can
configure a Make-based build system which is given for Zephyr.
|
|
|
|
|
|
|
|
Meson now handles this. CMake is only used as Meson external project to
build Zephyr firmwares.
|
|
|
|
Because of the Meson build system the application firmware is signed
automatically. Furthermore all artifacts required to flash the Nucleo
board are deployed to the website. Thus this script is not necessary
anymore.
|
|
This automates signing the application firmware image for the MCUboot
bootloader.
|
|
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.
|
|
|
|
This makes them re-usable for the application and native_sim firmwares.
|
|
|
|
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.
|
|
With multiple CMake Zephyr builds a single link does not make sense
anymore. The user should set a custom symlink.
`.gitignore` is altered to avoid committing such a link.
|
|
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.
|
|
|
|
To use a more readable scripting language and keep portability the POSIX
shell script for Zephyr configuration is replaced by Python.
|
|
|
|
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.
|
|
This makes the build system code way less hacky and more modular.
|
|
These important design files should be deployed with the website.
|
|
This triggers a website rebuild when schematic files are updated.
|
|
This allows to install the PCB-related files easier to the website which
is built with Meson.
|
|
Trying meson worked so well that CMake is no longer needed.
|
|
This uses meson to copy the simple.css file to the build dir and
references the CSS file in the HTML code.
|
|
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.
|
|
This provides the CSS code for the deploy website as well as the web
interface of the device.
|
