Tidying up header levels

Author: iriark01

docs/api/api.md

@@ -1,6 +1,6 @@
 # Full API list
 
-# Platform APIs
+## Platform APIs
 
 [Platform APIs](platform.html) provide general purpose MCU management infrastructure, common data structures and a consistent user experience on top of different standard libraries and toolchains.
 
@@ -45,7 +45,7 @@
 </tbody>
 </table>
 
-# Drivers APIs
+## Drivers APIs
 
 [Driver APIs](drivers.html) include analog and digital inputs and outputs on development boards, as well as digital interfaces, which allow your board to interface with a computer or external devices.
 
@@ -99,7 +99,7 @@
 </tbody>
 </table>
 
-# RTOS APIs
+## RTOS APIs
 
 The [Mbed OS RTOS](rtos.html) capabilities include managing objects such as threads, synchronization objects and timers. It also provides interfaces for attaching an application-specific idle hook function, reads the OS tick count and implements functionality to report RTOS errors.
 
@@ -127,7 +127,7 @@ The [Mbed OS RTOS](rtos.html) capabilities include managing objects such as thre
 </tbody>
 </table>
 
-# USB APIs
+## USB APIs
 
 The Mbed OS classes providing USB peripheral functionality, also known as [USB components](../apis/usb.html), inherit from USBDevice and provide specific USB peripherial functionality.
 
@@ -150,7 +150,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-# Network socket APIs
+## Network socket APIs
 
 [Network socket APIs](network-socket.html) include the application programming interface for IP networking. In Mbed OS, this API supports both TCP and UDP protocols.
 
@@ -171,7 +171,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-# Network interfaces APIs
+## Network interfaces APIs
 
 [Network interfaces](network-interfaces.html) are the application level APIs where users choose the driver, connectivity method and IP stack. These include ethernet, Wi-Fi, cellular and mesh interfaces.
 
@@ -189,7 +189,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-# Bluetooth Low Energy (BLE) APIs
+## Bluetooth Low Energy (BLE) APIs
 
 [Bluetooth low energy (BLE)](bluetooth.html) is a low power wireless technology standard for building personal area networks. Typical applications of BLE are health care, fitness trackers, beacons, smart home, security, entertainment, proximity sensors, industrial and automotive.
 
