This allows the processes launched from idf_tools.py to use the value
of IDF_PATH. One such example is the installation of Python packages,
when requirements.txt uses IDF_PATH to refer to the esp-windows-curses
package.
Closes https://github.com/espressif/esp-idf/issues/4341
implemented workaround in idf_monitor for known usbser.sys bug which
causes changes in RTS signal to only be sent if DTR signal also changes.
Works by forcing a dummy change in DTR signal (re-assigning its current
value, as it has previously been done in the flashing tool)
Closes https://github.com/espressif/esp-idf/pull/4676
Previous version used exception handling for program control flow,
which makes for long and confusing backtrace messages if an error
occurs while parsing the CSV (as it also prints the phony error that
occurred while trying to parse as a binary, then prints
"During handling of the above exception, another exception occurred:",
then prints the real error).
Use the same heuristic that is applied in gen_esp32_part, instead.
Also, avoid printing the entire backtrace if the error is a gen_esp32_part
InputError, same as gen_esp32part does.
Found while looking into https://github.com/espressif/esp-idf/issues/4474
The upper transport layer is using big endian ordering. The
PreviousAddress field of a Friend Request message should therefore
be converted to native endianess using sys_cpu_to_be16().
If the duration to publish is roughly the same as the period, we might
end up with elapsed == period, which returns 0 and cancel the periodic
publication. Instead 1 should be returned, just like when the elapsed
time is greater than the period.
Previously the FastPeriodDivisor value was introduced to the model
publication struct. Based on the way it was grouped it seems the
intention was to fit it within the same octet as other bit fields,
but it actually makes the octet overflow by one bit. This ends up
creating another u8_t variable which in turn adds 24 bits of padding
after it.
To keep the size of the struct as compact as possible, group the flag
together with the key index, since that only requires 12 bits. Some
care is needed here, since the mesh stack does have special internal
key index values that require more than 12 bits such as
BLE_MESH_KEY_UNUSED and BLE_MESH_KEY_DEV. In this case restricting
ourselves to 12 bits is fine since the value in the model publication
struct follows 1:1 the value received in the Config Model Publication
Set message, and there the parameter is defined to be exactly 12 bits.
For Low Power node and Proxy Server, the two features
depend on BLE_MESH_NODE in Kconfig.in, here in the
stack there is no need to judge if CONFIG_BLE_MESH_NODE
is enabled.
According to Mesh Spec 3.4.5.3, a node shall implement a local
network interface. And here we limit the situation just based
on the spec, and Provisioner directly sending the msg without
passing through the local network interface.
