Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions mdbook/src/04-meet-your-hardware/microbit-v2.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ short for radio frequency. If we search through the documentation of the chip l
[aQFN73]: https://en.wikipedia.org/wiki/Flat_no-leads_package
[Nordic Semiconductor]: https://www.nordicsemi.com/
[product page]: https://www.nordicsemi.com/products/nrf52833
[product specification]: https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf
[product specification]: https://docs-be.nordicsemi.com/bundle/ps_nrf52833/attach/nRF52833_PS_v1.7.pdf

- The `N52` is the MCU's series, indicating that there are other `nRF52` MCUs
- The `833` is the part code
Expand All @@ -33,7 +33,7 @@ short for radio frequency. If we search through the documentation of the chip l
- The `A0` is the build code, indicating the hardware version (`A`) as well as the product configuration (`0`)
- The `2024AL` is a tracking code, hence it might differ on your chip

The product specification does of course contain a lot more useful information about the chip: for
The [product specification] does of course contain a lot more useful information about the chip: for
example, that the chip is an Arm® Cortex™-M4 32-bit processor.


Expand Down
8 changes: 4 additions & 4 deletions mdbook/src/09-registers/rtrm.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,8 +25,6 @@ registers allocated in contiguous memory. The address at which the register bloc
its base address. We need to figure out what's the base address of the `P0` peripheral. That
information is in the following section of the microcontroller [Product Specification]:

[Product Specification]: https://docs.nordicsemi.com/bundle/nRF52833_PS_v1.6/resource/nRF52833_PS_v1.6.pdf

> Section 4.2.4 Instantiation - Page 22

The table says that base address of the `P0` register block is `0x5000_0000`.
Expand All @@ -38,7 +36,7 @@ peripheral, that table is in:
> Section 6.8.2 Registers - Page 144

`OUT` is the register which we will be using to set/reset. Its offset value is `0x504` from the base
address of the `P0`. We can look up `OUT` in the reference manual.
address of the `P0`. We can look up `OUT` in the [Product Specification].

That register is specified right under the `GPIO` registers table:

Expand Down Expand Up @@ -92,7 +90,7 @@ Breakpoint 1, registers::__cortex_m_rt_main () at src/07-registers/src/main.rs:1
```

Ok, we see that the register's value is `0x00000000` or `0` at this point. This corresponds with the
data in the product specification, which says that `0` is the 'reset value' of this register. That
data in the [Product Specification], which says that `0` is the 'reset value' of this register. That
means that once the MCU resets, the register will have `0` as its value.

Let's go on. This line consists of multiple instructions (reading, bitwise ORing and writing), so we
Expand Down Expand Up @@ -196,3 +194,5 @@ Program received signal SIGINT, Interrupt.
```

And at this points all LEDs should be turned off again!

[Product Specification]: https://docs-be.nordicsemi.com/bundle/ps_nrf52833/attach/nRF52833_PS_v1.7.pdf
4 changes: 3 additions & 1 deletion mdbook/src/09-registers/spooky-action-at-a-distance.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
you change the value of the pins, as can `OUTCLR`. However, `OUTSET` and `OUTCLR` don't let you
retrieve the current output status of port `P0`.

`OUTSET` is documented in:
`OUTSET` is documented in the [Product Specification]:

> Subsection 6.8.2.2. OUTSET - Page 145

Expand All @@ -30,3 +30,5 @@ $ cargo embed

Side effects! Although we are reading the same address multiple times without actually modifying it,
we still see its value change every time `OUTSET` or `OUTCLR` is written to.

[Product Specification]: https://docs-be.nordicsemi.com/bundle/ps_nrf52833/attach/nRF52833_PS_v1.7.pdf
18 changes: 10 additions & 8 deletions mdbook/src/12-i2c/read-a-single-register.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,19 +22,18 @@ that just happens to have the same address. As you can read in the LSM303AGR's
device. (The "A" is for "Accelerometer" and the "M" is for "Magnetometer".)

The only thing missing now is the software part: we need to determine which API of the `microbit` or
a HAL crate we should use for this. If you read through the datasheet of the nRF chip you are using
you will soon find out that it doesn't actually have an I2C-specific peripheral. Instead, it has
more general-purpose I2C-compatible peripherals called TWI ("Two-Wire Interface"), TWIM ("Two-Wire
Interface Master") and TWIS ("Two-Wire Interface Slave"). We will normally be operating in
controller mode and will use the newer TWIM, which supports "Easy DMA" — the TWI is provided mostly
for backward compatibility with older devices.
a HAL crate we should use for this. If you read through the [nRF52833 Product Specification]
you will soon find out that it doesn't actually have an I2C-specific peripheral.
Instead, it has more general-purpose I2C-compatible peripherals called TWI ("Two-Wire
Interface"), TWIM ("Two-Wire Interface Master") and TWIS ("Two-Wire Interface Slave").
We will normally be operating in controller mode and will use the newer TWIM, which
supports "Easy DMA" — the TWI is provided mostly for backward compatibility with older
devices.

Now if we put the documentation of the [`twi(m)` module] from the `microbit` crate
together with all the other information we have gathered so far we'll end up with this
piece of code to read out and print the two device IDs (`examples/chip-id.rs`):

[`twi(m)` module]: https://docs.rs/microbit-v2/0.11.0/microbit/hal/twim/index.html

``` rust
{{#include examples/chip-id.rs}}
```
Expand All @@ -45,6 +44,9 @@ chapter. We pass the peripheral as well as the pins that are used to communicat
the constructor; and then the frequency we wish the bus to operate on, in this case 100 kHz (`K100`,
since identifiers can't start with a digit).

[nRF52833 Product Specification]: https://docs-be.nordicsemi.com/bundle/ps_nrf52833/attach/nRF52833_PS_v1.7.pdf
[`twi(m)` module]: https://docs.rs/microbit-v2/0.11.0/microbit/hal/twim/index.html

## Testing it
As usual

Expand Down
2 changes: 1 addition & 1 deletion mdbook/src/16-snake-game/game-logic.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ cryptographically secure, but it is efficient, easy to implement and good enough
snake game. Our `Prng` struct requires an initial seed value, which we do get from the RNG
peripheral.

[nRF52833 spec]: https://infocenter.nordicsemi.com/pdf/nRF52833_PS_v1.3.pdf
[nRF52833 spec]: https://docs-be.nordicsemi.com/bundle/ps_nrf52833/attach/nRF52833_PS_v1.7.pdf
[pseudo-random]: https://en.wikipedia.org/wiki/Pseudorandom_number_generator
[xorshift]: https://en.wikipedia.org/wiki/Xorshift

Expand Down
Loading