The default macros GPIO_PIN and GPIO_UNDEF do not have to be overridden. The GPIO_PIN macro definition was even wrong for 40 GPIOs without splitting into ports, even if that did not lead to erroneous behavior.
Add support for specifying data bits, stop bits and parity at
runtime.
Introduce feature periph_uart_modecfg for uart_mode() till all
other CPUs implement it.
STM32 L1, F1, F2, F4 supports following modes:
* 7E1, 7E2
* 7O1, 7O2
* 8N1, 8N2
* 8E1, 8E2
* 8O1, 8O2
STM32 L0, L4, F0, F3, F7 supports following modes:
* 6E1, 6E2
* 6O1, 6O2
* 7E1, 7E2
* 7O1, 7O2
* 7N1, 7N2
* 8N1, 8N2
* 8E1, 8E2
* 8O1, 8O2
Use USART_CR1_M1 macro to detect 7-bit support because
even inside one family there could be devices that don't
support 7-bit mode. So just using a family macro is not
enough.
As stated in the datasheets for L0, L4, F0, F3, F7 devices,
data bits can only be changed when UART is disabled (UE=0).
Introduce uart_stop() routine to satisfy this requirement.
STM32 UART adds parity to the MSB of a byte to send. The same
also applies to the received bytes. As a result this bit must
be masked in order to get the pure data.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Checking by the send function that at least two maximum size Ethernet frames fit in the remaining heap before the LwIP packet buffer is allocated seems to increase stability. This can be caused by the fact that WLAN hardware interrupts allocate additional memory when receiving a frame during the send attempt.
Error case:
1. thread_yield_higher() stores the thread's ucontext
2. creates an "isr ucontext" for isr_thread_yield, switches to it
Case 1: no signals are pending, continues in isr_thread_yield()
3a. sched_run is called
4a. return to sched_active_thread ucontext
Case 2: signals pending (the crashing scenario), continues in native_irq_handler()
3b. handles signals
4b. if sched_context_switch_request is set, call sched_run
5b. return to sched_active_thread ucontext
4b misses the call to sched_run(), leading to a possible return into a
non-ready thread.
The situation where the firmware `lwIP` packet buffer is exhausted is an important indication that the traffic sent to and sent from the esp8266 is more than the esp8266 is able to handle. Therefore, it should be an error message.
It is not necessary to realize timeout handling in send function or to disconnect from AP if lwIP packet buffer is exhausted. Waiting that the frame allocated in lwIP packet buffer is freed by MAC layer led to the complete blockage of send function on heavy network load. Disconnecting from AP is counterproductive since reconnecting usually fails on heavy network load.
Disconnecting from the AP in the send function if the lwIP packet buffer is exhausted is counterproductive since reconnecting usually fails on heavy network load. A better strategy is to slow down the sending of MAC frames from netif a bit to wait for flushing the buffer in the MAC layer.
Defines a number of lwIP functions that are required as symbols by Espressif's SDK libraries. These functions are only dummies without real functionality. Using these functions instead of real lwIP functions provided with the SDK saves arround 4 kBytes of RAM.
Since _esp_wifi_recv_cb is not executed in interrupt context but in the context of the `ets` thread, it is not necessary to pass the`NETDEV_EVENT_ISR` event first. Instead, the receive function can be called directly which result in much faster handling, a less frame lost rate and more robustness.
Since _esp_wifi_recv_cb is not executed in interrupt context but in the context of the `ets` thread, the receive function can be called directly. There is no need for a mutex anymore to synchronize the access to the receive buffer between _esp_wifi_recv_cb and _recv function.
When the size of a received frame is checked, always the total length should be used instead of the length of the first lwIP pbuf in the pbuf chain. Otherwise, the check that the length does not exceed ETHERNET_MAX_LEN will always be true since the maximum size of one lwIP pbuf in a pbuf chain is 512 bytes.
Although only the station interface is needed, the WiFi interface has to be used in SoftAP + Station mode. Otherwise the send function blocks sporadically. Since the SoftAP interface is not used, it is configured with a hidden SSID and a long beacon interval. Connections from other stations are not allowed.
Some SDK interrupt service routines obviously use malloc/free in the interrupt context. Because the rmutex-based lock/unlock approach of the malloc/free function suite of the newlib does not work in the interrupt context, the SDK memory management functions MUST therefore be used. To use the same memory management functions in RIOT as in the SDK, the malloc/free function suite has to be replaced by wrapper functions.
