| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
This is the starting point of making the Hugo static site generation
part of the regular CMake build.
|
|
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
|
|
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.
|
|
KiCad based on the not committed user settings saves backups in
iot-contact-backups. Excluding those backups from Git is important to
not double-track changes.
|
|
|
|
This adds marking the application firmware image in the secondary slot
for a permanent update and rebooting the device.
It is a known bug that the corresponding HTTP request is never properly
closed since the device reboots while handling the request.
Nevertheless the current state works and enables remote updates.
|
|
This write the received firmware image data to the secondary MCUboot
slot. This prepares an update.
With the MCUboot shell it can be applied with:
mcuboot request_upgrade permanent
kernel reboot
If the signature is valid the device will permanently update to the new
application firmware. Otherwise it will refuse the new image and boot
the old one.
|
|
This implements a HTTP handler capable of receiving the full data of the
firmware image upload. The data is not handled at all and thus not
written to flash.
This is just an incremental step towards successful firmware image
upload to the secondary MCUboot slot.
|
|
This adds the HTTP PUT /update handler which just returns HTTP 204 No
Content.
This is the minimal first step towards a working /update handler.
|
|
This allows to use all MCUboot related functionality during the
development via the shell. Furthermore it allows to inspect the current
state of the primary and secondary slot.
Both traits are very valuable especially during the development of the
remote update system.
|
|
Because of an issue likely related to hardware design on the
nucleo_f767zi board (see issue [1] for details) the firmware should
reboot in case network access cannot be established after 4 seconds.
This makes the firmware more robust at the moment. As soon as
iot-contact hardware without this issue exists the behavior can be
changed again.
[1]: https://github.com/zephyrproject-rtos/zephyr/issues/77794
|
|
This made the `menuconfig` target disappear. Since the application has a
quite complex configuration compared to the bootloader it is embedded to
the primary CMake project while the bootloader stays an external
project.
|
|
This allows to keep the serial port open for a longer time and use the
nucleo.sh script only for signing and flashing.
|
|
This makes it faster and build can be easily executed by adding
`-DBOARD=nucleo_f767zi` to the CMake call.
|
|
Using CMake ExternalProject there are multiple compile_commands.json
files in the build tree. Thus there is one from fw/app or another one
when built for nucleo_f767zi from fw/btl.
Linking the one from fw/app by default is more usable since it is the
more relevant code base.
|
|
This adopts this pattern from the bootloader build. It adds more
flexibility. It is assumed that in this way multiple builds for
different boards can easily be achieved.
|
|
This moves the definition of ZEPHYR_MODULES and ZEPHYR_BASE to this rtos
folder where it fits best.
|
|
This key is only relevant for firmware. Thus it should be set in the
CMakeLists.txt file of the `fw` folder.
|
|
This submodule is called `hal_stm32` upstream. Thus the submodule
directory should here be called exactly the same to reduce confusion
compared to `stm32`.
|
|
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.
|
|
Previously a folder `build/fw/bootloader` was used in addition. This
change removes this and puts everything bootloader-related in
`build/fw/btl` to make this consistent to `build/fw/app`.
|
|
This was not explicitly set to the kernel located at `fw/rtos/zephyr`.
Thus depending on the environment other kernel checkout might be picked
like `~/zephyrproject/zephyr`.
This was not notices so far since there the exact same checkout was
used.
|
|
This makes calling cmake for this device repository easier.
|
|
This makes the structure of the `fw` folder more clear and separates
application-related code from bootloader- or rtos-related code.
|
|
Handling this in the nucleo.sh script was never necessary.
|
|
This reduces nesting and makes the directory structure simpler.
|
|
The directory structure should be less nested and with shorter paths.
This is a first step.
|
|
|
|
Usage instructions were outdated.
|
|
The imgtool.py should be used directly by the user but is deeply nested
inside the folder structure. A symlink solves this issue.
|
|
|
|
Using it for the native_sim board is not trivial. Thus it is first only
added for the Nucleo board.
|
|
This provides the source code for the used bootloader.
|
|
This ignores the special build tree for the Nucleo board.
|
|
This allows to set custom IPv6 addresses while there is not runtime
configuration.
|
|
Using Kconfig for now is a way to continue faster for now. Proper
runtime configuration should be added later.
The firmware in general should be fully usable without a DHCPv6 server
to not require central infrastructure.
While IPv6 link-local addresses provide static and unique addresses for
local communication and SLAAC provides global addresses there is still a
need for an additional static address.
For this there are basically two choices:
- global IPv6 prefixes
- IPv6 unique local addresses (ULAs)
ULAs are picked with this commit. They cannot be routed which makes
isolation from the internet independent of firewall rules adding
security.
Furthermore by picking them randomly they are in practise always unique.
This allows to assign them without a central IP network management and
allows to keep those addresses forever. Both great advantages over the
IPv4 192.168.0.0/16 and similar ranges.
|
|
|
|
The scope of the mac.{c,h} files was very small. Furthermore more
network related logic needs a place. Thus making the name more general
makes sense.
|
|
This makes it transparent to the user that there is an active connection
to the firmware. If the connection is broken the user notices that
quickly and can re-load the page.
|
|
The primary interface for this firmware was so far HTTP. This protocol
is not suitable for small and bidirectional messages which are
time-critical.
If something like this needs to be implemented with HTTP the best
approach is likely long-polling which at least makes it possible for the
server / the firmware to send data to the client / user as reaction to
an event like a closed door sensor.
TCP would fix this issue and is a good choice. Nevertheless web clients
are not allowed to open TCP connections for security purposes.
Thus the WebSocket protocol was created to fill this gap.
To not duplicate the any effort the WebSocket API should be used for
small, time-critical messages for all clients (one with TCP support like
CLI tools as well as web clients).
HTTP is still kept to provide a web page but also for functionality
where HTTP is more suitable like firmware uploads.
|
|
This is required for upcoming WebSocket APIs.
|
|
The heartbeat of the firmware might be used for multiple purposes. It
can trigger a blinking LED on the PCB, can be displayed in a client
program or might serve additional purposes.
Since at least display in client programs should be implemented and
multiple clients should be support in long term it improves the code
structure to use a zbus channel here to publish heartbeat messages in a
publish-subscribe pattern.
That way the publishing of the heartbeat message and the receiving by an
unknown number of observers is completely decoupled. A central trait of
the publish-subscribe pattern and an advantage for a modular code
structure.
|
|
Common browsers always request this URL. Not responding to it shows up
as an error.
To silence this error report the firmware just responds with HTTP 204 No
Content since a favicon is currently not available.
|
|
This script allows to easily:
- build for real hardware
- flash to the microcontroller
- open the Zephyr shell UART
|
|
|
|
|
|
This provides the index HTML page.
|
|
This follows the pattern:
* ERR in error handler if statements
* DBG at top of each function and on demand
* INF at end of function
|
|
The used MAC address is from an example range. Later it can easily be
combined with reading from a MAC-providing EEPROM chip to using a unique
hardware MAC on the device.
|
