latest updates for the docs - looking at markdown needs/uses

Author: gigapod

docs/ar_autoload.md

@@ -18,9 +18,9 @@ The key classes to support this pattern are:
 
 | | |
 |------|-------|
-**Device Driver** | The device specific driver, often implemented based on an existing Arduino Library |
-**Device Builder** | A device specific class that is automatically generated and used by the Framework to detect and instantiate a device
-**Device Factory** | An overall singleton within the system that enables device registration at startup and device discovery, instantiation and initialization at runtime
+|**Device Driver** | The device specific driver, often implemented based on an existing Arduino Library |
+|**Device Builder** | A device specific class that is automatically generated and used by the Framework to detect and instantiate a device |
+|**Device Factory** | An overall singleton within the system that enables device registration at startup and device discovery, instantiation and initialization at runtime|
 
 ### Device Class
 
@@ -36,38 +36,38 @@ The class hierarchy for the Device class is outlined in the following diagram:
 
 The following **static** methods form the device discovery interface:
 
-|||
-|----|---|
-```isConnected()``` | Called with an I2C bus object - should return true of the device is connected
-```connectedConfidence()``` | Returns a confidence level to indicate the accuracy of the ```isConnected()``` algorithm used. Helpful when resolving device address conflicts
-```getDeviceName()``` | Returns the name of the device - should be a static constant
-```getDefaultAddress()``` | Returns the default I2C address for the device. *This method is deprecated*
-```getDefaultAddresses()``` | Returns a list of I2C addresses the device can use. The first address should be the default address for the device. This array is terminated with the value ```kSparkDeviceAddressNull```
+| | |
+|----|----|
+|```isConnected()``` | Called with an I2C bus object - should return true of the device is connected|
+|```connectedConfidence()``` | Returns a confidence level to indicate the accuracy of the ```isConnected()``` algorithm used. Helpful when resolving device address conflicts|
+|```getDeviceName()``` | Returns the name of the device - should be a static constant|
+|```getDefaultAddress()``` | Returns the default I2C address for the device. *This method is deprecated*|
+|```getDefaultAddresses()``` | Returns a list of I2C addresses the device can use. The first address should be the default address for the device. This array is terminated with the value ```kSparkDeviceAddressNull```|
 
 #### Instance Methods
 
 For the startup sequence the following instance methods are important
-|||
+| | |
 |------|--------|
-```onInitialize()``` | Called during the initialization process allowing the performance of the driver specific startup sequence. The Arduino TwoWire (Wire) object is passed in for use by the driver. Note: to get the address to use for the device, the driver calls the ```address()``` method.
-```address()``` | Inherited - this method returns the address for the attached device
-```isInitialized()``` | Returns true of the method ```onInitialized()``` returned true - indicating the driver is initialized.
+|```onInitialize()``` | Called during the initialization process allowing the performance of the driver specific startup sequence. The Arduino TwoWire (Wire) object is passed in for use by the driver. Note: to get the address to use for the device, the driver calls the ```address()``` method.|
+|```address()``` | Inherited - this method returns the address for the attached device|
+|```isInitialized()``` | Returns true of the method ```onInitialized()``` returned true - indicating the driver is initialized.|
 
 ### Device Builder Class
 
 This class provides a common interface for the Factory class to use during the discovery and instantiation phase of device creation. The class is defined as a template, with the only template parameter being the class name of the Driver it represents.
 
 The template definition for the ```DeviceBuilder``` class:
 
-```c++
+```cpp
 template <class DeviceType> class DeviceBuilder : public flxDeviceBuilderI2C
 ```
 
 For the most part, all the methods in this class just wrap the *introspection* methods provided by the underlying Device class it represents. This allows allows the Factory class to work with object instances that bridge calls to the *static* methods of a Device object.
 
 Example of a wrapped method in the ```DeviceBuilder``` template:
 
-```C++
+```cpp
 bool isConnected(flxBusI2C &i2cDriver, uint8_t address)
 {
     return DeviceType::isConnected(i2cDriver, address);
@@ -82,7 +82,7 @@ In the implementation file of each device driver, a static ```global``` instance
 
 The definition of the ```DeviceBuilder``` constructor:
 
-```C++
+```cpp
 DeviceBuilder()
 {
     flxDeviceFactory::get().registerDevice(this);
@@ -95,19 +95,19 @@ The Flux Factory class ```flxDeviceFactory``` is a *singleton*, and globally acc
 
 To register a device driver, a static ```DeviceBuilder``` is added to the drivers implementation file.
 
-```C++
+```cpp
 static DeviceBuilder<kDevice> global_##kDevice##Builder;
 ```
 
 But to make this easier, the following macro is defined.
 
-```C++
+```cpp
 #define flxRegisterDevice(kDevice) static DeviceBuilder<kDevice> global_##kDevice##Builder;
 ```
 
 Using this macro, device registration looks like the following (using the BME280 driver)
 
-```C++
+```cpp
 flxRegisterDevice(flxDevBME280);
 ```
 

docs/dev_developing.md

