Merge #68

68: canonicalize URLs r=therealprof a=japaric

as per #55

closes #55

this PR also ignores print.html when `linkcheck`-ing as done in
rust-embedded/discovery#142

Co-authored-by: Jorge Aparicio <jorge@japaric.io>

src/intro/hardware.md

@@ -5,7 +5,7 @@ Let's get familiar with the hardware we'll be working with.
 ## STM32F3DISCOVERY (the "F3")
 
 <p align="center">
-<img title="F3" src="/book/assets/f3.jpg">
+<img title="F3" src="../assets/f3.jpg">
 </p>
 
 We'll refer to this board as "F3" throughout this book.

src/intro/install.md

@@ -92,6 +92,6 @@ $ rustup component add llvm-tools-preview
 
 Now follow the instructions specific to the OS you are using:
 
-- [Linux](/intro/install/linux.html)
-- [Windows](/intro/install/windows.html)
-- [macOS](/intro/install/macos.html)
+- [Linux](install/linux.md)
+- [Windows](install/windows.md)
+- [macOS](install/macos.md)

src/intro/install/linux.md

@@ -128,4 +128,4 @@ this device.
 
 Now, go to the [next section].
 
-[next section]: /intro/install/verify.html
+[next section]: verify.md

src/intro/install/macos.md

@@ -20,4 +20,4 @@ then first run `brew tap Caskroom/tap` and try again.
 
 That's all! Go to the [next section].
 
-[next section]: /intro/install/verify.html
+[next section]: verify.md

src/intro/install/verify.md

@@ -45,7 +45,7 @@ The contents may not match exactly but you should get the last line about
 breakpoints and watchpoints. If you got it then terminate the OpenOCD process
 and move to the [next section].
 
-[next section]: /install/hardware.html
+[next section]: ../hardware.md
 
 If you didn't get the "breakpoints" line then try the following command.
 
@@ -62,7 +62,7 @@ If neither command worked as a normal user then try to run them with root
 permission (e.g. `sudo openocd ..`). If the commands do work with root
 permission then check that the [udev rules] has been correctly set.
 
-[udev rules]: /install/linux.html
+[udev rules]: linux.md
 
 If you have reached this point and OpenOCD is not working please open [an issue]
 and we'll help you out!

src/intro/install/windows.md

@@ -49,4 +49,4 @@ instructions and make sure you install the right version (32-bit or 64-bit) of t
 
 That's all! Go to the [next section].
 
-[next section]: /intro/install/verify.html
+[next section]: verify.md

src/peripherals/peripherals.md

@@ -18,7 +18,7 @@ Although 32 bit microcontrollers have a real and linear address space from `0x00
 
 Rather than ignore that remaining space, Microcontroller designers instead mapped the interface for peripherals in certain memory locations. This ends up looking something like this:
 
-![](/assets/nrf52-memory-map.png)
+![](../assets/nrf52-memory-map.png)
 
 [Nordic nRF52832 Datasheet (pdf)]
 
@@ -28,7 +28,7 @@ Interaction with these peripherals is simple at a first glance - write the right
 
 Configuration of these peripherals works similarly. Instead of calling a function to configure a peripheral, a chunk of memory is exposed which serves as the hardware API. Write `0x8000_0000` to a SPI Frequency Configuration Register, and the SPI port will send data at 8 Megabits per second. Write `0x0200_0000` to the same address, and the SPI port will send data at 125 Kilobits per second. These configuration registers look a little bit like this:
 
-![](/assets/nrf52-spi-frequency-register.png)
+![](../assets/nrf52-spi-frequency-register.png)
 
 [Nordic nRF52832 Datasheet (pdf)]
 

src/start.md

@@ -8,7 +8,7 @@ In this section we'll walk you through the process of writing, building,
 flashing and debugging embedded programs. You will be able to try most of the
 examples without any special hardware as we will show you the basics using
 QEMU, a popular open-source hardware emulator. The only section where hardware
-is required is, naturally enough, the [Hardware](./start/hardware.md) section,
+is required is, naturally enough, the [Hardware](start/hardware.md) section,
 where we use OpenOCD to program an [STM32F3DISCOVERY].
 
 [STM32F3DISCOVERY]: http://www.st.com/en/evaluation-tools/stm32f3discovery.html

src/start/hardware.md

@@ -38,7 +38,7 @@ We'll start from scratch with a fresh template instance. Refer to the
 [previous section on QEMU] for a refresher on how to do this without
 `cargo-generate`.
 
-[previous section on QEMU]: /start/qemu.md
+[previous section on QEMU]: qemu.md
 
 ``` console
 $ cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart
@@ -102,7 +102,7 @@ time, however, the server will be OpenOCD.
 As done during the [verify] section connect the discovery board to your laptop /
 PC and check that the ST-LINK header is populated.
 
-[verify]: /intro/install/verify.md
+[verify]: ../intro/install/verify.md
 
 On a terminal run `openocd` to connect to the ST-LINK on the discovery board.
 Run this command from the root of the template; `openocd` will pick up the

src/start/registers.md

@@ -122,13 +122,13 @@ struct SysTick {
 }
 
 fn get_systick() -> &'static mut SysTick {
-	unsafe { &mut *(0xE000_E010 as *mut SysTick) }
+    unsafe { &mut *(0xE000_E010 as *mut SysTick) }
 }
 
 fn test() {
-	let systick = get_systick();
-	let time = systick.cvr.read();
-	unsafe { systick.rvr.write(time) };
+    let systick = get_systick();
+    let time = systick.cvr.read();
+    unsafe { systick.rvr.write(time) };
 }
 ```
 
@@ -140,4 +140,4 @@ position. We can always wrap this `struct` into a higher level API which
 verifies when these writes are safe - more on that in the chapter on [Static
 Guarantees].
 
-[Static Guarantees]: /static-guarantees/static-guarantees.md
+[Static Guarantees]: ../static-guarantees/static-guarantees.md