| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
|
|
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".
|
|
|
|
|
|
|
|
|
|
|
|
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 reduces the electrical contacts which is possible and necessary
because of size constraints.
|
|
|
|
|
|
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 is the starting point for the PCB development.
|
|
It is planned to switch to Ethernet instead of LoRa for communication.
Thus the custom PCB with the STM32WL MCU does not make sense anymore. To
get started the Ethernet variant will use a ST NUCLEO board to avoid
creating a custom PCB first.
|
|
This IC has a small footprint and will provide the 3.3 V for the
microcontroller.
|
|
|
|
|
|
|
|
Based on UM2592 the development kit Nucleo WL55JC which is used for
firmware development is based on the STM32WL55JCI7 microcontroller.
Thus this MCU should be a good starting point for now.
|
|
|
