diff --git a/mdbook/src/04-meet-your-hardware/microbit-v2.md b/mdbook/src/04-meet-your-hardware/microbit-v2.md index 0cecf02a..39f901bc 100644 --- a/mdbook/src/04-meet-your-hardware/microbit-v2.md +++ b/mdbook/src/04-meet-your-hardware/microbit-v2.md @@ -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 @@ -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. diff --git a/mdbook/src/09-registers/rtrm.md b/mdbook/src/09-registers/rtrm.md index 1c217127..edba348f 100644 --- a/mdbook/src/09-registers/rtrm.md +++ b/mdbook/src/09-registers/rtrm.md @@ -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`. @@ -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: @@ -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 @@ -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 diff --git a/mdbook/src/09-registers/spooky-action-at-a-distance.md b/mdbook/src/09-registers/spooky-action-at-a-distance.md index 8fecd43a..5e6ea2c1 100644 --- a/mdbook/src/09-registers/spooky-action-at-a-distance.md +++ b/mdbook/src/09-registers/spooky-action-at-a-distance.md @@ -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 @@ -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 diff --git a/mdbook/src/12-i2c/read-a-single-register.md b/mdbook/src/12-i2c/read-a-single-register.md index 45724829..e2b40b8e 100644 --- a/mdbook/src/12-i2c/read-a-single-register.md +++ b/mdbook/src/12-i2c/read-a-single-register.md @@ -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}} ``` @@ -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 diff --git a/mdbook/src/16-snake-game/game-logic.md b/mdbook/src/16-snake-game/game-logic.md index 0023321a..cc957eaa 100644 --- a/mdbook/src/16-snake-game/game-logic.md +++ b/mdbook/src/16-snake-game/game-logic.md @@ -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