Age | Commit message (Collapse) | Author |
|
This will be moved later to the user documentation so that the native
sim build of the application firmware can easily be used on Linux
machines using NetworkManager.
|
|
Deploying all build artifacts in a single tar archive file makes
deployment easier. The bundle stays consistent, GPG signatures can later
easily provided too, the archive and its top-level directory can have
the same and long name and the further paths in the archive can stay
short.
|
|
|
|
After the transition to tar archive based deployment it can now be
re-introduced with small changes.
|
|
All build artifacts should be deployed in a single `*.tar.zst` file.
This archive and the single top-level content (a directory called `*` in
this case) should contain the project name and version in its name.
The latter is added with this commit so that there is now an
`iot-contact-v0.0.0-dev.tar.zst` instead of an `iot-contact.tar.zst`.
|
|
This commit removes the path transformations apart from
project-prefixing from the deploy tree / artifact file archive.
This gives the source tree, build tree and deploy tree the same
directory hierarchy.
The advantages are simple implementation and maintenance and a common
structure for all parties (users, developers, producers, ...).
The disadvantage is obviously that the deploy tree structure cannot be
customized on its own. At least for now the approach "there is one right
structure to rule them all" is taken.
|
|
Everything else is implicitly build by default since it should
contribute to the tar archive.
|
|
|
|
|
|
This generates `build/iot-contact.tar.zst` as primary build artifact. It
contains all artifacts which should be deployed. Providing this as file
archive makes further handling more easy.
|
|
This was just a trick to provide a folder in the build tree where only
artifacts are stored. These artifacts are moved to the root of the build
tree.
This has the disadvantage that they are mixed with other files inside
this folder. Nevertheless they should soon be added by Meson to the file
archive used for deployment which solves this issue because it contains
by definition only artifacts.
|
|
This prepares switching to deployment with only a single archive file.
The deploy script will be re-written as soon as this transition is
complete.
|
|
This resolves ERC issues. The ERC complains that an power input is not
fed by a power output if there is a component like a ferrite bead or 0
Ohm resistor between the two.
The `PWR_FLAG` tells the ERC that it was explicitly checked that this is
not a mistake.
|
|
|
|
|
|
The internal pull-up resistor of the STM32 can be used.
|
|
|
|
|
|
It is hard to say if these are necessary. For sure they are not
necessary anymore when the device is assembled inside the case. Thus the
risk is taken to provide some more space and reduce assembly effort.
|
|
This chip provides a globally unique EUI-48 MAC address. This address
will be printed on the device enclosure.
The IPv6 link-local address of the device can be directly calculated
from this MAC address. Thus a commissioning software can directly access
the device when the user types in this MAC address without any discovery
protocol.
|
|
They are required to drive the transistors properly.
|
|
The idea of the red LED used to be to indicate power delivery to the
board independent of firmware.
While this is good to know it adds the constraint that even without
firmware the LED should light up. Furthermore it should stop lighting up
when the firmware takes over the blinking with different colors. This
was solved with a NOT gate.
This adds more parts to the assembly at the cost of rare space. To
reduce space consumption this feature is removed.
The effect is that the user cannot distinguish anymore if the board has
an issue with power supply or with not running firmware. This is
acceptable because the user cannot do anything about both issues.
Developers have the chance to e.g. connect the UART to validate if the
firmware is running.
|
|
It is required to save as much place as possible on the PCB. There used
to be these reset methods:
- JTAG reset
- button reset
- power-cycle
- firmware-based reset
Taking away the button reset option is reasonable since for the
development and production use case there are still enough options.
Developers should use the JTAG reset or power-cycle and users will
anyway use firmware-based resets (e.g. during updates) or power-cycles
which is anyway most intuitive to users.
|
|
Now there are 6 locations for 3 zero Ohm resistors. Three places to
power by PoE and three to power externally. Never all of them should be
placed.
|
|
|
|
|
|
This folder contains datasheets of the components. Because of unclear
license situation they are ignored to avoid legal issues on
re-distribution.
|
|
This makes it later possible to diff the planned `current.md` with the
`future.md`. When the firmware is feature-complete the diff should be
empty.
|
|
|
|
|
|
|
|
The status LED should always display on color either constantly on or
blinking.
To make sure even without firmware this is given a NOT gate is added.
|
|
This is more space efficient and makes it easier to label the LEDs.
There is just one "status LED" lighting up in different colors compared
to one "update LED", "power LED" and "activity LED".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- deploy `iot-contact.kicad_pcb` file for easy ordering
- add PCB versioning and process to update it
|
|
To allow features like PCB version detection the version encoding
requires manual intervention. A release checklist like this allows to
reliably execute such tasks.
|
|
This table is the result of running:
./tools/resistor_selector.py --output pcb/versions.tsv
Additionally the table was manually edited. The first column now
contains version strings to reserve resistor combinations.
This is used to keep track of existing versions, their resistor values
and related ADC values. The latter will be added to the firmware too.
|
|
Making them active-low makes it easier to reset the MCU. For the wipe
functionality it does not make a role since it will simply be defined in
Devicetree.
|
|
This voltage divider provides an analog voltage between GND and +3.3V to
indicate which hardware revision this board is.
Thus the same firmware image can be used on multiple PCB versions
compensating the hardware differences in software.
The resistor combinations are calculated by
`tools/resistory_selector.py`.
|
|
This had an actual effect on the output giving more available options.
|
|
This reduces the electrical contacts which is possible and necessary
because of size constraints.
|
|
These files seem to be present since KiCad 9.0 and should not be tracked
with version control.
|