ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
5,964 Commits
52 Branches
336 Tags
624 MiB
Commit Graph

1991 Commits (ca8ae5c5d6a38067d7863a3ee6870c01d50ad062)

Author SHA1 Message Date
Jimmy Brisson ca8ae5c5d6 provided a scirpt for moving from device.h to target.json 
use -h to find out how it works!
 2016-06-03 14:03:50 -05:00
Bartosz Szczepanski 766b5c29e2 [DISCO_F429ZI] Added CAN support 
Added CAN API support for DISCO_F429ZI target.

Change-Id: I54b7d0ed25baf179fd899087297f4b8e76fc040a
 2016-06-03 15:13:39 +02:00
Bartosz Szczepanski ce781448b7 [DISCO_F469NI] Added CAN support 
Added CAN API support for DISCO_F469NI target.

Change-Id: Icfc52ec532aa71412814f245b41494fa69df4430
 2016-06-03 15:13:39 +02:00
Bartosz Szczepanski 96787cd79e [NUCLEO_F446RE] Added CAN support 
Added CAN API support for NUCLEO_F446RE target.

Change-Id: I6e585fd5ef9e5395c1dc5b9c31d09427927a0021
 2016-06-03 14:48:20 +02:00
Martin Kojtal 57645936ba Merge pull request #1811 from lindvalla/lpc4088_misc_fixes 
Misc fixes for LPC4088/LPC4088DM:
 2016-06-03 09:22:38 +01: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
Anders Lindvall 617caf6d98 Added all symbols to assembler (not just FPU_PRESENT=1). Removed unused c 
compiler argument.
 2016-06-01 09:22:40 +02: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
Anders Lindvall d8935bb837 Misc fixes for LPC4088/LPC4088DM: 
- Resetting in LPCXpresso IDE did not reset the LCD controller which
  sometimes could cause strange behaviour
- The ROM_LAT bit in the MATRIXARB register must be set in order to
  prevent a HardFault when debugging
- The change of compiler in LPCXpresso IDE to ARM launchpad GCC5 was
  causing build errors due to multiply defined timeval symbol.
- The exporters for LPCXpresso IDE did not set the FPU_PRESENT define
  for assembler, only for c/c++. This caused very strange behaviour
  in the RTOS code (e.g. timeouts no longer working, context switches
  failing etc.)
 2016-05-30 10:50:17 +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