Commit Graph

1985 Commits (05baf365dcdf109d336fba0fe1911d892c3a25a6)

Author SHA1 Message Date
Laurent Meunier 05baf365dc Synchronize host and target for nc serial auto test
We're ensuring target and host start-up sync here in 2 ways:
1) adding a delay on host side to make sure the serial
initialization can happen before sending a character is sent to target
2) in case of serial_nc_rx_auto.py test, we're sending a
first character S which will trigger the move from rx+tx
to NC+rx.

This should  avoid any crossing case due to HSOT being faster than target or vice-versa
2016-06-03 09:32:13 +02:00
Martin Kojtal 5ac648f866 Merge pull request #1762 from BartSX/can-devel-f3
[STM32F3xx] CAN development for STM32F3xx family
2016-06-03 07:59:19 +01:00
Martin Kojtal 7643399c1d Merge pull request #1835 from stevew817/feature/rtos_support_efm32
[Silicon Labs] Disable RTOS support for EFM32ZG
2016-06-02 11:51:00 +01:00
Steven Cooreman d14fc7f744 Forgot to remove ZG RTOS from the automated build... 2016-06-02 11:56:09 +02:00
Steven Cooreman 0015943bd9 Remove RTOS support for EFM32 Zero Gecko because of too little RAM 2016-06-02 10:06:26 +02:00
Martin Kojtal 5df96fbec3 Merge pull request #1815 from stevew817/feature/rtos_support_efm32
[Silicon Labs] Provide RTOS support for EFM32 targets
2016-06-02 08:08:20 +01:00
Russ Butler 793f9c566a Add partial thread safety to GCC
Add lock functions so that malloc and environment variable access are
thread safe.  Add the compiler option "-o thread-safe" to use the full
version of newlib which is thread safe.

Note that this patch does NOT make file access thread safe.
2016-05-31 16:16:59 -05:00
Russ Butler bd216c37cb Make the IAR standard library thread safe
Add the locks and flags necessary to make the IAR standard library
thread safe.  These changes consist of:
-Add compiler flag "--guard_calls" to ensure C++ function-static
    variables with dynamic initializers are initialized in a
    thread safe manner
-Add the linker flag "--threaded_lib" so the thread safe version of
    the standard library is used
