1. BLE Mesh Core
* Provisioning: Node Role
* PB-ADV and PB-GATT
* Authentication OOB
* Provisioning: Provisioner Role
* PB-ADV and PB-GATT
* Authentication OOB
* Networking
* Relay
* Segmentation and Reassembly
* Key Refresh
* IV Update
* Proxy Support
* Multiple Client Models Run Simultaneously
* Support multiple client models send packets to different nodes simultaneously
* No blocking between client model and server
* NVS Storage
* Store BLE Mesh node related information in flash
* Store BLE Mesh Provisioner related information in flash
2. BLE Mesh Models
* Foundation Models
* Configuration Server Model
* Configuration Client Model
* Health Server Model
* Health Client Model
* Generic
* Generic OnOff Server
* Generic OnOff Client
* Generic Level Server
* Generic Level Client
* Generic Default Transition Time Server
* Generic Default Transition Time Client
* Generic Power OnOff Server
* Generic Power OnOff Setup Server
* Generic Power OnOff Client
* Generic Power Level Server
* Generic Power Level Setup Server
* Generic Power Level Client
* Generic Battery Server
* Generic Battery Client
* Generic Location Server
* Generic Location Setup Server
* Generic Location Client
* Generic Admin Property Server
* Generic Manufacturer Property Server
* Generic User Property Server
* Generic Client Property Server
* Generic Property Client
* Sensor Server Model
* Sensor Server
* Sensor Setup Server
* Sensor Client
* Time and Scenes
* Time Server
* Time Setup Server
* Time Client
* Scene Server
* Scene Setup Server
* Scene Client
* Scheduler Server
* Scheduler Setup Server
* Scheduler Client
* Lighting
* Light Lightness Server
* Light Lightness Setup Server
* Light Lightness Client
* Light CTL Server
* Light CTL Setup Server
* Light CTL Client
* Light CTL Temperature Server
* Light HSL Server
* Light HSL Setup Server
* Light HSL Client
* Light HSL Hue Server
* Light HSL Saturation Server
* Light xyL Server
* Light xyL Setup Server
* Light xyL Client
* Light LC Server
* Light LC Setup Server
* Light LC Client
3. BLE Mesh Applications
* BLE Mesh Node
* OnOff Client Example
* OnOff Server Example
* BLE Mesh Provisioner
* Example
* Fast Provisioning
* Vendor Fast Prov Server Model
* Vendor Fast Prov Client Model
* Examples
* Wi-Fi & BLE Mesh Coexistence
* Example
* BLE Mesh Console Commands
* Examples
Includes all the latest NimBLE stack changes from idf-v4.0 with few idf-v3.3
specific modifications.
- Addition of nimble component as submodule (`nimble-1.1.0-idf-v3.3`), contains
IDF v3.3 specific minor changes.
- Example applications are identical to idf-v4.0
- Modification in `bt/Kconfig` to accommodate NimBLE as a BT host.
List of changes in components/wifi_provisioning:
* Manager version is now v1.1
* .proto files and protocomm handler added for sending Wi-Fi scan command and receiving scan results
* Implemented handlers for wifi_scan protocomm endpoint
* Update manager context data structure to hold scan state and results
* scheme_softap now runs Wi-Fi in APSTA mode
* Wi-Fi is started in AP mode when provisioning is started. This is necessary for scan list to work
* Docs updates with information about new wifi_scan endpoint
List of changes in tools/esp_prov:
* Added functions for sending and receiving protobuf messages compatible with wifi_scan protocomm endpoint
* Added feature to display/refresh scan results and accept user selection at runtime
* New functions:
* get_version() : only returns the protocol version string
* has_capability() : check is a capability is present according to proto-ver response
* wifi_scan feature is provided only if the `wifi_scan` capability is present
Other changes:
* Replace recursive mutex with plain mutex
* assert on return value of mutex give / take calls
* replace all calls with macros ACQUIRE_LOCK and RELEASE_LOCK
* some checks added in scanning related private APIs
* free and nullify scanning context and state if service is stopped while ongoing scan
This example adds functionality to support basic communication in RS485 networks using Modbus protocol.
This example uses FreeModbus stack and regular UART driver API to communicate in RS485 half duplex mode.
Added initial support of modbus controller pure C api to access device parameters over Modbus transport.
Move freemodbus stack and port files into components folder
Move the modbus_controller interface into components idf folder
Source files updated after review.
Add modbus interface documentation docs/en/api-reference/protocols/modbus.rst
porttimer.c: fix bug with timer1 selected in the Kconfig
Add support of cmake system (added cmake files)
Closes https://github.com/espressif/esp-idf/issues/858
added docs and tests for mqtt library, small fixes (removed warnings, option for custom outbox, websocket bug fixed for longer transports). refactored to use common tcp_transport component, support for CMake build system.
Closes#2108
Add error handling for http client
set ssid password correct with Example_WIFI test, and clear password before free
Fixed the CI failure due to HTTP errror names
1. add the L1 include path with a prefix, such like osi/list.h, stack/a2d_api.h and etc.
2. modify component, only bluedroid/api/include/api is export to another component and application,
other include path just for bluedroid used
3. put bluedroid/include into common/include/common, so the root directory of bluedroid have no include path.
4. modify doxygen to use esp_bt.h and redirect to
component/bt/bluedroid/api/include/api/
fix compile
- Split SDMMC page into pages about SDMMC/SDSPI hosts and a page about
the protocol layer.
- Use autogenerated API reference instead of manually generated one.
- Add information about SDIO APIs.
The expected usage is:
esp_pthread_set_cfg(cfg);
pthread_create()
If the inherit flag is set, then all subsequent threads forked by this
thread will also inherit this configuration. This avoids having to
change/prefix this for each and every pthread_create() call.
- Use `code` tags instead of a mix of `<pre></pre>` and
`@verbatim .. @endverbatim`
- Remove manually added function prototypes from comment blocks
- Remove of grouping (`\defgroup`) — some extra work is needed
to make groups compatible with the way we auto-generate API
reference from Doxygen XML files. It's pretty easy to add the
grouping directives back if/when we implement support for
Doxygen groups in the later stages of documentation build
process.
- Hide private APIs under `@cond .. @endcond`
- Convert some comments into Doxygen-compatible ones
- Fix various documentation issues: missing documentation for
some parameters, mismatch between parameter names in comment
block and in function prototype.
- Add doxygen comments for functions which didn't have them
(thread local storage).
- Add [out] param tags where necessary
- Redefine `xTaskCreate` and `xTaskCreateStatic` as inline
functions instead of macros.
ESPNOW is a kind of WiFi communication bettween WiFi devices, no
matter they are connected to each other or not. Once two WiFi
devices are paired, they can send data to or receive data from
each other. The data is transmitted in action frame which can
be encrypted with CCMP method. ESPNOW also support mutilcast frame
transmitting.