@@ -210,7 +210,7 @@ The Mbed OS classes providing USB peripheral functionality, also known as [USB c
 </tbody>
 </table>
 
-# LoRaWAN APIs
+## LoRaWAN APIs
 
 Arm Mbed OS provides a native network stack for [LoRaWAN](lorawan.html). LoRaWAN is a technology designed for low-power battery-powered devices. These devices operate in an unlicensed spectrum, creating high density wide-area networks.
 
@@ -225,7 +225,7 @@ Arm Mbed OS provides a native network stack for [LoRaWAN](lorawan.html). LoRaWAN
 </tbody>
 </table>
 
-# NFC APIs
+## NFC APIs
 
 You can use [Near-Field Communication (NFC)](nfc.html), a short-range radio technology, to enable use cases such as contactless payments, access control and device pairing.
 
@@ -243,7 +243,7 @@ You can use [Near-Field Communication (NFC)](nfc.html), a short-range radio tech
 </tbody>
 </table>
 
-# Security API
+## Security API
 
 With [Arm Mbed TLS](security.html), a comprehensive SSL/TLS solution, you can include cryptographic and SSL/TLS capabilities in your code.
 
@@ -261,7 +261,7 @@ With [Arm Mbed TLS](security.html), a comprehensive SSL/TLS solution, you can in
 </tbody>
 </table>
 
-# Storage APIs
+## Storage APIs
 
 The [storage APIs](storage.html) include file system APIs, for file system operations, and block devices, which provide the raw storage for the file systems.
 

docs/api/bluetooth/BLE.md

@@ -8,7 +8,7 @@ Arm Mbed BLE, also called `BLE_API`, is the Bluetooth Low Energy software soluti
 
 Mbed’s `BLE_API` interfaces with the BLE controller on the platform. It hides the BLE stack’s complexity behind C++ abstractions and is compatible with all BLE-enabled Mbed platforms. The Mbed OS `BLE_API` automatically configuring the clocks, timers and other hardware peripherals to work at their lowest power consumption.
 
-# `BLE_API`, bridges and stacks
+## `BLE_API`, bridges and stacks
 
 <span class="images">![](../../images/BLEDiagram.png)</span>
 
@@ -18,7 +18,7 @@ You can build a BLE application using Mbed OS, `BLE_API` and a controller-specif
 - The bridge software is specific to each vendor’s platform. It provides the instantiations for the interfaces `BLE_API` offers and helps drive the underlying controller and Bluetooth stack.
 - The Bluetooth stack implements the Bluetooth protocol and is specific to the controller, so a vendor using different controllers may provide different stacks.
 
-# Inside `BLE_API`
+## Inside `BLE_API`
 
 <span class="images">![](../../images/Inside_API.png)</span>
 
@@ -28,7 +28,7 @@ You can build a BLE application using Mbed OS, `BLE_API` and a controller-specif
 
 1. Classes under `ble/services` to offer reference implementations for many of the commonly used GATT profiles. The code under 'services/' isn't essential, but it’s a useful starting point for prototyping. We continue to implement the standard GATT profiles.
 
-# The BLEDevice class and header
+## The BLEDevice class and header
 
 The entry point of Mbed's `BLE_API` is the BLE class accessible using the header `ble/BLE.h`. This class allows you to obtain a BLE object that includes the basic attributes of a spec-compatible BLE device and can work with any BLE radio:
 
@@ -44,31 +44,31 @@ The class's member functions can be divided by purpose:
 
 1. Accessor to Bluetooth Modules that manage GAP, GATT or the security.
 
-# Usage
+## Usage
 
 1. Set up advertising and connection modes.
 1. Assign UUIDs to the service and its characteristic.
 1. Create an input characteristic.
 1. Construct a service class and add it to the BLE stack.
 1. Push notifications when the characteristic's value changes.
 
-# BLE class reference
+## BLE class reference
 
 [![View code](https://www.mbed.com/embed/?type=library)](https://os.mbed.com/docs/development/mbed-os-api-doxy/class_b_l_e.html)
 
-# Example: BLE beacon
+## Example: BLE beacon
 
 Here is an example demonstrating how you can create a BLE beacon.
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-example-ble/blob/master/BLE_Beacon/source)](https://github.com/ARMmbed/mbed-os-example-ble/blob/mbed-os-5.14/BLE_Beacon/source/main.cpp)
 
-# Example: BLE heart rate monitor
+## Example: BLE heart rate monitor
 
 Here is an example demonstrating how to build a heart rate sensor that can be connected and monitored by a BLE client such as your phone.
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-example-ble/blob/master/BLE_HeartRate/source)](https://github.com/ARMmbed/mbed-os-example-ble/blob/mbed-os-5.14/BLE_HeartRate/source/main.cpp)
 
-# Related content
+## Related content
 
 - Mbed Enabled [targets and components](https://os.mbed.com/platforms/?mbed-enabled=15&connectivity=3) that support BLE.
 - [BLE tutorial](../tutorials/ble-tutorial.html).

docs/api/bluetooth/ble_tutorial.md

@@ -1,6 +1,6 @@
 <h1 id="ble-tutorial">BLE</h1>
 
-# Getting started
+## Getting started
 
 1. Choose an [Arm Mbed board that supports BLE](https://os.mbed.com/platforms/?mbed-enabled=15&connectivity=3), such as the [NRF51-DK](https://os.mbed.com/platforms/Nordic-nRF51-DK/).
 
@@ -21,7 +21,7 @@
 
     <span>**Tip:** Despite the differences between the different Mbed OS versions, there is only **one** version of Mbed BLE, and it is easy to move code from one version of the OS to another. Choose the sample you use according to the version of Mbed OS supported by your development board.</span>
 
-# Going further
+## Going further
 
 - The Mbed BLE [API reference](../apis/ble.html) offers the full details of the API.
 

docs/api/connectivity-arch.md

@@ -1,6 +1,6 @@
 <h1 id="connectivity-tech">Network connectivity in Mbed OS</h1>
 
-# Supported connectivity technologies
+## Supported connectivity technologies
 
 Mbed OS offers a strong, integrated stack of standards-based technologies:
 
@@ -18,11 +18,11 @@ Non-IP devices require a gateway:
 - LoRaWAN.
 - Cellular.
 
-# Choosing your connectivity method
+## Choosing your connectivity method
 
 There is a wide variety of possibilities for connected devices, and there is no globally correct connectivity method. Choose a method that fits your application needs, and then choose a device that can support that method. If you're already committed to a device type, you may need to adjust your application to work within that device's connectivity constraints.
 
-# Internet protocol (IP) networking
+## Internet protocol (IP) networking
 
 Mbed OS supports various IP-based connectivity options and IP stacks.
 
@@ -32,15 +32,15 @@ Our Socket API standardizes all of our connectivity options. It supports both IP
 
 Mbed OS provides network drivers, such as Ethernet, Wi-Fi and cellular.
 
-## Wi-Fi
+### Wi-Fi
 
 Wi-Fi has a relatively high throughput of up to 1 Gbps, which is suitable for data-heavy applications. The cost of this throughput is high power consumption. Wi-Fi is not ideal for long-term deployments of battery-powered devices. It can also prove problematic where other devices compete for the same bandwidth.
 
 It works for proof-of-concept devices because the infrastructure is in place in most offices, and its WPA2 security is familiar to developers.
 
 End devices for Wi-Fi are complicated due to hardware requirements and limitations. The network cost depends on whether the deployment location already includes a well-maintained Wi-Fi infrastructure. Wi-Fi is ubiquitous indoors, and Wi-Fi devices have a range of tens of meters, so for certain applications, such as those for homes and offices, the infrastructure likely already exists.
 
-## Cellular
+### Cellular
 
 Cellular has a variable throughput, reaching 10 Mbps. Its coverage is extensive, and its range is 25-100 km, so it is commonly used in transportation and logistics. It is also well suited for proof of concept, because, like Wi-Fi, it relies on an existing infrastructure. It's suitable for many use cases, from monitoring temperature sensors to streaming video.
 
@@ -54,15 +54,15 @@ The new cellular technologies, NB-IoT and CAT-M1, are designed for IoT devices.
 
 It can be deployed on a single spectrum, reducing antenna configuration complexity, but isn't deployed worldwide and can take years to be deployed in countries using 3G.
 
-## Bluetooth Low Energy (BLE)
+### Bluetooth Low Energy (BLE)
 
 BLE is optimized for cheap, battery-based devices and has a low memory footprint. It is widely adopted for connected spaces but requires setting up an infrastructure. Its range is up to 100 meters, with 1 mbps bandwidth. You need an edge gateway, so devices in your network can connect to the internet.
 
 Typical applications of BLE are health care, fitness trackers, beacons, smart homes, security, entertainment, proximity sensors, industrial applications and automotives.
 
 To learn how to use BLE on Mbed OS, please refer to the [Bluetooth overview](../apis/ble.html).
 
-## 6LoWPAN Mesh 
+### 6LoWPAN Mesh
 
 Mesh networks are designed to form IPv6 networks automatically for a larger area than is possible with single radio link. TDifferent protocols form flexible network topology using different design principles. As a technology designed for large-scale deployment, 6LoWPAN-based mesh is optimized for long battery life and low cost.
 
@@ -80,25 +80,25 @@ Additionally, Mbed OS Thread stack is certified using predefined test sets for s
 
 For descriptions of different 6LoWPAN mesh networks, please see the introduction of the [Thread](../reference/thread-tech.html), [Wi-SUN](../reference/wisun-tech.html) and [6LoWPAN-ND](../reference/6LoWPAN-ND-tech.html) mesh networks.
 
-# Non-IP networking
+## Non-IP networking
 
-## LoRaWAN
+### LoRaWAN
 
 LoRaWAN, a technology not based on IP, is optimized for low power consumption and a low memory footprint (allowing low-cost devices). The downside is a low throughput of no more than 50 kbps, as well as delays.
 
 Because of its long range (up to 20 km) and low power, it is suitable for outdoor solutions with low data rates.
 
 The [LoRa](lora-tech.html) section and [LoRa tutorial](../tutorials/LoRa-tutorial.html) describe LoRA networking in detail.
 
-## NFC
+### NFC
 
 <span class="images">![](../../images/n_mark.png)<span>NFC</span></span>
 
 Near-field communication (NFC) is a short range (few centimeters) wireless technology standard for personal area networks. Typical uses of NFC are commissioning, sharing of small content and Bluetooth connection initiation and out-of-band pairing.
 
 To learn how to use NFC with Mbed OS, please refer to the [Mbed OS NFC overview](../apis/nfc.html).
 
-## NB-IoT cellular
+### NB-IoT cellular
 
 Non-IP Data Delivery (NIDD) is a new feature for communication over NB-IoT. Control Plane cellular IoT EPS optimization enables NIDD, which is meant to provide improved support of small data transfer. It does this by transporting user data over the control channel, thus reducing the total number of control plane messages when handling a short data transaction.
 

docs/api/connectivity-config.md

@@ -143,7 +143,7 @@ Name: lwip.use-mbed-trace
     No value set
 ```
 
-# Selecting the default network interface
+## Selecting the default network interface
 
 Applications can use the default network interface without directly specifying its type. This requires settings from `mbed_app.json` to work.
 

docs/api/io/alarm-tutorial.md

@@ -13,7 +13,7 @@ mbed import mbed-os-example-alarm
 cd mbed-os-example-alarm
 ```
 
-If using the Mbed Online Compiler, use the **Import into Mbed IDE" button below:
+If using the Mbed Online Compiler, use the **Import into Mbed IDE** button below:
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Tutorials_UsingAPIs/Alarm)](https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Tutorials_UsingAPIs/Alarm/main.cpp)
 

docs/api/io/flow_control.md

@@ -2,15 +2,15 @@
 
 We can use Blinky to explore flow control and task management in Arm Mbed OS applications. We'll look at automated actions first, then move on to handling user actions.
 
-# Flow control for automated actions
+## Flow control for automated actions
 
 If we want to automatically blink an LED, we have three main techniques:
 
 1. [Busy wait](#busy-wait)
 1. [Ticker](#ticker)
 1. [Thread](#thread)
 
-## Busy wait
+### Busy wait
 
 Busy wait is a method that blocks the processor for a period of time. This is an effective way to create time delays, but it’s inefficient because it wastes processor time and keeps the processor running at full power for the duration of the wait:
 
@@ -20,25 +20,25 @@ Notice `printf()`; you can enable this by uncommenting the line (remove the `//`
 
 <span class="tips">**Tip:** We recommend using [CoolTerm](http://freeware.the-meiers.org/), as it works the same on Windows, Linux and OS X. [Here is a handy video on how to use CoolTerm](https://www.youtube.com/watch?v=jAMTXK9HjfU) to connect to your board and view the `printf()` statements. For more information, see our [serial communication tutorials](../tutorials/serial-communication.html).</span>
 
-## Ticker
+### Ticker
 
 Tickers and timers are another way of creating a time interval. These methods are somewhat better than busy wait because they allow other code to run while you are waiting. It is even possible, though nontrivial, to sleep during the wait period.
 
 Here is an example that doesn't include sleeping:
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Tutorials_UsingAPIs/Flow-Control-Ticker)](https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Tutorials_UsingAPIs/Flow-Control-Ticker/main.cpp)
 
-## Thread
+### Thread
 
 Threads are the most efficient way to blink an LED. During the waiting period, it is possible to take advantage of Mbed OS optimizations to automatically conserve power and deal with other tasks. While this is not the most visually appealing method, nor the simplest, it is the preferred way for large scale deployments:
 
 [![View code](https://www.mbed.com/embed/?url=https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Tutorials_UsingAPIs/Flow-Control-Thread)](https://github.com/ARMmbed/mbed-os-examples-docs_only/blob/master/Tutorials_UsingAPIs/Flow-Control-Thread/main.cpp)
 
-# Flow control for manual actions
+## Flow control for manual actions
 
 Let’s try using a DigitalIn pin from the button to control the application. There are two ways to read input data: we can either constantly poll the button in a busy wait, or set an interrupt to trigger when pressed. We’ll explore these methods below.
 
-## Busy wait button
+### Busy wait button
 
 We can wait for digital input the same way we waited for time to pass - using a `while()` loop. In the example below the digital input is a button press, which causes the application to flash the LED and then wait for 1 second.
 
@@ -50,7 +50,7 @@ We constantly poll the button to see whether it has a value that matches `button
 
 `button_press` is used to denote what value the switch uses to represent the state *pushed*. Most switches are by default open (unpressed), so they will read as 0 while pressed. If you see your LED blinking without the button being pressed - try changing `button_press` to `1`.
 
-## Interrupt button
+### Interrupt button
 
 An alternative way to poll the button is to use an interrupt. Interrupts let you say `when that pin changes value, call this function`. In other words, we can tell the MCU to call a function when the button is pressed. In our case, that function toggles the LED: