updated nRF52833 Product Specification links to v1.7

- replaced v1.3/v1.6 infocenter/docs URLs with v1.7 docs-be
- added links where the PS was referenced without one
- moved link definitions to end of their sections

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: BartMassey

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.
 
 

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

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

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
 

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