Updated SetOption36 (markdown)

SetOption36.md

@@ -1,5 +1,8 @@
 ### SetOption36 - Dynamic Sleep (CPU Main loop target / CPU Power Management)
 
+
+SetOption36 and SLEEP are mutually exclusive (ensured with 6.3.0.15 or higher).
+
 The term CPU is used loosely here for the sake of making it easier to understand - When the term CPU is used it is actually referring to the ESP8266 SoC Micro Controller.
 
 With the introduction of many new drivers, sensors and other functions as part of the Sonoff-Tasmota firmware, it has become more important to pay specific attention to the amount of microcontroller clock cycles shared with the underlying SDK/Arduino ESP8266 Core.
@@ -28,10 +31,16 @@ The time management functionality offered by SetOption36 will compute this time
 
 Sleep was previously the only option for Tasmota powered devices wishing to take advantage of power saving but it does have the disadvantage that the sleep would be a constant setting insofar that the entire firmware codebase would run at a pre-determined speed causing some drivers to run slower than expected and decreasing the speed at which services such as the WebUI is rendered (This varies between the various underlying cores depending on which version is used.)
 
-Using SetOption36 instead of sleep has the advantage that CPU time will be given to any particular driver or process (let's say the WebUI) on demand as and when needed whilst spending most of its time waiting for the next main loop iteration to occur.
+Using SetOption36 instead of Sleep has the advantage that CPU time will be given to any particular driver or process (let's say the WebUI) on demand as and when needed whilst spending most of its time waiting for the next main loop iteration to occur.
 
 During this time of waiting the ESP8266's power demand can go from 80mA all the way down to 20mA which yields great benefits for power saving vs. firmware responsiveness compared to the traditional sleep setting.
 
+Normally the target main loop setting would be 50 milliseconds. The firmware will service all the driver and sensor callbacks up to a maximum of 20 times per second. In most cases this is unnecessary as most normal sensors like temperature sensors only need polling once per second. So, whether you poll the temperature sensor 20 times per second (SetOption36 50) or 5 times per second (SetOption36 200) it has no impact on the functionality.
+ 
+Allowing the main loop to iterate 20 times per second vs. 5 times per second is obviously more time consuming and processor consuming leaving less time to idle (i.e., save power).
+ 
+For example, if you were using a MCP230xx with interrupts, and you need a high interrupt response then SetOption36 50 or lower would make sense since that specific driver can poll once per 50 milliseconds to check for interrupts. Most other sensor polling can be done in intervals longer than 50 milliseconds so you achieve more idle time, and therefore also more sleep time so it saves power.
+
 ### Monitoring Performance
 
 Given all the above it is an obvious conclusion that in order to manage something you would need to be able to measure it. For this reason two new variables have been added to the telemetry data namely **LoopSet** and **LoadAvg** and are represented in the telemetry JSON as follows: