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

2003 Commits (00feaa02f21f032f692e765745fa467c34b9de34)

Author SHA1 Message Date
Martin Kojtal 4afc14d18b Merge pull request #1781 from LMESTM/fix_MBED_37_Init 
Modify serial nc tests init part
 2016-06-07 12:15:57 +01:00
Martin Kojtal 02ce61d802 Merge pull request #1774 from BartSX/can-devel-l4 
[STM32L4xx] CAN development for STM32L4xx family
 2016-06-07 07:45:42 +01:00
Jimmy Brisson 32075c38e4 added extra_labels_add checking to script 
and moved a previously missed device.h file to targets.json
 2016-06-06 10:33:58 -05:00
Bartosz Szczepanski 10cce638a2 [NUCLEO_L476RG] Added CAN support 
Added CAN API support for NUCLEO_L476RG target.

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

Change-Id: Ifadf7048f6c72c0311ec915e47ce2190460ede68
 2016-06-06 16:20:46 +02:00
Bartosz Szczepanski 155d38ef9e [DISCO_L476VG] Added CAN support 
Added CAN API support for DISCO_L476VG target.

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

NOTE: MBED_29 or MBED_30 cannot be tested on this platform because CAN pins are
soldered to USB, GYRO and others.

Change-Id: I2e85bd36dc45872b1ab617f072de98164f2c96f8
 2016-06-06 16:19:11 +02:00
Bartosz Szczepanski bafd20f561 [DISCO_F746NG] Added CAN support 
Added CAN API support for DISCO_F746NG target.

Change-Id: I3b475309ab9b08c2e0ca1e8fe7e10489b8256321
 2016-06-06 13:28:00 +02:00
Bartosz Szczepanski 4d22e94156 [NUCLEO_F746ZG] Added CAN support 
Added CAN API support for NUCLEO_F746ZG target.

Change-Id: Ib9d416125671e3e1f1ef89e88e6da66f4c457f02
 2016-06-06 13:28:00 +02:00
Bartosz Szczepanski 6e77543313 [NUCLEO_F103RB] Added CAN support 
Added CAN API support for NUCLEO_F103RB target.

Change-Id: Ib5dac8023917afef683ba0703d732bbf53efdcd9
 2016-06-06 13:00:03 +02:00
Jimmy Brisson 66574aaa9d made features a first class citizen 2016-06-03 16:18:23 -05:00
Jimmy Brisson 2fe708d526 added features support to all of the toolchains 2016-06-03 14:03:50 -05:00
Jimmy Brisson 76e6c885a2 auto-formatted target.json 2016-06-03 14:03:50 -05:00
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
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
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