diff --git a/README.md b/README.md
index 406d2cc..bfd33a3 100644
--- a/README.md
+++ b/README.md
@@ -2,35 +2,18 @@
Open-source firmware for USB Power Delivery trigger board based on an FUSB302B power delivery controller and a STM32F030F4 MCU.
-
+
-## Building
+## Building and Uploading
-- Clone the project from GitHub
-- Open it with Visual Studio Code
-- Install the PlatformIO extension
-- Click the build icon in the status bar
+The firmware is built using Visual Studio Code and the PlatformIO extension.
+To upload it, a SWD capable debug probe like ST-Link, J-Link or Black Magic Probe is connected to the four SWD pads on the back side of the board.
-## Upload
+See [Build and upload](https://github.com/manuelbl/zy12pdn-oss/wiki/Build-and-upload) in the wiki for detailed instructions.
-The ZY12PDN board has 4 pads for SWD at the bottom. Either solder wires to them, or use a 4-pin adapter with pogo pins to connect a debug adapter.
-
-
-
-Connect the SWD pads with an ST-Link, J-Link or Black Magic Probe to your computer and click the upload icon in the status bar of Visual Studio Code.
-
-As sold, the boards have flash protection enabled. It can be disabled using *openocd*. Note: This command erases the flash memory:
-
-```
-openocd -f interface/stlink.cfg -f target/stm32f0x.cfg -c "init; reset halt; stm32f0x unlock 0; stm32f0x mass_erase 0; reset halt; exit"
-```
-
-
-## Hardware
-
-See [Hardware](doc/hardware.md) for a detailed description of the board and its components (incl. schematic).
+
## Usage Instructions
@@ -65,36 +48,21 @@ The mode can be selected by pressing the button until the desired voltage or mod
*Note: Even if a fixed voltage above 5V has been selected and the selected voltage can be provided by the power supply, the supply will initially proivde 5V until the target voltage has been successfully negotiated. 5V is also provided at the output of the ZY12PDN board as it is passed through directly. There is no switch (or MOSFET) in between.*
-## Supported PD Messages
-
- - *Capabilities*: The source announces the supported voltages (called "capabilities"). The sink must immediately request one of them.
- - *Request*: The sink requests a specific voltage and maximum current.
- - *Accept*: The source confirms the requested voltage. The new voltage is not ready yet.
- - *Reject*: The source rejects the requested voltage.
- - *PS_RDY*: The source indicates that the requested voltage has been applied.
-
-
-## Notes
-
-- If the event type of the `pd_sink` callback is `callback_event::source_caps_changed`, `request_power()` must be called to request a voltage – even if it is 5V. Otherwise the source will reset.
-- The firmware is currently limited to the fixed voltages, i.e. pressing the button switches between the fixed voltages. The class `pd_sink` also support *programmable power supply* (PPS) capabilities. But a different user interfaces / modified firmware is needed to actually use them.
-- Using the build flag `-D PD_DEBUG`, debugging output can be enabled. In order to see it, you have to solder a wire to PA2 (USART2 TX pin) and connect it to a serial adapter. The baud rate is 115,200 bps (8 bits, 1 stop bit, no parity).
-- Since the USB PD protocol is timing sensitive, debug output must not delay normal operation. For that reason, the debug output is written to a circular buffer and then transmitted using non-blocking DMA. Blocking UART operation would introduce delays and violate the timing causing the power supply to reset or even to cut power.
+## Documentation
+Additional documentation can be found in the [Wiki](https://github.com/manuelbl/zy12pdn-oss/wiki/Hardware-versions):
-## Firmware Mode
+- [Hardware analysis](https://github.com/manuelbl/zy12pdn-oss/wiki/Hardware-analysis)
-The SWDIO line is shared with the interrupt line of the USB PD controller.
+- [Hardware versions](https://github.com/manuelbl/zy12pdn-oss/wiki/Hardware-versions)
-In order to enable firmware upload, the FUSB302B interrupt is not activated until USB PD activity has been detected. To implement this behavior, the code manually switches between measuring CC1 and CC2 even though the FUSB302B chip could do it automatically.
+- [USB PD introduction](https://github.com/manuelbl/zy12pdn-oss/wiki/USB-PD-introduction)
-To upload firmware, connect a debug adapter (such as ST-Link or J-Link) to the SWD pads on the bottom of the board and provide power from any source except a USB PD power supply:
+- [Software implementation notes](https://github.com/manuelbl/zy12pdn-oss/wiki/Implementation-notes)
-- Feed power to the USB connector from a non USB PD power supply
-- Feed 3.3V to the VCC pad on the bottom side of the board (e.g. through an older ST-Link adapter)
-- Feed 5V to the output terminal
+- [Build and Uplaod](https://github.com/manuelbl/zy12pdn-oss/wiki/Build-and-upload)
-SWD can be used to upload new firmware. But debugging is only possible until the interrupt pin is activated in code.
+- [Debugging hints](https://github.com/manuelbl/zy12pdn-oss/wiki/Debugging-hints)
## Acknowledgements
diff --git a/doc/board.jpg b/doc/board.jpg
deleted file mode 100644
index 9b99707..0000000
Binary files a/doc/board.jpg and /dev/null differ
diff --git a/doc/board.png b/doc/board.png
new file mode 100644
index 0000000..cc9209d
Binary files /dev/null and b/doc/board.png differ
diff --git a/doc/components.jpg b/doc/components.jpg
deleted file mode 100644
index c559f76..0000000
Binary files a/doc/components.jpg and /dev/null differ
diff --git a/doc/hardware.md b/doc/hardware.md
deleted file mode 100644
index 5d1d809..0000000
--- a/doc/hardware.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Hardware
-
-
-## Schematic
-
-
-
-The SWD programming port is available as 4 pads on the bottom side of the board.
-
-
-## Components
-
-
-
-| Label | Component | Purpose |
-| ----- | --------- | ------- |
-| U1 | FUSB302BMPX | USB PD controller |
-| U2 | STM32F030F4P6 | Microcontroller |
-| U3 | ME6203A33M3G | 3.3V voltage regular (LDO), Vin up to 40V, Iout = 100mA |
-| D1, D2 | CESD3V3D5 | ESD protection diode, reverse stand-off voltage = 3.3V |
-| D3 | RB521S-40 | Schottky diode, reverse voltage protection |
-| C1 | 1µF | Decoupling capacitor at input of LDO |
-| C2 | 470nF | Decoupling capacitor at input of LDO |
-| C3 | 4.7µF | Decoupling capacitor at output of LDO |
-| C4 | 100nF | Decoupling capacitor at VDD/VDDA of MCU |
-| C5 | 100nF | Debouncing capacitor for button |
-| C6 | 100nF | Timing capacitor for reset |
-| R1, R2 | 100Ω | Input protection for CC1/CC2 |
-| R3 | 2.2kΩ | Pull-up resistor for SDA |
-| R4 | 2.2kΩ | Current limiting resistor for blue LED |
-| R5 | 5.6kΩ | Current limiting resistor for green LED |
-| R6 | 2.2kΩ | Current limiting resistor for red LED |
-| SW1 | SKRPACE010 (or similar) | Tactile switch |
-| LED1 | TJ-S1615SW6TGLCCYRGB-A5 (or similar)| RGB LED |
-| USBC1 | 918-418K2023S40001 (or similar) | USB-C female connector, 16 pin |
-
-
-## Notes
-
-- The USB PD controller has a *VBUS* input to measure and monitor the VBUS voltage. The pin is connected to ground. Therefore, the VBUS monitoring cannot be used.
-- The I2C pins of the MCU are PA9 and PA10 for SCL and SDA, respectively. However, the SCL and SDA traces are connected to PA10 and PA9. Thus they are swapped to save board space with short traces (see image below). Therefore, the MCU's I2C peripheral cannot be used. Instead, I2C bit banging must be used.
-- The SWDIO pin is connected to both SWDIO and the USB PD controller's interrupt pin, again to achieve short traces (see below). Tricks must be used to ensure firmware can still be uploaded. See below how to revive the board if the trick fails.
-- VBUS of the USB-C connector is directly connected to the positive contacts of the output. There is no controllable switch in-between. Therefore, there will always be 5V on the output when the board is initially connected to a power supply, no matter how sophisticated the firmware is. To improve, a MOSFET would need to be connected down-stream and controlled from the MCU.
-- There are several unused MCU pins that can be used for different purposes: PA0 thru PA4 and PB1. The firmware can use PA2 for serial output (debugging).
-
-
-
-
-## Revive Board
-
-If the board can no longer be flashed with the SWD connector on the bottom side because the firmware cannot stop the PD controller from interfering with the SWDIO line, the board can be revive like so:
-
-- Solder a wire to NRST. The easiest location for soldering is capacitor C6 (on the left side of the capacitor in the above image).
-- Connect all four SWD pins plus NRST to a debug adapter.
-- Use a firmware upload/erase configuration that connects under reset.
-- Erase the flash.
-
-I've been successful with a J-Link adapter and J-Flash Lite (but not with J-Flash). An ST-Link adapter and the proper configuration might also work if you know how.
diff --git a/doc/schematic.svg b/doc/schematic.svg
deleted file mode 100644
index f0456f0..0000000
--- a/doc/schematic.svg
+++ /dev/null
@@ -1 +0,0 @@
-
\ No newline at end of file
diff --git a/doc/swd.jpg b/doc/swd.jpg
deleted file mode 100644
index 90f8015..0000000
Binary files a/doc/swd.jpg and /dev/null differ
diff --git a/doc/swd.png b/doc/swd.png
new file mode 100644
index 0000000..c155c53
Binary files /dev/null and b/doc/swd.png differ
diff --git a/doc/traces.jpg b/doc/traces.jpg
deleted file mode 100644
index 0fd067d..0000000
Binary files a/doc/traces.jpg and /dev/null differ
-## Building
+## Building and Uploading
-- Clone the project from GitHub
-- Open it with Visual Studio Code
-- Install the PlatformIO extension
-- Click the build icon in the status bar
+The firmware is built using Visual Studio Code and the PlatformIO extension.
+To upload it, a SWD capable debug probe like ST-Link, J-Link or Black Magic Probe is connected to the four SWD pads on the back side of the board.
-## Upload
+See [Build and upload](https://github.com/manuelbl/zy12pdn-oss/wiki/Build-and-upload) in the wiki for detailed instructions.
-The ZY12PDN board has 4 pads for SWD at the bottom. Either solder wires to them, or use a 4-pin adapter with pogo pins to connect a debug adapter.
-
-
-
-Connect the SWD pads with an ST-Link, J-Link or Black Magic Probe to your computer and click the upload icon in the status bar of Visual Studio Code.
-
-As sold, the boards have flash protection enabled. It can be disabled using *openocd*. Note: This command erases the flash memory:
-
-```
-openocd -f interface/stlink.cfg -f target/stm32f0x.cfg -c "init; reset halt; stm32f0x unlock 0; stm32f0x mass_erase 0; reset halt; exit"
-```
-
-
-## Hardware
-
-See [Hardware](doc/hardware.md) for a detailed description of the board and its components (incl. schematic).
+
## Usage Instructions
@@ -65,36 +48,21 @@ The mode can be selected by pressing the button until the desired voltage or mod
*Note: Even if a fixed voltage above 5V has been selected and the selected voltage can be provided by the power supply, the supply will initially proivde 5V until the target voltage has been successfully negotiated. 5V is also provided at the output of the ZY12PDN board as it is passed through directly. There is no switch (or MOSFET) in between.*
-## Supported PD Messages
-
- - *Capabilities*: The source announces the supported voltages (called "capabilities"). The sink must immediately request one of them.
- - *Request*: The sink requests a specific voltage and maximum current.
- - *Accept*: The source confirms the requested voltage. The new voltage is not ready yet.
- - *Reject*: The source rejects the requested voltage.
- - *PS_RDY*: The source indicates that the requested voltage has been applied.
-
-
-## Notes
-
-- If the event type of the `pd_sink` callback is `callback_event::source_caps_changed`, `request_power()` must be called to request a voltage – even if it is 5V. Otherwise the source will reset.
-- The firmware is currently limited to the fixed voltages, i.e. pressing the button switches between the fixed voltages. The class `pd_sink` also support *programmable power supply* (PPS) capabilities. But a different user interfaces / modified firmware is needed to actually use them.
-- Using the build flag `-D PD_DEBUG`, debugging output can be enabled. In order to see it, you have to solder a wire to PA2 (USART2 TX pin) and connect it to a serial adapter. The baud rate is 115,200 bps (8 bits, 1 stop bit, no parity).
-- Since the USB PD protocol is timing sensitive, debug output must not delay normal operation. For that reason, the debug output is written to a circular buffer and then transmitted using non-blocking DMA. Blocking UART operation would introduce delays and violate the timing causing the power supply to reset or even to cut power.
+## Documentation
+Additional documentation can be found in the [Wiki](https://github.com/manuelbl/zy12pdn-oss/wiki/Hardware-versions):
-## Firmware Mode
+- [Hardware analysis](https://github.com/manuelbl/zy12pdn-oss/wiki/Hardware-analysis)
-The SWDIO line is shared with the interrupt line of the USB PD controller.
+- [Hardware versions](https://github.com/manuelbl/zy12pdn-oss/wiki/Hardware-versions)
-In order to enable firmware upload, the FUSB302B interrupt is not activated until USB PD activity has been detected. To implement this behavior, the code manually switches between measuring CC1 and CC2 even though the FUSB302B chip could do it automatically.
+- [USB PD introduction](https://github.com/manuelbl/zy12pdn-oss/wiki/USB-PD-introduction)
-To upload firmware, connect a debug adapter (such as ST-Link or J-Link) to the SWD pads on the bottom of the board and provide power from any source except a USB PD power supply:
+- [Software implementation notes](https://github.com/manuelbl/zy12pdn-oss/wiki/Implementation-notes)
-- Feed power to the USB connector from a non USB PD power supply
-- Feed 3.3V to the VCC pad on the bottom side of the board (e.g. through an older ST-Link adapter)
-- Feed 5V to the output terminal
+- [Build and Uplaod](https://github.com/manuelbl/zy12pdn-oss/wiki/Build-and-upload)
-SWD can be used to upload new firmware. But debugging is only possible until the interrupt pin is activated in code.
+- [Debugging hints](https://github.com/manuelbl/zy12pdn-oss/wiki/Debugging-hints)
## Acknowledgements
diff --git a/doc/board.jpg b/doc/board.jpg
deleted file mode 100644
index 9b99707..0000000
Binary files a/doc/board.jpg and /dev/null differ
diff --git a/doc/board.png b/doc/board.png
new file mode 100644
index 0000000..cc9209d
Binary files /dev/null and b/doc/board.png differ
diff --git a/doc/components.jpg b/doc/components.jpg
deleted file mode 100644
index c559f76..0000000
Binary files a/doc/components.jpg and /dev/null differ
diff --git a/doc/hardware.md b/doc/hardware.md
deleted file mode 100644
index 5d1d809..0000000
--- a/doc/hardware.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Hardware
-
-
-## Schematic
-
-
-
-The SWD programming port is available as 4 pads on the bottom side of the board.
-
-
-## Components
-
-
-
-| Label | Component | Purpose |
-| ----- | --------- | ------- |
-| U1 | FUSB302BMPX | USB PD controller |
-| U2 | STM32F030F4P6 | Microcontroller |
-| U3 | ME6203A33M3G | 3.3V voltage regular (LDO), Vin up to 40V, Iout = 100mA |
-| D1, D2 | CESD3V3D5 | ESD protection diode, reverse stand-off voltage = 3.3V |
-| D3 | RB521S-40 | Schottky diode, reverse voltage protection |
-| C1 | 1µF | Decoupling capacitor at input of LDO |
-| C2 | 470nF | Decoupling capacitor at input of LDO |
-| C3 | 4.7µF | Decoupling capacitor at output of LDO |
-| C4 | 100nF | Decoupling capacitor at VDD/VDDA of MCU |
-| C5 | 100nF | Debouncing capacitor for button |
-| C6 | 100nF | Timing capacitor for reset |
-| R1, R2 | 100Ω | Input protection for CC1/CC2 |
-| R3 | 2.2kΩ | Pull-up resistor for SDA |
-| R4 | 2.2kΩ | Current limiting resistor for blue LED |
-| R5 | 5.6kΩ | Current limiting resistor for green LED |
-| R6 | 2.2kΩ | Current limiting resistor for red LED |
-| SW1 | SKRPACE010 (or similar) | Tactile switch |
-| LED1 | TJ-S1615SW6TGLCCYRGB-A5 (or similar)| RGB LED |
-| USBC1 | 918-418K2023S40001 (or similar) | USB-C female connector, 16 pin |
-
-
-## Notes
-
-- The USB PD controller has a *VBUS* input to measure and monitor the VBUS voltage. The pin is connected to ground. Therefore, the VBUS monitoring cannot be used.
-- The I2C pins of the MCU are PA9 and PA10 for SCL and SDA, respectively. However, the SCL and SDA traces are connected to PA10 and PA9. Thus they are swapped to save board space with short traces (see image below). Therefore, the MCU's I2C peripheral cannot be used. Instead, I2C bit banging must be used.
-- The SWDIO pin is connected to both SWDIO and the USB PD controller's interrupt pin, again to achieve short traces (see below). Tricks must be used to ensure firmware can still be uploaded. See below how to revive the board if the trick fails.
-- VBUS of the USB-C connector is directly connected to the positive contacts of the output. There is no controllable switch in-between. Therefore, there will always be 5V on the output when the board is initially connected to a power supply, no matter how sophisticated the firmware is. To improve, a MOSFET would need to be connected down-stream and controlled from the MCU.
-- There are several unused MCU pins that can be used for different purposes: PA0 thru PA4 and PB1. The firmware can use PA2 for serial output (debugging).
-
-
-
-
-## Revive Board
-
-If the board can no longer be flashed with the SWD connector on the bottom side because the firmware cannot stop the PD controller from interfering with the SWDIO line, the board can be revive like so:
-
-- Solder a wire to NRST. The easiest location for soldering is capacitor C6 (on the left side of the capacitor in the above image).
-- Connect all four SWD pins plus NRST to a debug adapter.
-- Use a firmware upload/erase configuration that connects under reset.
-- Erase the flash.
-
-I've been successful with a J-Link adapter and J-Flash Lite (but not with J-Flash). An ST-Link adapter and the proper configuration might also work if you know how.
diff --git a/doc/schematic.svg b/doc/schematic.svg
deleted file mode 100644
index f0456f0..0000000
--- a/doc/schematic.svg
+++ /dev/null
@@ -1 +0,0 @@
-
\ No newline at end of file
diff --git a/doc/swd.jpg b/doc/swd.jpg
deleted file mode 100644
index 90f8015..0000000
Binary files a/doc/swd.jpg and /dev/null differ
diff --git a/doc/swd.png b/doc/swd.png
new file mode 100644
index 0000000..c155c53
Binary files /dev/null and b/doc/swd.png differ
diff --git a/doc/traces.jpg b/doc/traces.jpg
deleted file mode 100644
index 0fd067d..0000000
Binary files a/doc/traces.jpg and /dev/null differ