With tickless mechanism hsem can be used for quite a long time
(time to set up PLL clock).
Also, if hsem is held to long, then this is not the current core which is faulty,
but probably the other (the one which hold the HSEM)
Add 2 targets for DISCO_H747I dualcore:
* DISCO_H747I -> for CM7 core
* DISCO_H747I_CM4 -> for CM4 core
Current restrictions:
* TICKLESS deactivated
* DeepSleep not supported (DeepSleep wrapped to sleep)
Warning: use of the same IP (example I2C1) by both core at the same time is not prevented,
but is strongly not recommended.
Some Hardware Semaphore are use for common IP, to manage concurrent access by both cores: Flash, GPIO, RCC.
Warning: Drag and drop of binary to DISCO_H747I will flash CM7.
In order to flash CM4, one can use STM32 CubeProgrammer tool.
As suggested by Russ Butler in mbed-os issue #7328, and until there is an
implementation of mbed-os issue #4408, we are implementing a workaround
at HAL level to check if there is any ongoing serial transfer (which happens
if HW FIFO is not yet empty).
In case a transfer is ongoing, we're not entering deep sleep and
return immediately.
- serial_init, serial_free and serial_baud function moved from serial_device.c (specific to each STM32 family) to serial_api.c (common STM32 file)
- default baudrate value was hardcoded to 9600
- Value is set now to MBED_CONF_PLATFORM_STDIO_BAUD_RATE for STDIO
- Value is set now to MBED_CONF_PLATFORM_DEFAULT_SERIAL_BAUD_RATE for other use
- UART init will not be stopped before calling serial_baud function
Reworked the serial_format() function for STM32F0x
devices to take the format in the form:
data_bits - parity - stop_bits
E.g. 8 - N - 1
where data_bits exclude the parity bit.
Added a case for 7 bits data as at least the chips
STM32F0x1/STM32F0x2/STM32F0x8 support 7 bits data.
Consolidated serial_format() and uart_init()
functions into a general TARGET_STM serial_api.c
file since the functions are common to all STM targets.
Fixes#4189