With this patch in place, tests.py uses targets names instead of target
instances, which makes it possible to use application defined targets
with tests.
With this change, custom targets defined by the application being
tested in its mbed_app.json file can be used with tests. Note that
`build_project` already accepts both target names and instances, so the
call to `build_project` inside `build_tests` will still work.
The configuration object is now created early in the build_project
function. This way, if there's a mbed_app.json that contains a custom
target, that target is taken into account. This is useful (for example)
when compiling tests for an application that defines a custom target.
As first reported on STM32F3 family in #1682, we need to cope
with periods in the seconds range as well. This is fixed here in
the same way as was done for STM32F3 by using the pre-scaler.
As first reported on STM32F3 family in #1682, we need to cope
with periods in the seconds range as well. This is fixed here in
the same way as was done for STM32F3 by using the pre-scaler.
As first reported on STM32F3 family in #1682, we need to cope
with periods in the seconds range as well. This is fixed here in
the same way as was done for STM32F3 by using the pre-scaler.
As first reported on STM32F3 family in #1682, we need to cope
with periods in the seconds range as well. This is fixed here in
the same way as was done for STM32F3 by using the pre-scaler.
As first reported on STM32F3 family in #1682, we need to cope
with periods in the seconds range as well. This is fixed here in
the same way as was done for STM32F3 by using the pre-scaler.
As first reported on STM32F3 family in #1682, we need to cope
with periods in the seconds range as well. This is fixed here in
the same way as was done for STM32F3 by using the pre-scaler.
As first reported on STM32F3 family in #1682, we need to cope
with periods in the seconds range as well. This is fixed here in
the same way as was done for STM32F3 by using the pre-scaler.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
Some of the objects in object.h are the same for all targets.
Create a place where to define those common definitions, and
start using it for pwm object.
The new period needs to be saved before the duty cycle is updated as
the period is used in pwmout_write function.
Also presclaer shall better be initiliazed properly.
- removing redundancy as discussed in PR #2087:
- in target.json the core option can have only this values : "Cortex-M0", "Cortex-M0+", "Cortex-M1", "Cortex-M3", "Cortex-M4", "Cortex-M7", "Cortex-A9" - Cortex-M4F and Cortex-M7F removed
- in target.json an additional fpu option with values: "single" and "double" can be used
- build and export scripts are changed to handle this
- tested (compiling, running on hardware) with nucleo_f767 (cortex-m7 with double precision fpu), nucleo_f746 (cortex-m7 with single precision fpu), nucleo_f446 and nucleo_l467 (cortex-m4 with single precision fpu), teensy31 (cortex-m4 without fpu - only build test), nucleo_l073 (cortex-m0)
- singletest results are added to PR #2087 comments
- creating new core name Cortex_M7F_DP for a target with a double precision fpu
- adding new core name to arm.py to set compiler/linker flags to a double precision fpu when configured in target.json
- up to now: gcc wrote flag for a double precision fpu -> target with STM32F746 didn't run when using double variables - mcu has only single precision fpu
- changing gcc.py to use single precision for Cortex-M7 und double precision for Cortex_M7F_DP
tested with NUCLEO_F746, NUCLEO_F767 and build.py+make.py and exporting with project.py + compiling/flashing
- iar.py need a similar extention - I didn't change that yet because
- did not run at the moment - python exception
- currently worked on in PR #1948
Bogdan Marinescu
Martin Kojtal
Jimmy Brisson
Brian Daniels
Michel Jaouen
Bogdan Marinescu
Laurent MEUNIER
Michel JAOUEN
Olaf Hagendorf
Marcelo Salazar
Erwan GOURIOU
Erwan Gouriou
Laurent Meunier