add wakeup from touch sensor, and deep sleep example
- add new deep sleep wakeup mode
- change documentation to explain incompatibilities between different wakeup mode, add error checks
- add new ULP instructions necessary for ULP wakeup scenario
- fix issues with I_WR_REG, I_SLEEP, I_END instructions
- add deep sleep example, illustrating the use of timer, gpio, touch, and ULP wakeup triggers
See merge request !461
component/bt: optimize stack size of Bluetooth Tasks and make them be configurab…
Bluetooth tasks' stack size are optimized and can be configured by the CONFIG_NEWLIB_NANO_FORMAT option.
See merge request !559
Allow separate ethernet & wifi configuration
If only 1/2 of ethernet & WiFi are enabled in config, the other interface is no longer linked into the firmware.
* Fixes bug where enabling Ethernet but not WiFi would fail to compile.
* Also means that enabling WiFi but not Ethernet no longer links some unused ethernet interface functions.
See merge request !525
Feature/add user set mac
1. Add menuconfig for user to set mac address of wifi, bt and ethernet.
2. Add the number of MAC address generated from efuse for user to choose.
3. Add MAC address derive method.
See merge request !542
1. RTC V214: modify APLL function for the chip of ECO version.
2. Add API phy_close_rf() and use it in esp_phy_deinit() instead of pm_close_rf().
3. RTC V213: fix BT will not work when BT-init is called more than once.
Optimize or release memory in bluetooth
1. add option to release about 30K from BT if BLE only
2. later BT/BLE will be separated by BT/BLE macro, but this option should use when user make sure that in BLE only mode.
See merge request !520
This change adds esp_deep_sleep_get_wakeup_cause, which returns the
source which has caused wakeup from deep sleep.
Similar to esp_deep_sleep_get_ext1_wakeup_status, a function is added
to check touch pad wakeup status: esp_deep_sleep_get_touchpad_wakeup_status.
This function returns the touch pad which has caused wakeup.
ULP and touch FSMs in ESP32 revisions 0 and 1 do not operate correctly
if RTC_PERIPH power domain is force powered on (ESP_PD_OPTION_ON).
Both ULP and touch still work, but clock frequency of the ULP may be
incorrect and touch values may be off by considerable amount. As such,
when these wakeup modes are used, RTC_PERIPH power domain has to be set
to ESP_PD_OPTION_AUTO (or, in the current implementation,
ESP_PD_OPTION_OFF — though this will change in the future when _OFF will
actually *force* the power domain to be powered off).
Because EXT0 wakeup source requires RTC_PERIPH to be powered ON, mark
ULP and touch wakeup sources as incompatible with EXT0. Workaround for
this is to use EXT1 wakeup source instead, which offers similar or
better functions without having to keep RTC_PERIPH powered on.
In case WiFi/BT stack has been enabled but wasn’t disabled, some RTC
bits may be left enabled, causing increased current consumption.
This change returns some of the bits back to their default values.
1. add new APIs bt controller enable/disab/deinit
2. make bt controller work need to call two APIs of esp_bt_controller_init and enable
3. modify phy init to make mac reset once
1. add a macro in menuconfig for users to choose whether store phy calibration data into NVS or not.
2. rename some disable phy and rf APIs so that existing code which calls old APIS will fail to compile.
1. Add disable PHY and RF when WiFi and BT are both disabled(including call sniffer disable API).
2. Do not init PHY and RF when cpu start. Init PHY and RF when call Wifi or BT start APIs(including sniffer enable API).
3. Add a temporary lib: librtc_clk.a and will delete it when CPU frequency switching function is done.
4. Add an function to get OS tick rate.
5. Do not put the whole pp.a in iram0, only put lmac.o, ieee80211_misc.o, ets_time.o and wdev.o in iram0.
phy_init: don’t rewrite valid calibration data
In the default PHY init routine, calibration data is loaded from NVS.
Most of the time the incremental changes to calibration will be fairly
small, so we don’t need to rewrite the existing calibration data stored
in the NVS.
Possible enhancement to be done in the future: expose a function in PHY
library to tell how big was the change in calibration data. If the
change was significant, then calibration data stored in NVS should be
updated.
See merge request !487
