| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
This script can be called with root permissions and without any
arguments to provide a virtual network interface `zeth` and an IPv6
router advertisement daemon to provide a realistic network environment
without any hardware.
|
|
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 makes it easier to develop the whole network-related firmware parts
on a simulation board instead of hardware.
The nucleo_f767zi board has likely a hardware bug making Ethernet
sometimes fail. This is not suitable for development.
|
|
This is the latest release of the Zephyr real-time operating system.
|
|
|
|
|
|
This makes it easier to keep the descriptions and the text inside the
schematic in sync.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Power over Ethernet (PoE) has the disadvantage that GND is significantly
below earth. This requires that GND of a PoE-powered device is never
attached to earthed devices.
In production use cases this is no problem. The earth lines are
isolated.
Nevertheless for debugging it is sometimes useful to connect measuring
equipment like logic analyzers and oscilloscopes to the board. This is
not possible with PoE. Thus an alternative earth-based 5V power input is
useful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This simplifies the CMake code and the paths inside the build folder.
|
|
|
|
|
|
This CMake function integrates converting the schematic to PDF as part
of the standard build.
|
|
|
|
This is the starting point for the PCB development.
|
|
|
|
|
|
|
|
This license is the primary one for the whole project. Sub-directories
might have other licenses like e.g. `fw`.
|
|
|
|
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.
|
