It's currently possible to generate a socket event when a non-blocking socket is closed:
1. _pending is set to 0 in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/TCPSocket.cpp#L22
when the socket is created.
2. close() calls event() in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/Socket.cpp#L66
3. event() increments _pending, and since _pending is 1 it will call _callback() in https://github.com/ARMmbed/mbed-os/blob/master/features/netsocket/TCPSocket.cpp#L167
However, if send() (for example) is called, this can happen:
- send() is called and sets _pending to 0.
- when the data is sent, event() is called, which sets _pending to 1 and calls _callback().
- if close() is called at this point, there won't be an event generated for close() anymore,
since _pending will be set to 2.
Same thing for recv. Also, same thing for TCPServer and UDPSocket.
This PR changes the initial value of _pending to 1 instead of 0, so that
events are never generated for close().
Even when HSE is used, it is possible to get a 32MHz system clock
8MHz x PLLMUL=12 % PLLDIV=2 = 32MHz
And we still get 48MHz USB clock:
8MHz x PLLMUL=12 % 2 = 48MHz
This allows to take full benefit of the CPU capability.
* Change default SRC setting and add mbed_sdk_init() for DELTA_DFBM_NQ620
Change SRC setting to RC as default to match with hardware config.
mbed_sdk_init() is added for internal debug purpose (experimental)
* remove the redundant #define
Those #define never used.
So make the assert to cover all possible values
Also assert applies only for I2C_IP_VERSION_V2.
Also in case of I2C_IP_VERSION_V1, the HAL makes the proper
checks and can dynamically scale the frequency in case of
intermediate value.
Until now, when the frequency function of CAN driver was executed, signal no output, and the frequency could not be changed.
Since there was an error in the frequency changing procedure I modified it.
Since most of the code in i2c_api.c is now relying on STM32 HAL, there
is now a possibility to make a common usage of this code accross families.
The IP version definition is introduced per family, to allow a switch of
functionnalities, especially the frequency management which differs.
BTw, we fix the F0 frequency settings at the same time.
F1 is managed for now as an exception as the HAL API for sequential transmit
/receive is not yet available (coming soon)
In case of sequential transmit / receive, there is a need to:
- not use the reload option
- generate a new START on each new transaction
This applies to all HAL supporting the IP version V2.
Kevin Gillespie
Bogdan Marinescu
jeromecoutant
andreas.larsson
Mahadevan Mahesh
Anna Bridge
Martin Kojtal
Laurent MEUNIER
Jimmy Brisson
adustm
Martin Kojtal
TsungtaWu
Simon D Hughes
ccli8
Russ Butler
Sarah Marsh
sarahmarshy
tomoyuki yamanaka
Michel Jaouen
bcostm