docs: fix callouts, wiki references, and improve hardware pages

.gitignore

@@ -23,5 +23,4 @@ _wasi_sdk_fetch
 *.pyc
 
 # MkDocs
-site/
-.cache/
+/site/

README.md

@@ -43,7 +43,7 @@ EdgeTX is the cutting edge of OpenTX. It is the place where innovative ideas and
 
 - Sound Packs:  [Info](https://github.com/EdgeTX/edgetx-sdcard-sounds) - [Downloads](https://github.com/EdgeTX/edgetx-sdcard-sounds/releases)
 
-- [Development Wiki](https://github.com/EdgeTX/edgetx/wiki) - [Docker Build Environment](https://github.com/EdgeTX/build-edgetx)
+- [Developer Documentation](https://edgetx.org/edgetx/latest/) - [Docker Build Environment](https://github.com/EdgeTX/build-edgetx)
 
 
 ## Acknowledgements

docs/README.md

@@ -0,0 +1,71 @@
+# EdgeTX Developer Documentation
+
+This folder contains the source for the EdgeTX developer documentation site, built with [MkDocs](https://www.mkdocs.org/) using the [Material theme](https://squidfunk.github.io/mkdocs-material/).
+
+## Prerequisites
+
+Install the required packages from the repo root. Using [`uv`](https://docs.astral.sh/uv/getting-started/installation/) is recommended:
+
+```bash
+uv pip install -r docs-requirements.txt
+```
+
+Or with plain pip:
+
+```bash
+pip install -r docs-requirements.txt
+```
+
+[`mike`](https://github.com/jimporter/mike) is included as a dependency — it manages versioned deployments of the site (e.g. publishing a new release). You won't need it for local editing or preview.
+
+## Local preview
+
+Serve the docs locally with live reload:
+
+```bash
+mkdocs serve
+```
+
+Then open [http://127.0.0.1:8000](http://127.0.0.1:8000) in your browser. The site will automatically refresh as you edit files.
+
+## Building
+
+To build a static copy of the site into the `site/` directory:
+
+```bash
+mkdocs build
+```
+
+CI runs `mkdocs build --strict` on pull requests, which treats warnings (e.g. broken internal links) as errors. It's worth running this locally before submitting a PR to catch any issues early:
+
+```bash
+mkdocs build --strict
+```
+
+## Deployment
+
+The docs are deployed automatically via GitHub Actions (`.github/workflows/docs.yml`):
+
+- Pushes to `main` are deployed as the `latest` version.
+- Release tags (e.g. `v2.11.0`) are deployed as a numbered version (e.g. `v2.11`) and aliased as `stable`.
+
+## Project structure
+
+```
+docs/
+├── assets/          # Images, stylesheets
+├── building/        # Build guides (Windows, Linux, macOS, CodeSpaces)
+├── contributing/    # Git workflow and contribution guides
+├── development/     # Developer reference (CLI, protocols, etc.)
+├── hardware/        # Radio specs and hardware reference
+├── mods/            # Hardware modification guides
+└── troubleshooting/ # Troubleshooting guides
+```
+
+Site navigation is defined in [`mkdocs.yml`](../mkdocs.yml) at the repo root.
+
+## Adding or editing pages
+
+1. Create or edit a `.md` file in the appropriate subfolder.
+2. If adding a new page, add it to the `nav:` section in `mkdocs.yml`.
+3. Preview with `mkdocs serve` and verify with `mkdocs build --strict` before submitting a PR.

docs/building/codespaces.md

@@ -43,8 +43,8 @@ Next, issue:
 cmake --build . --target arm-none-eabi-configure --parallel 2
 ```
 
-> [!NOTE]
-> The `--parallel 2` in the command above instructs the cmake build system as to how many tasks to execute in parallel. Typically, you would set this to the number of CPU cores your machine has. So if you are using a higher CPU core count GitHub machine type, you can increase this to suit, and get a faster build.
+!!! note
+    The `--parallel 2` in the command above instructs the cmake build system as to how many tasks to execute in parallel. Typically, you would set this to the number of CPU cores your machine has. So if you are using a higher CPU core count GitHub machine type, you can increase this to suit, and get a faster build.
 
 Only a few seconds later, you should be greeted with "-- Generating done" message.
 
@@ -55,8 +55,8 @@ cmake --build arm-none-eabi --target firmware
 
 This time it can take few minutes so until the firmware binary is successfully built. If you see "[100%] Built target firmware" then all went smoothly, and you have just made yourself a custom EdgeTX firmware. If you are making incremental modifications to the firmware, subsequent firmware builds will be a lot faster.
 
-> [!TIP]
-> If you want more information about the firmware binary - such as how big the firmware is in relation to the FLASH memory the target handset has, you can compile the `firmware-size` target instead of firmware, and you'll get a summary at the end of the firmware build.
+!!! tip
+    If you want more information about the firmware binary - such as how big the firmware is in relation to the FLASH memory the target handset has, you can compile the `firmware-size` target instead of firmware, and you'll get a summary at the end of the firmware build.
 
 It's a good idea to rename the binary, so that it is easier later to see the target radio and which options were baked into it. For this, issue in the terminal:
 ```
@@ -66,6 +66,6 @@ mv firmware.bin edgetx_main_tx16s_bt_release.bin
 
 In the left file browser tree open the **build** folder and then open **arm-none-eabi** folder. Right click at _edgetx_main_tx16s_bt_release.bin_ and select Download.
 
-Put the downloaded firmware binary into your radio SD card \FIRMWARE subfolder, and flash it to your radio either using EdgeTX bootloader, [EdgeTX Buddy](https://buddy.edgetx.org/), EdgeTX Companion or [STM32CubeProgrammer](../mods/unbrick.md).
+Put the downloaded firmware binary into your radio SD card \FIRMWARE subfolder, and flash it to your radio either using EdgeTX bootloader, [EdgeTX Buddy](https://buddy.edgetx.org/), EdgeTX Companion or [STM32CubeProgrammer](../troubleshooting/unbrick.md).
 
 Use [EdgeTX Buddy](https://buddy.edgetx.org/) or EdgeTX Companion to fill your SD card appropriately for your radio.