mirrors
/
Tasmota
mirror of https://github.com/arendst/Tasmota.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add debugging info

Theo Arends 2018-07-17 11:48:56 +02:00
parent bafbbc3145
commit 8da78a95d2
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Sensor-API.md

@ -1,15 +1,17 @@
This wiki page is an attempt to document the Tasmota sensor API for sensor driver development.
# Important things to consider
* There are currently no SPI drivers as examples in the development codebase, but there are several I2C sensor examples you can take from when writing your own and you are encouraged to do this as it is a quick and easy way to see how things fit together.
* There are several I2C sensor examples you can take from the development codebase when writing your own and you are encouraged to do this as it is a quick and easy way to see how things fit together.
* There are currently no SPI drivers as examples in the development codebase. To see a SPI example look in the development_display codebase.
* The Tasmota firmware is essentially intended for Sonoff devices and commits to the main development branch will be subject to review based on whether or not what you intend to develop or add to the existing code is relevant to the general Sonoff device users.
* That being said, there is a lot of development going into the firmware which extends the functionality of standard off the shelf Sonoff devices, the firmware in itself is also useful to other ESP8266 based boards such as the WeMos ESP8266 boards and more technically inclined individuals who use generic ESP8266 modules in their own circuits which provides more access to pins and the ability to add more sensors and hardware external to the Sonoff device or the generic ESP8266 module circuits.
* The resources on the ESP8266 are finite. Most of the Sonoff devices ship with 1Mbyte SPI flash chips which means for the generic Sonoff device users the code generally needs to be less than 502Kbytes to ensure that OTA (Over The Air) flash functionality (which is the main reason why people use this firmware) remains available. RAM is also limited to an absolute maximum of 80Kbytes.
* The resources on the ESP8266 are finite. Most of the Sonoff devices ship with 1Mbyte SPI flash chips which means for the generic Sonoff device users the code generally needs to be less than 502Kbytes to ensure that OTA (Over The Air) flash functionality (which is the main reason why people use this firmware) remains available. RAM is also limited to an absolute maximum of 80Kbytes. This memory is divided into heap (used by global variables and Strings) and stack (used by local variables) where stack space is just 4Kbytes.
* Given the above resource constraints its important to keep your code as small as possible, as fast running as possible, and use as little RAM as possible.
* You need to think about these resource constraints all the time whilst doing any development you wish to add to the firmware functionality - Face the fact that microcontroller development isn't as close a relative to standard computer programming as you'd expect.
* You will be adding code to an existing framework which requires you to adhere to some simple but strict rules such as not having any infinite loops like you would have in your generic Arduino code and try to avoid using the delay() functions when writing your code as this will cause the entire firmware to be subjected to these delay()'s you have added - Infinite loops will cause the firmware to lock up completely!
* If your sensor has configuration options please make these available by using the SensorXX framework which is already incorporated in the base code - This may not stop you from using a web-based configuration interface but since web-based configuration takes up a lot of code space in flash it is very important to make this optional by means of a compiler directive or a #define in the configuration file and as such something you need to keep in mind during your development and debugging - The more progressively optional additional features are in your driver the smaller the basic codebase can be for minimalist implementations.
* Whilst developing drivers for devices that use the I2C bus always consider other devices already supported in the codebase which may use the same address range. This could mean you need to find a unique way of differentiating your device detection from other devices on the same address range and/or disabling by #undef existing devices if yours is selected with a #define statement and in such cases always provide a warning to the user during compile time using the #warning pragma such as including `#warning **** Turned off conflicting drivers SHT and VEML6070 ****` in your code.
* While developing you might want to enable additional debugging provided by file ``xdrv_99_debug.ino`` using define USE_DEBUG_DRIVER which provides some commands for managing configuration settings and CPU timing. In addition you can enable define PROFILE_XSNS_SENSOR_EVERY_SECOND to profile your drivers duration.
* Do not assume others will know immediately how to use your addition and know that you will need to write a Wiki for it in the end.
# Directory/file structure