This change means that there is only one set of global stdin, stdout, and stderr
FILE streams shared by all the threads. This reduces memory usage and avoids
having to close these streams before threads exit. These streams still have a
lock to synchronise access.
Look-up tables were used for determining the delay loop counts before.
Based on these hand-tuned values, the loop overhead was estimated for
each option -- 80 and 160 MHz, fast and slow GPIO access. Instead of the
great number of tunable parameters one now only has to tune the overhead
values if the code is changed.
Functions were added to the API which allow setting an arbitrary
frequency. API backward compatibility is retained.
i2c: fix potential overflow situation
* 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.
It seems most common for the connection to the wider internet to be
via the station netif even if there is also an AP netif, so set the
default to the station netif. The lwip ipv4 route logic will still use
the AP netif if the destination is to that subnet.
The locks are using a bit of the limited ram. It's probably fine to combine some
of these to use the same mutex, and this patch does so for the set initialized
early. The file locks will still be separate, and dynamically created, so a
thread blocking on them will not deadlock all uses of newlib that need a lock.
