Remove HAL_Init and related code from SystemInit and move it to
mbed_sdk_init. The function SystemInit is called early in the boot
sequence before RAM is initialized or the VTOR is setup, so it should
not be used to perform the HAL initialization.
This fixes crashes due the vector table being used before it has been
relocated.
Note that this could have side effects on the application as it would
not be aware that data has been missed. This may be later solved by
adding an error management parameter to the Serial API in mbed.
The advantage is that the serial link can work again.
As reported in issue #4214, there are seen issues seen first on
NUCLEO_F103RB in case of successive Reads of 1 byte at a time.
This issue is due to a wrong state management in the end of read sequence.
Also F1 i2c driver was not fully aligned to others, which is updated here.
For STM32 targets using a 32-bit timer for the microsecond ticker, the
driver did not properly handle timestamps that are in the past. It
would just blindly set the compare register to the requested timestamp,
resulting in the interrupt being serviced up to 4295 seconds late
(i.e. after the 32-bit timer counts all the way around to hit the
timestamp again).
This problem can easily be reproduced by creating a Timeout object
then calling the timeout's attach_us() member function to attach a
callback with a timeout of 0 us. The callback will not get called for
over 2147 seconds, and possibly up to 4295 seconds late if no other
microsecond ticker events are getting scheduled in the meantime.
Now, after the compare register has been set, the timestamp is checked
against the current time to see if the timestamp is in the past, and
if so, the compare event is manually set.
NOTE: By checking if the timestamp is in the past after configuring the
capture register, we ensure proper handling in the case where the timer
updates past the timestamp while setting the capture register.
For keep supporting external APIs with the same name (supposedly there are a larger
number of users of those APIs), BufferedSerial and ATParser are being renamed.
BufferedSerial becomes UARTSerial, will complement a future USBSerial etc.
ATParser becomes ATCmdParser.
* UARTSerial moves to /drivers
* APN_db.h is moved from platform to cellular/util/.
* Original CellularInterface is restored for backward compatability (again, supposedly there
are users of that).
* A new file, CellularBase is added which will now servce as the base class for all
upcoming drivers.
* Special restructuring for the driver has been undertaken. This makes a clear cut distinction
between an on-board or an off-board implementation.
- PPPCellularInterface is a generic network interface that works with a generic FileHandle
and PPP. A derived class is needed to pass that FileHandle.
- PPPCellularInterface provides some base functionality like network registration, AT setup,
PPP connection etc. Lower level job is delegated to the derived classes and various modem
specific APIs are provided which are supposed to be overridden.
- UARTCellularInterface is derived from PPPCellularInterface. It constructs a FileHandle and
passes it back to PPPCellularInterface as well as provides modem hangupf functionality.
In future we could proive a USBInterface that would derive from PPPCellularInterface and could
pass the FileHandle back.
- OnboardCellularInterface is derived from UARTCellularInterfae and provides hooks to
the target provided implementation of onbard_modem_api.h. An off-board modem, i.e, a modem on
a shield has to override the modem_init(), modem_power_up() etc as it cannot use
onboard_modem_api.h.
This provides a HAL layer for Modem bearing devices.
Provides a standard interface to upper layer drivers.
Platform providers will be implementing this API under their
specific targets.
As a reference, two implementations are provided under TARGET_C027 (UBLOX)
and TARGET_MTS_DRAGONFLY_F411RE (MultiTech).
targets.json now contains a tag "MODEM" which tells that this target
has a modem and the modem_api is protected by a flag DEVICE_MODEM
(following the DEVICE_SERIAL fashion ).
* Lays down ground for mbed modem_api
* Standardizes pin names relating to modem device for UBLOX C027 and MTS_DRAGONFLY_F411RE
devices
* Ublox modem api is changed to use a standard, platform independent name so that same
api could be used with multiple ubloc modems.
* DCD Polarity macro is added to assist the driver in knowing correct polarity
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
When we want to activate USE_FULL_ASSERT macro in STM32 CUBE, there is a
need to have the assert map to MBED.
The easiest way to have this definition in a single place for all STM32
HAL and LL files using it, is to add a specific header file where the
porting to MBED is done.
Martin Kojtal
Jimmy Brisson
Anna Bridge
andreas.larsson
Rob Meades
Andreas Larsson
Russ Butler
Laurent MEUNIER
Sam Grove
Bradley Scott
arostm
Hasnain Virk
Bartek Szatkowski
Francisco J. Manno
adustm