mirrors/embedded-trainings-2020
1
0
Fork 0
mirror of https://github.com/ferrous-systems/embedded-trainings-2020.git synced 2024-10-31 22:28:49 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #34 from ferrous-systems/fixes2

Browse source 
Assorted fixes to the beginner material
This commit is contained in:
Jorge Aparicio 2020-07-13 15:47:08 +00:00 committed by GitHub
commit 3fffebd4a6
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
embedded-workshop-book/src/dongle.md
View file

@ -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
(..) (..)
``` ```

6
embedded-workshop-book/src/radio-out.md
View file

@ -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.

4
embedded-workshop-book/src/using-hal.md
View file

@ -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