-Implement mutex functions required for IAR thread safety
-Create a set of stub functions in retarget.c for when the rtos is not present
2016-05-31 14:41:21 -05:00
Steven Cooreman cc34a7bada Provide initial RTOS support for EFM32 targets 2016-05-30 14:14:36 +02:00
Mihail Stoyanov 8a7bb1b7a6 Fixed ignore files for the new .mbedignore logic 2016-05-29 11:16:43 +01:00
Sam Grove d94627e042 move target description from tools into hal where the target code lives 2016-05-28 12:46:08 +08:00
Sam Grove cd9f9331dc Updates for CI (#1760)
* Dont exclude tests from magical lists

* update default toolchain locations for windows pointing to latest supported versions

* Fixing build loop in build_release.py

* Fixing incorrect target name in release script, preventing traceback in this case

* Breaking up the uploading of build/test results.
It defaults to 1000 'projectRuns' per POST call, though this can be
modified via the '-l' parameter when invoking 'add-project-runs'.

* remove default path to GCC. Setting takes priority to PATH so this breaks linux and Mac

* revert is_supported chages in favor of alternative command line option
2016-05-27 13:10:04 +01:00
Martin Kojtal ffa9d17bab Merge pull request #1751 from mbedmicro/json_targets
Moved target definitions to JSON format
2016-05-27 11:52:57 +01:00
0xc0170 627fe55c21 Synch - fix lwip-eth path
Fixes #1786 issue
2016-05-26 08:32:24 +01:00
Bartosz Szczepanski f1c42bfc69 [NUCLEO_F302R8] Added CAN support
Added CAN API support for NUCLEO_F302R8 target.

*stm32f302x8.h* file was changed to avoid compilation errors.

Change-Id: Ia4ee8a90fe3f0ad6955dde21e78ea4a6c05e4fcd
2016-05-23 15:55:00 +02:00
Bartosz Szczepanski 347a5e629d [NUCLEO_F303K8] Added CAN support
Added CAN API support for NUCLEO_F303K8 target.

*stm32f303x8.h* file was changed to avoid compilation errors.

Change-Id: If093c84f19c5a5ef68938af4653a25271c1108ba
2016-05-23 15:55:00 +02:00
Bartosz Szczepanski 9a78b010a0 [NUCLEO_F303RE] Added CAN support
Added CAN API support for NUCLEO_F303RE target.

*stm32f303xe.h* file was changed to avoid compilation errors.

Change-Id: Ia6519c982261d43165dbce73cab7cfc0617474e2
2016-05-23 15:55:00 +02:00
Bartosz Szczepanski 656d1953d9 [NUCLEO_F334R8] Added CAN support
Added CAN API support for NUCLEO_F334R8 target.

*stm32f334x8.h* file was changed to avoid compilation errors.

Change-Id: Ic7b3273ffe24940ecdc189d2566a6a7f66825ce6
2016-05-23 15:55:00 +02:00
0xc0170 369841a6cb Merge branch 'master' of https://github.com/adustm/mbed into adustm-master
Conflicts:
	workspace_tools/tests.py
2016-05-23 11:10:03 +01:00
0xc0170 c70aedc044 Merge branch 'can-devel-f0' of https://github.com/BartSX/mbed into BartSX-can-devel-f0 2016-05-23 10:37:22 +01:00
Mihail Stoyanov 9db0f2e6e0 Update synch.py script to use the paths defined in paths.py 2016-05-23 09:14:04 +01:00
Mihail Stoyanov d5ad8cb949 Rename .mbedignore to .buildignore 2016-05-23 09:14:03 +01:00
Mihail Stoyanov 9bd2b4e4b1 Align paths config (paths.py) with the new directory layout. Also rename the output build folder to .build 2016-05-23 09:14:01 +01:00
Mihail Stoyanov d9734e5a32 Simplify layout:
* /libraries/mbed -> /hal
* /libraries/rtos -> /rtos
2016-05-23 09:13:59 +01:00
Bartosz Szczepanski fad2190225 [NUCLEO_F042K6] Added CAN support
Added CAN API support for NUCLEO_F042K6 target.

"stm32f042x6.h" file was changed to avoid compilation errors.

Change-Id: I9622a233775fc6834201a322740bf5026244d50e
2016-05-20 13:27:58 +02:00
Bartosz Szczepanski d140e9959a [NUCLEO_F072RB] Added CAN support
Added CAN API support for NUCLEO_F072RB target.

*stm32f072xb.h* file was changed to avoid compilation errors.

Change-Id: I9da75fde29fd19f0326d554acc1dbb5386b08317
2016-05-20 11:48:34 +02:00
Bartosz Szczepanski 8577163ca3 [NUCLEO_F091RC] Added CAN support
Added CAN API suport for NUCLEO_F091RC target.

*stm32f091xc.h* file was changed to avoid compilation errors.

Change-Id: I9207575a0e2ad0f8e3a4bb78eb23d1e7b4a94171
2016-05-20 11:48:33 +02:00
Bogdan Marinescu bc063a3903 Moved target definitions to JSON format
(long commit message ahead. Sorry about that, it can't be helped.)

This commit changs targets definition from Python to JSON format, as
part of the configuration mechanism implementation. There is a new file
under workspace_tools/ called "targets.json" which contains the target
definitions. "targets.py" remains, but becomes a wrapper on top of
"targets.json", with the same interface as before. This has the
advantage of not requiring code changes outside "targets.py".

Most of the JSON definitions of targets were automatically generated by a
script (available upon request since it doesn't make a lot of sense to
include it here), only those targets that had more than one parent in
the Python implementation were converted by hand. The target definitions
should be pretty self-explanatory. A number of things are different in
the JSON implementation (this is just a summary, check docs/mbed_targets.md
(also part of this PR) for a more complete description):

- "program_cycle_s" is now a value (as opposed to a function in the
Python implementation), since it only returned a number in all the
Python target implementations. The main definition that actually contains
some code (in class "Target") remains in target.py
- array values in "macros" and "extra_labels" can be modified
dynamically. Values can be added using "macros_add" and
"extra_labels_add" or removed using "macros_remove" and
"extra_labels_remove". This mechanism is available for all attributes
with a list type, but it's currently enabled only for "macros" and
"extra_labels" to keep things simple.
- "init_hooks"/"binary_hook" are now implemented in terms of a single
JSON key valled "post_binary_hook". The corresponding code is also in
"targets.py", under the various TargetCode classes (see for example
LPC4088Code in targets.py).

Just like in the Python implementation, a target can inherit from zero,
one or more targets. The resolution order for the target's attributes
follows the one used by the Python code (I used
http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path
as a reference for the implementation of resolution order).

This is obviously a very dangerous commit, since it affects all targets.
I tested compilation for a number of targets (K64F, LPC1768, NRF51822)
but there's definitely a lot more to be done in terms of testing.

I also tried to test in a different way: I wrote a script that imports the
old (Python) and the new (JSON) implementations and verifies that the
attributes in the old implementations exist and have the same values
in the new implementations (it also verifies that the attribute
resolution order is the same in the two implementations). If you're
interested, the script is here:

https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c

And the results of running the script are below (note that the script
outputs only the target names that were found to be problematic):

NRF51_MICROBIT_BOOT:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
NRF51_MICROBIT:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC']
NRF51_MICROBIT_OTA:
    Resolution order is different in old and new
        old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110']
        new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target']
    'extra_labels' has different values in old and new
        old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT']
        new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT']
    'macros' has different values in old and new
        old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
        new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC']
NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA']

The reasons for the above output are subtle and related to the
extremely weird way in which we defined target data in the Python
implementation: we used both class attributes and instance attributes.
This can complicate resolution order quite a bit and those two levels
don't exist in JSON: there's only one attribute type (equivalent to
Python's instance attributes). To make that work, I had to change the
inheritance order of the above targets (that use multiple inheritance)
which in turn changed the order of some macros and extra_labels (and of
course the resolution order). No harm done: the values are the same,
only their ordering is different. I don't believe this causes any
problems for 'extra_labels' and 'macros'.

This method of testing has its limitations though; in particular, it
can't test the hooks. I'm opened to ideas about how to test this better,
but I think that we need to remember that this commit might break some
targets and keep an eye out for "weird errors" in the future.
2016-05-17 21:42:55 +03:00
bcostm 13f0c1ff6f [NUCLEO_F746ZG] Add RTOS and MBED_A8 tests (#1728)
* Add RTOS, MBED_A8 tests

* [NUCLEO_F746ZG] Add pins for MBED_A8 test
2016-05-13 15:46:03 +01:00
Olaf Hagendorf a4c55293e0 minor change in doc string format in exporter.py (#1739) 2016-05-13 10:39:56 +01:00
adustm e5c1d37c25 [STM32F7] add FPU option for assembly compiling (needed for rtos library) 2016-05-13 11:19:07 +02:00
adustm dbb99d4eee NUCLEO_F746ZG] add this board to rtos 1-8 tests 2016-05-13 10:59:59 +02:00
0xc0170 1290925ad1 Build release - RZ_A1H iar removal
There are issues with cmsis API, which were not ported to IAR.
2016-05-10 10:21:09 -05:00
Martin Kojtal be6e09bec3 Merge pull request #1725 from 0xc0170/fix_ksdk_old_macro
Target - backward compatibility KSDK 1.0 labels
2016-05-09 15:12:13 -05:00
0xc0170 5681da0845 Target - backward compatibility KSDK 1.0 labels
The extra_labels should not be removed, as it could break old sources or
mbed-lib or applications.
2016-05-09 13:44:37 -05:00
0xc0170 58e47dc500 gcc makefile - use group for ld to resolve symbols from libraries 2016-05-09 12:06:33 -05:00
0xc0170 8681a8d53e gcc - use group for ld to resolve symbols from libraries
This fixes problem we have seen with rtos_idle_loop. The symbols
was not resolved as order played a role in this case. Remove circular
dependencies member, as it should not be required anymore.
2016-05-09 12:02:23 -05:00
0xc0170 def841979a RTOS - fix Cortex-M version - add macros required for new kernel
2 new macros were introduced to capture changes in the kernel. We used toolchains/__init__
script to capture those, which is not in the sync with actual sources. This fix introduces
those macros in the source, rather than a script.

We will further eliminate those macros to be used outside of RTX kernel (c++ API).
2016-05-06 11:50:21 -05:00
0xc0170 8bbe0bb3ca Cortex symbols - add cmsis rtos for all cortex cores 2016-05-05 12:10:56 -05:00
0xc0170 89b6c41a1b uvision5 - add flags from uvision toolchain class
Flags should be unique, thus use list(set()) to remove duplicates
2016-05-04 16:56:43 -05:00
0xc0170 5ce3ec9619 uvision - fix INC dir
The path for INC might be with spaces, uvision does not handle it well,
thus wrapping around ""
2016-05-04 16:41:01 -05:00
0xc0170 ded7d39c76 uvision - microlib fix - commands to use -D__MICROLIB
Exporters use --library_type=microlib. This will be unified soon, as currently
the templates does not support ASM macros.
2016-05-04 11:42:45 -05:00
0xc0170 5018270bb5 uvision - asm flags fix
Use deepcopy to get flags as they are shared between ARM and uARM. asm flags
for command line require c flags as it used to be.
2016-05-04 10:58:44 -05:00
0xc0170 ee00dbd9a7 uvision - fix c/asm flags
Some flags are only C specific, causes problems when there's .S file in the workspace.
For instance, -Ox is only C flag, causes a project to fail with "unrecognized option"
2016-05-04 09:45:16 -05:00
Martin Kojtal 9cef243de2 Merge pull request #1700 from NXPmicro/dev_ksdk_2.0
Switch to KSDK 2.0
2016-05-02 18:13:47 -05:00
Mahadevan Mahesh da0924f95c Networking update for FRDM K64 platform
Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-04-29 15:54:01 -05:00
Mahadevan Mahesh fffadba309 Moved SDK 2.0 platforms back to TARGET_Freescale from TARGET_NXP.
Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-04-29 15:53:53 -05:00
Mahadevan Mahesh f512738f91 Add support for KL27Z FRDM board
Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-04-29 15:45:05 -05:00
Mahadevan Mahesh 06698f4ffa Add support for the K64F Hexiwear board
Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-04-29 15:45:02 -05:00
Mahadevan Mahesh-R9AADQ 6ff2badf1f Added support for Kinetis K22
Use Kinetis SDK 2.0
Moved to TARGET_NXP

Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-04-29 15:44:58 -05:00