This change was spurred by a confusing error. I attempted to compile for
the RZ_A1H (a Cortex-A device), and I had the standalone ARM compiler in
my system path, which supports Cortex-A. However, the default path for
the ARM compiler in settings.py uses a Keil installation, which only
supports Cortex-M. It found my Keil installation and used that instead.
This change proposes to remove this default behavior and instead
requires the user to explicitly set the intended compiler, either by a
settings file, mbed CLI, environment variables, or by placing the
compiler in your PATH.
Previously, the RTOS threads test was conditionally change the thread
stack size for all test cases based on the target. Now, it uses the
default stack size for all targets when threads are created serially,
and uses a 512 byte stack for the threads that are created in parallel.
To allow a network stack to support both NSAPI and its own options, try to make
sure the NSAPI levels don't collide with level numbers likely to be used by
network stacks.
Distinguish between socket and stack options, and tighten up documentation. Add
IP MRU stack options as an example (implementation not immediately planned for
any stack, but could be useful).
A few new error codes are added to nsapi_error_t and
support for non-blocking socket connect is added.
Nanostack's connect call will be non-blocking.
Whereas LWIP connect call is currently blocking, and it could be changed now
to be non-blocking.
I modified the TTB setting of RO_DATA area.
The current setting of this area is "not executable".
Therefore, when trying to execute a program placed in this area, a prefetch abort will occur.
So I changed from "Sect_Normal_RO" to "Sect_Normal_Cod".
If an example's GitHub repository contains multiple child examples, the
script was incorrectly filtering out all the child examples when
compiling and exporting. This patch now handles this case correctly.
During open, the socket checked the internal stack variable,
assuming it would alway be null on a socket not connected to
the network. However, when a socket is closed, the stack variable
was not updated, causing the socket to incorrectly return a
parameter error if reopened.
The simple fix was to set the stack to null on close. A non-null
stack is a predicate for a non-null socket variable, so no additional
checks are needed in socket functions.
- GPIO: mode was not allowed by ST HAL API
- PIN map: assert has highlighted an issue for pullup/pulldown setting
- RTC: year after 2000 was not taken into account
In case the user applicaiton makes a mixed usage of unitary function
(start, stop, byte write & read) with SYNC operation (write and read of
data buffers with start and stop management), we need to reset the
STM32 HAL state as it is by-passed by a direct call to STOP