Update README.md (#425)8758187580875798757887577875768757587574875738757287571875708756987568875678756687565875648756387562

1 files changed, 15 insertions, 10 deletions

diff --git a/spb/SkeletonI2C/README.md b/spb/SkeletonI2C/README.md
index 1e1efa4d..1affed0d 100644
--- a/spb/SkeletonI2C/README.md
+++ b/spb/SkeletonI2C/README.md
@@ -10,9 +10,9 @@ products:
 
 # Skeleton I2C Sample Driver
 
-The SkeletonI2C sample demonstrates how to design a KMDF controller driver for Windows that conforms to the [simple peripheral bus](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450903) (SPB) device driver interface (DDI). SPB is an abstraction for low-speed serial buses (for example, I<sup>2</sup>C and SPI) that allows peripheral drivers to be developed for cross-platform use without any knowledge of the underlying bus hardware or device connections. While this sample implements an empty I<sup>2</sup>C driver, it could just as easily be the starting point for an SPI driver with only minor modifications.
+The SkeletonI2C sample demonstrates how to design a KMDF controller driver for Windows that conforms to the [simple peripheral bus](https://docs.microsoft.com/windows-hardware/design/component-guidelines/simple-peripheral-bus--spb-) (SPB) device driver interface (DDI). SPB is an abstraction for low-speed serial buses (for example, I<sup>2</sup>C and SPI) that allows peripheral drivers to be developed for cross-platform use without any knowledge of the underlying bus hardware or device connections. While this sample implements an empty I<sup>2</sup>C driver, it could just as easily be the starting point for an SPI driver with only minor modifications.
 
-Note that the SkeletonI2C sample is simplified to show the overall structure of an SPB controller, but contains only the code that the driver requires to communicate with the [SPB framework extension (SpbCx)](http://msdn.microsoft.com/en-us/library/windows/hardware/hh406203) and KMDF. The SkeletonI2C sample driver omits all hardware-specific code. It does not simulate data transfers or implement request completion asynchronously. Pay close attention to code comments marked with "TODO" that refer to blocks of code that must be removed or updated.
+Note that the SkeletonI2C sample is simplified to show the overall structure of an SPB controller, but contains only the code that the driver requires to communicate with the [SPB framework extension (SpbCx)](https://docs.microsoft.com/windows-hardware/drivers/spb/spb-framework-extension) and KMDF. The SkeletonI2C sample driver omits all hardware-specific code. It does not simulate data transfers or implement request completion asynchronously. Pay close attention to code comments marked with "TODO" that refer to blocks of code that must be removed or updated.
 
 The simplified structure of the SkeletonI2C sample driver makes it a convenient starting point for development of a real SPB controller driver that manages the hardware functions in an SPB controller.
 
@@ -21,10 +21,15 @@ The simplified structure of the SkeletonI2C sample driver makes it a convenient
 Here are some high-level points to consider when modifying the SkeletonI2C sample for use on real hardware:
 
 - Edit (and likely rename) Skeletoni2c.h to describe your hardware's register set.
+
 - Modify Controller.cpp and Device.cpp to translate the SPB DDI and primitives into I<sup>2</sup>C or SPI protocol for your hardware. This includes initialization, I/O configuration, and interrupt processing.
+
 - Address any comments marked with "TODO" in the sample, especially those that short circuit the I/O path to complete requests synchronously.
+
 - Modify the HWID (`ACPI\skeletoni2c`) in Skeletoni2c.inf to match the device node in your firmware.
+
 - Generate and specify a unique trace GUID in I2ctrace.h.
+
 - Refactor the driver name, functions, comments, etc., to better describe your implementation.
 
 ## Code tour
@@ -33,25 +38,25 @@ Here are some high-level points to consider when modifying the SkeletonI2C sampl
 
 The following are relevant functions in the SkeletonI2C driver for implementing the SPB DDI.
 
-INITIALIZATION
+#### INITIALIZATION
 
 `OnDeviceAdd`
 
 Within `OnDeviceAdd`, the driver makes several configuration calls for SPB.
 
-[**SpbDeviceInitConfig**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450918) must be called before creating the WDFDEVICE. Note that SpbCx sets a default security descriptor on the device object, but the controller driver can override it by calling [**WdfDeviceInitAssignSDDLString**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff546035) after **SpbDeviceInitConfig**.
+[**SpbDeviceInitConfig**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/spbcx/nf-spbcx-spbdeviceinitconfig) must be called before creating the WDFDEVICE. Note that SpbCx sets a default security descriptor on the device object, but the controller driver can override it by calling [**WdfDeviceInitAssignSDDLString**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdfdevice/nf-wdfdevice-wdfdeviceinitassignsddlstring) after **SpbDeviceInitConfig**.
 
-After creating the WDFDEVICE, the driver configures it appropriately for SPB by calling [**SpbDeviceInitialize**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450919). Here the driver also sets the target and request attributes.
+After creating the WDFDEVICE, the driver configures it appropriately for SPB by calling [**SpbDeviceInitialize**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/spbcx/nf-spbcx-spbdeviceinitialize). Here the driver also sets the target and request attributes.
 
 Finally the driver configures a WDF system-managed idle time-out.
 
-TARGET CONNECTION
+#### TARGET CONNECTION
 
 `OnTargetConnect`
 
 Invoked when a client opens a handle to the specified SPB target. Queries the I<sup>2</sup>C connection parameters from the resource hub (via SPB) and initializes the target context.
 
-SPB I/O CALLBACKS
+#### SPB I/O CALLBACKS
 
 `OnRead`
 
@@ -81,7 +86,7 @@ Configures the request context for the specified transfer index. This could be a
 
 `PbcRequestComplete`
 
-Sets the number of bytes completed for a request and invokes the [**SpbRequestComplete**](http://msdn.microsoft.com/en-us/library/windows/hardware/hh450920) method.
+Sets the number of bytes completed for a request and invokes the [**SpbRequestComplete**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/spbcx/nf-spbcx-spbrequestcomplete) method.
 
 \*An atomic transfer in SPB is implemented using Sequence or a Lock/Unlock pair. For I<sup>2</sup>C, this means a set of reads and writes with restarts in between. For SPI, this means a set of reads and writes with the chip select-line asserted throughout.
 
@@ -89,7 +94,7 @@ Sets the number of bytes completed for a request and invokes the [**SpbRequestCo
 
 The following are relevant functions in the SkeletonI2C driver for implementing controller-specific I2C protocol. For the most part, these are placeholders and must be filled in appropriately.
 
-INITIALIZATION
+#### INITIALIZATION (controller-specific)
 
 `ControllerInitialize`
 
@@ -101,7 +106,7 @@ Per-I/O controller configuration. Depending on the type of I/O (and whether its
 
 Additionally, for I<sup>2</sup>C, the driver may need to insert a start, restart, or stop bit as necessary, and for SPI the driver may need to assert or de-assert the chip select line.
 
-I/O PROCESSING
+#### I/O PROCESSING
 
 `OnInterruptIsr`