mirror of
https://github.com/ferrous-systems/embedded-trainings-2020.git
synced 2024-10-31 22:28:49 +00:00
Merge pull request #34 from ferrous-systems/fixes2
Assorted fixes to the beginner material
This commit is contained in:
commit
3fffebd4a6
3 changed files with 6 additions and 6 deletions
|
@ -56,7 +56,7 @@ If you run the `serial-term` application you should see the following output:
|
||||||
|
|
||||||
``` console
|
``` console
|
||||||
$ serial-term
|
$ serial-term
|
||||||
deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm
|
deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm app=loopback.hex
|
||||||
(..)
|
(..)
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
|
@ -8,7 +8,7 @@ First run the program as it is. You should new output in the output of the `seri
|
||||||
|
|
||||||
``` console
|
``` console
|
||||||
$ serial-term
|
$ serial-term
|
||||||
deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm
|
deviceid=588c06af0877c8f2 channel=20 TxPower=+8dBm app=loopback.hex
|
||||||
received 5 bytes (LQI=49)
|
received 5 bytes (LQI=49)
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -103,7 +103,7 @@ Now run the `radio-send` program several times with different variations:
|
||||||
- change the length of the packet
|
- change the length of the packet
|
||||||
- different combinations of all of the above
|
- different combinations of all of the above
|
||||||
|
|
||||||
Take note of how LQI changes with these changes. Do packet loss occur in any of these configurations?
|
Take note of how LQI changes with these changes. Does packet loss occur in any of these configurations?
|
||||||
|
|
||||||
> NOTE if you decide to send many packets in a single program then you should use the `Timer` API to insert a delay of at least five milliseconds between the transmissions. This is required because the Dongle will use the radio medium right after it receives a packet. Not including the delay will result in the Dongle missing packets
|
> NOTE if you decide to send many packets in a single program then you should use the `Timer` API to insert a delay of at least five milliseconds between the transmissions. This is required because the Dongle will use the radio medium right after it receives a packet. Not including the delay will result in the Dongle missing packets
|
||||||
|
|
||||||
|
@ -111,6 +111,6 @@ Take note of how LQI changes with these changes. Do packet loss occur in any of
|
||||||
|
|
||||||
## 802.15.4 compatibility
|
## 802.15.4 compatibility
|
||||||
|
|
||||||
The radio API we are using follows the PHY layer of the IEEE 802.15.4 specification but it's missing MAC level features like addressing (each device gets its own address), opt-in acknowledgment (a transmitted packet must be acknowledged with a response acknowledgment packet; the packet is re-transmitted if the packet is not acknowledged in time). These MAC level features are not implemented *in hardware* (in the nRF52840 Radio peripheral) so they would need to be implemented in software to be fully IEEE 802.15.4 compliant.
|
The radio API we are using follows the PHY layer of the IEEE 802.15.4 specification, but it's missing MAC level features like addressing (each device gets its own address), opt-in acknowledgment (a transmitted packet must be acknowledged with a response acknowledgment packet; the packet is re-transmitted if the packet is not acknowledged in time). These MAC level features are not implemented *in hardware* (in the nRF52840 Radio peripheral) so they would need to be implemented in software to be fully IEEE 802.15.4 compliant.
|
||||||
|
|
||||||
This is not an issue for the workshop exercises but it's something to consider if you would like to continue from here and build a 802.15.4 compliant network API.
|
This is not an issue for the workshop exercises but it's something to consider if you would like to continue from here and build a 802.15.4 compliant network API.
|
||||||
|
|
|
@ -19,8 +19,8 @@ Check the API docs of the `Led` abstraction then run the `led` program. Two of t
|
||||||
|
|
||||||
Now, uncomment the `log::set_max_level` line. This will make the logs more verbose; they will now include logs from the board initialization function (`dk::init`) and from the `Led` API.
|
Now, uncomment the `log::set_max_level` line. This will make the logs more verbose; they will now include logs from the board initialization function (`dk::init`) and from the `Led` API.
|
||||||
|
|
||||||
Among the logs you'll find the line "I/O pins have been configured for digital output". At this point the electrical pins of the nRF52840 microcontroller has been configured to drive the 4 LEDs on the board.
|
Among the logs you'll find the line "I/O pins have been configured for digital output". At this point the electrical pins of the nRF52840 microcontroller have been configured to drive the 4 LEDs on the board.
|
||||||
|
|
||||||
After the `dk::init` logs you'll find logs about the `Led` API. As the logs indicate an LED becomes active when the output of the pin is a *logical zero*, which is also referred as the "low" state. This "active low" configuration does not apply to all boards: it depends on how the pins have been wired to the LEDs. You should refer to the [board documentation] to find out which pins are connected to LEDs and whether "active low" or "active high" applies to it.
|
After the `dk::init` logs you'll find logs about the `Led` API. As the logs indicate an LED becomes active when the output of the pin is a *logical zero*, which is also referred as the "low" state. This "active low" configuration does not apply to all boards: it depends on how the pins have been wired to the LEDs. You should refer to the [board documentation] to find out which pins are connected to LEDs and whether "active low" or "active high" applies to it.
|
||||||
|
|
||||||
[board documentation]: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52840_dk%2FUG%2Fnrf52840_DK%2Fintro.html
|
[board documentation]: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf52840_dk%2FUG%2Fnrf52840_DK%2Fintro.html
|
||||||
|
|
Loading…
Reference in a new issue