In this commit, the analogin_s structure is moved to commonn_objects.h file
to limit the duplicaion.
The ADC handle is moved from a global variable to a struct member of the
analogin object. This allows multiple ADC instances to work correctly.
Note that State needs to be explicitely set to HAL_ADC_STATE_RESET
because the object is not zero initialized.
TXE indicates that a byte can be written to UART register for sending,
while TC indicates that last byte was completely sent. So the TXE flag
can be used in case of interrupt based Serial communication, to allow
faster and efficient application buffer emptying.
Also TXE flag will be erased from the interrupt when writing to register.
In case there is nothing to write in the register, the application is
expected to disable the interrupt.
The RXNE flag is getting cleared when reading Data Register so it should
not be cleared here. Especially in case of high data rate, another byte of
data could have received during irq_handler call and clearing the flag
would read and discard this data which would be lost for application.
This commit completely rewrote flash_api.c in a few places so kicked out changes from Master and accepted the branch changes.
F429 + F439 : changes after code review
GetSector has been rewritten
- default value is the same as before patch
- system_stm32f4xx.c file is copied to family level with all other ST cube files
- specific clock configuration is now in a new file: system_clock.c
- nvic_addr.h file is now in TARGET_STM level, and can be used everywhere
Moving some code in common to be able to manage several ADC instances,
or several channels of an instance.
The change involves:
- moving dac_s structure definition to common_object.h
- create TARGET_STM/analogout_api.c and move fully common analog_out
functions in there
- rename analogout_api.c of each target family into analogout_device.c
to keep platform specific code
- update analogout_device.c to rely on obj->handle and obj->channel
- align analogout_init function as much as possible between families in
analogout_device.c files
This commit implements a SPI mode which will offer better performance
thanks to usage of Lower Layer API which use fewer registers access,
at the cost of lower robustness (no error management).
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.
According to @betzw, #3424 was put in for I2S with DMA. However, the latest I2S library now works without this patch.
The changes in DMA HAL for this potentially introduced corner case
scenarios. So it's best to revert the DMA changes.
If you are using Ethernet, and not SPI Arduino pins:
=> keep your board with the default configuration
If you are using SPI Arduino pins, and not Ethernet:
=> you should remove the JP6 bridge on the front side of the board
If you need SPI Arduino and Ethernet:
=> you have to patch the NUCLEO board on the back side: set solder bridge SB121 to off, and SB122 to on
=> D11 is no more connected to PA_7 but to PB_5
=> overwrite d11_configuration config value in json file
When attempting to perform a test build of various mbed-os targets with
GCC configured to build -std=gnu++11, all of the targets built
successfully except for this one. It gave errors like this:
../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp: In function 'emac_interface_t* wifi_emac_get_interface()':
../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp:331:38: error: use of deleted function 'emac_interface::emac_interface()'
_intf = new emac_interface_t();
^
In file included from ../mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_UBLOX_EVK_ODIN_W2/sdk/wifi_emac/wifi_emac_api.cpp:9:0:
../mbed-os/hal/emac_api.h:150:16: note: 'emac_interface::emac_interface()' is implicitly deleted because the default definition would be ill-formed:
typedef struct emac_interface {
^
../mbed-os/hal/emac_api.h:150:16: error: uninitialized const member in 'struct emac_interface'
../mbed-os/hal/emac_api.h:151:32: note: 'const emac_interface_ops_t emac_interface::ops' should be initialized
const emac_interface_ops_t ops;
This commit contains a proposed change which fixes this issue by not
using the new operator to allocate the emac_interface_t structure but
instead using the malloc() function since the construction is being
handled explicitly in the subsequent lines of the
wifi_emac_get_interface() function anyway.
I also added code which only completes the initialization of the _intf
object if its allocation succeeds and just returns NULL otherwise.
I see no deallocation of the _intf object occurring so no change from
delete to free() needed to be made.
Revert HRM1017 file source deletion
Added in small comment next to additions
Added mapping to BTN-labelled switches
Added mapping to USER_BUTTON-labelled switches
Undo incorrect mapping to SWIO pin in NORDIC target
Before this patch, many warnings like below were generated
during compilation with ArmCC
[Warning] lwip_ethernet.h@57,0: #3135-D: attribute does not apply to any entity
This happens here as ``--gnu`` option of ArmCC is being used, which
enables the GNU compiler extensions that the ARM compiler supports.
This is solve by adding a extra check on __CCARM .
Targets NUCLEO_F429ZI and UBLOX_EVK_ODIN_W2 have 192K RAM.
Heap size in PR #3871 was increased from 48K to 96K as tls-client
example failed with 48K heap. But this resulted in compilation failures
in mbed-client that requires 71K for global/static data.
Hence this PR reduces heap to 64K that minimum required by tls-client
to work. This also meets mbed-client data segment requirements.
Check in flash algos for the K64F, KL46Z, F429, F439 and Odin board
and enable these features accordingly in targets.json. This
implementation uses flash algo blob that are generated via scripts.
The K64F and KL46Z were generated directly from packs, while the
KL46Z, F429, F439 and odin were generated from code checked into
the FlashAlgo repo.
The address of the vector table is hardcoded to the start of flash in
many, if not all, ST targets. This causes a crash in applications that
are using a bootloader. This patch updates the boards STM32F429xI,
STM32F439xI and Odin so they properly handle updating the VTOR with
a bootloader.
The pwmout driver is very similar for each STM32 family.
The only family specific part is defined in pwmout_device.h file.
It mainly contains few specific information:
- The mapping of PWM/TIMERS to APB1 or APB2 so that we can get the clock
- The clock calculation uses the right APB clock, which was sometimes
not the case before and could have lead to errors in case dividers were
enabled on APB clock settings. This case is now covered.
- Inactivation of inverted support on feaw families
this first makes pinmap.c a common file
then rework it with several goals:
- avoid gpio / irq / pin management extra dependencies
- improve performances when switching between pin modes
This change is based on LL layer to access to registers level
instead of using HAL higher level API.
The family specific functions are implemented in pin_device.h
of each family. Mostly this is F1 family that is differnt
from other ones.
Add MBED_APP_START and MBED_APP_SIZE to the Odin's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
Add MBED_APP_START and MBED_APP_SIZE to the stm32f429's linker script
so the start and size of an image can be specified. This allows the
ROM to be split into a bootloader region and an application region.
With the RTOS, the STACK_SIZE specified here is unrelated to the stack
size available for the main thread (that runs pre_main). Save memory by
reducing the stack size to a more reasonable amount.
On uVisor, HEAP_SIZE is both a minimum available and maximum available
heap size. The heap can't grow beyond the end of the heap into the
neighboring stack. On all uVisor-supported platforms, guarantee at least
0x6000 bytes of heap space. This increases the portability of uVisor
applications as the memory available for legacy heap allocations is
guaranteed. This helps to avoid out of memory errors on platforms that
were previously guaranteeing less memory.
Only one point of attention:
STM_MODE_ANALOG_ADC_CONTROL is a specific mode that is only supported on L4.
So STM_MODE_ANALOG_ADC_CONTROL was moved to index 13 (last entry)
of gpio_mode table so that all the other modes are common and only the last
one is specific.
Let's make the code more common for gpios.
The only difference between STM32 families is that BRR register may
not be available. In case BRR is not available, we use the 16 left bits
of BSRR instead. We could always use BSRR, but BRR saves one left-shift
operation, so let's use it when available.
By default we will consider using BRR, except for platforms that define
GPIO_IP_WITHOUT_BRR.
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)
As reported during review, this was not understandable as it is.
the get_i2c_obj allows to get a pointer to i2c_s struct from the
handle pointer. This therefore makes a hard-coded assumption
about the struct itself
in case of 2 consecutives calls to HAL_I2C_Master_Sequential_Receive_IT
with the Xfer mode I2C_FIRST_AND_LAST_FRAME, the second trasnfer does
not start at all.
It seems this is because the previous state is maintained as I2C_STATE_MASTER_BUSY_RX
and therefore the START condition will not be generated
With this new implementation, as in slave implementaiton, we use the
interrupts instead of accessing to registers continuously.
This has 2 main advantages:
- this shall improve performances overall and allows for sleep
time in the future
- this also removes some direct registers access from this
layer of code and makes it more generic among families
The timeout values are based on for loops and therefore should depend
on the core frequency and the I2C interface frequency.
This patch introduces this computation and base the timeout on the time
it should take to send a byte over the I2C interface. When sending a
number of bytes, this value can also be used.
In the loops, the timeout should also be decreased before the while
condition so that its value is 0 in case the timeout elapsed and this
can be treated as an error.
With this new implementation, the slave use the Interrupt
to be notified of a request from master, instead of
accessing to registers continuously.
This has 2 main advantages:
- this shall improve performances overall and allows for sleep
time in the future
- this also removes some direct registers access from this
layer of code and makes it more generic among families
With this commit we define I2C irq handlers that can be used by the driver
in sync mode. This also provides a mecanism for enabling and/or disabling
these handlers
Those handlers will be superseded by MBED ones in case of async mode usage.
the SPI_ASYNCH feature has been already activated for STM32F4.
This patchset makes it supported on all STM32 families by:
- moving spi_s structure at family level instead of board level
- using the F4 spi_api.c reference implementation and making it a common
stm_spi_api.c file which makes maintenance a lot easier.
- the only part that needs to be implemented for each family is the computation
of the clock frequency input to the spi peripheral which is not the same
accross families. So this is what remains in the spi_api.c of each family.
Because of the introduction of the common file, all the above modifications
needs to be done at once.
- Remove waiting for 'BTF' flag in 'i2c_stop()':
When 'i2c_stop()' is called from 'i2c_read()' or 'i2c_write()' flag 'BTF'
has already been cleared (indirectly) by the calling functions and therefore
'i2c_stop()' would mistakenly always run into a timeout.
- Delay clock enabling until pins are configured:
Enabling the I2C bus clock before configuring its pins might in rare
cases lead to HW faults on the bus.
- Move initialization of 'handle->Instance' to function 'i2c_reset()':
As 'i2c_reset()' uses '__HAL_I2C_GET_FLAG(handle, I2C_FLAG_BUSY)' field
'handle->Instance' must have been initialized before doing so. Therefore,
this operation has been anticipated by moving it from function
'i2c_frequency()' to function 'i2c_reset()'.