| Age | Commit message (Collapse) | Author |
|---|
|
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 the structure of the `fw` folder more clear and separates
application-related code from bootloader- or rtos-related code.
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
This provides the index HTML page.
|
|
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.
|
|
Network-based logging via the syslog protocol allows to log from many
IoT devices to a central log server.
This makes reading logs way easier. Choosing UDP removes the need for
logic keeping a state. Maybe dropped packages are acceptable for the use
case but should be rare anyway.
|
|
Using this board by default allows easier development since it compiles
to a Linux executable which can be executed with `./zephyr.exe`,
debugged with `gdb zephyr.exe` and has a virtual serial port for the
Zephyr shell.
Later the 32 bit version or even a QEMU variant should be used but the
64 bit variant is a low hanging fruit since the host libraries can be
used. This is not wanted but easy to accomplish.
|
|
This allows to easily build everything from the repository root. For now
this only covers firmware but later electrical PCB and mechanical case
files can be added.
|
|
|
|
The Mozilla Public License seems to be suitable for this firmware
project. See the original license text for details.
This commit also adds a `.txt` suffix to the LICENSE file to make the
file type more visible to humans and tools.
|
|
This makes the name shorter which is especially relevant for Git commit
messages.
|
