* The mdns responder has been reworked to lower stack and memory usage. This is
a variation on the upstream code, it use malloc whereas the upstream code uses
pools. The high stack usage of the mdns responder was problem for
esp-open-rtos, so we might have to maintain the differences for now.
* Improved lwip core locking, and lock checking. Upstream improvements, that
need some added support from esp-open-rtos specific code. More core lock is
performed when calling from the esp-open-rtos code now, so a little safer. The
checking is not enforced, but projects might see warning messages and might
want to look into them.
* The esp-open-rtos lwip support has been sync'ed with the new freertos port
included with lwip. There are still some minor differences.
* A few lwip timer bugs have been resolved. This might help resolve some issues.
* Plus it picks up all the other upstream fixes and improvements.
* The default lwip stack has been lowered from 768 words to 480 words,
due to the reduced stack usage by the mdns responder.
Multicast frames were being dropped by ieee80211_output_pbuf. It appears to look
up the destination address using cnx_node_search which only has an entry for the
broadcast address (all ones). This patch modifies cnx_node_search to return the
broadcast cnx_node for the multicast addresses too.
This is needed to support services such as mDNS on the softap interface.
Also adds source code for sdk_cnx_rc_search, adding a null pointer dereference
check (that is not expected to be seen), and source code for sdk_cnx_remove_rc.
Switch from FreeRTOS queue to task notification.
Removed unknown/unused code.
Rename sdk_ets_handler_isr to process_pending_timers
Add function for microseconds
Simplify time to ticks conversion
Fix sdk_system_rtc_mem_write and sdk_system_rtc_mem_read,
the functions did not use the user-provided offsets to rtc_mem.
Without using offset, rboot's rtcdata access, and its
temp_rom handling were broken.
Also code for sdk_cnx_sta_leave, although disabled due to accessing static date, but it shows a reference to the netif->flags and the NETIF_FLAG_DHCP flag removed in lwip v2.
Function sdk_eagle_auth_done accesses the netif-flags and the NETIF_FLAG_DHCP flag removed in lwip v2, and also the netif->ip_addr so is needed for lwip development.
Function sdk_wpa_config_bss accesses the netif->hwaddr.
Also code for a few other trivial functions that help debug the dhcpc paths.
The function sdk_wifi_station_start is one of two paths that allocates a lwip struct netif and also accesses the netif->hwaddr slot so this is required for lwip development.
Also code for sdk_wifi_station_stop and sdk_sta_status_set to better understand the status state.
Add source code for functions touching the struct netif to better support lwip development: sdk_wifi_get_ip_info, sdk_wifi_set_ip_info, sdk_wifi_get_macaddr, sdk_wifi_set_macaddr.
Also code for sdk_wifi_station_get_connect_status.
Also code for wifi_get_sleep_type and set_sleep_type, noting wifi_set_sleep_type returns a bool success flag, and implement wifi_get_sleep_type using sdk_pm_get_sleep_type.
Also comment the point at which the bus clock that drives the uart changes on startup and comment out the change in the uart divisor. This at least allows a consistent uart baud rate during a restart if using the rate 115200.
* wifi_set_sleep_type returns a bool success flag.
* wifi_get_sleep_type seemed useless, just returning an argument. Added an implementation using sdk_pm_get_sleep_type.
Fixes#147
* Can vary tick rate from 100Hz via configTICK_RATE_HZ. Note that the
SDK binary libraries are hard-coded to assume the tick rate is 100Hz,
so changing the tick rate may have unexpected consequences for lower
layer WiFi behaviour (such as certain kinds of timeouts happening
faster/slower.)
* Setting configCPU_CLOCK_HZ to 160MHz means ESP will set 160MHz during
initialisation. Only 80MHz and 160MHz are supported.
* Timing of tasks is no longer affected by current CPU freq (whether set
via configCPU_CLOCK_HZ or via sdk_system_update_cpu_freq().)
Previously doubling the CPU frequency would double the tick rate.
