From 37efd1b8f19eadafb45d1d52148d5e21e3fef204 Mon Sep 17 00:00:00 2001
From: Kevin O'Connor <kevin@koconnor.net>
Date: Tue, 27 Jul 2021 13:29:36 -0400
Subject: [PATCH] docs: Use hash marks for header lines

Consistently use leading hash marks (#) to note section headers.

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
---
 docs/API_Server.md             | 15 ++++--------
 docs/BLTouch.md                | 24 +++++++------------
 docs/Benchmarks.md             | 36 ++++++++++++++---------------
 docs/Bootloaders.md            | 42 +++++++++++++++-------------------
 docs/Code_Overview.md          | 27 ++++++++--------------
 docs/Kinematics.md             |  6 ++---
 docs/Measuring_Resonances.md   |  3 +--
 docs/Resonance_Compensation.md |  3 +--
 docs/beaglebone.md             | 15 ++++--------
 9 files changed, 67 insertions(+), 104 deletions(-)

diff --git a/docs/API_Server.md b/docs/API_Server.md
index 1ccb6d91..b8419a8d 100644
--- a/docs/API_Server.md
+++ b/docs/API_Server.md
@@ -4,8 +4,7 @@ This document describes Klipper's Application Programmer Interface
 (API). This interface enables external applications to query and
 control the Klipper host software.
 
-Enabling the API socket
------------------------
+## Enabling the API socket
 
 In order to use the API server, the klippy.py host software must be
 started with the `-a` parameter. For example:
@@ -17,8 +16,7 @@ This causes the host software to create a Unix Domain Socket. A client
 can then open a connection on that socket and send commands to
 Klipper.
 
-Request format
---------------
+## Request format
 
 Messages sent and received on the socket are JSON encoded strings
 terminated by an ASCII 0x03 character:
@@ -38,8 +36,7 @@ be on a single line, and it will automatically append the 0x03
 terminator when transmitting a request. (The Klipper API server does
 not have a newline requirement.)
 
-API Protocol
-------------
+## API Protocol
 
 The command protocol used on the communication socket is inspired by
 [json-rpc](https://www.jsonrpc.org/).
@@ -92,8 +89,7 @@ which could cause the associated response to be sent out of order with
 respect to responses from other requests. A JSON request will never
 pause the processing of future JSON requests.
 
-Subscriptions
--------------
+## Subscriptions
 
 Some Klipper "endpoint" requests allow one to "subscribe" to future
 asynchronous update messages.
@@ -120,8 +116,7 @@ with "endpoint" specific contents to the response template and then
 send that template. If a "response_template" field is not provided
 then it defaults to an empty dictionary (`{}`).
 
-Available "endpoints"
----------------------
+## Available "endpoints"
 
 By convention, Klipper "endpoints" are of the form
 `<module_name>/<some_name>`. When making a request to an "endpoint",
diff --git a/docs/BLTouch.md b/docs/BLTouch.md
index 6fad76c5..e763fbef 100644
--- a/docs/BLTouch.md
+++ b/docs/BLTouch.md
@@ -1,7 +1,6 @@
 # BL-Touch
 
-Connecting BL-Touch
--------------------
+## Connecting BL-Touch
 
 A **warning** before you start: Avoid touching the BL-Touch pin with
 your bare fingers, since it is quite sensitive to finger grease. And
@@ -39,8 +38,7 @@ It's important that the z_hop movement in safe_z_home is high enough
 that the probe doesn't hit anything even if the probe pin happens to
 be in its lowest state.
 
-Initial tests
--------------
+## Initial tests
 
 Before moving on, verify that the BL-Touch is mounted at the correct
 height, the pin should be roughly 2 mm above the nozzle when retracted
@@ -83,8 +81,7 @@ doesn't stop when you touch the pin.
 If that was successful, do another `G28` (or `PROBE`) but this time
 let it touch the bed as it should.
 
-BL-Touch gone bad
------------------
+## BL-Touch gone bad
 
 Once the BL-Touch is in inconsistent state, it starts blinking red.
 You can force it to leave that state by issuing:
@@ -106,8 +103,7 @@ right position so it is able to lower and raise the pin and the red
 light turns on and of. Use the `reset`, `pin_up` and `pin_down`
 commands to achieve this.
 
-BL-Touch "clones"
------------------
+## BL-Touch "clones"
 
 Many BL-Touch "clone" devices work correctly with Klipper using the
 default configuration. However, some "clone" devices may require
@@ -144,8 +140,7 @@ the second query reports "probe: TRIGGERED" then it indicates that
 `pin_up_reports_not_triggered` should be set to False in the Klipper
 config file.
 
-BL-Touch v3
------------
+## BL-Touch v3
 
 Some BL-Touch v3.0 and BL-Touch 3.1 devices may require configuring
 `probe_with_touch_mode` in the printer config file.
@@ -172,8 +167,7 @@ probe. If configuring this value on a "clone" or older BL-Touch
 device, be sure to test the probe accuracy before and after setting
 this value (use the `PROBE_ACCURACY` command to test).
 
-Multi-probing without stowing
------------------------------
+## Multi-probing without stowing
 
 By default, Klipper will deploy the probe at the start of each probe
 attempt and then stow the probe afterwards. This repetitive deploying
@@ -203,8 +197,7 @@ to True. On these devices it is a good idea to test the probe accuracy
 before and after setting `probe_with_touch_mode` (use the
 `PROBE_ACCURACY` command to test).
 
-Calibrating the BL-Touch offsets
---------------------------------
+## Calibrating the BL-Touch offsets
 
 Follow the directions in the [Probe Calibrate](Probe_Calibrate.md)
 guide to set the x_offset, y_offset, and z_offset config parameters.
@@ -218,8 +211,7 @@ far above the nozzle as possible to avoid it touching printed parts.
 If an adjustment is made to the probe position, then rerun the probe
 calibration steps.
 
-BL-Touch output mode
---------------------
+## BL-Touch output mode
 
 * A BL-Touch V3.0 supports setting a 5V or OPEN-DRAIN output mode,
   a BL-Touch V3.1 supports this too, but can also store this in its
diff --git a/docs/Benchmarks.md b/docs/Benchmarks.md
index 7ed16312..77906afb 100644
--- a/docs/Benchmarks.md
+++ b/docs/Benchmarks.md
@@ -2,8 +2,7 @@
 
 This document describes Klipper benchmarks.
 
-Micro-controller Benchmarks
----------------------------
+## Micro-controller Benchmarks
 
 This section describes the mechanism used to generate the Klipper
 micro-controller step rate benchmarks.
@@ -25,7 +24,7 @@ or other innocuous pins. **Always verify that it is safe to drive the
 configured pins prior to running a benchmark.** It is not recommended
 to drive an actual stepper during a benchmark.
 
-### Step rate benchmark test ###
+### Step rate benchmark test
 
 The test is performed using the console.py tool (described in
 [Debugging.md](Debugging.md)). The micro-controller is configured for
@@ -88,7 +87,7 @@ delay"). This configuration is believed to be valid in real-world
 usage when one is solely using Trinamic stepper drivers. The results
 of these benchmarks are not reported in the Features.md document.
 
-### AVR step rate benchmark ###
+### AVR step rate benchmark
 
 The following configuration sequence is used on AVR chips:
 ```
@@ -111,7 +110,7 @@ results match tests on both a 16Mhz at90usb and a 16Mhz atmega2560).
 | 2 stepper        | 296   |
 | 3 stepper        | 472   |
 
-### Arduino Due step rate benchmark ###
+### Arduino Due step rate benchmark
 
 The following configuration sequence is used on the Due:
 ```
@@ -133,7 +132,7 @@ The test was last run on commit `8d4a5c16` with gcc version
 | 1 stepper (no delay) | 77    |
 | 3 stepper (no delay) | 299   |
 
-### Duet Maestro step rate benchmark ###
+### Duet Maestro step rate benchmark
 
 The following configuration sequence is used on the Duet Maestro:
 ```
@@ -155,7 +154,7 @@ The test was last run on commit `8d4a5c16` with gcc version
 | 1 stepper (no delay) | 70    |
 | 3 stepper (no delay) | 254   |
 
-### Duet Wifi step rate benchmark ###
+### Duet Wifi step rate benchmark
 
 The following configuration sequence is used on the Duet Wifi:
 ```
@@ -179,7 +178,7 @@ The test was last run on commit `59a60d68` with gcc version
 | 3 stepper        | 525   |
 | 4 stepper        | 703   |
 
-### Beaglebone PRU step rate benchmark ###
+### Beaglebone PRU step rate benchmark
 
 The following configuration sequence is used on the PRU:
 ```
@@ -200,7 +199,7 @@ The test was last run on commit `b161a69e` with gcc version `pru-gcc
 | 2 stepper        | 853   |
 | 3 stepper        | 883   |
 
-### STM32F042 step rate benchmark ###
+### STM32F042 step rate benchmark
 
 The following configuration sequence is used on the STM32F042:
 ```
@@ -220,7 +219,7 @@ The test was last run on commit `0b0c47c5` with gcc version
 | 2 stepper        | 328   |
 | 3 stepper        | 558   |
 
-### STM32F103 step rate benchmark ###
+### STM32F103 step rate benchmark
 
 The following configuration sequence is used on the STM32F103:
 ```
@@ -242,7 +241,7 @@ The test was last run on commit `8d4a5c16` with gcc version
 | 1 stepper (no delay) | 71    |
 | 3 stepper (no delay) | 288   |
 
-### STM32F4 step rate benchmark ###
+### STM32F4 step rate benchmark
 
 The following configuration sequence is used on the STM32F4:
 ```
@@ -277,7 +276,7 @@ using a 168Mhz clock).
 | 1 stepper (no delay) | 52    |
 | 3 stepper (no delay) | 226   |
 
-### LPC176x step rate benchmark ###
+### LPC176x step rate benchmark
 
 The following configuration sequence is used on the LPC176x:
 ```
@@ -308,7 +307,7 @@ results were obtained by overclocking an LPC1768 to 120Mhz.
 | 1 stepper (no delay) | 56    |
 | 3 stepper (no delay) | 240   |
 
-### SAMD21 step rate benchmark ###
+### SAMD21 step rate benchmark
 
 The following configuration sequence is used on the SAMD21:
 ```
@@ -331,7 +330,7 @@ micro-controller.
 | 1 stepper (no delay) | 83    |
 | 3 stepper (no delay) | 321   |
 
-### SAMD51 step rate benchmark ###
+### SAMD51 step rate benchmark
 
 The following configuration sequence is used on the SAMD51:
 ```
@@ -362,7 +361,7 @@ micro-controller.
 | 1 stepper (no delay) | 42    |
 | 3 stepper (no delay) | 194   |
 
-### RP2040 step rate benchmark ###
+### RP2040 step rate benchmark
 
 The following configuration sequence is used on the RP2040:
 
@@ -388,7 +387,7 @@ Pico board.
 | 1 stepper (no delay) | 5     |
 | 3 stepper (no delay) | 22    |
 
-### Linux MCU step rate benchmark ###
+### Linux MCU step rate benchmark
 
 The following configuration sequence is used on a Raspberry Pi:
 ```
@@ -409,7 +408,7 @@ The test was last run on commit `db0fb5d5` with gcc version `gcc
 | 2 stepper            | 350   |
 | 3 stepper            | 400   |
 
-## Command dispatch benchmark ##
+## Command dispatch benchmark
 
 The command dispatch benchmark tests how many "dummy" commands the
 micro-controller can process. It is primarily a test of the hardware
@@ -450,8 +449,7 @@ hub.
 | stm32f446 (USB)     | 870K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
 | rp2040 (USB)        | 873K | c5667193 | arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 |
 
-Host Benchmarks
----------------
+## Host Benchmarks
 
 It is possible to run timing tests on the host software using the
 "batch mode" processing mechanism (described in
diff --git a/docs/Bootloaders.md b/docs/Bootloaders.md
index bb070a70..40c1acd2 100644
--- a/docs/Bootloaders.md
+++ b/docs/Bootloaders.md
@@ -25,7 +25,7 @@ application.  This document is not an authoritative reference; it is
 intended as a collection of useful information that the Klipper
 developers have accumulated.
 
-## AVR micro-controllers ##
+## AVR micro-controllers
 
 
 In general, the Arduino project is a good reference for bootloaders
@@ -46,7 +46,7 @@ use.
 The "avrdude" program is the most common tool used to flash atmega
 chips (both bootloader flashing and application flashing).
 
-### Atmega2560 ###
+### Atmega2560
 
 This chip is typically found in the "Arduino Mega" and is very common
 in 3d printer boards.
@@ -65,7 +65,7 @@ To flash an application use something like:
 avrdude -cwiring -patmega2560 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
 ```
 
-### Atmega1280 ###
+### Atmega1280
 
 This chip is typically found in earlier versions of the "Arduino
 Mega".
@@ -84,7 +84,7 @@ To flash an application use something like:
 avrdude -carduino -patmega1280 -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
 ```
 
-### Atmega1284p ###
+### Atmega1284p
 
 This chip is commonly found in "Melzi" style 3d printer boards.
 
@@ -109,7 +109,7 @@ application use something like this instead:
 avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
 ```
 
-### At90usb1286 ###
+### At90usb1286
 
 This document does not cover the method to flash a bootloader to the
 At90usb1286 nor does it cover general application flashing to this
@@ -124,7 +124,7 @@ One can flash an application with it using something like:
 teensy_loader_cli --mcu=at90usb1286 out/klipper.elf.hex -v
 ```
 
-### Atmega168 ###
+### Atmega168
 
 The atmega168 has limited flash space. If using a bootloader, it is
 recommended to use the Optiboot bootloader. To flash that bootloader
@@ -143,8 +143,7 @@ like:
 avrdude -carduino -patmega168 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
 ```
 
-SAM3 micro-controllers (Arduino Due)
-------------------------------------
+## SAM3 micro-controllers (Arduino Due)
 
 It is not common to use a bootloader with the SAM3 mcu. The chip
 itself has a ROM that allows the flash to be programmed from 3.3V
@@ -167,8 +166,7 @@ bossac -U -p /dev/ttyACM0 -a -e -w out/klipper.bin -v -b
 bossac -U -p /dev/ttyACM0 -R
 ```
 
-SAM4 micro-controllers (Duet Wifi)
-----------------------------------
+## SAM4 micro-controllers (Duet Wifi)
 
 It is not common to use a bootloader with the SAM4 mcu. The chip
 itself has a ROM that allows the flash to be programmed from 3.3V
@@ -187,8 +185,7 @@ To flash an application use something like:
 bossac --port=/dev/ttyACM0 -b -U -e -w -v -R out/klipper.bin
 ```
 
-SAMD21 micro-controllers (Arduino Zero)
----------------------------------------
+## SAMD21 micro-controllers (Arduino Zero)
 
 The SAMD21 bootloader is flashed via the ARM Serial Wire Debug (SWD)
 interface. This is commonly done with a dedicated SWD hardware dongle.
@@ -226,8 +223,7 @@ flash command within the first few seconds of boot - something like:
 avrdude -c stk500v2 -p atmega2560 -P /dev/ttyACM0 -u -Uflash:w:out/klipper.elf.hex:i
 ```
 
-SAMD51 micro-controllers (Adafruit Metro-M4 and similar)
---------------------------------------------------------
+## SAMD51 micro-controllers (Adafruit Metro-M4 and similar)
 
 Like the SAMD21, the SAMD51 bootloader is flashed via the ARM Serial
 Wire Debug (SWD) interface. To flash a bootloader with
@@ -255,8 +251,7 @@ like:
 bossac -U -p /dev/ttyACM0 --offset=0x4000 -w out/klipper.bin -v -b -R
 ```
 
-STM32F103 micro-controllers (Blue Pill devices)
------------------------------------------------
+## STM32F103 micro-controllers (Blue Pill devices)
 
 The STM32F103 devices have a ROM that can flash a bootloader or
 application via 3.3V serial. To access this ROM, one should connect
@@ -276,7 +271,7 @@ for details on enabling the full uart on the Raspberry Pi GPIO pins.
 After flashing, set both "boot 0" and "boot 1" back to low so that
 future resets boot from flash.
 
-### STM32F103 with stm32duino bootloader ###
+### STM32F103 with stm32duino bootloader
 
 The "stm32duino" project has a USB capable bootloader - see:
 [https://github.com/rogerclarkmelbourne/STM32duino-bootloader](https://github.com/rogerclarkmelbourne/STM32duino-bootloader)
@@ -301,7 +296,8 @@ bootloader is still active (the bootloader will flash a board led
 while it is running). Alternatively, set the "boot 0" pin to low and
 "boot 1" pin to high to stay in the bootloader after a reset.
 
-### STM32F103 with HID bootloader ###
+### STM32F103 with HID bootloader
+
 The [HID bootloader](https://github.com/Serasidis/STM32_HID_Bootloader) is a
 compact, driverless bootloader capable of flashing over USB. Also available
 is a [fork with builds specific to the SKR Mini E3 1.2](
@@ -389,8 +385,8 @@ not available, so it may be done by setting pin PA2 low if you flashed
 the SKR Mini E3's "PIN" document. There is a ground pin next to PA2
 which you can use to pull PA2 low.
 
-STM32F4 micro-controllers (SKR Pro 1.1)
-===============================================
+## STM32F4 micro-controllers (SKR Pro 1.1)
+
 STM32F4 microcontrollers come equipped with a built-in system bootloader
 capable of flashing over USB (via DFU), 3.3v Serial, and various other
 methods (see STM Document AN2606 for more information).  Some
@@ -423,8 +419,7 @@ setting "boot 0" low, "boot 1" high and plugging in the device.  After
 programming is complete unplug the device and set "boot 1" back to low
 so the application will be loaded.
 
-LPC176x micro-controllers (Smoothieboards)
-------------------------------------------
+## LPC176x micro-controllers (Smoothieboards)
 
 This document does not describe the method to flash a bootloader
 itself - see:
@@ -439,8 +434,7 @@ this bootloader is to copy the application file (eg,
 `out/klipper.bin`) to a file named `firmware.bin` on an SD card, and
 then to reboot the micro-controller with that SD card.
 
-Running OpenOCD on the Raspberry PI
------------------------------------
+## Running OpenOCD on the Raspberry PI
 
 OpenOCD is a software package that can perform low-level chip flashing
 and debugging. It can use the GPIO pins on a Raspberry Pi to
diff --git a/docs/Code_Overview.md b/docs/Code_Overview.md
index fff6d7c9..2e9dcf04 100644
--- a/docs/Code_Overview.md
+++ b/docs/Code_Overview.md
@@ -3,8 +3,7 @@
 This document describes the overall code layout and major code flow of
 Klipper.
 
-Directory Layout
-----------------
+## Directory Layout
 
 The **src/** directory contains the C source for the micro-controller
 code. The **src/atsam/**, **src/atsamd/**, **src/avr/**,
@@ -40,8 +39,7 @@ contains temporary build time objects. The final micro-controller
 object that is built is **out/klipper.elf.hex** on AVR and
 **out/klipper.bin** on ARM.
 
-Micro-controller code flow
---------------------------
+## Micro-controller code flow
 
 Execution of the micro-controller code starts in architecture specific
 code (eg, **src/avr/main.c**) which ultimately calls sched_main()
@@ -91,8 +89,7 @@ inlining functions across compilation units, so most of these tiny
 gpio functions are inlined into their callers, and there is no
 run-time cost to using them.
 
-Klippy code overview
---------------------
+## Klippy code overview
 
 The host code (Klippy) is intended to run on a low-cost computer (such
 as a Raspberry Pi) paired with the micro-controller. The code is
@@ -117,8 +114,7 @@ response messages from the micro-controller in the Python code (see
 the log (see **klippy/queuelogger.py**) so that the other threads
 never block on log writes.
 
-Code flow of a move command
----------------------------
+## Code flow of a move command
 
 A typical printer movement starts when a "G1" command is sent to the
 Klippy host and it completes when the corresponding step pulses are
@@ -229,8 +225,7 @@ kinematic classes. It's this part of the code which specifies the
 movements and their timings. The remaining parts of the processing is
 mostly just communication and plumbing.
 
-Adding a host module
---------------------
+## Adding a host module
 
 The Klippy host code has a dynamic module loading capability. If a
 config section named "[my_module]" is found in the printer config file
@@ -309,8 +304,7 @@ The following may also be useful:
   sure to place a copyright notice at the top of the module. See the
   existing modules for the preferred format.
 
-Adding new kinematics
----------------------
+## Adding new kinematics
 
 This section provides some tips on adding support to Klipper for
 additional types of printer kinematics. This type of activity requires
@@ -349,8 +343,7 @@ Useful steps:
    to micro-controller commands. This is useful to exercise corner
    cases and to check for regressions.
 
-Porting to a new micro-controller
----------------------------------
+## Porting to a new micro-controller
 
 This section provides some tips on porting Klipper's micro-controller
 code to a new architecture. This type of activity requires good
@@ -402,8 +395,7 @@ Useful steps:
    the micro-controller with the main klippy.py program.
 9. Consider adding build test cases in the test/ directory.
 
-Coordinate Systems
-------------------
+## Coordinate Systems
 
 Internally, Klipper primarily tracks the position of the toolhead in
 cartesian coordinates that are relative to the coordinate system
@@ -488,8 +480,7 @@ cartesian coordinates relative to the coordinate system specified in
 the config file) after a `G28` home command. The `SET_GCODE_OFFSET`
 command can alter this value.
 
-Time
-----
+## Time
 
 Fundamental to the operation of Klipper is the handling of clocks,
 times, and timestamps. Klipper executes actions on the printer by
diff --git a/docs/Kinematics.md b/docs/Kinematics.md
index fff02dba..313d5dce 100644
--- a/docs/Kinematics.md
+++ b/docs/Kinematics.md
@@ -197,7 +197,7 @@ stepper_position = (sqrt(arm_length^2
                     + cartesian_z_position)
 ```
 
-### Stepper motor acceleration limits ###
+### Stepper motor acceleration limits
 
 With delta kinematics it is possible for a move that is accelerating
 in cartesian space to require an acceleration on a particular stepper
@@ -218,7 +218,7 @@ this limit, moves at the extreme edge of the build envelope (where a
 stepper arm may be nearly horizontal) will have a lower maximum
 acceleration and velocity.
 
-### Extruder kinematics ###
+### Extruder kinematics
 
 Klipper implements extruder motion in its own kinematic class. Since
 the timing and speed of each print head movement is fully known for
@@ -232,7 +232,7 @@ generation uses the same formulas that cartesian robots use:
 stepper_position = requested_e_position
 ```
 
-### Pressure advance ###
+### Pressure advance
 
 Experimentation has shown that it's possible to improve the modeling
 of the extruder beyond the basic extruder formula. In the ideal case,
diff --git a/docs/Measuring_Resonances.md b/docs/Measuring_Resonances.md
index c4051976..f9272ed3 100644
--- a/docs/Measuring_Resonances.md
+++ b/docs/Measuring_Resonances.md
@@ -1,5 +1,4 @@
-Measuring Resonances
-====================
+# Measuring Resonances
 
 Klipper has built-in support for ADXL345 accelerometer, which can be used to
 measure resonance frequencies of the printer for different axes, and auto-tune
diff --git a/docs/Resonance_Compensation.md b/docs/Resonance_Compensation.md
index 5707d51b..b83211ce 100644
--- a/docs/Resonance_Compensation.md
+++ b/docs/Resonance_Compensation.md
@@ -1,5 +1,4 @@
-Resonance Compensation
-====================
+# Resonance Compensation
 
 Klipper supports Input Shaping - a technique that can be used to reduce ringing
 (also known as echoing, ghosting or rippling) in prints. Ringing is a surface
diff --git a/docs/beaglebone.md b/docs/beaglebone.md
index 322db01e..f8c798b8 100644
--- a/docs/beaglebone.md
+++ b/docs/beaglebone.md
@@ -3,8 +3,7 @@
 This document describes the process of running Klipper on a Beaglebone
 PRU.
 
-Building an OS image
---------------------
+## Building an OS image
 
 Start by installing the
 [Debian 9.9 2019-08-03 4GB SD IoT](https://beagleboard.org/latest-images)
@@ -20,8 +19,7 @@ git clone https://github.com/KevinOConnor/klipper
 ./klipper/scripts/install-beaglebone.sh
 ```
 
-Install Octoprint
------------------
+## Install Octoprint
 
 One may then install Octoprint:
 ```
@@ -56,8 +54,7 @@ sudo systemctl start octoprint
 Make sure the octoprint web server is accessible - it should be at:
 [http://beaglebone:5000/](http://beaglebone:5000/)
 
-Building the micro-controller code
-----------------------------------
+## Building the micro-controller code
 
 To compile the Klipper micro-controller code, start by configuring it
 for the "Beaglebone PRU":
@@ -87,15 +84,13 @@ make flash
 sudo service klipper start
 ```
 
-Remaining configuration
------------------------
+## Remaining configuration
 
 Complete the installation by configuring Klipper and Octoprint
 following the instructions in
 [the main installation document](Installation.md#configuring-klipper).
 
-Printing on the Beaglebone
---------------------------
+## Printing on the Beaglebone
 
 Unfortunately, the Beaglebone processor can sometimes struggle to run
 OctoPrint well. Print stalls have been known to occur on complex