@@ -0,0 +1,4 @@
+# Framework Development {#framework_development}
+
+* @subpage properties_overview
+* @subpage parameters_overview

docs/device_writing.md

@@ -19,11 +19,11 @@ The new device class should subclass from the frameworks ```flxDevice``` class,
 
 > Note - In some cases, because of the underlying Arduino Library design, an alternative > implementation pattern is required - such as object containment.
 
-##### Example of a class definition
+### Example of a class definition
 
 Implementing a driver for the `BME280` Device.
 
-```C++
+```cpp
 class flxDevBME280 : public flxDeviceI2CType<flxDevBME280>, public BME280
 {
 
@@ -38,12 +38,12 @@ To accomplish this task, class level (static) methods and data are implemented b
 
 |Item | Description|
 |----|--|
- ```bool isConnected(flxBusI2C, address)``` | Returns true if the device is connected |
- ```char* getDeviceName()``` | Returns the Device Name |
+| ```bool isConnected(flxBusI2C, address)``` | Returns true if the device is connected |
+| ```char* getDeviceName()``` | Returns the Device Name |
 |```uint8_t *getDefaultAddresses()``` | Return a list of addresses for the device. This list terminates with the value of ```kSparkDeviceAddressNull``` |
 |```flxDeviceConfidence_t connectedConfidence()``` | Returns the confidence level of the drivers ```isConnected()``` algorithm. Values supported range from *Exact* to *Ping* |
 
-Note
+> [!note]
 >
 >* Often the device implements the address list as a class level variable
 >* It is common to define a constant or macro for the device name and return it from ```getDeviceName()```
@@ -56,9 +56,9 @@ The first step for a given driver is the retrieval of default addresses for the
 
 The system uses the array of addresses to determine what addresses are currently available, and call the ```isConnected()``` with the possible and available addresses until a connection is found, or it hits the end of the possible addresses for the device.
 
-##### Method Signature
+##### Method Signature {#device-address-method}
 
-```C++
+```cpp
 static const uint8_t *getDefaultAddresses();
 ```
 
@@ -68,9 +68,9 @@ For each of the addresses returned, the system calls the drivers ```isConnected(
 
 How the driver determines if a device is connected is determined by the implementation
 
-##### Method Signature
+##### Method Signature {#is-connected-method}
 
-```C++
+```cpp
 static bool isConnected(flxBusI2C &i2cDriver, uint8_t address);
 ```
 
@@ -83,9 +83,9 @@ static bool isConnected(flxBusI2C &i2cDriver, uint8_t address);
 
 The static interface for the device also includes a method to return the name of the device.
 
-##### Method Signature
+##### Method Signature {#device-name-method}
 
-```C++
+```cpp
 static const char *getDeviceName()
 ```
 
@@ -97,19 +97,19 @@ This method returns the confidence level for the algorithm in the devices ```isC
 
 This confidence level is used to resolve detection conflicts between devices that support the same address on the I2C bus. Drivers that have a higher confidence level are evaluated first.
 
-#### Method Signature
+#### Method Signature {#confidence-level-method}
 
-```C++
+```cpp
 static flxDeviceConfidence_t connectedConfidence(void)
 ```
 
 The return value should be one of the following:
 
-|||
+| | |
 |---|---|
-```flxDevConfidenceExact``` | The algorithm can perform an exact match
-```flxDevConfidenceFuzzy``` | The algorithm has high-confidence in a match, but it's not exact
-```flxDevConfidencePing``` | An address "ping" is used - just detecting a device at a location, but not verifying the device type.
+|```flxDevConfidenceExact``` | The algorithm can perform an exact match|
+|```flxDevConfidenceFuzzy``` | The algorithm has high-confidence in a match, but it's not exact|
+|```flxDevConfidencePing``` | An address "ping" is used - just detecting a device at a location, but not verifying the device type.|
 
 > Note: Only one device with a PING confidence is allowed at an address.
 
@@ -119,7 +119,7 @@ This example is taken from the device driver for the BME280 device.
 
 The class definition - ```flxDevBME280.h```
 
-```C++
+```cpp
 // What is the name used to ID this device?
 #define kBME280DeviceName "bme280";
 
@@ -166,19 +166,20 @@ To complete the auto-discovery capabilities of the system, besides the implement
 
 This is call is placed before the class implementation and has the following signature:
 
-```C++
+```cpp
 flxRegisterDevice(DeviceClassName);
 ```
 
 Where `DeviceClassName` is the class name of the device being registered.
 
 Once a device is registered, it is available for auto-detection and loading by the framework during the startup process of system.
 
-> Note: The ```flxRegisterDevice()``` call is a macro that defines a global object using a c++ template. The object is instantiated on system startup (all globals are), and in the constructor of the object, it registers itself with the device discovery system.
+> ![note]
+> The ```flxRegisterDevice()``` call is a macro that defines a global object using a c++ template. The object is instantiated on system startup (all globals are), and in the constructor of the object, it registers itself with the device discovery system.
 
 Building off the above BME280 example, the implementation looks like:
 
-```C++
+```cpp
 #define kBMEAddressDefault 0x77
 #define kBMEAddressAlt1 0x76
 
@@ -204,15 +205,15 @@ flxDevBME280::flxDevBME280()
 }
 ```
 
-Notes
-
-* This example includes the implementation of ```defaultDeviceAddress[]```, the class variable holding the addresses for the device.
-* The device is registered before the class constructor
-* In the constructor, the device identity is set, which is based of runtime conditions.
+> [!note]
+>
+> * This example includes the implementation of ```defaultDeviceAddress[]```, the class variable holding the addresses for the device.
+> * The device is registered before the class constructor
+> * In the constructor, the device identity is set, which is based of runtime conditions.
 
 The isConnected() method for this example is:
 
-```C++
+```cpp
 bool flxDevBME280::isConnected(flxBusI2C &i2cDriver, uint8_t address)
 {
 
@@ -223,25 +224,25 @@ bool flxDevBME280::isConnected(flxBusI2C &i2cDriver, uint8_t address)
 }
 ```
 
-Note
-
-* This is a static (has no `this` instance) and as such uses the methods on the passed in I2C bus driver to determine in a BME280 is connected to the system
+> [!note]
+>
+> * This is a static (has no `this` instance) and as such uses the methods on the passed in I2C bus driver to determine in a BME280 is connected to the system
 
 ### Startup Sequence
 
 The last part of implementing a device descriptor/driver class is the addition of an initialization method, named ``onInitialize()``.
 
-##### Method Signature
+#### Method Signature {#on-init-method}
 
-```C++
+```cpp
  bool onInitialize(TwoWire &);
  ```
 
 The only argument to this methods is the Arduino I2C `TwoWire` class, which the class can use to initialize the device. The method returns `true` on success, `false` on failure.
 
 The BME280 example implementation:
 
-```C++
+```cpp
 bool flxDevBME280::onInitialize(TwoWire &wirePort)
 {
 
@@ -251,7 +252,8 @@ bool flxDevBME280::onInitialize(TwoWire &wirePort)
 }
 ```
 
-> Note: The ```address()``` method returns the device address for this instance of the driver.
+> [!note]
+> The ```address()``` method returns the device address for this instance of the driver.
 
 ### Determining if a Device is Initialized
 

docs/doxygen/doxygen-config

@@ -171,7 +171,7 @@ ALWAYS_DETAILED_SEC    = YES
 # operators of the base classes will not be shown.
 # The default value is: NO.
 
-INLINE_INHERITED_MEMB  = YES
+INLINE_INHERITED_MEMB  = NO
 
 # If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path
 # before files name in the file list and in the header files. If set to NO the

docs/parameters.md

@@ -1,11 +1,10 @@
-
-# Parameters
+# Parameters Overview  {#parameters_overview}
 
 Parameters represent the method to read or pass in a specific data  _value_ to an operation object  withing the SDK. Parameters can be thought of as the data values passed into or returned from a function call. Parameter objects provide a means to support dynamically discoverable input and output data for a particular operation within the framework.
 
 There are two types of Parameter objects with the framework: Input Parameters ("functions") and Output Parameters
 
-### Parameter Attributes
+## Parameter Attributes
 
 The following are key attributes of parameters within the framework
 
@@ -14,7 +13,7 @@ The following are key attributes of parameters within the framework
 * Parameter objects can act like a function
 * Parameter objects allow introspection - they can be discovered and manipulated at runtime via software
 
-#### Parameter Data Types
+### Parameter Data Types
 
 The following types are available for properties
 
@@ -126,7 +125,7 @@ Note
 
 Data limits define restrictions on the values the input parameter accepts. There are two types of data limits: range and valid value sets.
 
-*Data Range*
+_Data Range_
 This represents the minimum and maximum values a input parameter will accept. The values can be specified at parameter definition and also set at runtime.
 
 To set the range at parameter definition, just set the declared parameter to the range using a C++ initializer list ```{ min, max}```
@@ -151,7 +150,7 @@ Using the example parameter from above:
 
 This changes the data range accepted by the input parameter and deletes any existing data limit.
 
-*Data Valid Value Set*
+_Data Valid Value Set_
 This represents data limit provides a defined set of valid values for the input parameter. The limit is defined by a set of _name,value_ pairs that enable a human readable presentation for the values a input parameter will accept. The values can be specified at parameter definition and also set at runtime.
 
 To set the valid values at parameter definition, just set the declared parameter to the range using a C++ initializer list of name value pairs:  

docs/properties.md

@@ -1,7 +1,5 @@
-\addtogroup module_properties
-@{
 
-# Properties
+# Properties Overview {#properties_overview}
 
 Properties represent the "_settings_" for a particular object within the system. This property values describe their object, as well as how the object behaves/operates within the system.
 
@@ -369,5 +367,3 @@ Or for an entire parameter list:
 ```
 
 The values are added to the current valid value list. If a _ValidValue_ data limit was not in place when called, any current limit (i.e. range limit) is deleted and a valid value limit is put in place.
-
-@}