ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
mbed-os/targets/targets.json

4160 lines
176 KiB
JSON
Raw Normal View History

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 17:50:01 +00:00
{
"Target": {
"core": null,
"default_toolchain": "ARM",
"supported_toolchains": null,
"extra_labels": [],
"is_disk_virtual": false,
"macros": [],
Rename "features" to "device_has" in targets.json "features" will make more sense in the context of the feature support that we'll introduce later (related to #1878). Plus, "device_has" is arguably a better description of the actual content of this key.
2016-06-08 15:28:05 +00:00
"device_has": [],
Added features to Target description to support the changed names and build extensions
2016-06-09 14:00:36 +00:00
"features": [],
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 17:50:01 +00:00
"detect_code": [],
Only allow one thread on unsafe standard libs When using a standard library which does not support multi-threading allow only one thread to be used. This allows the code to remain safe.
2016-06-11 21:05:54 +00:00
"public": false,
Fail bootloader builds on targets that don't support it This patch will prevent building bootloader builds on targets that have not yet had their linker scripts/scatter files changed to allow for the ROM space shrinking expected by bootloader builds. At the point of this patch, bootloader linker script modifications are only supported by the NUCLEO_F429ZI, K64F, KL46Z, and Odin.
2017-02-23 00:27:23 +00:00
"default_lib": "std",
Optional hardware flow control for STDOUT Some platforms have interface chips with hardware flow control enabled by default. This commit adds configurable flow control to STDOUT. Usage: * Define pin names STDIO_UART_RTS for Rx-flow-control and STDIO_UART_CTS for Tx-flow-control. * Set target.console-uart-flow-control. Valid options are: null, RTS, CTS, and RTSCTS.
2018-04-11 16:53:06 +00:00
"bootloader_supported": false,
"config": {
"console-uart-flow-control": {
"help": "Console hardware flow control. Options: null, RTS, CTS, RTSCTS.",
"value": null
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
},
"network-default-interface-type": {
"help": "Default network interface type. Typical options: null, ETHERNET, WIFI, CELLULAR, MESH",
"value": null
Optional hardware flow control for STDOUT Some platforms have interface chips with hardware flow control enabled by default. This commit adds configurable flow control to STDOUT. Usage: * Define pin names STDIO_UART_RTS for Rx-flow-control and STDIO_UART_CTS for Tx-flow-control. * Set target.console-uart-flow-control. Valid options are: null, RTS, CTS, and RTSCTS.
2018-04-11 16:53:06 +00:00
}
}
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 17:50:01 +00:00
},
"CM4_UARM": {
"inherits": ["Target"],
"core": "Cortex-M4",
"default_toolchain": "uARM",
"public": false,
Only allow one thread on unsafe standard libs When using a standard library which does not support multi-threading allow only one thread to be used. This allows the code to remain safe.
2016-06-11 21:05:54 +00:00
"supported_toolchains": ["uARM"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small"
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 17:50:01 +00:00
},
"CM4_ARM": {
"inherits": ["Target"],
"core": "Cortex-M4",
"public": false,
Adding concept of release versions for targets. Previously, the condition for including a target in a release was decided by a 'release' key being set to 'true' in hal/targets.json. This doesn't have enough granularity when we release multiple versions of mbed. This PR changes the 'release' key to an array of strings, where each member is a version that the target supports. Currently the valid versions are '2' and '5'. This PR also adds more robust checking for invalid target configurations in a release. This is enforced whenever the release list is built from the data, preventing invalid targets from coming into the release. Finally, it updates the build_release.py script to use the new api for fetching release targets.
2016-07-26 15:22:02 +00:00
"supported_toolchains": ["ARM"]
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 17:50:01 +00:00
},
"CM4F_UARM": {
"inherits": ["Target"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"default_toolchain": "uARM",
"public": false,
Only allow one thread on unsafe standard libs When using a standard library which does not support multi-threading allow only one thread to be used. This allows the code to remain safe.
2016-06-11 21:05:54 +00:00
"supported_toolchains": ["uARM"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small"
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 17:50:01 +00:00
},
"CM4F_ARM": {
"inherits": ["Target"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"public": false,
Adding concept of release versions for targets. Previously, the condition for including a target in a release was decided by a 'release' key being set to 'true' in hal/targets.json. This doesn't have enough granularity when we release multiple versions of mbed. This PR changes the 'release' key to an array of strings, where each member is a version that the target supports. Currently the valid versions are '2' and '5'. This PR also adds more robust checking for invalid target configurations in a release. This is enforced whenever the release list is built from the data, preventing invalid targets from coming into the release. Finally, it updates the build_release.py script to use the new api for fetching release targets.
2016-07-26 15:22:02 +00:00
"supported_toolchains": ["ARM"]
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 17:50:01 +00:00
},
"LPCTarget": {
"inherits": ["Target"],
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"post_binary_hook": {"function": "LPCTargetCode.lpc_patch"},
Adding concept of release versions for targets. Previously, the condition for including a target in a release was decided by a 'release' key being set to 'true' in hal/targets.json. This doesn't have enough granularity when we release multiple versions of mbed. This PR changes the 'release' key to an array of strings, where each member is a version that the target supports. Currently the valid versions are '2' and '5'. This PR also adds more robust checking for invalid target configurations in a release. This is enforced whenever the release list is built from the data, preventing invalid targets from coming into the release. Finally, it updates the build_release.py script to use the new api for fetching release targets.
2016-07-26 15:22:02 +00:00
"public": false
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 17:50:01 +00:00
},
"LPC11C24": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"extra_labels": ["NXP", "LPC11XX_11CXX", "LPC11CXX"],
Change detault output_ext for LPC11C24 to hex (for flashmagic)
2018-04-09 09:27:00 +00:00
"OUTPUT_EXT": "hex",
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "LPC11C24FBD48/301"
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 17:50:01 +00:00
},
"LPC1114": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11XX_11CXX", "LPC11XX"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC1114FN28/102"
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 17:50:01 +00:00
},
"LPC11U24": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX", "LPC11U24_401"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["1040"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC11U24FBD48/401"
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 17:50:01 +00:00
},
"OC_MBUINO": {
"inherits": ["LPC11U24"],
Add virtual nvic support to OC_MBUINO (LPC11U24 based)
2017-06-09 04:49:07 +00:00
"macros": ["TARGET_LPC11U24", "CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"extra_labels": ["NXP", "LPC11UXX"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"LPC11U24_301": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"extra_labels": ["NXP", "LPC11UXX"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "LPC11U24FHI33/301"
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 17:50:01 +00:00
},
"LPC11U34_421": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
Added support for ADI EV-COG-AD4050LZ platform.
2017-09-20 04:37:22 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "LPC11U34FBD48/311"
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 17:50:01 +00:00
},
"MICRONFCBOARD": {
"inherits": ["LPC11U34_421"],
targets: micronfcboard should add macros, not overwrite
2017-06-15 11:09:05 +00:00
"macros_add": ["LPC11U34_421", "APPNEARME_MICRONFCBOARD"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"extra_labels_add": ["APPNEARME_MICRONFCBOARD"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC11U34FBD48/311"
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 17:50:01 +00:00
},
"LPC11U35_401": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC11U35FBD48/401"
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 17:50:01 +00:00
},
"LPC11U35_501": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX", "MCU_LPC11U35_501"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC11U35FHI33/501"
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 17:50:01 +00:00
},
"LPC11U35_501_IBDAP": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX", "MCU_LPC11U35_501"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"default_lib": "small",
"device_name": "LPC11U35FHI33/501"
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 17:50:01 +00:00
},
"XADOW_M0": {
Inherit Xadow M0 target from LPC11U35_501 targets/targets.json already added MCU_LPC11U35_501 as an extra label but it didn't have LPC11U35_501 (without the MCU_ prefix). Both of these target names are used as folder names to organize files specific to this device. For example the LPC11U35.ld linker script used by GCC_ARM for this target is located in a TARGET_LPC11U35_501 folder. I switched to using inheritance to properly setup the target labels based on @theotherjimmy comments on PR #4252. Everything in the XADOW_M0 targe appears to have been copy/pasted from LPC11U35_501 anyway so inheritance seems to be the best way to set the values of the XADOW_M0 properties.
2017-05-02 15:14:17 +00:00
"inherits": ["LPC11U35_501"]
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 17:50:01 +00:00
},
"LPC11U35_Y5_MBUG": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX", "MCU_LPC11U35_501"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"default_lib": "small",
"device_name": "LPC11U35FHI33/501"
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 17:50:01 +00:00
},
"LPC11U37_501": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"default_lib": "small",
"device_name": "LPC11U37FBD64/501"
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 17:50:01 +00:00
},
"LPCCAPPUCCINO": {
"inherits": ["LPC11U37_501"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "LPC11U37FBD64/501"
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 17:50:01 +00:00
},
"ARCH_GPRS": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX", "LPC11U37_501"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
"inherits": ["LPCTarget"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC11U37FBD64/501"
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 17:50:01 +00:00
},
"LPC11U68": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11U6X"],
"supported_toolchains": ["ARM", "uARM", "GCC_CR", "GCC_ARM", "IAR"],
"inherits": ["LPCTarget"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["1168"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PWMOUT", "SERIAL", "SLEEP", "SPI"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC11U68JBD100"
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 17:50:01 +00:00
},
"LPC1347": {
"inherits": ["LPCTarget"],
"core": "Cortex-M3",
"extra_labels": ["NXP", "LPC13XX"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC1347FBD48"
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 17:50:01 +00:00
},
"LPC1549": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M3",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC15XX"],
"supported_toolchains": ["uARM", "GCC_CR", "GCC_ARM", "IAR"],
"inherits": ["LPCTarget"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["1549"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "INTERRUPTIN", "PWMOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
Fix or remove invalid device names The field device_name is intended to match that of a target in a device family pack. Remove this field for devices which do not have a pack. Fix the name for devices that have the name incorrect. Update IAR definitions for device which no longer have a device_name but still need to have support for the IAR exporter.
2017-01-16 00:42:02 +00:00
"device_name": "LPC1549JBD64"
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 17:50:01 +00:00
},
"LPC1768": {
"inherits": ["LPCTarget"],
"core": "Cortex-M3",
Removes FLASH capabilities for the ARCH_PRO. This platform is failing a flash test at this time. This commit disables the capability (and therefore the test) until it is fixed.
2017-05-10 15:41:58 +00:00
"extra_labels": ["NXP", "LPC176X", "MBED_LPC1768"],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["1010"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "FLASH"],
Add feature LWIP to LPC1768, UBLOX_C027 and ARCH_PRO targets.
2016-10-01 07:16:45 +00:00
"release_versions": ["2", "5"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"features": ["LWIP"],
Enable LPC1768 bootloader support
2017-09-05 15:09:41 +00:00
"device_name": "LPC1768",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
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 17:50:01 +00:00
},
LPCXpresso LPC1769 board ported The blinky example compiles and runs. The board has a different eth phy component than mbed LPC1768. It requires a driver.
2017-09-05 14:30:14 +00:00
"LPC1769": {
lpc1769 inherits from lpc1768; reuse lpc1768.ld for LPC1769 target
2017-10-17 10:12:59 +00:00
"inherits": ["LPC1768"],
LPCXpresso LPC1769 board ported The blinky example compiles and runs. The board has a different eth phy component than mbed LPC1768. It requires a driver.
2017-09-05 14:30:14 +00:00
"device_name": "LPC1769"
},
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 17:50:01 +00:00
"ARCH_PRO": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
Removes FLASH capabilities for the ARCH_PRO. This platform is failing a flash test at this time. This commit disables the capability (and therefore the test) until it is fixed.
2017-05-10 15:41:58 +00:00
"extra_labels": ["NXP", "LPC176X"],
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 17:50:01 +00:00
"macros": ["TARGET_LPC1768"],
"inherits": ["LPCTarget"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "FLASH"],
Add feature LWIP to LPC1768, UBLOX_C027 and ARCH_PRO targets.
2016-10-01 07:16:45 +00:00
"release_versions": ["2", "5"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"features": ["LWIP"],
Enable LPC1768 bootloader support
2017-09-05 15:09:41 +00:00
"device_name": "LPC1768",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
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 17:50:01 +00:00
},
"UBLOX_C027": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
LPC1768 IAP Fix (#4993) use IAP routines for the flash HAL implementation
2017-09-22 10:30:43 +00:00
"extra_labels": ["NXP", "LPC176X"],
Major Refactoring & extensions 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.
2017-05-23 17:07:24 +00:00
"config": {
"modem_is_on_board": {
"help": "Value: Tells the build system that the modem is on-board as oppose to a plug-in shield/module.",
"value": 1,
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"macro_name": "MODEM_ON_BOARD"
Major Refactoring & extensions 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.
2017-05-23 17:07:24 +00:00
},
"modem_data_connection_type": {
"help": "Value: Defines how the modem is wired up to the MCU, e.g., data connection can be a UART or USB and so forth.",
"value": 1,
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"macro_name": "MODEM_ON_BOARD_UART"
Major Refactoring & extensions 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.
2017-05-23 17:07:24 +00:00
}
},
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 17:50:01 +00:00
"macros": ["TARGET_LPC1768"],
"inherits": ["LPCTarget"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "FLASH"],
Add feature LWIP to LPC1768, UBLOX_C027 and ARCH_PRO targets.
2016-10-01 07:16:45 +00:00
"release_versions": ["2", "5"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"features": ["LWIP"],
Enable LPC1768 bootloader support
2017-09-05 15:09:41 +00:00
"device_name": "LPC1768",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "CELLULAR"
}
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 17:50:01 +00:00
},
"XBED_LPC1768": {
"inherits": ["LPCTarget"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
LPC1768 IAP Fix (#4993) use IAP routines for the flash HAL implementation
2017-09-22 10:30:43 +00:00
"extra_labels": ["NXP", "LPC176X", "XBED_LPC1768"],
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 17:50:01 +00:00
"macros": ["TARGET_LPC1768"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["1010"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "LPC1768"
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 17:50:01 +00:00
},
"LPC810": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC81X"],
"is_disk_virtual": true,
"supported_toolchains": ["uARM", "IAR", "GCC_ARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["I2C", "I2CSLAVE", "INTERRUPTIN", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"default_lib": "small",
"device_name": "LPC810M021FN8"
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 17:50:01 +00:00
},
"LPC812": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC81X"],
"is_disk_virtual": true,
"supported_toolchains": ["uARM", "IAR", "GCC_ARM"],
"inherits": ["LPCTarget"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["1050"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["I2C", "I2CSLAVE", "INTERRUPTIN", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC812M101JDH20"
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 17:50:01 +00:00
},
"LPC824": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC82X"],
"is_disk_virtual": true,
"supported_toolchains": ["uARM", "GCC_ARM", "GCC_CR", "IAR"],
"inherits": ["LPCTarget"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC824M201JDH20"
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 17:50:01 +00:00
},
"SSCI824": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC82X"],
"is_disk_virtual": true,
"supported_toolchains": ["uARM", "GCC_ARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
Correct definition of LPC4088* to use a common ancestry
2017-01-17 21:16:55 +00:00
"MCU_LPC4088": {
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 17:50:01 +00:00
"inherits": ["LPCTarget"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"extra_labels": ["NXP", "LPC408X"],
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "GCC_CR", "GCC_ARM", "IAR"],
"post_binary_hook": {
LPC4088 - Fix vector checksum Turn on the vector checksum on all LPC4088 variants. This checksum is required for an application to boot.
2017-01-10 20:53:24 +00:00
"function": "LPC4088Code.binary_hook"
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 17:50:01 +00:00
},
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
LPC4088: Enable LWIP feature This patch enable the LWIP feature for the LPC4088 and LPC4088_DM boards. The lwIP stack support already this hardware. See: ./features/FEATURE_LWIP/lwip-interface/lwip-eth/arch/TARGET_NXP/lpc17_emac.c
2017-04-16 09:16:51 +00:00
"features": ["LWIP"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"device_name": "LPC4088FBD144",
"overrides": {
"network-default-interface-type": "ETHERNET"
}
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 17:50:01 +00:00
},
Correct definition of LPC4088* to use a common ancestry
2017-01-17 21:16:55 +00:00
"LPC4088": {
"inherits": ["MCU_LPC4088"],
"release_versions": ["2", "5"]
},
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 17:50:01 +00:00
"LPC4088_DM": {
Correct definition of LPC4088* to use a common ancestry
2017-01-17 21:16:55 +00:00
"inherits": ["MCU_LPC4088"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2", "5"]
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 17:50:01 +00:00
},
"LPC4330_M4": {
"inherits": ["LPCTarget"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"extra_labels": ["NXP", "LPC43XX", "LPC4330"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["ARM", "GCC_CR", "IAR", "GCC_ARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "LPC4330"
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 17:50:01 +00:00
},
"LPC4330_M0": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"extra_labels": ["NXP", "LPC43XX", "LPC4330"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["ARM", "GCC_CR", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"]
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 17:50:01 +00:00
},
"LPC4337": {
"inherits": ["LPCTarget"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"extra_labels": ["NXP", "LPC43XX", "LPC4337"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["ARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "DEBUG_AWARENESS", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC4337"
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 17:50:01 +00:00
},
"LPC1800": {
"inherits": ["LPCTarget"],
"core": "Cortex-M3",
"extra_labels": ["NXP", "LPC43XX"],
"public": false,
"supported_toolchains": ["ARM", "GCC_CR", "IAR"]
},
"LPC11U37H_401": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR"],
"inherits": ["LPCTarget"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "LPC11U37HFBD64/401"
Add lpc821 cocorico target Added by @ElektorLabs PR #1840, squashed manually.
2016-06-02 09:19:46 +00:00
},
"ELEKTOR_COCORICO": {
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC81X"],
"supported_toolchains": ["uARM", "GCC_ARM", "IAR"],
"inherits": ["LPCTarget"],
"is_disk_virtual": true,
"detect_code": ["C000"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"default_lib": "small",
"device_name": "LPC812M101JDH16"
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 17:50:01 +00:00
},
"KL05Z": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["Freescale", "KLXX"],
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"inherits": ["Target"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "MKL05Z32xxx4"
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 17:50:01 +00:00
},
"KL25Z": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"extra_labels": ["Freescale", "KLXX"],
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"inherits": ["Target"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0200"],
Disable boards which does not fulfil new sleep standards. These boards will be re-enabled when sleep driver for them is ready. Note: This operation is done by removing "SLEEP" feature from target's "device_has" list (in targets.json config file). For NRF52_DK removing of "SLEEP" feature causes some timing issues which have influence on tests. In order to successfully disable this board we need to disable also related features like "USTICKER", "LOWPOERTIMER" and slightly modify ticker tests, so they will not be executed if usticker support is not available (by default all targets support us ticker).
2017-12-21 09:52:40 +00:00
"device_has": ["USTICKER", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "MKL25Z128xxx4"
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 17:50:01 +00:00
},
"KL26Z": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"extra_labels": ["Freescale", "KLXX"],
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"inherits": ["Target"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "MKL26Z128xxx4"
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 17:50:01 +00:00
},
"KL46Z": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
Add K64F, KL46Z, F429, F439 and odin flash algos 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.
2017-02-18 17:09:56 +00:00
"extra_labels": ["Freescale", "KLXX", "FLASH_CMSIS_ALGO"],
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 17:50:01 +00:00
"is_disk_virtual": true,
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
"inherits": ["Target"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0220"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Fail bootloader builds on targets that don't support it This patch will prevent building bootloader builds on targets that have not yet had their linker scripts/scatter files changed to allow for the ROM space shrinking expected by bootloader builds. At the point of this patch, bootloader linker script modifications are only supported by the NUCLEO_F429ZI, K64F, KL46Z, and Odin.
2017-02-23 00:27:23 +00:00
"device_name": "MKL46Z256xxx4",
"bootloader_supported": true
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 17:50:01 +00:00
},
"K20D50M": {
"inherits": ["Target"],
"core": "Cortex-M4",
"extra_labels": ["Freescale", "K20XX"],
"is_disk_virtual": true,
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0230"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "MK20DX128xxx5"
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 17:50:01 +00:00
},
"TEENSY3_1": {
"inherits": ["Target"],
"core": "Cortex-M4",
"extra_labels": ["Freescale", "K20XX", "K20DX256"],
"OUTPUT_EXT": "hex",
"is_disk_virtual": true,
"supported_toolchains": ["GCC_ARM", "ARM"],
"post_binary_hook": {
"function": "TEENSY3_1Code.binary_hook",
"toolchains": ["ARM_STD", "ARM_MICRO", "GCC_ARM"]
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0230"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "MK20DX256xxx7"
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 17:50:01 +00:00
},
Folder re-org to fit new MCU K22F variances This is a simple re-structure of the K22F folder to allow other MCU variances to land here. Created the MCU_K22F512 device but left the 'K22F' as a target for the FRDM-K22F board. Rebased to master
2016-10-25 21:34:18 +00:00
"MCU_K22F512": {
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Rename KSDK2 to MCUXpresso. This is the new name of this package from NXP Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:17:36 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "MCU_K22F", "MCU_K22F512", "FRDM", "KPSDK_MCUS", "KPSDK_CODE"],
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 17:50:01 +00:00
"is_disk_virtual": true,
Incorporating Brian Daniel's review comments for PR 3136
2016-11-01 11:44:27 +00:00
"public": false,
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 17:50:01 +00:00
"macros": ["CPU_MK22FN512VLH12", "FSL_RTOS_MBED"],
"inherits": ["Target"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0231"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "MK22DN512xxx5"
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 17:50:01 +00:00
},
Folder re-org to fit new MCU K22F variances This is a simple re-structure of the K22F folder to allow other MCU variances to land here. Created the MCU_K22F512 device but left the 'K22F' as a target for the FRDM-K22F board. Rebased to master
2016-10-25 21:34:18 +00:00
"K22F": {
Incorporating Brian Daniel's review comments for PR 3136
2016-11-01 11:44:27 +00:00
"supported_form_factors": ["ARDUINO"],
Folder re-org to fit new MCU K22F variances This is a simple re-structure of the K22F folder to allow other MCU variances to land here. Created the MCU_K22F512 device but left the 'K22F' as a target for the FRDM-K22F board. Rebased to master
2016-10-25 21:34:18 +00:00
"inherits": ["MCU_K22F512"],
Incorporating Brian Daniel's review comments for PR 3136
2016-11-01 11:44:27 +00:00
"release_versions": ["2", "5"],
Folder re-org to fit new MCU K22F variances This is a simple re-structure of the K22F folder to allow other MCU variances to land here. Created the MCU_K22F512 device but left the 'K22F' as a target for the FRDM-K22F board. Rebased to master
2016-10-25 21:34:18 +00:00
"extra_labels_add": ["FRDM"]
},
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 17:50:01 +00:00
"KL27Z": {
"inherits": ["Target"],
"core": "Cortex-M0+",
Rename KSDK2 to MCUXpresso. This is the new name of this package from NXP Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:17:36 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM"],
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 17:50:01 +00:00
"macros": ["CPU_MKL27Z64VLH4", "FSL_RTOS_MBED"],
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
"is_disk_virtual": true,
"default_toolchain": "ARM",
"detect_code": ["0261"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "std",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "MKL27Z64xxx4"
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 17:50:01 +00:00
},
Add support for KL43Z using KSDK 2.0 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-05 18:51:07 +00:00
"KL43Z": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Rename KSDK2 to MCUXpresso. This is the new name of this package from NXP Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:17:36 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM"],
Add support for KL43Z using KSDK 2.0 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-05 18:51:07 +00:00
"macros": ["CPU_MKL43Z256VLH4", "FSL_RTOS_MBED"],
"is_disk_virtual": true,
"inherits": ["Target"],
"detect_code": ["0262"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "MKL43Z256xxx4"
Add support for KL43Z using KSDK 2.0 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-05 18:51:07 +00:00
},
Add support for KL82Z FRDM board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-15 20:58:12 +00:00
"KL82Z": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Rename KSDK2 to MCUXpresso. This is the new name of this package from NXP Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:17:36 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM"],
Add support for KL82Z FRDM board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-15 20:58:12 +00:00
"macros": ["CPU_MKL82Z128VLK7", "FSL_RTOS_MBED"],
"is_disk_virtual": true,
"inherits": ["Target"],
"detect_code": ["0218"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
Add support for FRDM-K82F Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-20 17:49:47 +00:00
"release_versions": ["2", "5"],
"device_name": "MKL82Z128xxx7"
Add support for KL82Z FRDM board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-15 20:58:12 +00:00
},
Add USENSE and UBRIDGE targets, and add trng to K82F and KL82Z
2017-03-31 16:37:45 +00:00
"USENSE": {
Use target inheritance for USENSE and UBRIDGE
2017-05-15 14:22:07 +00:00
"inherits": ["KL82Z"],
"extra_labels_remove": ["FRDM"],
"supported_form_factors": []
Add USENSE and UBRIDGE targets, and add trng to K82F and KL82Z
2017-03-31 16:37:45 +00:00
},
Add support for FRDM KW24D Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-10-03 16:23:24 +00:00
"KW24D": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Rename KSDK2 to MCUXpresso. This is the new name of this package from NXP Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:17:36 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM"],
Add support for FRDM KW24D Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-10-03 16:23:24 +00:00
"is_disk_virtual": true,
"macros": ["CPU_MKW24D512VHA5", "FSL_RTOS_MBED"],
"inherits": ["Target"],
"detect_code": ["0250"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG", "FLASH"],
Add support for FRDM-K82F Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-20 17:49:47 +00:00
"release_versions": ["2", "5"],
Add bootloader support for NXP FRDM-KW24D
2017-08-24 02:19:51 +00:00
"device_name": "MKW24D512xxx5",
"bootloader_supported": true
Add support for FRDM KW24D Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-10-03 16:23:24 +00:00
},
Add support for FRDM-KW41 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-11-03 12:06:29 +00:00
"KW41Z": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0+",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Rename KSDK2 to MCUXpresso. This is the new name of this package from NXP Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:17:36 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM"],
Add support for FRDM-KW41 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-11-03 12:06:29 +00:00
"is_disk_virtual": true,
"macros": ["CPU_MKW41Z512VHT4", "FSL_RTOS_MBED"],
"inherits": ["Target"],
"detect_code": ["0201"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "TRNG", "STDIO_MESSAGES"],
Add support for FRDM-KW41 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-11-03 12:06:29 +00:00
"release_versions": ["2", "5"],
"device_name": "MKW41Z512xxx4"
},
[RO359B] platform added
2017-05-11 11:39:45 +00:00
"MCU_K24F1M": {
"core": "Cortex-M4F",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Flash API support using the MCUXpresso drivers Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-03-28 16:50:53 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "MCU_K24F", "KPSDK_MCUS", "KPSDK_CODE"],
[RO359B] platform added
2017-05-11 11:39:45 +00:00
"is_disk_virtual": true,
"public": false,
"macros": ["CPU_MK24FN1M0VDC12", "FSL_RTOS_MBED"],
"inherits": ["Target"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE", "STDIO_MESSAGES", "TRNG", "FLASH"],
[RO359B] platform added
2017-05-11 11:39:45 +00:00
"device_name": "MK24FN1M0xxx12"
},
"RO359B": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_K24F1M"],
"detect_code": ["1022"],
[RO359B] removed itself from extra_labels
2017-05-12 14:19:01 +00:00
"release_versions": ["2", "5"]
[RO359B] platform added
2017-05-11 11:39:45 +00:00
},
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 17:50:01 +00:00
"K64F": {
"supported_form_factors": ["ARDUINO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM", "KPSDK_MCUS", "KPSDK_CODE", "MCU_K64F", "Freescale_EMAC"],
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 17:50:01 +00:00
"is_disk_virtual": true,
Modify mbedtls scripts to add config-no-entropy.h
2016-09-15 13:57:18 +00:00
"macros": ["CPU_MK64FN1M0VMD12", "FSL_RTOS_MBED"],
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 17:50:01 +00:00
"inherits": ["Target"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0240"],
Enable RTC support for K64F board.
2018-03-01 08:25:42 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "CRC", "ANALOGIN", "ANALOGOUT", "EMAC", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE", "STDIO_MESSAGES", "STORAGE", "TRNG", "FLASH"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP", "STORAGE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Fail bootloader builds on targets that don't support it This patch will prevent building bootloader builds on targets that have not yet had their linker scripts/scatter files changed to allow for the ROM space shrinking expected by bootloader builds. At the point of this patch, bootloader linker script modifications are only supported by the NUCLEO_F429ZI, K64F, KL46Z, and Odin.
2017-02-23 00:27:23 +00:00
"device_name": "MK64FN1M0xxx12",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
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 17:50:01 +00:00
},
Added support for ADI EV-COG-AD4050LZ platform.
2017-09-20 04:37:22 +00:00
"EV_COG_AD4050LZ": {
"inherits": ["Target"],
Add ARMC6 feature to EV_COG_AD4050LZ and EV_COG_AD3029LZ
2017-11-21 03:02:34 +00:00
"core": "Cortex-M4F",
Added support for ADI EV-COG-AD4050LZ platform.
2017-09-20 04:37:22 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"macros": ["__ADUCM4050__", "EV_COG_AD4050LZ"],
"extra_labels": ["Analog_Devices", "ADUCM4X50", "ADUCM4050", "EV_COG_AD4050LZ", "FLASH_CMSIS_ALGO"],
Disable FLASH for AD boards as they fail the tests intermittently
2018-05-26 15:46:57 +00:00
"device_has": ["USTICKER", "RTC", "SERIAL", "STDIO_MESSAGES", "TRNG", "SLEEP", "INTERRUPTIN", "SPI", "I2C", "ANALOGIN"],
Added support for ADI EV-COG-AD4050LZ platform.
2017-09-20 04:37:22 +00:00
"device_name": "ADuCM4050",
"detect_code": ["0603"],
ADI: Enable bootloader for EV_COG_AD3029LZ and EV_COG_AD4050LZ
2018-04-20 06:00:20 +00:00
"release_versions": ["5"],
"bootloader_supported": true
Added support for ADI EV-COG-AD4050LZ platform.
2017-09-20 04:37:22 +00:00
},
Added support for ADI EV-COG-AD3029LZ platform. Fixed issues raised from ARM PR review and removed the unsupported platform. - Fixed an issue where the TRNG is read even though it may not be ready; - Added configuration to ensure the buffering mode is disabled so only 8-bit bytes are generated; - Moved the TRNG device handle into the trng_t structure. Removed undefined spi slave related functions. - Added error checking for trng_get_bytes function; - Added curly brackets to single line conditions for some files; - Changed rx and tx buffers in serial module as local variables; - Removed some unused code and some minor formatting corrections; - Minor i2c & spi updates for github pull request; - Added function definition for spi_master_block_write. Added default delay and sample times for the ADC during initialization. - Added code to clear stack variable in trng_get_bytes upon exiting the function; - Remove lp ticker functionality as the timer hardware does not satisfy lp timer requirements. Added a check for the STUCK bit before reading the RNG data register to ensure there are no hardware faults. - Removed .mbedignore to work around some exporter issues; - Added #includes to some of the driver data C files for them to build on their own.
2017-09-19 05:55:12 +00:00
"EV_COG_AD3029LZ": {
"inherits": ["Target"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"macros": ["__ADUCM3029__", "EV_COG_AD3029LZ"],
"extra_labels": ["Analog_Devices", "ADUCM302X", "ADUCM3029", "EV_COG_AD3029LZ", "FLASH_CMSIS_ALGO"],
ADI: Re-enable DEVICE_RTC for EV_COG_AD3029LZ and EV_COG_AD4050LZ
2018-05-18 05:34:41 +00:00
"device_has": ["USTICKER", "RTC", "SERIAL", "STDIO_MESSAGES", "TRNG", "SLEEP", "INTERRUPTIN", "SPI", "I2C", "FLASH", "ANALOGIN"],
Added support for ADI EV-COG-AD3029LZ platform. Fixed issues raised from ARM PR review and removed the unsupported platform. - Fixed an issue where the TRNG is read even though it may not be ready; - Added configuration to ensure the buffering mode is disabled so only 8-bit bytes are generated; - Moved the TRNG device handle into the trng_t structure. Removed undefined spi slave related functions. - Added error checking for trng_get_bytes function; - Added curly brackets to single line conditions for some files; - Changed rx and tx buffers in serial module as local variables; - Removed some unused code and some minor formatting corrections; - Minor i2c & spi updates for github pull request; - Added function definition for spi_master_block_write. Added default delay and sample times for the ADC during initialization. - Added code to clear stack variable in trng_get_bytes upon exiting the function; - Remove lp ticker functionality as the timer hardware does not satisfy lp timer requirements. Added a check for the STUCK bit before reading the RNG data register to ensure there are no hardware faults. - Removed .mbedignore to work around some exporter issues; - Added #includes to some of the driver data C files for them to build on their own.
2017-09-19 05:55:12 +00:00
"device_name": "ADuCM3029",
"detect_code": ["0602"],
ADI: Enable bootloader for EV_COG_AD3029LZ and EV_COG_AD4050LZ
2018-04-20 06:00:20 +00:00
"release_versions": ["5"],
"bootloader_supported": true
Added support for ADI EV-COG-AD3029LZ platform. Fixed issues raised from ARM PR review and removed the unsupported platform. - Fixed an issue where the TRNG is read even though it may not be ready; - Added configuration to ensure the buffering mode is disabled so only 8-bit bytes are generated; - Moved the TRNG device handle into the trng_t structure. Removed undefined spi slave related functions. - Added error checking for trng_get_bytes function; - Added curly brackets to single line conditions for some files; - Changed rx and tx buffers in serial module as local variables; - Removed some unused code and some minor formatting corrections; - Minor i2c & spi updates for github pull request; - Added function definition for spi_master_block_write. Added default delay and sample times for the ADC during initialization. - Added code to clear stack variable in trng_get_bytes upon exiting the function; - Remove lp ticker functionality as the timer hardware does not satisfy lp timer requirements. Added a check for the STUCK bit before reading the RNG data register to ensure there are no hardware faults. - Removed .mbedignore to work around some exporter issues; - Added #includes to some of the driver data C files for them to build on their own.
2017-09-19 05:55:12 +00:00
},
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 17:50:01 +00:00
"MTS_GAMBIT": {
"inherits": ["Target"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "GCC_ARM"],
Flash API support using the MCUXpresso drivers Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-03-28 16:50:53 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "KPSDK_MCUS", "KPSDK_CODE", "MCU_K64F"],
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 17:50:01 +00:00
"is_disk_virtual": true,
"macros": ["CPU_MK64FN1M0VMD12", "FSL_RTOS_MBED", "TARGET_K64F"],
Disable FLASH for AD boards as they fail the tests intermittently
2018-05-26 15:46:57 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "MK64FN1M0xxx12"
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 17:50:01 +00:00
},
"HEXIWEAR": {
"inherits": ["Target"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
Flash API support using the MCUXpresso drivers Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-03-28 16:50:53 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "MCU_K64F"],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"macros": ["CPU_MK64FN1M0VMD12", "FSL_RTOS_MBED", "TARGET_K64F"],
"is_disk_virtual": true,
"default_toolchain": "ARM",
"detect_code": ["0214"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE", "STDIO_MESSAGES", "TRNG", "FLASH"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "std",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
HEXIWEAR: define HEXIWEAR target to support bootloader.
2017-11-03 16:25:02 +00:00
"device_name": "MK64FN1M0xxx12",
"bootloader_supported": true
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 17:50:01 +00:00
},
Add support for FRDM K66 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-09 13:05:48 +00:00
"K66F": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM", "Freescale_EMAC"],
Add support for FRDM K66 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-09 13:05:48 +00:00
"is_disk_virtual": true,
Modify mbedtls scripts to add config-no-entropy.h
2016-09-15 13:57:18 +00:00
"macros": ["CPU_MK66FN2M0VMD18", "FSL_RTOS_MBED"],
Add support for FRDM K66 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-09 13:05:48 +00:00
"inherits": ["Target"],
"detect_code": ["0311"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "EMAC", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG", "FLASH"],
K66F: Enable LWIP feature Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-05 23:01:35 +00:00
"features": ["LWIP"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
add updates for bootloader support to K66F
2017-08-24 18:42:05 +00:00
"device_name": "MK66FN2M0xxx18",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
Add support for FRDM K66 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-09 13:05:48 +00:00
},
Add support for FRDM-K82F Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-20 17:49:47 +00:00
"K82F": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Rename KSDK2 to MCUXpresso. This is the new name of this package from NXP Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:17:36 +00:00
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KSDK2_MCUS", "FRDM"],
Add support for FRDM-K82F Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-20 17:49:47 +00:00
"is_disk_virtual": true,
"macros": ["CPU_MK82FN256VDC15", "FSL_RTOS_MBED"],
"inherits": ["Target"],
"detect_code": ["0217"],
MCUXpresso: Enable RTC support Same MCUXpresso SDK driver used for Kinetis devices Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 13:15:59 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG", "FLASH"],
Add support for FRDM-K82F Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-20 17:49:47 +00:00
"release_versions": ["2", "5"],
Fix formatting in targets/targets.json
2017-03-31 09:47:50 +00:00
"device_name": "MK82FN256xxx15"
Add support for FRDM-K82F Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-09-20 17:49:47 +00:00
},
Add USENSE and UBRIDGE targets, and add trng to K82F and KL82Z
2017-03-31 16:37:45 +00:00
"UBRIDGE": {
Use target inheritance for USENSE and UBRIDGE
2017-05-15 14:22:07 +00:00
"inherits": ["K82F"],
"extra_labels_remove": ["FRDM"],
"supported_form_factors": []
Add USENSE and UBRIDGE targets, and add trng to K82F and KL82Z
2017-03-31 16:37:45 +00:00
},
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"FAMILY_STM32": {
"inherits": ["Target"],
"public": false,
"extra_labels": ["STM"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
#6536 rebase correction
2018-04-23 16:01:33 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2", "LPTICKER_DELAY_TICKS=3"],
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"config": {
"lse_available": {
"help": "Define if a Low Speed External xtal (LSE) is available on the board (0 = No, 1 = Yes). If Yes, the LSE will be used to clock the RTC, LPUART, ... otherwise the Low Speed Internal clock (LSI) will be used",
"value": "1"
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
},
"stdio_uart_tx": {
"help": "default TX STDIO pins is defined in PinNames.h file, but it can be overridden"
},
"stdio_uart_rx": {
"help": "default RX STDIO pins is defined in PinNames.h file, but it can be overridden"
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
}
},
Enable RTC support for FAMILY_STM32.
2018-02-21 12:45:09 +00:00
"device_has": ["USTICKER", "LPTICKER", "RTC", "ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"]
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
},
NXP: Add support for MIMXRT1050_EVK Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2017-12-19 21:18:05 +00:00
"MIMXRT1050_EVK": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M7FD",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"extra_labels": ["NXP", "MCUXpresso_MCUS", "EVK", "MIMXRT1050", "IMX"],
"is_disk_virtual": true,
"macros": ["CPU_MIMXRT1052DVL6A", "FSL_RTOS_MBED"],
"inherits": ["Target"],
"detect_code": ["0227"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2CSLAVE", "ERROR_RED", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
NXP: Add support for MIMXRT1050_EVK Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2017-12-19 21:18:05 +00:00
"release_versions": ["2", "5"],
"device_name": "MIMXRT1052"
},
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"LPC54114": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
"supported_toolchains": ["ARM", "IAR", "GCC_ARM"],
NXP: Add support for MIMXRT1050_EVK Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2017-12-19 21:18:05 +00:00
"extra_labels": ["NXP", "MCUXpresso_MCUS", "LPC54114_M4", "LPCXpresso", "LPC"],
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"is_disk_virtual": true,
"macros": ["CPU_LPC54114J256BD64_cm4", "FSL_RTOS_MBED"],
"inherits": ["Target"],
"detect_code": ["1054"],
MCUXpresso: Enable RTC on LPC54114 and LPC546XX Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 19:55:55 +00:00
"device_has": ["USTICKER", "RTC", "ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "FLASH"],
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"release_versions": ["2", "5"],
"device_name" : "LPC54114J256BD64"
},
LPC546XX: Add support for 220MHz core speed available on LPC54628 Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-02-20 19:31:20 +00:00
"MCU_LPC546XX": {
Add support for LPC54608 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-06-06 14:31:42 +00:00
"core": "Cortex-M4F",
"supported_toolchains": ["ARM", "IAR", "GCC_ARM"],
LPC546XX: Add ENET support Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-04-27 20:14:24 +00:00
"extra_labels": ["NXP", "MCUXpresso_MCUS", "LPCXpresso", "LPC", "LPC546XX", "NXP_EMAC"],
Add support for LPC54608 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-06-06 14:31:42 +00:00
"is_disk_virtual": true,
LPC546XX: Add support for 220MHz core speed available on LPC54628 Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-02-20 19:31:20 +00:00
"macros": ["CPU_LPC54628J512ET180", "FSL_RTOS_MBED"],
Add support for LPC54608 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-06-06 14:31:42 +00:00
"inherits": ["Target"],
MCUXpresso: Enable RTC on LPC54114 and LPC546XX Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
2018-03-26 19:55:55 +00:00
"device_has": ["USTICKER", "RTC", "ANALOGIN", "EMAC", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "FLASH", "TRNG"],
LPC546XX: Add ENET support Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-09-22 16:03:50 +00:00
"features": ["LWIP"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"device_name" : "LPC54628J512ET180",
"overrides": {
"network-default-interface-type": "ETHERNET"
}
Add support for LPC54608 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2017-06-06 14:31:42 +00:00
},
lpc546xx and ff_lpc546xx: create parent object MCU_LPC546XX
2018-01-17 20:32:21 +00:00
"LPC546XX": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_LPC546XX"],
mcu_lpc546xx: move "release_versions" to children
2018-02-28 12:16:01 +00:00
"detect_code": ["1056"],
"release_versions": ["2", "5"]
lpc546xx and ff_lpc546xx: create parent object MCU_LPC546XX
2018-01-17 20:32:21 +00:00
},
add new target L-Tek FF-LPC546XX
2017-10-18 20:14:12 +00:00
"FF_LPC546XX": {
lpc546xx and ff_lpc546xx: create parent object MCU_LPC546XX
2018-01-17 20:32:21 +00:00
"inherits": ["MCU_LPC546XX"],
add new target L-Tek FF-LPC546XX
2017-10-18 20:14:12 +00:00
"extra_labels_remove" : ["LPCXpresso"],
mcu_lpc546xx: move "release_versions" to children
2018-02-28 12:16:01 +00:00
"detect_code": ["8081"],
"release_versions": ["2", "5"]
add new target L-Tek FF-LPC546XX
2017-10-18 20:14:12 +00:00
},
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 17:50:01 +00:00
"NUCLEO_F030R8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F0", "STM32F030R8"],
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0725"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HAL CRC: Add additional STM32 targets
2018-05-15 15:55:06 +00:00
"device_has_add": ["CRC", "SERIAL_FC"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F030R8"
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 17:50:01 +00:00
},
"NUCLEO_F031K6": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F0", "STM32F031K6"],
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0791"],
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
STM32 LOW_POWER_TIMER update : targets.json Move LSI configuration from macro to config part Add missing boards to the LPT supported targets
2017-11-23 14:33:02 +00:00
"macros_add": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HAL CRC: Add additional STM32 targets
2018-05-15 15:55:06 +00:00
"device_has_add": ["CRC", "SERIAL_FC"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F031K6"
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 17:50:01 +00:00
},
"NUCLEO_F042K6": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F0", "STM32F042K6"],
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0785"],
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
STM32 LOW_POWER_TIMER update : targets.json Move LSI configuration from macro to config part Add missing boards to the LPT supported targets
2017-11-23 14:33:02 +00:00
"macros_add": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HAL CRC: Add additional STM32 targets
2018-05-15 15:55:06 +00:00
"device_has_add": ["CAN", "CRC", "SERIAL_FC"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F042K6"
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 17:50:01 +00:00
},
"NUCLEO_F070RB": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F0", "STM32F070RB"],
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0755"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["CRC", "SERIAL_FC", "SERIAL_ASYNCH", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F070RB"
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 17:50:01 +00:00
},
"NUCLEO_F072RB": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F0", "STM32F072RB"],
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0730"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_FC", "SERIAL_ASYNCH", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F072RB"
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 17:50:01 +00:00
},
"NUCLEO_F091RC": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F0", "STM32F091RC"],
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0750"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_FC", "SERIAL_ASYNCH", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F091RC"
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 17:50:01 +00:00
},
"NUCLEO_F103RB": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M3",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F1", "STM32F103RB"],
STM32F1 : json clock source configuration - default value is the same as before patch - system_stm32f1xx.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 (target level)
2017-07-10 09:50:39 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (SYSCLK=72 MHz) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI (SYSCLK=64 MHz)",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F1 : json clock source configuration - default value is the same as before patch - system_stm32f1xx.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 (target level)
2017-07-10 09:50:39 +00:00
"macro_name": "CLOCK_SOURCE"
},
"clock_source_usb": {
"help": "In case of HSI clock source, to get 48 Mhz USB, SYSCLK has to be reduced from 64 to 48 MHz (set 0 for the max SYSCLK value)",
"value": "0",
"macro_name": "CLOCK_SOURCE_USB"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0700"],
STM32F1: Add Flash API support
2017-12-15 09:09:20 +00:00
"device_has_add": ["CAN", "SERIAL_FC", "SERIAL_ASYNCH", "FLASH"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_remove": ["LPTICKER"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F103RB"
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 17:50:01 +00:00
},
Update targets.json to add NUCLEO_F207ZG
2016-07-11 13:25:45 +00:00
"NUCLEO_F207ZG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Update targets.json to add NUCLEO_F207ZG
2016-07-11 13:25:45 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M3",
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F2", "STM32F207ZG", "STM_EMAC"],
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
"config": {
"d11_configuration": {
"help": "Value: PA_7 for the default board configuration, PB_5 in case of solder bridge update (SB121 off/ SB122 on)",
"value": "PA_7",
"macro_name": "STM32_D11_SPI_ETHERNET_PIN"
STM32F2 : json clock source configuration - default value is the same as before patch - system_stm32f2xx.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 (target level)
2017-07-10 10:51:59 +00:00
},
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F2 : json clock source configuration - default value is the same as before patch - system_stm32f2xx.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 (target level)
2017-07-10 10:51:59 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
}
},
Update targets.json to add NUCLEO_F207ZG
2016-07-11 13:25:45 +00:00
"detect_code": ["0835"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USBHOST_OTHER"],
Enabled greentea and mbed-os-example-tls/client/sockets test for STM
2018-02-08 11:32:26 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "EMAC", "SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_remove": ["LPTICKER"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"device_name": "STM32F207ZG",
"overrides": {
"network-default-interface-type": "ETHERNET"
}
Update targets.json to add NUCLEO_F207ZG
2016-07-11 13:25:45 +00:00
},
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 17:50:01 +00:00
"NUCLEO_F302R8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F3", "STM32F302x8", "STM32F302R8"],
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0705"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F302R8"
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 17:50:01 +00:00
},
"NUCLEO_F303K8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F3", "STM32F303x8", "STM32F303K8"],
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0775"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_FC"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F303K8"
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 17:50:01 +00:00
},
"NUCLEO_F303RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F3", "STM32F303xE", "STM32F303RE"],
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0745"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F303RE"
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 17:50:01 +00:00
},
[NUCLEO_F303ZE]Add Hal Target
2016-07-07 15:31:22 +00:00
"NUCLEO_F303ZE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
[NUCLEO_F303ZE]Add Hal Target
2016-07-07 15:31:22 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
[NUCLEO_F303ZE] test / export scripts update
2016-07-07 15:31:22 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F3", "STM32F303xE", "STM32F303ZE"],
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
[NUCLEO_F303ZE] MBED-OS5 capability
2016-09-23 07:24:23 +00:00
"detect_code": ["0747"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "FLASH"],
Additional device names. mbed_targets.md update
2016-09-21 19:36:21 +00:00
"release_versions": ["2", "5"],
Add LOWPOWERTIMER capability for NUCLEO_F303ZE
2016-10-20 13:01:05 +00:00
"device_name": "STM32F303ZE"
[NUCLEO_F303ZE]Add Hal Target
2016-07-07 15:31:22 +00:00
},
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 17:50:01 +00:00
"NUCLEO_F334R8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F3", "STM32F334x8", "STM32F334R8"],
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0735"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F334R8"
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 17:50:01 +00:00
},
"NUCLEO_F401RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F401xE", "STM32F401RE"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0720"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F401RE"
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 17:50:01 +00:00
},
Add support for STEVAL-3DP001V1 board, which has an STM32F401VE chip. This support is based on the NUCLEO-F401RE board. Which has the same amount of flash/ram but less pins available on the chip.
2018-02-14 17:00:01 +00:00
"STEVAL_3DP001V1": {
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32F4", "STM32F401xE", "STM32F401VE"],
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL | USE_PLL_HSI",
"value": "USE_PLL_HSE_XTAL|USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER", "HSE_VALUE=25000000"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
Add support for STEVAL-3DP001V1 board, which has an STM32F401VE chip. This support is based on the NUCLEO-F401RE board. Which has the same amount of flash/ram but less pins available on the chip.
2018-02-14 17:00:01 +00:00
"overrides": {"lse_available": 0},
"release_versions": ["2", "5"],
"device_name": "STM32F401VE"
},
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 17:50:01 +00:00
"NUCLEO_F410RB": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F410RB","STM32F410xB", "STM32F410Rx"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
}
},
NUCLEO_F410RB: Add I2C_ASYNCH capability It has disappeeared with https://github.com/ARMmbed/mbed-os/pull/2765
2016-11-04 13:08:42 +00:00
"detect_code": ["0744"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F410RB"
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 17:50:01 +00:00
},
"NUCLEO_F411RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F411xE", "STM32F411RE"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0740"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
},
"clock_source_usb": {
"help": "As 48 Mhz clock is configured for USB, SYSCLK has to be reduced from 100 to 96 MHz (set 0 for the max SYSCLK value)",
"value": "0",
"macro_name": "CLOCK_SOURCE_USB"
}
},
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Add bootloader support for NUCLEO_F411RE target
2018-04-26 13:19:43 +00:00
"device_name": "STM32F411RE",
"bootloader_supported": true
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 17:50:01 +00:00
},
Add GCC_ARM files and fix errors during GCC build
2016-11-23 17:25:16 +00:00
"NUCLEO_F412ZG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Add GCC_ARM files and fix errors during GCC build
2016-11-23 17:25:16 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F412xG", "STM32F412ZG"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
Add GCC_ARM files and fix errors during GCC build
2016-11-23 17:25:16 +00:00
"detect_code": ["0826"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["CAN", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
Add platform in other python and json files
2016-12-02 14:44:42 +00:00
"release_versions": ["2", "5"],
Add bootloader support
2017-08-03 13:07:14 +00:00
"device_name": "STM32F412ZG",
"bootloader_supported": true
Add GCC_ARM files and fix errors during GCC build
2016-11-23 17:25:16 +00:00
},
Adding MTB MXChip EMW3166 as a new target
2018-01-08 21:07:38 +00:00
"MTB_MXCHIP_EMW3166": {
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32F4", "STM32F412xG", "STM32F412ZG"],
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["CAN", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
Adding MTB MXChip EMW3166 as a new target
2018-01-08 21:07:38 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F412ZG",
"bootloader_supported": true,
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
}
},
Add new target MTB_ADV_WISE_1530. MTB_ADV_WISE_1530 and MTB_USI_WM_BN_BM_22 includes same usi chip, so common USI_WM_BN_BM_22 target has been created. MTB_ADV_WISE_1530 and MTB_USI_WM_BN_BM_22 are inheting the common usi target
2018-04-11 12:50:28 +00:00
"USI_WM_BN_BM_22": {
Adding USI WM-BN-BM-22 as a new target
2018-03-29 15:20:54 +00:00
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32F4", "STM32F412xG", "STM32F412ZG"],
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
"device_has_add": ["SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
"release_versions": ["2", "5"],
"device_name": "STM32F412ZG",
"bootloader_supported": true,
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
Adding MTB MXChip EMW3166 as a new target
2018-01-08 21:07:38 +00:00
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
}
},
Add new target MTB_ADV_WISE_1530. MTB_ADV_WISE_1530 and MTB_USI_WM_BN_BM_22 includes same usi chip, so common USI_WM_BN_BM_22 target has been created. MTB_ADV_WISE_1530 and MTB_USI_WM_BN_BM_22 are inheting the common usi target
2018-04-11 12:50:28 +00:00
"MTB_USI_WM_BN_BM_22": {
"inherits": ["USI_WM_BN_BM_22"]
},
"MTB_ADV_WISE_1530": {
"inherits": ["USI_WM_BN_BM_22"],
"overrides": {
"stdio_uart_tx": "PB_10",
"stdio_uart_rx": "PC_11"
}
},
DISCO_F413ZH: add terget.json, build_travis.py and test.py changes
2017-05-10 12:47:26 +00:00
"DISCO_F413ZH": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
DISCO_F413ZH: add terget.json, build_travis.py and test.py changes
2017-05-10 12:47:26 +00:00
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F413xx", "STM32F413ZH", "STM32F413xH"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
}
},
DISCO_F413ZH: add terget.json, build_travis.py and test.py changes
2017-05-10 12:47:26 +00:00
"detect_code": ["0743"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
DISCO_F413ZH: add terget.json, build_travis.py and test.py changes
2017-05-10 12:47:26 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F413ZH"
},
NUCLEO_F413ZH: Add support for the NUCLEO-F413ZH board Merged from the existing TARGET_DISCO_F413ZH code (which has the same MCU) and TARGET_NUCLEO_F412ZG code (which has the same Nucleo-144 board and pinout).
2017-12-29 14:26:04 +00:00
"NUCLEO_F413ZH": {
"inherits": ["FAMILY_STM32"],
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32F4", "STM32F413xx", "STM32F413ZH", "STM32F413xH"],
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
LPTICKER targets json update for STM32 supporting LPTIMER STM32L0, STM32L4, STM32F7 and few STM32F4
2018-03-27 09:32:33 +00:00
},
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
"value": 1
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
}
},
DISCO_F413ZH: add terget.json, build_travis.py and test.py changes
2017-05-10 12:47:26 +00:00
"detect_code": ["0743"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
DISCO_F413ZH: add terget.json, build_travis.py and test.py changes
2017-05-10 12:47:26 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F413ZH"
},
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 17:50:01 +00:00
"ELMO_F411RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"default_toolchain": "uARM",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F411xE", "STM32F411RE"],
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["----"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"device_has_add": [],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F411RE"
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 17:50:01 +00:00
},
[STM32F4xx][NUCLEO_F429ZI] Add on for NUCLEO_F429ZI export and tests
2016-07-04 13:04:58 +00:00
"NUCLEO_F429ZI": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Add ARDUINO to supported form factors of F429ZI Add support for the arduino form factor in targets.json for the NUCLEO_F429ZI.
2016-08-05 21:01:45 +00:00
"supported_form_factors": ["ARDUINO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
"config": {
"d11_configuration": {
"help": "Value: PA_7 for the default board configuration, PB_5 in case of solder bridge update (SB121 off/ SB122 on)",
"value": "PA_7",
"macro_name": "STM32_D11_SPI_ETHERNET_PIN"
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
},
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
},
"clock_source_usb": {
"help": "As 48 Mhz clock is configured for USB, SYSCLK has to be reduced from 180 to 168 MHz (set 0 for the max SYSCLK value)",
"value": "1",
"macro_name": "CLOCK_SOURCE_USB"
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
}
},
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F4", "STM32F429", "STM32F429ZI", "STM32F429xx", "STM32F429xI", "STM_EMAC"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "EMAC", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
[STM32F4xx][NUCLEO_F429ZI] Add on for NUCLEO_F429ZI export and tests
2016-07-04 13:04:58 +00:00
"detect_code": ["0796"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Fix formatting in targets/targets.json
2017-03-31 09:47:50 +00:00
"device_name": "STM32F429ZI",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
[STM32F4xx][NUCLEO_F429ZI] Add on for NUCLEO_F429ZI export and tests
2016-07-04 13:04:58 +00:00
},
ADD NEW TARGET : NUCLEO_F439ZI, based on existing NUCLEO_F429ZI
2016-10-10 16:31:45 +00:00
"NUCLEO_F439ZI": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
ADD NEW TARGET : NUCLEO_F439ZI, based on existing NUCLEO_F429ZI
2016-10-10 16:31:45 +00:00
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
"config": {
"d11_configuration": {
"help": "Value: PA_7 for the default board configuration, PB_5 in case of solder bridge update (SB121 off/ SB122 on)",
"value": "PA_7",
"macro_name": "STM32_D11_SPI_ETHERNET_PIN"
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
},
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
},
"clock_source_usb": {
"help": "As 48 Mhz clock is configured for USB, SYSCLK has to be reduced from 180 to 168 MHz (set 0 for the max SYSCLK value)",
"value": "1",
"macro_name": "CLOCK_SOURCE_USB"
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
}
},
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F4", "STM32F439", "STM32F439ZI", "STM32F439xx", "STM32F439xI", "STM_EMAC"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["MBEDTLS_CONFIG_HW_SUPPORT", "USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "EMAC", "SERIAL_FC", "TRNG", "FLASH"],
ADD NEW TARGET : NUCLEO_F439ZI, based on existing NUCLEO_F429ZI
2016-10-10 16:31:45 +00:00
"detect_code": ["0797"],
"features": ["LWIP"],
"release_versions": ["2", "5"],
Rebase of: https://github.com/ARMmbed/mbed-os/pull/4081/commits/2d2f0a0b5ce45614c40fff37f33c4ee8eaf7226a Added missing bootloader_supported for NUCLEO_F439ZI
2017-03-30 17:13:18 +00:00
"device_name" : "STM32F439ZI",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
ADD NEW TARGET : NUCLEO_F439ZI, based on existing NUCLEO_F429ZI
2016-10-10 16:31:45 +00:00
},
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 17:50:01 +00:00
"NUCLEO_F446RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F446xE", "STM32F446RE"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0777"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Add bootloaderd support to NUCLEO_F446RE target
2017-09-30 18:07:38 +00:00
"device_name": "STM32F446RE",
"bootloader_supported": true
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 17:50:01 +00:00
},
[NUCLEO_F446ZE] Add HAL target Inspired from NUCLEO_F446RE, only PinNames.h updated according to NUCLEO_F446ZE schematics.
2016-04-27 08:21:36 +00:00
"NUCLEO_F446ZE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
[NUCLEO_F446ZE] Add HAL target Inspired from NUCLEO_F446RE, only PinNames.h updated according to NUCLEO_F446ZE schematics.
2016-04-27 08:21:36 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F446xE", "STM32F446ZE"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
[NUCLEO_F446ZE] Add HAL target Inspired from NUCLEO_F446RE, only PinNames.h updated according to NUCLEO_F446ZE schematics.
2016-04-27 08:21:36 +00:00
"detect_code": ["0778"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Fix formatting in targets/targets.json
2017-03-31 09:47:50 +00:00
"device_name": "STM32F446ZE"
[NUCLEO_F446ZE] Add HAL target Inspired from NUCLEO_F446RE, only PinNames.h updated according to NUCLEO_F446ZE schematics.
2016-04-27 08:21:36 +00:00
},
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 17:50:01 +00:00
"B96B_F446VE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F446xE", "STM32F446VE"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0840"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name":"STM32F446VE"
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 17:50:01 +00:00
},
"NUCLEO_F746ZG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M7F",
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F7", "STM32F746", "STM32F746xG", "STM32F746ZG", "STM_EMAC"],
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
"config": {
"d11_configuration": {
"help": "Value: PA_7 for the default board configuration, PB_5 in case of solder bridge update (SB121 off/ SB122 on)",
"value": "PA_7",
"macro_name": "STM32_D11_SPI_ETHERNET_PIN"
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
},
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
}
},
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USBHOST_OTHER"],
[NUCLEO_F746ZG] Add Arduino Form Factor property
2016-06-29 12:46:19 +00:00
"supported_form_factors": ["ARDUINO"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0816"],
LPTICKER targets json update for STM32 supporting LPTIMER STM32L0, STM32L4, STM32F7 and few STM32F4
2018-03-27 09:32:33 +00:00
"device_has_add": ["LPTICKER", "ANALOGOUT", "CAN", "CRC", "EMAC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
BL NUCLEO_F746ZG: enable bootloader
2017-12-19 15:39:14 +00:00
"device_name": "STM32F746ZG",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
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 17:50:01 +00:00
},
ADD NEW TARGET : NUCLEO_F756ZG, based on existing NUCLEO_F746ZG
2016-10-11 08:47:14 +00:00
"NUCLEO_F756ZG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
ADD NEW TARGET : NUCLEO_F756ZG, based on existing NUCLEO_F746ZG
2016-10-11 08:47:14 +00:00
"core": "Cortex-M7F",
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F7", "STM32F756", "STM32F756xG", "STM32F756ZG", "STM_EMAC"],
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
"config": {
"d11_configuration": {
"help": "Value: PA_7 for the default board configuration, PB_5 in case of solder bridge update (SB121 off/ SB122 on)",
"value": "PA_7",
"macro_name": "STM32_D11_SPI_ETHERNET_PIN"
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
},
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
}
},
Change 'macros' to 'macros_add' for NUCLEO_F756ZG Address PR feedback by renaming 'macros' to 'macros_add'.
2017-07-19 18:09:45 +00:00
"macros_add": ["TRANSACTION_QUEUE_SIZE_SPI=2", "USBHOST_OTHER", "MBEDTLS_CONFIG_HW_SUPPORT"],
ADD NEW TARGET : NUCLEO_F756ZG, based on existing NUCLEO_F746ZG
2016-10-11 08:47:14 +00:00
"supported_form_factors": ["ARDUINO"],
"detect_code": ["0819"],
LPTICKER targets json update for STM32 supporting LPTIMER STM32L0, STM32L4, STM32F7 and few STM32F4
2018-03-27 09:32:33 +00:00
"device_has_add": ["LPTICKER", "ANALOGOUT", "CAN", "CRC", "EMAC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
ADD NEW TARGET : NUCLEO_F756ZG, based on existing NUCLEO_F746ZG
2016-10-11 08:47:14 +00:00
"features": ["LWIP"],
"release_versions": ["2", "5"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"device_name": "STM32F756ZG",
"overrides": {
"network-default-interface-type": "ETHERNET"
}
ADD NEW TARGET : NUCLEO_F756ZG, based on existing NUCLEO_F746ZG
2016-10-11 08:47:14 +00:00
},
fpu with single/double precision - removing redundancy - 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
2016-07-04 19:51:21 +00:00
"NUCLEO_F767ZI": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M7FD",
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F7", "STM32F767", "STM32F767xI", "STM32F767ZI", "STM_EMAC"],
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
"config": {
"d11_configuration": {
"help": "Value: PA_7 for the default board configuration, PB_5 in case of solder bridge update (SB121 off/ SB122 on)",
"value": "PA_7",
"macro_name": "STM32_D11_SPI_ETHERNET_PIN"
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
},
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32 NUCLEO boards with Ethernet connector: solve conflict with D11 arduino pin 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
2017-05-04 12:07:45 +00:00
}
},
Add Arduino form factor for DISCO_F746NG and NUCLEO_F767ZI
2016-10-12 13:33:40 +00:00
"supported_form_factors": ["ARDUINO"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["USBHOST_OTHER"],
fpu with single/double precision - removing redundancy - 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
2016-07-04 19:51:21 +00:00
"detect_code": ["0818"],
LPTICKER targets json update for STM32 supporting LPTIMER STM32L0, STM32L4, STM32F7 and few STM32F4
2018-03-27 09:32:33 +00:00
"device_has_add": ["LPTICKER", "ANALOGOUT", "CAN", "CRC", "EMAC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
NUCLEO_F767ZI: Add bootloader support
2018-01-10 09:01:56 +00:00
"device_name": "STM32F767ZI",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
fpu with single/double precision - removing redundancy - 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
2016-07-04 19:51:21 +00:00
},
[NUCLEO_L011K4] Add to the build and export scripts
2016-06-02 15:41:56 +00:00
"NUCLEO_L011K4": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
[NUCLEO_L011K4] Add to the build and export scripts
2016-06-02 15:41:56 +00:00
"core": "Cortex-M0+",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L0", "STM32L011K4"],
[NUCLEO_L011K4] build issues Target FLASH is quiet small (16KB), so only uARM is supported and very small applications.
2016-08-23 13:06:09 +00:00
"supported_toolchains": ["uARM"],
[NUCLEO_L011K4] Add to the build and export scripts
2016-06-02 15:41:56 +00:00
"default_toolchain": "uARM",
"supported_form_factors": ["ARDUINO"],
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
}
},
[NUCLEO_L011K4] Add to the build and export scripts
2016-06-02 15:41:56 +00:00
"detect_code": ["0780"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["CRC", "SERIAL_FC", "FLASH"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32L011K4"
[NUCLEO_L011K4] Add to the build and export scripts
2016-06-02 15:41:56 +00:00
},
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 17:50:01 +00:00
"NUCLEO_L031K6": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Change NUCLEO_L031K6 to M0+ Change the core type of the NUCLEO_L031K6 from an M0 to an M0+ so NVIC_SetVector works correctly.
2017-06-09 02:16:19 +00:00
"core": "Cortex-M0+",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L0", "STM32L031K6"],
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 17:50:01 +00:00
"default_toolchain": "uARM",
"supported_form_factors": ["ARDUINO"],
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
}
},
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 17:50:01 +00:00
"detect_code": ["0790"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["CRC", "SERIAL_FC", "FLASH"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32L031K6"
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 17:50:01 +00:00
},
"NUCLEO_L053R8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0+",
STM32L053x8: Add STM32L053x8 label in targets.json
2017-08-07 12:44:22 +00:00
"extra_labels_add": ["STM32L0", "STM32L053x8", "STM32L053R8"],
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0715"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_FC", "SERIAL_ASYNCH", "FLASH"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32L053R8"
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 17:50:01 +00:00
},
"NUCLEO_L073RZ": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0+",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L0", "STM32L073RZ", "STM32L073xx"],
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0760"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_FC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32L073RZ"
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 17:50:01 +00:00
},
"NUCLEO_L152RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M3",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L1", "STM32L152RE"],
STM32L1 : json clock source configuration - default value is the same as before patch - system_stm32l1xx.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 (target level)
2017-07-11 12:00:47 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32L1 : json clock source configuration - default value is the same as before patch - system_stm32l1xx.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 (target level)
2017-07-11 12:00:47 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0710"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32L152RE"
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 17:50:01 +00:00
},
[NUCLEO_L432KC] Add to build and export scripts
2016-06-06 08:16:22 +00:00
"NUCLEO_L432KC": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
[NUCLEO_L432KC] Add to build and export scripts
2016-06-06 08:16:22 +00:00
"supported_form_factors": ["ARDUINO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L4", "STM32L432xC", "STM32L432KC"],
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
}
},
[NUCLEO_L432KC] Add to build and export scripts
2016-06-06 08:16:22 +00:00
"detect_code": ["0770"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_FC", "SERIAL_ASYNCH", "CAN", "TRNG", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Enbaled bootloader support for STM32L432KC Added NUCLEO_L433RC_P target
2017-11-27 14:26:00 +00:00
"device_name": "STM32L432KC",
"bootloader_supported": true
},
"NUCLEO_L433RC_P": {
"inherits": ["FAMILY_STM32"],
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32L4", "STM32L433xC", "STM32L433RC"],
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
Enbaled bootloader support for STM32L432KC Added NUCLEO_L433RC_P target
2017-11-27 14:26:00 +00:00
}
},
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"detect_code": ["0779"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_FC", "SERIAL_ASYNCH", "CAN", "TRNG", "FLASH"],
Enbaled bootloader support for STM32L432KC Added NUCLEO_L433RC_P target
2017-11-27 14:26:00 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32L433RC",
"bootloader_supported": true
add support for STM32L443RC & WISE-1510
2018-01-17 12:27:31 +00:00
},
fix device name (an mixed tab/space)
2018-03-27 10:49:12 +00:00
"MTB_ADV_WISE_1510": {
add support for STM32L443RC & WISE-1510
2018-01-17 12:27:31 +00:00
"inherits": ["FAMILY_STM32"],
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32L4", "STM32L443xC", "STM32L443RC"],
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
"overrides": {"lse_available": 0},
"release_versions": ["5"],
HAL CRC: Add additional STM32 targets
2018-05-15 15:55:06 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_FC", "SERIAL_ASYNCH", "CAN", "TRNG", "FLASH"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_remove": ["LPTICKER"],
add support for STM32L443RC & WISE-1510
2018-01-17 12:27:31 +00:00
"macros_add": ["MBEDTLS_CONFIG_HW_SUPPORT"],
"device_name" : "STM32L443RC",
"detect_code": ["0458"],
"bootloader_supported": true
[NUCLEO_L432KC] Add to build and export scripts
2016-06-06 08:16:22 +00:00
},
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 17:50:01 +00:00
"NUCLEO_L476RG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L4", "STM32L476RG", "STM32L476xG"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0765"],
Use the TWO_RAM_REGIONS in targets.json for STM32L475 / STM32L476 and STM32L486 devices
2018-02-22 16:23:08 +00:00
"macros_add": ["USBHOST_OTHER", "TWO_RAM_REGIONS"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Enable bootloader on NUCLEO_L476RG
2017-03-28 20:28:58 +00:00
"device_name": "STM32L476RG",
"bootloader_supported": true
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 17:50:01 +00:00
},
added SILICA_SENSOR_NODE in target.json
2017-09-13 13:48:43 +00:00
"SILICA_SENSOR_NODE": {
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M4F",
"default_toolchain": "GCC_ARM",
"extra_labels_add": ["STM32L4", "STM32L476xG", "STM32L476JG"],
added clock_source for tests
2017-09-13 14:20:54 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
}
},
added SILICA_SENSOR_NODE in target.json
2017-09-13 13:48:43 +00:00
"detect_code": ["0766"],
Use the TWO_RAM_REGIONS in targets.json for STM32L475 / STM32L476 and STM32L486 devices
2018-02-22 16:23:08 +00:00
"macros_add": ["USBHOST_OTHER", "TWO_RAM_REGIONS"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
added SILICA_SENSOR_NODE in target.json
2017-09-13 13:48:43 +00:00
"release_versions": ["5"],
"device_name": "STM32L476JG"
},
ADD NEW TARGET : NUCLEO_L486RG, based on existing NUCLEO_L476RG
2016-10-11 07:45:41 +00:00
"NUCLEO_L486RG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
ADD NEW TARGET : NUCLEO_L486RG, based on existing NUCLEO_L476RG
2016-10-11 07:45:41 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L4", "STM32L486RG", "STM32L486xG"],
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
}
},
ADD NEW TARGET : NUCLEO_L486RG, based on existing NUCLEO_L476RG
2016-10-11 07:45:41 +00:00
"detect_code": ["0827"],
STM32L486: fix two ram region define for GCC ARM Based on the changes for other targets, these 2 were left.
2018-03-13 12:01:20 +00:00
"macros_add": ["USBHOST_OTHER", "MBEDTLS_CONFIG_HW_SUPPORT", "TWO_RAM_REGIONS"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
ADD NEW TARGET : NUCLEO_L486RG, based on existing NUCLEO_L476RG
2016-10-11 07:45:41 +00:00
"release_versions": ["2", "5"],
Fix or remove invalid device names The field device_name is intended to match that of a target in a device family pack. Remove this field for devices which do not have a pack. Fix the name for devices that have the name incorrect. Update IAR definitions for device which no longer have a device_name but still need to have support for the IAR exporter.
2017-01-16 00:42:02 +00:00
"device_name": "STM32L486RG"
ADD NEW TARGET : NUCLEO_L486RG, based on existing NUCLEO_L476RG
2016-10-11 07:45:41 +00:00
},
Add MTB_ADV_WISE_1570 target
2018-02-02 12:21:04 +00:00
"MTB_ADV_WISE_1570": {
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32L4", "STM32L486RG", "STM32L486xG", "WISE_1570"],
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_HSE_XTAL",
"macro_name": "CLOCK_SOURCE"
}
},
"detect_code": ["0460"],
STM32L486: fix two ram region define for GCC ARM Based on the changes for other targets, these 2 were left.
2018-03-13 12:01:20 +00:00
"macros_add": ["MBEDTLS_CONFIG_HW_SUPPORT", "WISE_1570", "TWO_RAM_REGIONS"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_remove": ["LPTICKER"],
Add MTB_ADV_WISE_1570 target
2018-02-02 12:21:04 +00:00
"release_versions": ["5"],
WISE_1570: use hex as output Fixes #6252. Use hex rather than binary - use the hex format validation.
2018-03-13 13:52:11 +00:00
"device_name": "STM32L486RG",
"OUTPUT_EXT": "hex"
Add MTB_ADV_WISE_1570 target
2018-02-02 12:21:04 +00:00
},
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 17:50:01 +00:00
"ARCH_MAX": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM"],
"program_cycle_s": 2,
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F407", "STM32F407xG", "STM32F407VG"],
"device_has_add": ["ANALOGOUT"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F407VG"
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 17:50:01 +00:00
},
"DISCO_F051R8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"core": "Cortex-M0",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F0", "STM32F051", "STM32F051R8"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["GCC_ARM"],
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F0 : json clock source configuration - default value is the same as before patch - system_stm32f0xx.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 (target level)
2017-07-07 13:59:58 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
HAL CRC: Add additional STM32 targets
2018-05-15 15:55:06 +00:00
"device_has_add": ["CRC", "SERIAL_FC"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "STM32F051R8"
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 17:50:01 +00:00
},
"DISCO_F100RB": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"core": "Cortex-M3",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F1", "STM32F100RB"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["GCC_ARM"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"device_has_add": [],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_remove": ["LPTICKER"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "STM32F100RB"
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 17:50:01 +00:00
},
"DISCO_F303VC": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F3", "STM32F303", "STM32F303xC", "STM32F303VC"],
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
DISCO_F303VC : Align clock configuration with STM32 family
2018-02-08 10:12:19 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSI",
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"release_versions": ["2", "5"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_FC"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "STM32F303VC"
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 17:50:01 +00:00
},
"DISCO_F334C8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F3", "STM32F334x8","STM32F334C8"],
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F3 : json clock source configuration - default value is the same as before patch - system_stm32f3xx.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 (target level)
2017-07-10 12:28:47 +00:00
"macro_name": "CLOCK_SOURCE"
}
},
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0810"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_ASYNCH", "SERIAL_FC"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F334C8"
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 17:50:01 +00:00
},
"DISCO_F407VG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F407", "STM32F407xG", "STM32F407VG"],
DISCO_F407VG : alignment with other STM32 - clock source is now a user choice - IAR tool chain is available
2018-01-08 12:24:15 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL | USE_PLL_HSI",
"value": "USE_PLL_HSE_XTAL|USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"macros_add": ["USB_STM_HAL"],
"overrides": {"lse_available": 0},
Unified the LED error pattern for all boards - Removed the patterned LED sequence, all boards now use the 4 fast pulse, 4 slow pulses LED sequence. - Changed the LED used from LED_RED to LED1. Only 58/174 targets seem to define LED_RED but they all define LED1. - Removed all ERROR_RED and ERROR_PATTERN definitions from targets/targets.json
2017-08-16 10:54:19 +00:00
"device_has_add": ["ANALOGOUT"],
DISCO_F407VG : alignment with other STM32 - clock source is now a user choice - IAR tool chain is available
2018-01-08 12:24:15 +00:00
"release_versions": ["2", "5"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "STM32F407VG"
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 17:50:01 +00:00
},
"DISCO_F429ZI": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
Replase CMSIS flash driver by SDK flash driver
2017-03-28 21:39:31 +00:00
"extra_labels_add": ["STM32F4", "STM32F429", "STM32F429ZI", "STM32F429xI", "STM32F429xx"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL | USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"value": "USE_PLL_HSE_XTAL|USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
},
"clock_source_usb": {
"help": "As 48 Mhz clock is configured for USB, SYSCLK has to be reduced from 180 to 168 MHz (set 0 for the max SYSCLK value)",
"value": "1",
"macro_name": "CLOCK_SOURCE_USB"
}
},
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
STM32 LOW_POWER_TIMER update : targets.json Move LSI configuration from macro to config part Add missing boards to the LPT supported targets
2017-11-23 14:33:02 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Unified the LED error pattern for all boards - Removed the patterned LED sequence, all boards now use the 4 fast pulse, 4 slow pulses LED sequence. - Changed the LED used from LED_RED to LED1. Only 58/174 targets seem to define LED_RED but they all define LED1. - Removed all ERROR_RED and ERROR_PATTERN definitions from targets/targets.json
2017-08-16 10:54:19 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Support bootloader for DISCO_F429ZI.
2017-11-30 10:41:41 +00:00
"device_name": "STM32F429ZI",
"bootloader_supported": true
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 17:50:01 +00:00
},
"DISCO_F469NI": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F469", "STM32F469NI", "STM32F469xI", "STM32F469xx"],
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"config": {
"clock_source": {
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL | USE_PLL_HSI",
STM32F4: json clock source configuration - 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
2017-06-22 15:28:01 +00:00
"value": "USE_PLL_HSE_XTAL|USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0788"],
STM32 USBHOST: Add support of DISCO_F469NI and DISCO_F769NI
2017-10-04 09:03:25 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_FC", "TRNG", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F469NI"
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 17:50:01 +00:00
},
"DISCO_L053C8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"core": "Cortex-M0+",
STM32L053x8: Add STM32L053x8 label in targets.json
2017-08-07 12:44:22 +00:00
"extra_labels_add": ["STM32L0", "STM32L053x8", "STM32L053C8"],
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32 : Disable HSE XTAL choice from the default clock source
2017-09-13 12:47:43 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
}
},
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CRC", "SERIAL_FC", "FLASH"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32L053C8"
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 17:50:01 +00:00
},
DISCO_L072CZ_LRWAN1: add LRWAN1 to the name
2017-04-18 14:50:09 +00:00
"DISCO_L072CZ_LRWAN1": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
DISCO_L072CZ: Modifications and verifications to build
2017-04-13 14:39:08 +00:00
"core": "Cortex-M0+",
Move TARGET_DISCO_L072CZ_LRWAN1 folder
2018-02-07 15:23:09 +00:00
"extra_labels_add": ["STM32L0", "STM32L072CZ", "STM32L072xZ", "STM32L072xx"],
DISCO_L072CZ_LRWAN1: targets.json correction
2017-04-25 09:04:34 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"config": {
"clock_source": {
DISCO_L072CZ: add comment in clock_source config
2017-11-13 10:36:22 +00:00
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L0 : json clock source configuration - default value is the same as before patch - system_stm32l0xx.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 (target level)
2017-07-10 15:45:23 +00:00
}
},
DISCO_L072CZ_LRWAN1: targets.json correction
2017-04-25 09:04:34 +00:00
"detect_code": ["0833"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "SERIAL_FC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
DISCO_L072CZ_LRWAN1: targets.json correction
2017-04-25 09:04:34 +00:00
"release_versions": ["2", "5"],
DISCO_L072CZ: Modifications and verifications to build
2017-04-13 14:39:08 +00:00
"device_name": "STM32L072CZ"
},
rename MURATA type ABZ & WISE_1510 to their expected name
2018-02-06 20:18:43 +00:00
"MTB_MURATA_ABZ": {
add support for the murata's module based on STM32L0
2018-01-18 13:51:32 +00:00
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M0+",
"extra_labels_add": ["STM32L0", "STM32L0x2xZ", "STM32L082CZ", "STM32L082xx"],
"detect_code": ["0456"],
"device_has_add": ["ANALOGOUT", "SERIAL_FC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_remove": ["LPTICKER"],
add support for the murata's module based on STM32L0
2018-01-18 13:51:32 +00:00
"release_versions": ["5"],
"device_name": "STM32L082CZ"
},
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 17:50:01 +00:00
"DISCO_F746NG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M7F",
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F7", "STM32F746", "STM32F746xG", "STM32F746NG", "STM_EMAC"],
Add Arduino form factor for DISCO_F746NG and NUCLEO_F767ZI
2016-10-12 13:33:40 +00:00
"supported_form_factors": ["ARDUINO"],
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL | USE_PLL_HSI",
"value": "USE_PLL_HSE_XTAL|USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
DISCO_F746NG: add usp_speed config
2017-11-23 12:17:34 +00:00
},
"usb_speed": {
DISCO_F746NG: typo in config name
2017-11-27 08:46:36 +00:00
"help": "Select the USB speed/connector (0=FullSpeed, 1=HighSpeed)",
DISCO_F746NG: add usp_speed config
2017-11-23 12:17:34 +00:00
"value": "1"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0815"],
STM32 USBHOST: Corrections for DISCO_F746NG
2017-10-31 09:22:51 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
LPTICKER targets json update for STM32 supporting LPTIMER STM32L0, STM32L4, STM32F7 and few STM32F4
2018-03-27 09:32:33 +00:00
"device_has_add": ["LPTICKER", "ANALOGOUT", "CAN", "EMAC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"device_name": "STM32F746NG",
"overrides": {
"network-default-interface-type": "ETHERNET"
}
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 17:50:01 +00:00
},
[disco_f769ni] adding target
2016-08-20 18:14:32 +00:00
"DISCO_F769NI": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
[disco_f769ni] adding target
2016-08-20 18:14:32 +00:00
"core": "Cortex-M7FD",
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F7", "STM32F769", "STM32F769xI", "STM32F769NI", "STM_EMAC"],
DISCO_F769NI: targets update - correct clock for USB - add ARM micro support - add OS5 release support - add TRNG support - add ARDUINO form factor support
2017-01-12 14:36:30 +00:00
"supported_form_factors": ["ARDUINO"],
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL | USE_PLL_HSI",
DISCO_F769NI: set clock_source to USE_PLL_HSE_EXTC
2018-04-09 08:17:42 +00:00
"value": "USE_PLL_HSE_EXTC|USE_PLL_HSI",
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32F7 : json clock source configuration - default value is the same as before patch - system_stm32f7xx.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 (target level)
2017-07-10 14:59:39 +00:00
}
},
[disco_f769ni] adding target
2016-08-20 18:14:32 +00:00
"detect_code": ["0817"],
STM32 USBHOST: Corrections for DISCO_F769NI in targets.json
2017-10-31 08:48:42 +00:00
"macros_add": ["USB_STM_HAL", "USBHOST_OTHER"],
LPTICKER targets json update for STM32 supporting LPTIMER STM32L0, STM32L4, STM32F7 and few STM32F4
2018-03-27 09:32:33 +00:00
"device_has_add": ["LPTICKER", "ANALOGOUT", "CAN", "EMAC", "SERIAL_ASYNCH", "TRNG", "FLASH"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
DISCO_F769NI: targets update - correct clock for USB - add ARM micro support - add OS5 release support - add TRNG support - add ARDUINO form factor support
2017-01-12 14:36:30 +00:00
"release_versions": ["2", "5"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"device_name": "STM32F769NI",
"overrides": {
"network-default-interface-type": "ETHERNET"
}
[disco_f769ni] adding target
2016-08-20 18:14:32 +00:00
},
Add "01A" suffix in target name
2017-01-27 13:49:10 +00:00
"DISCO_L475VG_IOT01A": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Add DISCO_L475VG_IOT in targets.json
2017-01-25 14:49:44 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L4", "STM32L475xG", "STM32L475VG"],
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
}
},
DISCO_L475VG_IOT: Add ARDUINO in "supported_form_factor"
2017-01-27 13:26:27 +00:00
"supported_form_factors": ["ARDUINO"],
Add DISCO_L475VG_IOT in targets.json
2017-01-25 14:49:44 +00:00
"detect_code": ["0764"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"macros_add": ["USBHOST_OTHER"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_FC", "TRNG", "FLASH"],
Add DISCO_L475VG_IOT in targets.json
2017-01-25 14:49:44 +00:00
"release_versions": ["2", "5"],
Add mbed-cloud-client support on DISCO_L475VG_IOT01A with wifi_esp8266_v4.json.
2017-11-02 20:15:38 +00:00
"device_name": "STM32L475VG",
"bootloader_supported": true
Add DISCO_L475VG_IOT in targets.json
2017-01-25 14:49:44 +00:00
},
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 17:50:01 +00:00
"DISCO_L476VG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L4", "STM32L476xG", "STM32L476VG"],
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
STM32L4 : json clock source configuration - default value is the same as before patch - system_stm32l4xx.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 (target level) - nvic_addr.h file is now in TARGET_STM level
2017-07-11 12:58:53 +00:00
}
},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["0820"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"macros_add": ["USBHOST_OTHER"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "SERIAL_FC", "TRNG", "FLASH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
Fix a parse error at targets/targets.json.
2017-08-31 02:18:31 +00:00
"device_name": "STM32L476VG",
Add bootloader support configuration for DISCO_L476VG.
2017-08-29 10:01:25 +00:00
"bootloader_supported": true
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 17:50:01 +00:00
},
"MTS_MDOT_F405RG": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F405RG"],
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 17:50:01 +00:00
"is_disk_virtual": true,
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"macros_add": ["HSE_VALUE=26000000"],
"device_has_add": ["ANALOGOUT"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32F405RG"
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 17:50:01 +00:00
},
"MTS_MDOT_F411RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F411RE"],
"macros_add": ["HSE_VALUE=26000000", "USE_PLL_HSE_EXTC=0", "VECT_TAB_OFFSET=0x00010000"],
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 17:50:01 +00:00
"post_binary_hook": {
"function": "MTSCode.combine_bins_mts_dot",
Add IAR to post_binary_hook toolchains so the boot loader is pre-pended to the binary file when using the IAR compiler.
2017-05-22 18:38:02 +00:00
"toolchains": ["GCC_ARM", "ARM_STD", "ARM_MICRO", "IAR"]
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 17:50:01 +00:00
},
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"device_has_add": [],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F411RE"
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 17:50:01 +00:00
},
"MTS_DRAGONFLY_F411RE": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F411RE"],
Major Refactoring & extensions 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.
2017-05-23 17:07:24 +00:00
"config": {
"modem_is_on_board": {
"help": "Value: Tells the build system that the modem is on-board as oppose to a plug-in shield/module.",
"value": 1,
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"macro_name": "MODEM_ON_BOARD"
Major Refactoring & extensions 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.
2017-05-23 17:07:24 +00:00
},
"modem_data_connection_type": {
"help": "Value: Defines how an on-board modem is wired up to the MCU, e.g., data connection can be a UART or USB and so forth.",
"value": 1,
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"macro_name": "MODEM_ON_BOARD_UART"
Major Refactoring & extensions 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.
2017-05-23 17:07:24 +00:00
}
},
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
"macros_add": ["HSE_VALUE=26000000", "VECT_TAB_OFFSET=0x08010000"],
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"post_binary_hook": {
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 17:50:01 +00:00
"function": "MTSCode.combine_bins_mts_dragonfly",
Add IAR to post_binary_hook toolchains so the boot loader is pre-pended to the binary file when using the IAR compiler.
2017-05-22 18:38:02 +00:00
"toolchains": ["GCC_ARM", "ARM_STD", "ARM_MICRO", "IAR"]
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 17:50:01 +00:00
},
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"device_has_add": [],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F411RE"
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 17:50:01 +00:00
},
Adding MTB MTS_Dragonfly as a new target
2018-01-18 17:08:59 +00:00
"MTB_MTS_DRAGONFLY": {
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32F4", "STM32F411RE"],
"config": {
"modem_is_on_board": {
"help": "Value: Tells the build system that the modem is on-board as oppose to a plug-in shield/module.",
"value": 1,
"macro_name": "MODEM_ON_BOARD"
},
"modem_data_connection_type": {
"help": "Value: Defines how an on-board modem is wired up to the MCU, e.g., data connection can be a UART or USB and so forth.",
"value": 1,
"macro_name": "MODEM_ON_BOARD_UART"
MTB_XX : STDIO configuration Here is a proposition - to align with other STM32 - and to remove compilation warnings : [Warning] PeripheralNames.h@38,0: "STDIO_UART" redefined
2018-01-25 14:46:36 +00:00
}
Adding MTB MTS_Dragonfly as a new target
2018-01-18 17:08:59 +00:00
},
"overrides": {
"lse_available": 0
},
"macros_add": ["HSE_VALUE=26000000", "VECT_TAB_OFFSET=0x08010000"],
"post_binary_hook": {
"function": "MTSCode.combine_bins_mtb_mts_dragonfly",
"toolchains": ["GCC_ARM", "ARM_STD", "ARM_MICRO", "IAR"]
},
"release_versions": ["2", "5"],
"device_name": "STM32F411RE",
"bootloader_supported": true
},
rebase support for MultiTech xDot platform [XDOT_L151] copy new target CMSIS files from NZ32_SC151 target [XDOT_L151] remove Modtronix code, add HardFault_Handler, update clock configuration to match xDot hardware [XDOT_L151] copy new target HAL files from NZ32_SC151 target [XDOT_L151] update HAL to match xDot hardware [XDOT_L151] add xdot_eeprom.* and xdot_low_power.* files [XDOT_L151] add RTOS support for target Conflicts: rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c [XDOT_L151] match NUCLEO_L152RE startup code for GCC_ARM so RTOS works [XDOT_L151] fix GPIO write failure [XDOT_L151] add XDOT_L151CC target to targets.json [XDOT_L151] change xDot default stack size to 256 bytes and main stack size to 1.5kB [XDOT_L151] update PinNames.h to match rev E hardware - no change to external pinout [XDOT_L151] update style in custom xDot HAL files Conflicts: rtos/rtx/TARGET_CORTEX_M/RTX_CM_lib.h rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c
2016-08-31 17:36:32 +00:00
"XDOT_L151CC": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
rebase support for MultiTech xDot platform [XDOT_L151] copy new target CMSIS files from NZ32_SC151 target [XDOT_L151] remove Modtronix code, add HardFault_Handler, update clock configuration to match xDot hardware [XDOT_L151] copy new target HAL files from NZ32_SC151 target [XDOT_L151] update HAL to match xDot hardware [XDOT_L151] add xdot_eeprom.* and xdot_low_power.* files [XDOT_L151] add RTOS support for target Conflicts: rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c [XDOT_L151] match NUCLEO_L152RE startup code for GCC_ARM so RTOS works [XDOT_L151] fix GPIO write failure [XDOT_L151] add XDOT_L151CC target to targets.json [XDOT_L151] change xDot default stack size to 256 bytes and main stack size to 1.5kB [XDOT_L151] update PinNames.h to match rev E hardware - no change to external pinout [XDOT_L151] update style in custom xDot HAL files Conflicts: rtos/rtx/TARGET_CORTEX_M/RTX_CM_lib.h rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c
2016-08-31 17:36:32 +00:00
"core": "Cortex-M3",
"default_toolchain": "ARM",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L1", "STM32L151CC"],
xdot: fix target clock config in targets.json Resolves #4876
2017-08-16 20:12:23 +00:00
"config": {
"hse_value": {
"value": "24000000",
"macro_name": "HSE_VALUE"
}
},
[XDOT_L151] add IAR support
2016-09-27 21:09:15 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
initial commit of xDot bootloader
2017-06-11 21:37:22 +00:00
"device_has_add": ["ANALOGOUT", "FLASH"],
fixed missing device_name for xDot and removed progen
2017-04-25 19:23:42 +00:00
"release_versions": ["5"],
initial commit of xDot bootloader
2017-06-11 21:37:22 +00:00
"device_name": "STM32L151CC",
"bootloader_supported": true
rebase support for MultiTech xDot platform [XDOT_L151] copy new target CMSIS files from NZ32_SC151 target [XDOT_L151] remove Modtronix code, add HardFault_Handler, update clock configuration to match xDot hardware [XDOT_L151] copy new target HAL files from NZ32_SC151 target [XDOT_L151] update HAL to match xDot hardware [XDOT_L151] add xdot_eeprom.* and xdot_low_power.* files [XDOT_L151] add RTOS support for target Conflicts: rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c [XDOT_L151] match NUCLEO_L152RE startup code for GCC_ARM so RTOS works [XDOT_L151] fix GPIO write failure [XDOT_L151] add XDOT_L151CC target to targets.json [XDOT_L151] change xDot default stack size to 256 bytes and main stack size to 1.5kB [XDOT_L151] update PinNames.h to match rev E hardware - no change to external pinout [XDOT_L151] update style in custom xDot HAL files Conflicts: rtos/rtx/TARGET_CORTEX_M/RTX_CM_lib.h rtos/rtx/TARGET_CORTEX_M/RTX_Conf_CM.c
2016-08-31 17:36:32 +00:00
},
new target added L-TEK FF1705 based on XDOT
2017-08-24 17:24:02 +00:00
"FF1705_L151CC": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["XDOT_L151CC"],
extra label deleted
2017-08-30 06:16:08 +00:00
"detect_code": ["8080"]
new target added L-TEK FF1705 based on XDOT
2017-08-24 17:24:02 +00:00
},
Adding MTB_MTS_XDOT as a new target
2018-01-30 17:48:45 +00:00
"MTB_MTS_XDOT": {
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M3",
"default_toolchain": "ARM",
"extra_labels_add": ["STM32L1", "STM32L151CC"],
"config": {
"hse_value": {
"value": "24000000",
"macro_name": "HSE_VALUE"
}
},
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
"overrides": {
"stdio_uart_tx": "PA_2",
"stdio_uart_rx": "PA_3"
},
Adding MTB_MTS_XDOT as a new target
2018-01-30 17:48:45 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"device_has_add": ["ANALOGOUT", "FLASH"],
"release_versions": ["5"],
"device_name": "STM32L151CC",
"bootloader_supported": true
},
add support for the RAK811
2018-02-08 17:42:13 +00:00
"MTB_RAK811": {
"inherits": ["FAMILY_STM32"],
"core": "Cortex-M3",
"default_toolchain": "ARM",
switch to stm32l151cb-a & work around flash size field width.
2018-03-26 17:00:18 +00:00
"extra_labels_add": ["STM32L1", "STM32L151xBA", "STM32L151CBA"],
add IAR to the supported toolchain
2018-03-27 16:55:09 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
switch to stm32l151cb-a & work around flash size field width.
2018-03-26 17:00:18 +00:00
"device_has_add": ["ANALOGOUT"],
add support for the RAK811
2018-02-08 17:42:13 +00:00
"release_versions": ["5"],
fix device name (an mixed tab/space)
2018-03-27 10:49:12 +00:00
"device_name": "STM32L151CBxxA",
add support for the RAK811
2018-02-08 17:42:13 +00:00
"bootloader_supported": true
},
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 17:50:01 +00:00
"MOTE_L152RC": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"core": "Cortex-M3",
"default_toolchain": "uARM",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L1", "STM32L152RC"],
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"detect_code": ["4100"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"device_has_add": ["ANALOGOUT"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "STM32L152RC"
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 17:50:01 +00:00
},
"DISCO_F401VC": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"default_toolchain": "GCC_ARM",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F4", "STM32F401", "STM32F401xC", "STM32F401VC"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"supported_toolchains": ["GCC_ARM"],
Unified the LED error pattern for all boards - Removed the patterned LED sequence, all boards now use the 4 fast pulse, 4 slow pulses LED sequence. - Changed the LED used from LED_RED to LED1. Only 58/174 targets seem to define LED_RED but they all define LED1. - Removed all ERROR_RED and ERROR_PATTERN definitions from targets/targets.json
2017-08-16 10:54:19 +00:00
"device_has_add": [],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "STM32F401VC"
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 17:50:01 +00:00
},
introduced mbed Connect Cloud board based on ODIN-W2 Module rety commit, added ublox changes Corrected error Corrected error in targets json Reworked JSON Added lwip-eth to Connect ODIN removes ARM CC error Fixed formating issues Correct formating error in .json Indentation errors
2017-10-12 10:21:20 +00:00
"MODULE_UBLOX_ODIN_W2": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F4", "STM32F439", "STM32F439ZI","STM32F439xx", "STM32F439xI", "STM_EMAC"],
EMAC adaption added, updated ODIN drivers to v2.5.0 RC1
2018-05-15 13:22:51 +00:00
"macros": ["MBEDTLS_CONFIG_HW_SUPPORT", "HSE_VALUE=24000000", "HSE_STARTUP_TIMEOUT=5000", "CB_INTERFACE_SDIO","CB_CHIP_WL18XX","SUPPORT_80211D_ALWAYS","WLAN_ENABLED","CB_FEATURE_802DOT11W","CB_FEATURE_802DOT11R","MBEDTLS_ARC4_C","MBEDTLS_DES_C","MBEDTLS_MD4_C","MBEDTLS_MD5_C","MBEDTLS_SHA1_C"],
"device_has_add": ["CAN", "EMAC", "TRNG", "FLASH", "WIFI"],
Fix target definition for Odin boards
2018-05-25 03:47:42 +00:00
"device_has_remove": [],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
Fail bootloader builds on targets that don't support it This patch will prevent building bootloader builds on targets that have not yet had their linker scripts/scatter files changed to allow for the ROM space shrinking expected by bootloader builds. At the point of this patch, bootloader linker script modifications are only supported by the NUCLEO_F429ZI, K64F, KL46Z, and Odin.
2017-02-23 00:27:23 +00:00
"device_name": "STM32F439ZI",
replace tab with spaces
2018-04-09 20:18:56 +00:00
"public": false,
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "WIFI"
}
introduced mbed Connect Cloud board based on ODIN-W2 Module rety commit, added ublox changes Corrected error Corrected error in targets json Reworked JSON Added lwip-eth to Connect ODIN removes ARM CC error Fixed formating issues Correct formating error in .json Indentation errors
2017-10-12 10:21:20 +00:00
},
"UBLOX_EVK_ODIN_W2": {
"inherits": ["MODULE_UBLOX_ODIN_W2"],
"supported_form_factors": ["ARDUINO"],
"release_versions": ["5"],
Fix target definition for Odin boards
2018-05-25 03:47:42 +00:00
"device_has_remove": [],
Moved STDIO_UART defines to targets.json for UBLOX_EVK_ODIN_W2 instead of hardcoded.
2017-09-25 14:47:38 +00:00
"config": {
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
"stdio_uart_tx_help": {
"help": "Value: D8(default) or D1"
Moved STDIO_UART defines to targets.json for UBLOX_EVK_ODIN_W2 instead of hardcoded.
2017-09-25 14:47:38 +00:00
},
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
"stdio_uart_rx_help": {
"help": "Value: D2(default) or D0"
Moved STDIO_UART defines to targets.json for UBLOX_EVK_ODIN_W2 instead of hardcoded.
2017-09-25 14:47:38 +00:00
}
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
},
"overrides": {
"stdio_uart_tx": "D8",
"stdio_uart_rx": "D2"
Moved STDIO_UART defines to targets.json for UBLOX_EVK_ODIN_W2 instead of hardcoded.
2017-09-25 14:47:38 +00:00
}
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 17:50:01 +00:00
},
introduced mbed Connect Cloud board based on ODIN-W2 Module rety commit, added ublox changes Corrected error Corrected error in targets json Reworked JSON Added lwip-eth to Connect ODIN removes ARM CC error Fixed formating issues Correct formating error in .json Indentation errors
2017-10-12 10:21:20 +00:00
"MBED_CONNECT_ODIN": {
"inherits": ["MODULE_UBLOX_ODIN_W2"],
"release_versions": ["5"],
"config": {
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
"stdio_uart_tx_help": {
"help": "Value: PA_9(default) or PD_8"
introduced mbed Connect Cloud board based on ODIN-W2 Module rety commit, added ublox changes Corrected error Corrected error in targets json Reworked JSON Added lwip-eth to Connect ODIN removes ARM CC error Fixed formating issues Correct formating error in .json Indentation errors
2017-10-12 10:21:20 +00:00
},
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
"stdio_uart_rx_help": {
"help": "Value: PA_10(default) or PD_9"
introduced mbed Connect Cloud board based on ODIN-W2 Module rety commit, added ublox changes Corrected error Corrected error in targets json Reworked JSON Added lwip-eth to Connect ODIN removes ARM CC error Fixed formating issues Correct formating error in .json Indentation errors
2017-10-12 10:21:20 +00:00
}
STM32 STDIO pin redefinition wiki page https://os.mbed.com/teams/ST/wiki/STDIO updated
2018-02-08 13:15:39 +00:00
},
"overrides": {
"stdio_uart_tx": "PA_9",
"stdio_uart_rx": "PA_10"
introduced mbed Connect Cloud board based on ODIN-W2 Module rety commit, added ublox changes Corrected error Corrected error in targets json Reworked JSON Added lwip-eth to Connect ODIN removes ARM CC error Fixed formating issues Correct formating error in .json Indentation errors
2017-10-12 10:21:20 +00:00
}
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 17:50:01 +00:00
},
Adding MTB ublox ODIN W2
2017-12-20 18:52:04 +00:00
"MTB_UBLOX_ODIN_W2": {
"inherits": ["MODULE_UBLOX_ODIN_W2"],
Fix target definition for Odin boards
2018-05-25 03:47:42 +00:00
"device_has_add": [],
STM32F4: STDIO_UART_TX and STDIO_UART_RX can be now user defined NB for UBLOX targets: usb_rx and usb_tx config name are still available in order to not break current applications.
2017-12-07 10:56:49 +00:00
"release_versions": ["5"]
Adding MTB ublox ODIN W2
2017-12-20 18:52:04 +00:00
},
Introducing UBLOX_C030 platform.
2017-03-22 18:10:39 +00:00
"UBLOX_C030": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Introducing UBLOX_C030 platform.
2017-03-22 18:10:39 +00:00
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M4F",
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Add extra labels for Freescale & STM EMAC drivers Just checking "does the chip have an EMAC" doesn't work - there are targets using those chips which do not have an Ethernet connector and don't provide the necessary surrounding infrastructure (eg DISCO_F429ZI, not providing the board emac config call, and HEXIWEAR not providing PHY info). Make the targets that actually do want EMAC define their own local Freescale_EMAC and STM_EMAC labels, and move the drivers into the corresponding TARGET_ directories, removing the #ifdefs.
2018-03-05 13:40:10 +00:00
"extra_labels_add": ["STM32F4", "STM32F437", "STM32F437VG", "STM32F437xx", "STM32F437xG", "STM_EMAC"],
Platform support for OnboardCellular modem and u-blox cellular interface drivers. This change allows the u-blox C027 and C030 boards to use both the mbed-os OnboardCellular modem driver and the u-blox cellular interface drivers (which support both PPP and AT data modes).
2017-06-15 13:32:09 +00:00
"config": {
"modem_is_on_board": {
"help": "Value: Tells the build system that the modem is on-board as oppose to a plug-in shield/module.",
"value": 1,
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"macro_name": "MODEM_ON_BOARD"
Platform support for OnboardCellular modem and u-blox cellular interface drivers. This change allows the u-blox C027 and C030 boards to use both the mbed-os OnboardCellular modem driver and the u-blox cellular interface drivers (which support both PPP and AT data modes).
2017-06-15 13:32:09 +00:00
},
"modem_data_connection_type": {
"help": "Value: Defines how the modem is wired up to the MCU, e.g., data connection can be a UART or USB and so forth.",
"value": 1,
Add mbed support for LPCXpresso54114 board Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-12-15 21:02:00 +00:00
"macro_name": "MODEM_ON_BOARD_UART"
Platform support for OnboardCellular modem and u-blox cellular interface drivers. This change allows the u-blox C027 and C030 boards to use both the mbed-os OnboardCellular modem driver and the u-blox cellular interface drivers (which support both PPP and AT data modes).
2017-06-15 13:32:09 +00:00
}
},
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"macros_add": ["MBEDTLS_CONFIG_HW_SUPPORT", "HSE_VALUE=12000000", "GNSSBAUD=9600"],
"overrides": {"lse_available": 0},
Enabled greentea and mbed-os-example-tls/client/sockets test for STM
2018-02-08 11:32:26 +00:00
"device_has_add": ["ANALOGOUT", "EMAC", "SERIAL_FC", "TRNG", "FLASH"],
U-BLOX_C030: Default XTAL is now 12MHz onboard. Option to use Debug 8MHz XTAL by using Macro USE_DEBUG_8MHz_XTAL
2017-03-07 18:12:33 +00:00
"features": ["LWIP"],
[UBLOX_C030] make the UBLOX_C030 target private and introduce UBLOX_C030_U201 and UBLOX_C030_N211 for the two versions of the board (for the Sara U201 module and Sara N211 module respectively). These targets then inherit the UBLOX_C030 "base" target. The two targets are the same right now but will diverge when the cellular API is introduced.
2017-04-12 15:56:36 +00:00
"public": false,
Add bootloader support for the UBLOX_C030 platforms.
2017-06-30 08:52:07 +00:00
"device_name": "STM32F437VG",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
[UBLOX_C030] make the UBLOX_C030 target private and introduce UBLOX_C030_U201 and UBLOX_C030_N211 for the two versions of the board (for the Sara U201 module and Sara N211 module respectively). These targets then inherit the UBLOX_C030 "base" target. The two targets are the same right now but will diverge when the cellular API is introduced.
2017-04-12 15:56:36 +00:00
},
"UBLOX_C030_U201": {
"inherits": ["UBLOX_C030"],
"release_versions": ["5"]
},
"UBLOX_C030_N211": {
"inherits": ["UBLOX_C030"],
"release_versions": ["5"]
},
Support added for R410M Changes target added r410m Spaces removed Trace updated
2018-01-26 12:25:05 +00:00
"UBLOX_C030_R410M": {
"inherits": ["UBLOX_C030"],
"release_versions": ["5"]
},
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 17:50:01 +00:00
"NZ32_SC151": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
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 17:50:01 +00:00
"core": "Cortex-M3",
"default_toolchain": "uARM",
"program_cycle_s": 1.5,
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32L1", "STM32L151RC"],
STM32: RTC_LSI macro is replaced by lse_available config
2017-12-04 13:00:30 +00:00
"overrides": {"lse_available": 0},
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 17:50:01 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"device_has_add": ["ANALOGOUT"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"default_lib": "small",
"device_name": "STM32L151RC"
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 17:50:01 +00:00
},
"MCU_NRF51": {
"inherits": ["Target"],
"core": "Cortex-M0",
"OVERRIDE_BOOTLOADER_FILENAME": "nrf51822_bootloader.hex",
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["NRF51", "TARGET_NRF51822", "CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
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 17:50:01 +00:00
"MERGE_BOOTLOADER": false,
"extra_labels": ["NORDIC", "MCU_NRF51", "MCU_NRF51822"],
"OUTPUT_EXT": "hex",
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "GCC_ARM"],
"public": false,
"MERGE_SOFT_DEVICE": true,
"EXPECTED_SOFTDEVICES_WITH_OFFSETS": [
{
"boot": "s130_nrf51_1.0.0_bootloader.hex",
"name": "s130_nrf51_1.0.0_softdevice.hex",
"offset": 114688
},
{
"boot": "s110_nrf51822_8.0.0_bootloader.hex",
"name": "s110_nrf51822_8.0.0_softdevice.hex",
"offset": 98304
},
{
"boot": "s110_nrf51822_7.1.0_bootloader.hex",
"name": "s110_nrf51822_7.1.0_softdevice.hex",
"offset": 90112
},
{
"boot": "s110_nrf51822_7.0.0_bootloader.hex",
"name": "s110_nrf51822_7.0.0_softdevice.hex",
"offset": 90112
},
{
"boot": "s110_nrf51822_6.0.0_bootloader.hex",
"name": "s110_nrf51822_6.0.0_softdevice.hex",
"offset": 81920
}
],
"detect_code": ["1070"],
"post_binary_hook": {
"function": "MCU_NRF51Code.binary_hook",
"toolchains": ["ARM_STD", "GCC_ARM"]
},
Use nano lib by default for nrf51 based targets.
2016-06-27 13:33:01 +00:00
"program_cycle_s": 6,
Add device_has to all nrf51 devices Move common device_has attributes into MCU_NRF51 and MCU_NRF51_UNIFIED. This ensures all nrf51 devices have the correct features enabled. Any devices that want to explicitly disable features should use device_has_remove.
2016-09-13 17:57:37 +00:00
"features": ["BLE"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"]
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 17:50:01 +00:00
},
"MCU_NRF51_16K_BASE": {
"inherits": ["MCU_NRF51"],
"extra_labels_add": ["MCU_NORDIC_16K", "MCU_NRF51_16K"],
"macros_add": ["TARGET_MCU_NORDIC_16K", "TARGET_MCU_NRF51_16K"],
Change default_build from small to standard on NRF based targets with at least 32K of RAM. NRF targets with 16K keep their default_build configuration set to small.
2016-07-27 22:42:19 +00:00
"public": false,
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small"
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 17:50:01 +00:00
},
"MCU_NRF51_16K_BOOT_BASE": {
"inherits": ["MCU_NRF51_16K_BASE"],
"MERGE_BOOTLOADER": true,
"extra_labels_add": ["MCU_NRF51_16K_BOOT"],
"macros_add": ["TARGET_MCU_NRF51_16K_BOOT", "TARGET_OTA_ENABLED"],
"public": false
},
"MCU_NRF51_16K_OTA_BASE": {
"inherits": ["MCU_NRF51_16K_BASE"],
"public": false,
"extra_labels_add": ["MCU_NRF51_16K_OTA"],
"macros_add": ["TARGET_MCU_NRF51_16K_OTA", "TARGET_OTA_ENABLED"],
"MERGE_SOFT_DEVICE": false
},
"MCU_NRF51_16K": {
"inherits": ["MCU_NRF51_16K_BASE"],
"extra_labels_add": ["MCU_NRF51_16K_S130"],
"macros_add": ["TARGET_MCU_NRF51_16K_S130"],
"public": false
},
"MCU_NRF51_S110": {
"extra_labels_add": ["MCU_NRF51_16K_S110"],
"macros_add": ["TARGET_MCU_NRF51_16K_S110"],
"EXPECTED_SOFTDEVICES_WITH_OFFSETS": [
{
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"name": "s110_nrf51822_8.0.0_softdevice.hex",
"boot": "s110_nrf51822_8.0.0_bootloader.hex",
"offset": 98304
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 17:50:01 +00:00
},
{
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"name": "s110_nrf51822_7.1.0_softdevice.hex",
"boot": "s110_nrf51822_7.1.0_bootloader.hex",
"offset": 90112
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 17:50:01 +00:00
}
],
"public": false
},
"MCU_NRF51_16K_S110": {
"inherits": ["MCU_NRF51_S110", "MCU_NRF51_16K_BASE"],
"public": false
},
"MCU_NRF51_16K_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT_BASE"],
"extra_labels_add": ["MCU_NRF51_16K_S130"],
"macros_add": ["TARGET_MCU_NRF51_16K_S130"],
"public": false
},
"MCU_NRF51_16K_BOOT_S110": {
"inherits": ["MCU_NRF51_S110", "MCU_NRF51_16K_BOOT_BASE"],
"public": false
},
"MCU_NRF51_16K_OTA": {
"inherits": ["MCU_NRF51_16K_OTA_BASE"],
"extra_labels_add": ["MCU_NRF51_16K_S130"],
"macros_add": ["TARGET_MCU_NRF51_16K_S130"],
"public": false
},
"MCU_NRF51_16K_OTA_S110": {
"inherits": ["MCU_NRF51_S110", "MCU_NRF51_16K_OTA_BASE"],
"public": false
},
"MCU_NRF51_32K": {
"inherits": ["MCU_NRF51"],
"extra_labels_add": ["MCU_NORDIC_32K", "MCU_NRF51_32K"],
"macros_add": ["TARGET_MCU_NORDIC_32K", "TARGET_MCU_NRF51_32K"],
"public": false
},
"MCU_NRF51_32K_BOOT": {
"inherits": ["MCU_NRF51_32K"],
"MERGE_BOOTLOADER": true,
"extra_labels_add": ["MCU_NRF51_32K_BOOT"],
"macros_add": ["TARGET_MCU_NRF51_32K_BOOT", "TARGET_OTA_ENABLED"],
"public": false
},
"MCU_NRF51_32K_OTA": {
"inherits": ["MCU_NRF51_32K"],
"public": false,
"extra_labels_add": ["MCU_NRF51_32K_OTA"],
"macros_add": ["TARGET_MCU_NRF51_32K_OTA", "TARGET_OTA_ENABLED"],
"MERGE_SOFT_DEVICE": false
},
"NRF51822": {
"inherits": ["MCU_NRF51_16K"],
"extra_labels_add": ["NRF51822", "NRF51822_MKIT"],
added extra_labels_add checking to script and moved a previously missed device.h file to targets.json
2016-06-06 15:18:25 +00:00
"macros_add": ["TARGET_NRF51822_MKIT"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"NRF51822_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["NRF51822", "NRF51822_MKIT"],
Add device_has to all nrf51 devices Move common device_has attributes into MCU_NRF51 and MCU_NRF51_UNIFIED. This ensures all nrf51 devices have the correct features enabled. Any devices that want to explicitly disable features should use device_has_remove.
2016-09-13 17:57:37 +00:00
"macros_add": ["TARGET_NRF51822_MKIT"]
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 17:50:01 +00:00
},
"NRF51822_OTA": {
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["NRF51822", "NRF51822_MKIT"],
Add device_has to all nrf51 devices Move common device_has attributes into MCU_NRF51 and MCU_NRF51_UNIFIED. This ensures all nrf51 devices have the correct features enabled. Any devices that want to explicitly disable features should use device_has_remove.
2016-09-13 17:57:37 +00:00
"macros_add": ["TARGET_NRF51822_MKIT"]
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 17:50:01 +00:00
},
"ARCH_BLE": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"ARCH_BLE_BOOT": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["ARCH_BLE"],
"macros_add": ["TARGET_ARCH_BLE"]
},
"ARCH_BLE_OTA": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["ARCH_BLE"],
"macros_add": ["TARGET_ARCH_BLE"]
},
"ARCH_LINK": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K"],
"extra_labels_add": ["ARCH_BLE"],
"macros_add": ["TARGET_ARCH_BLE"]
},
"ARCH_LINK_BOOT": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["ARCH_BLE", "ARCH_LINK"],
"macros_add": ["TARGET_ARCH_BLE", "TARGET_ARCH_LINK"]
},
"ARCH_LINK_OTA": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["ARCH_BLE", "ARCH_LINK"],
"macros_add": ["TARGET_ARCH_BLE", "TARGET_ARCH_LINK"]
},
"SEEED_TINY_BLE": {
"inherits": ["MCU_NRF51_16K"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"SEEED_TINY_BLE_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["SEEED_TINY_BLE"],
"macros_add": ["TARGET_SEEED_TINY_BLE"]
},
"SEEED_TINY_BLE_OTA": {
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["SEEED_TINY_BLE"],
"macros_add": ["TARGET_SEEED_TINY_BLE"]
},
"HRM1017": {
"inherits": ["MCU_NRF51_16K"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros_add": ["TARGET_NRF_LFCLK_RC"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"HRM1017_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["HRM1017"],
"macros_add": ["TARGET_HRM1017", "TARGET_NRF_LFCLK_RC"]
},
"HRM1017_OTA": {
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["HRM1017"],
"macros_add": ["TARGET_HRM1017", "TARGET_NRF_LFCLK_RC"]
},
"RBLAB_NRF51822": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"RBLAB_NRF51822_BOOT": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["RBLAB_NRF51822"],
"macros_add": ["TARGET_RBLAB_NRF51822"]
},
"RBLAB_NRF51822_OTA": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["RBLAB_NRF51822"],
"macros_add": ["TARGET_RBLAB_NRF51822"]
},
"RBLAB_BLENANO": {
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"inherits": ["MCU_NRF51_16K"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"RBLAB_BLENANO_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["RBLAB_BLENANO"],
"macros_add": ["TARGET_RBLAB_BLENANO"]
},
"RBLAB_BLENANO_OTA": {
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["RBLAB_BLENANO"],
"macros_add": ["TARGET_RBLAB_BLENANO"]
},
Add support for RedBear's BLE Nano 2 Cribbed from https://github.com/redbear/mbed-os/commit/4bf42f2e205e81ffb50a013b16c0366607bf8146 I'm not sure if if there are any copyright issues here with what is effectively a set of config files. A few folks have been bugging me (and the redbear folks) for these changes, so I wanted them somewhere centralized.
2017-10-01 21:29:01 +00:00
"RBLAB_BLENANO2": {
"supported_form_factors": ["ARDUINO"],
Change target.json to use new SDK and folder structure for NRF52
2018-01-17 20:43:04 +00:00
"inherits": ["MCU_NRF52832"],
Enable us lp ticker support for entire MCU_NRF52832 family
2018-05-23 11:58:46 +00:00
"release_versions": ["5"],
Add support for RedBear's BLE Nano 2 Cribbed from https://github.com/redbear/mbed-os/commit/4bf42f2e205e81ffb50a013b16c0366607bf8146 I'm not sure if if there are any copyright issues here with what is effectively a set of config files. A few folks have been bugging me (and the redbear folks) for these changes, so I wanted them somewhere centralized.
2017-10-01 21:29:01 +00:00
"device_name": "nRF52832_xxAA"
},
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 17:50:01 +00:00
"NRF51822_Y5_MBUG": {
Add device_has to all nrf51 devices Move common device_has attributes into MCU_NRF51 and MCU_NRF51_UNIFIED. This ensures all nrf51 devices have the correct features enabled. Any devices that want to explicitly disable features should use device_has_remove.
2016-09-13 17:57:37 +00:00
"inherits": ["MCU_NRF51_16K"]
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 17:50:01 +00:00
},
"WALLBOT_BLE": {
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"inherits": ["MCU_NRF51_16K"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"WALLBOT_BLE_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["WALLBOT_BLE"],
"macros_add": ["TARGET_WALLBOT_BLE"]
},
"WALLBOT_BLE_OTA": {
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["WALLBOT_BLE"],
"macros_add": ["TARGET_WALLBOT_BLE"]
},
"DELTA_DFCM_NNN40": {
"inherits": ["MCU_NRF51_32K"],
"program_cycle_s": 10,
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros_add": ["TARGET_NRF_LFCLK_RC"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "DEBUG_AWARENESS", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"DELTA_DFCM_NNN40_BOOT": {
"inherits": ["MCU_NRF51_32K_BOOT"],
"program_cycle_s": 10,
"extra_labels_add": ["DELTA_DFCM_NNN40"],
"macros_add": ["TARGET_DELTA_DFCM_NNN40", "TARGET_NRF_LFCLK_RC"]
},
"DELTA_DFCM_NNN40_OTA": {
"inherits": ["MCU_NRF51_32K_OTA"],
"program_cycle_s": 10,
"extra_labels_add": ["DELTA_DFCM_NNN40"],
"macros_add": ["TARGET_DELTA_DFCM_NNN40", "TARGET_NRF_LFCLK_RC"]
},
Add DELTA_DFCM_NNN50 platform greentea tests are all passing mbedgt: test case results: 175 OK Please kindly review this PR
2017-01-18 03:01:48 +00:00
"DELTA_DFCM_NNN50": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_UNIFIED"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
Add DELTA_DFCM_NNN50 platform greentea tests are all passing mbedgt: test case results: 175 OK Please kindly review this PR
2017-01-18 03:01:48 +00:00
"device_name": "nRF51822_xxAC"
},
"DELTA_DFCM_NNN50_BOOT": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_BOOT"],
"extra_labels_add": ["DELTA_DFCM_NNN50"],
"macros_add": ["TARGET_DELTA_DFCM_NNN50"]
},
"DELTA_DFCM_NNN50_OTA": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_OTA"],
"extra_labels_add": ["DELTA_DFCM_NNN50"],
"macros_add": ["TARGET_DELTA_DFCM_NNN50"]
},
Merge remote-tracking branch 'mbed-nordic/epr_integration' into nrf52_nrf51_unified_integration
2016-07-21 13:50:37 +00:00
"NRF51_DK_LEGACY": {
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 17:50:01 +00:00
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"extra_labels_add": ["NRF51_DK"]
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 17:50:01 +00:00
},
"NRF51_DK_BOOT": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_BOOT"],
"extra_labels_add": ["NRF51_DK"],
"macros_add": ["TARGET_NRF51_DK"]
},
"NRF51_DK_OTA": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_OTA"],
"extra_labels_add": ["NRF51_DK"],
"macros_add": ["TARGET_NRF51_DK"]
},
NORDIC - Update NRF51_DONGLE target to takes advantage of the NRF5 implementation of BLE and device drivers.
2016-09-22 12:36:57 +00:00
"NRF51_DONGLE_LEGACY": {
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 17:50:01 +00:00
"inherits": ["MCU_NRF51_32K"],
TARGET_NRF51_DONGLE_LEGACY - Add NRF51_DONGLE to the list of paths available for this target.
2016-09-26 15:39:22 +00:00
"extra_labels_add": ["NRF51_DONGLE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"NRF51_DONGLE_BOOT": {
"inherits": ["MCU_NRF51_32K_BOOT"],
"extra_labels_add": ["NRF51_DONGLE"],
"macros_add": ["TARGET_NRF51_DONGLE"]
},
"NRF51_DONGLE_OTA": {
"inherits": ["MCU_NRF51_32K_OTA"],
"extra_labels_add": ["NRF51_DONGLE"],
"macros_add": ["TARGET_NRF51_DONGLE"]
},
"NRF51_MICROBIT": {
"inherits": ["MCU_NRF51_16K_S110"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros_add": ["TARGET_NRF_LFCLK_RC"],
Add a device_name to microbit entry in targets.json
2016-10-31 23:01:58 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"NRF51_MICROBIT_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT_S110"],
"extra_labels_add": ["NRF51_MICROBIT"],
"macros_add": ["TARGET_NRF51_MICROBIT", "TARGET_NRF_LFCLK_RC"]
},
"NRF51_MICROBIT_OTA": {
"inherits": ["MCU_NRF51_16K_OTA_S110"],
"extra_labels_add": ["NRF51_MICROBIT"],
"macros_add": ["TARGET_NRF51_MICROBIT", "TARGET_NRF_LFCLK_RC"]
},
"NRF51_MICROBIT_B": {
"inherits": ["MCU_NRF51_16K"],
"extra_labels_add": ["NRF51_MICROBIT"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"macros_add": ["TARGET_NRF51_MICROBIT", "TARGET_NRF_LFCLK_RC"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"NRF51_MICROBIT_B_BOOT": {
"inherits": ["MCU_NRF51_16K_BOOT"],
"extra_labels_add": ["NRF51_MICROBIT"],
"macros_add": ["TARGET_NRF51_MICROBIT", "TARGET_NRF_LFCLK_RC"]
},
"NRF51_MICROBIT_B_OTA": {
"inherits": ["MCU_NRF51_16K_OTA"],
"extra_labels_add": ["NRF51_MICROBIT"],
"macros_add": ["TARGET_NRF51_MICROBIT", "TARGET_NRF_LFCLK_RC"]
},
[MTM_MTCONNECT04S] Added support for MTM_MTCONNECT04S
2016-09-05 02:53:39 +00:00
"MTM_MTCONNECT04S": {
"inherits": ["MCU_NRF51_32K"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAA"
[MTM_MTCONNECT04S] Added support for MTM_MTCONNECT04S
2016-09-05 02:53:39 +00:00
},
"MTM_MTCONNECT04S_BOOT": {
"inherits": ["MCU_NRF51_32K_BOOT"],
"extra_labels_add": ["MTM_CONNECT04S"],
"macros_add": ["TARGET_MTM_CONNECT04S"]
},
"MTM_MTCONNECT04S_OTA": {
"inherits": ["MCU_NRF51_32K_OTA"],
"extra_labels_add": ["MTM_CONNECT04S"],
"macros_add": ["TARGET_MTM_CONNECT04S"]
},
Adding LAIRD_BL600 MTB
2018-02-01 17:21:37 +00:00
"MTB_LAIRD_BL600": {
"inherits": ["MCU_NRF51_32K_UNIFIED"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
Adding LAIRD_BL600 MTB
2018-02-01 17:21:37 +00:00
"device_name": "nRF51822_xxAA",
"release_versions" : ["5"],
"extra_labels_add": ["MTB_LAIRD_BL600"],
"config": {
"usb_tx": {
"help": "Value SIO_21",
"value": "SIO_21"
},
"usb_rx": {
"help": "Value SIO_22",
"value": "SIO_22"
},
"stdio_uart": {
"help": "Value: UART_0",
"value": "UART_0",
"macro_name": "STDIO_UART"
}
},
"overrides": {
"uart_hwfc": 0
}
},
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 17:50:01 +00:00
"TY51822R3": {
[TY51822r3] Add support for mbed OS 5 - Changed inherit to "MCU_NRF51_32K_UNIFIED". - Added 32MHz XTAL support to "system_nrf.c". - Added TY51822r3 support to "MCU_NRF51_32K_UNIFIED".
2016-08-15 10:18:56 +00:00
"inherits": ["MCU_NRF51_32K_UNIFIED"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros_add": ["TARGET_NRF_32MHZ_XTAL"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
[TY51822r3] Add support for mbed OS 5 - Changed inherit to "MCU_NRF51_32K_UNIFIED". - Added 32MHz XTAL support to "system_nrf.c". - Added TY51822r3 support to "MCU_NRF51_32K_UNIFIED".
2016-08-15 10:18:56 +00:00
"detect_code": ["1019"],
[TY51822r3] a patch for TY51822r3 to use a change of PR #2535
2016-08-26 13:44:24 +00:00
"release_versions": ["2", "5"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"overrides": {"uart_hwfc": 0},
"device_name": "nRF51822_xxAA"
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 17:50:01 +00:00
},
"TY51822R3_BOOT": {
"inherits": ["MCU_NRF51_32K_BOOT"],
"extra_labels_add": ["TY51822R3"],
"macros_add": ["TARGET_TY51822R3", "TARGET_NRF_32MHZ_XTAL"]
},
"TY51822R3_OTA": {
"inherits": ["MCU_NRF51_32K_OTA"],
"extra_labels_add": ["NRF51_DK"],
"macros_add": ["TARGET_TY51822R3", "TARGET_NRF_32MHZ_XTAL"]
},
"ARM_MPS2_Target": {
"inherits": ["Target"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"public": false,
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"]
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 17:50:01 +00:00
},
"ARM_MPS2_M0": {
"inherits": ["ARM_MPS2_Target"],
"core": "Cortex-M0",
"supported_toolchains": ["ARM"],
"extra_labels": ["ARM_SSG", "MPS2", "MPS2_M0"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSDK_CM0", "CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"ARM_MPS2_M0P": {
"inherits": ["ARM_MPS2_Target"],
"core": "Cortex-M0+",
"supported_toolchains": ["ARM"],
"extra_labels": ["ARM_SSG", "MPS2", "MPS2_M0P"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros": ["CMSDK_CM0plus"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"ARM_MPS2_M3": {
"inherits": ["ARM_MPS2_Target"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM"],
"extra_labels": ["ARM_SSG", "MPS2", "MPS2_M3"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros": ["CMSDK_CM3"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"ARM_MPS2_M4": {
"inherits": ["ARM_MPS2_Target"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
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 17:50:01 +00:00
"supported_toolchains": ["ARM"],
"extra_labels": ["ARM_SSG", "MPS2", "MPS2_M4"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros": ["CMSDK_CM4"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"ARM_MPS2_M7": {
"inherits": ["ARM_MPS2_Target"],
"core": "Cortex-M7",
"supported_toolchains": ["ARM"],
"extra_labels": ["ARM_SSG", "MPS2", "MPS2_M7"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros": ["CMSDK_CM7"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
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 17:50:01 +00:00
},
"ARM_IOTSS_Target": {
"inherits": ["Target"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"public": false,
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"]
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 17:50:01 +00:00
},
"ARM_IOTSS_BEID": {
"inherits": ["ARM_IOTSS_Target"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM"],
"extra_labels": ["ARM_SSG", "IOTSS", "IOTSS_BEID"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"macros": ["CMSDK_BEID"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["AACI", "ANALOGIN", "CLCD", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"],
Changing 'release' key to 'release_versions'. The key 'release' in hal/targets.json is ambiguous. This changes the key to 'release_versions' to emphasize that the entries should be version numbers/strings and that it should be an array, not a singular value.
2016-07-27 18:30:53 +00:00
"release_versions": ["2"]
Create CM3DS_MPS2 target - Creates new target in targets.json - Creates device specific files under ARM_SSG/CM3DS_MPS2 directory - Driver layer files under CM3DS_MPS2 are based on Beid target - Device specific files under CM3DS_MPS2/device are based on CMSIS_5 and Beetle Change-Id: I29ea7a7f42b11cf25b516cce4b9255ab828ca019 Signed-off-by: Tamas Kaman <Tamas.Kaman@arm.com> Signed-off-by: Marc Moreno <marc.morenoberengue@arm.com>
2017-04-06 08:09:03 +00:00
},
"ARM_CM3DS_MPS2": {
"inherits": ["ARM_IOTSS_Target"],
"core": "Cortex-M3",
Enable IAR and GCC_ARM compiler for CM3DS MPS2 1. Add startup code and linker script for IAR and GCC_ARM compilers. 2. Enable IAR and GCC_ARM compilers in targets.json. Change-Id: I742a89ae73a4e5ede980a8af0821c3f0e5a461ef Signed-off-by: Mate Toth-Pal <mate.toth-pal@arm.com>
2017-06-01 10:56:02 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Create CM3DS_MPS2 target - Creates new target in targets.json - Creates device specific files under ARM_SSG/CM3DS_MPS2 directory - Driver layer files under CM3DS_MPS2 are based on Beid target - Device specific files under CM3DS_MPS2/device are based on CMSIS_5 and Beetle Change-Id: I29ea7a7f42b11cf25b516cce4b9255ab828ca019 Signed-off-by: Tamas Kaman <Tamas.Kaman@arm.com> Signed-off-by: Marc Moreno <marc.morenoberengue@arm.com>
2017-04-06 08:09:03 +00:00
"extra_labels": ["ARM_SSG", "CM3DS_MPS2"],
CM3DS: switch to larger memories for code and data This patch changes the linker files and defines to use the ZBT SSRAM instead of the FPGA Block RAM for code and data. The section 4.1.1, Code and RAM memory map, of the CM3DS Eval RTL and testbench user guide explains the available memories. This switch improves code memory from 256 kB to 4 MB and data memory from 128 kB to 4 MB. However, the ZBT SSRAM1 for code memory begins at 0x00400000 while the processor can only boot at address 0x00000000 which means that it expects the vector table to be at that address. That is why we have to create 2 load regions in the linker scripts: one with only the vector table at address 0x0 and one with code + data at address 0x00400000. Because of these two load regions, linker will produce different behaviours: * GCC_ARM and IAR will only create 1 binary with both load regions padding with 0 in between. The binary will then be very large (at least 4 MB) and the flash process will take longer. * ARM and ARMC6 will create 2 binaries for the two load regions. The load addresses of the two binaries can be written in the images.txt file on the MPS2 board. You can also use the --bincombined option of fromelf utility to produce only 1 large binary. This patch also adds the memory_zones.h file to try to put in common all the memory addresses that were previously hard coded in the linker scripts / startup files. With that patch in, the simplest option is to directly use the .elf file with the MPS2, which is only possible with mbb_v225.ebf and more recent firmwares. It will now be the default for CM3DS. This commit works with greentea thanks to the now merged pull request ARMmbed/htrun#181 in order to copy .elf file to the MPS2 board. Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2018-01-08 15:19:48 +00:00
"OUTPUT_EXT": "elf",
Create CM3DS_MPS2 target - Creates new target in targets.json - Creates device specific files under ARM_SSG/CM3DS_MPS2 directory - Driver layer files under CM3DS_MPS2 are based on Beid target - Device specific files under CM3DS_MPS2/device are based on CMSIS_5 and Beetle Change-Id: I29ea7a7f42b11cf25b516cce4b9255ab828ca019 Signed-off-by: Tamas Kaman <Tamas.Kaman@arm.com> Signed-off-by: Marc Moreno <marc.morenoberengue@arm.com>
2017-04-06 08:09:03 +00:00
"macros": ["CMSDK_CM3DS"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "ETHERNET", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SPI", "TRNG"],
"release_versions": ["2", "5"],
Enable greentea testing on CM3DS_MPS2 target Set copy_method and reset_method in targets.json which is needed for htrun.
2017-07-04 19:21:45 +00:00
"copy_method": "mps2",
"reset_method": "reboot.txt"
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 17:50:01 +00:00
},
[BEETLE] Add initial support This patch adds support for the BEETLE Target. The compilers supported by this target are: * ARMCC * GCC ARM The exporters and the CMSIS/HAL components will follow in future patches. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
2016-05-11 13:57:33 +00:00
"ARM_BEETLE_SOC": {
"inherits": ["ARM_IOTSS_Target"],
"core": "Cortex-M3",
[BEETLE] Add support for IAR compiler IAR compiler support is a mandatory requirement for mbed-os 5.1. This patch adds support to IAR on Beetle mbed-os platform. It contains: * Linker script * Startup code * Target enablement * Cordio libraries for BLE Signed-off-by: Douglas Raillard <douglas.raillard@arm.com> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
2016-08-11 13:44:17 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
[BEETLE] Add initial support This patch adds support for the BEETLE Target. The compilers supported by this target are: * ARMCC * GCC ARM The exporters and the CMSIS/HAL components will follow in future patches. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
2016-05-11 13:57:33 +00:00
"default_toolchain": "ARM",
"extra_labels": ["ARM_SSG", "BEETLE"],
"macros": ["CMSDK_BEETLE", "WSF_MS_PER_TICK=20", "WSF_TOKEN_ENABLED=FALSE", "WSF_TRACE_ENABLED=TRUE", "WSF_ASSERT_ENABLED=FALSE", "WSF_PRINTF_MAX_LEN=128", "ASIC", "CONFIG_HOST_REV=0x20", "CONFIG_ALLOW_DEEP_SLEEP=FALSE", "HCI_VS_TARGET", "CONFIG_ALLOW_SETTING_WRITE=TRUE", "WSF_MAX_HANDLERS=20", "NO_LEDS"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has": ["ANALOGIN", "CLCD", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SLEEP", "SPI"],
[BEETLE] Change release_version to 5 mbedci-test CI server is complian only with mbed-os release version 5.x. This patch updates the Beetle section of the target.json file in order to comply with the requirement. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
2016-08-12 09:51:28 +00:00
"features": ["BLE"],
Fix or remove invalid device names The field device_name is intended to match that of a target in a device family pack. Remove this field for devices which do not have a pack. Fix the name for devices that have the name incorrect. Update IAR definitions for device which no longer have a device_name but still need to have support for the IAR exporter.
2017-01-16 00:42:02 +00:00
"release_versions": ["2", "5"]
[BEETLE] Add initial support This patch adds support for the BEETLE Target. The compilers supported by this target are: * ARMCC * GCC ARM The exporters and the CMSIS/HAL components will follow in future patches. Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
2016-05-11 13:57:33 +00:00
},
Add "RZ_A1XX" label for commonizing in targets.json I added the "RZ_A1XX" label for commonizing the setting in targets.json, and inherited in both RZ_A1H and VK_RZ_A1H.
2018-01-12 06:01:52 +00:00
"RZ_A1XX": {
"inherits": ["Target"],
Partially Revert "Remove Cortex A boards as Cortex-A it is not supported in CMSIS5/RTX2" This partially reverts commit e535493a01503eaa4ebdd448552ca844371d52cf.
2017-05-23 18:57:59 +00:00
"core": "Cortex-A9",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Add "RZ_A1XX" label for commonizing in targets.json I added the "RZ_A1XX" label for commonizing the setting in targets.json, and inherited in both RZ_A1H and VK_RZ_A1H.
2018-01-12 06:01:52 +00:00
"extra_labels": ["RENESAS", "RZ_A1XX"],
Implement of RTC feature for Renesas mbed boards I implemented the RTC feature. The mainly changing is here. - rtc_init() Previously, I have initialized the time information register in the function, so the time count was cleaned by every calling rtc_init(). Currently, rtc_init() doesn't stop RTC from counting, and rtc_init() is safe to call repeatedly. Therefore in order to satisfy specifications,I removed the initialization process of the time information register in the function. - rtc_free() Previously, I have initialized the RTC related register same as rtc_init(), so the time count was cleaned by calling rtc_free(). Currently, rtc_free() doesn't stop RTC from counting. Therefore in order to satisfy specifications,I removed the process and decided not to do anything in the function. If powerdown the RTC, Supply of the clock to the RTC is stopped, cannot keeping the count.
2018-03-28 21:15:22 +00:00
"device_has": ["SLEEP", "USTICKER", "RTC", "ANALOGIN", "CAN", "ETHERNET", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
Partially Revert "Remove Cortex A boards as Cortex-A it is not supported in CMSIS5/RTX2" This partially reverts commit e535493a01503eaa4ebdd448552ca844371d52cf.
2017-05-23 18:57:59 +00:00
"features": ["LWIP"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"program_cycle_s": 2,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
Add "RZ_A1XX" label for commonizing in targets.json I added the "RZ_A1XX" label for commonizing the setting in targets.json, and inherited in both RZ_A1H and VK_RZ_A1H.
2018-01-12 06:01:52 +00:00
},
"RZ_A1H": {
"inherits": ["RZ_A1XX"],
"supported_form_factors": ["ARDUINO"],
Implementation of unified EMAC driver for Renesas mbed boards Implementation of unified EMAC driver for Renesas mbed boards Based on the driver so far, Renesas implemented the emac driver for GR-PEACH and VK-RZ/A1H. The mainly changes is below. - Add the connection part with LWIP according to the unified emac specification. - Add three new multicast functions(add, remove, set_all). The Greentea test netsocket and emac test passed.
2018-05-11 03:20:17 +00:00
"extra_labels_add": ["RZA1H", "MBRZA1H", "RZ_A1_EMAC"],
"device_has_add": ["EMAC"],
Revert "Remove Cortex-A mbed OS 5 support" I changed the python and json files to re-registering GR-PEACH to Mbed OS 5.
2017-12-14 11:35:42 +00:00
"release_versions": ["2", "5"]
Partially Revert "Remove Cortex A boards as Cortex-A it is not supported in CMSIS5/RTX2" This partially reverts commit e535493a01503eaa4ebdd448552ca844371d52cf.
2017-05-23 18:57:59 +00:00
},
"VK_RZ_A1H": {
Add "RZ_A1XX" label for commonizing in targets.json I added the "RZ_A1XX" label for commonizing the setting in targets.json, and inherited in both RZ_A1H and VK_RZ_A1H.
2018-01-12 06:01:52 +00:00
"inherits": ["RZ_A1XX"],
Implementation of unified EMAC driver for Renesas mbed boards Implementation of unified EMAC driver for Renesas mbed boards Based on the driver so far, Renesas implemented the emac driver for GR-PEACH and VK-RZ/A1H. The mainly changes is below. - Add the connection part with LWIP according to the unified emac specification. - Add three new multicast functions(add, remove, set_all). The Greentea test netsocket and emac test passed.
2018-05-11 03:20:17 +00:00
"extra_labels_add": ["RZA1H", "VKRZA1H", "RZ_A1_EMAC"],
"device_has_add": ["EMAC"],
Enabled os5 support for VK_RZ_A1H & synced with rest Renesas targets ! Mbed-os 5.4.7 was the last unofficial working support for this target. Since Mbed-os 5.6.0, the support is now official and VK_RZ_A1H is now "codebase aligned" with GR_PEACH (RZ_A1H) & GR_LYCHEE (RZ_A1LU) !
2018-03-01 14:06:18 +00:00
"release_versions": ["2", "5"]
Partially Revert "Remove Cortex A boards as Cortex-A it is not supported in CMSIS5/RTX2" This partially reverts commit e535493a01503eaa4ebdd448552ca844371d52cf.
2017-05-23 18:57:59 +00:00
},
Add GR_LYCHEE as a new target board in terget.json, build_travis.py and tests.py I added GR-LYCHEE's configuration in targets.json file. Also, I added GR_LYCHEE as a Renesas new target board in build_travis.py and tests.py.
2018-01-16 04:25:17 +00:00
"GR_LYCHEE": {
"inherits": ["RZ_A1XX"],
"supported_form_factors": ["ARDUINO"],
"extra_labels_add": ["RZA1UL", "MBRZA1LU"],
Support TRNG function for GR-LYCHEE I supported the TRNG function when target is GR-LYCHEE. GR-LYCHEE generates TRNG by acquiring the random number of Wifi module(ESP32) incorporated in it using I2C.
2018-01-16 04:45:15 +00:00
"device_has_add": ["TRNG"],
Add GR_LYCHEE as a new target board in terget.json, build_travis.py and tests.py I added GR-LYCHEE's configuration in targets.json file. Also, I added GR_LYCHEE as a Renesas new target board in build_travis.py and tests.py.
2018-01-16 04:25:17 +00:00
"device_has_remove": ["ETHERNET"],
"features_remove": ["LWIP"],
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"release_versions": ["2", "5"],
"overrides": {
"network-default-interface-type": null
}
Add GR_LYCHEE as a new target board in terget.json, build_travis.py and tests.py I added GR-LYCHEE's configuration in targets.json file. Also, I added GR_LYCHEE as a Renesas new target board in build_travis.py and tests.py.
2018-01-16 04:25:17 +00:00
},
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 17:50:01 +00:00
"MAXWSNENV": {
"inherits": ["Target"],
"core": "Cortex-M3",
"macros": ["__SYSTEM_HFX=24000000"],
"extra_labels": ["Maxim", "MAX32610"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "STDIO_MESSAGES"],
[MAX326xx] Added support for FEATURE_BLE. Integrated MaximBLE library.
2016-10-05 21:20:44 +00:00
"features": ["BLE"],
Disable Maxim boards as LP_TICKER is used in RTC and they don't respect device_has
2018-03-14 11:43:09 +00:00
"release_versions": []
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 17:50:01 +00:00
},
"MAX32600MBED": {
"inherits": ["Target"],
"core": "Cortex-M3",
"macros": ["__SYSTEM_HFX=24000000"],
"extra_labels": ["Maxim", "MAX32600"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "STDIO_MESSAGES"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"release_versions": ["2", "5"]
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
},
"MAX32620HSP": {
"inherits": ["Target"],
"core": "Cortex-M4F",
"extra_labels": ["Maxim", "MAX32620"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "STDIO_MESSAGES"],
[MAX326xx] Added support for FEATURE_BLE. Integrated MaximBLE library.
2016-10-05 21:20:44 +00:00
"features": ["BLE"],
Disable Maxim boards as LP_TICKER is used in RTC and they don't respect device_has
2018-03-14 11:43:09 +00:00
"release_versions": []
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 17:50:01 +00:00
},
[MAX32620C] Add new target
2018-02-13 20:58:15 +00:00
"MAX32620FTHR": {
"inherits": ["Target"],
"core": "Cortex-M4F",
"macros": ["__SYSTEM_HFX=96000000","TARGET=MAX32620","TARGET_REV=0x4332","OPEN_DRAIN_LEDS"],
"extra_labels": ["Maxim", "MAX32620C"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
Disable RTC on MAX32630FTHR due to failing tests
2018-05-26 15:41:36 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "STDIO_MESSAGES", "USTICKER"],
mbed-os v5.9 USTICKER implementation
2018-05-17 19:45:55 +00:00
"release_versions": ["2", "5"]
[MAX32620C] Add new target
2018-02-13 20:58:15 +00:00
},
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"MAX32625_BASE": {
[MAX32625MBED] Adding new Maxim Integrated target.
2016-10-07 19:07:05 +00:00
"inherits": ["Target"],
"core": "Cortex-M4F",
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"macros": ["TARGET=MAX32625","TARGET_REV=0x4132", "OPEN_DRAIN_LEDS"],
[MAX32625MBED] Adding new Maxim Integrated target.
2016-10-07 19:07:05 +00:00
"extra_labels": ["Maxim", "MAX32625"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
mbed-os v5.9 LPTICKER implementation
2018-05-17 19:46:36 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "STDIO_MESSAGES", "USTICKER"],
mbed-os v5.9 USTICKER implementation
2018-05-17 19:45:55 +00:00
"release_versions": ["2", "5"],
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"public": false
},
"MAX32625_BOOT": {
"inherits": ["MAX32625_BASE"],
"extra_labels_add": ["MAX32625_BOOT"],
"public": false
},
"MAX32625_NO_BOOT": {
"inherits": ["MAX32625_BASE"],
"extra_labels_add": ["MAX32625_NO_BOOT"],
"public": false
},
"MAX32625MBED": {
"inherits": ["MAX32625_NO_BOOT"]
},
"MAX32625PICO": {
"inherits": ["MAX32625_BOOT"],
"extra_labels_add": ["MAX32625PICO_BASE"]
},
"MAX32625PICO_NO_BOOT": {
"inherits": ["MAX32625_NO_BOOT"],
"extra_labels_add": ["MAX32625PICO_BASE"]
[MAX32625MBED] Adding new Maxim Integrated target.
2016-10-07 19:07:05 +00:00
},
[MAX32625NEXPAQ] Adding new Maxim Integrated target.
2016-08-31 15:09:21 +00:00
"MAX32625NEXPAQ": {
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"inherits": ["MAX32625_BASE"],
"extra_labels_add": ["MAX32625NEXPAQ"]
[MAX32630FTHR] Adding new platform
2016-11-09 19:33:11 +00:00
},
"MAX32630FTHR": {
"inherits": ["Target"],
"core": "Cortex-M4F",
Update BLE, fix sleep and open-drain LEDs in MAX326xx MAX32630FTHR gets BLE, uses timer peripheral 5 for HCI timing libexactLE update for 610,620 Fixup hal_sleep and hal_deepsleep for 620 LEDn outputs now forced to open-drain
2017-06-14 00:26:03 +00:00
"macros": ["__SYSTEM_HFX=96000000", "TARGET=MAX32630", "TARGET_REV=0x4132", "BLE_HCI_UART", "OPEN_DRAIN_LEDS"],
[MAX32630FTHR] Adding new platform
2016-11-09 19:33:11 +00:00
"extra_labels": ["Maxim", "MAX32630"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
Disable RTC on MAX32630FTHR due to failing tests
2018-05-26 15:41:36 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SPI", "STDIO_MESSAGES", "USTICKER"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"features": ["BLE"],
mbed-os v5.9 LPTICKER implementation
2018-05-17 19:46:36 +00:00
"release_versions": ["2", "5"]
[MAX32625NEXPAQ] Adding new Maxim Integrated target.
2016-08-31 15:09:21 +00:00
},
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"EFM32": {
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 17:50:01 +00:00
"inherits": ["Target"],
"extra_labels": ["Silicon_Labs", "EFM32"],
Enable tickless mode on Silicon Labs targets
2018-03-27 10:44:53 +00:00
"macros": ["MBEDTLS_CONFIG_HW_SUPPORT", "MBED_TICKLESS"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"public": false
},
"EFM32GG990F1024": {
"inherits": ["EFM32"],
Stop using device_has for non-mbed options As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
2017-03-17 12:01:50 +00:00
"extra_labels_add": ["EFM32GG", "1024K", "SL_AES"],
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 17:50:01 +00:00
"core": "Cortex-M3",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFM32GG990F1024", "TRANSACTION_QUEUE_SIZE_SPI=4"],
[EFM32] Add IAR support for remaining Silicon Labs targets Added startup files and IAR memory map files for the remaining Silicon Labs targets as part of the mbed enabled criteria.
2016-09-14 15:06:21 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32GG990F1024",
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
},
"EFM32GG_STK3700": {
"inherits": ["EFM32GG990F1024"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"progen": {"target": "efm32gg-stk"},
Re-implement RTC for Silicon Labs targets mbed RTC specifications now dictate that the RTC needs to retain and keep on counting through reset. On Silicon Labs parts, this means the RTC API can not be backed by the Silicon Labs RTC peripheral, since that doesn't provide retention functionality. Therefore: * On EFM32GG, EFM32WG, EFM32LG: mbed RTC API is now backed by BURTC. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: mbed RTC API is now backed by RTCC. * On EFM32ZG, EFM32HG: mbed RTC API is sadly no longer supported, since these chips don't have retained memory.
2018-03-26 20:32:55 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "FLASH", "ITM"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "48000000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "21000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of _CMU_HFRCOCTRL_BAND_28MHZ, _CMU_HFRCOCTRL_BAND_21MHZ, _CMU_HFRCOCTRL_BAND_14MHZ, _CMU_HFRCOCTRL_BAND_11MHZ, _CMU_HFRCOCTRL_BAND_7MHZ, _CMU_HFRCOCTRL_BAND_1MHZ. Be sure to set hfrco_clock_freq accordingly!",
"value": "_CMU_HFRCOCTRL_BAND_21MHZ",
"macro_name": "HFRCO_FREQUENCY_ENUM"
[EFM32] Move board controller pin setting to config system
2016-10-28 06:21:39 +00:00
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PF7",
"macro_name": "EFM_BC_EN"
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
}
}
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 17:50:01 +00:00
},
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"EFM32LG990F256": {
"inherits": ["EFM32"],
Stop using device_has for non-mbed options As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
2017-03-17 12:01:50 +00:00
"extra_labels_add": ["EFM32LG", "256K", "SL_AES"],
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 17:50:01 +00:00
"core": "Cortex-M3",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFM32LG990F256", "TRANSACTION_QUEUE_SIZE_SPI=4"],
[EFM32] Add IAR support for remaining Silicon Labs targets Added startup files and IAR memory map files for the remaining Silicon Labs targets as part of the mbed enabled criteria.
2016-09-14 15:06:21 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32LG990F256",
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
},
"EFM32LG_STK3600": {
"inherits": ["EFM32LG990F256"],
Re-implement RTC for Silicon Labs targets mbed RTC specifications now dictate that the RTC needs to retain and keep on counting through reset. On Silicon Labs parts, this means the RTC API can not be backed by the Silicon Labs RTC peripheral, since that doesn't provide retention functionality. Therefore: * On EFM32GG, EFM32WG, EFM32LG: mbed RTC API is now backed by BURTC. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: mbed RTC API is now backed by RTCC. * On EFM32ZG, EFM32HG: mbed RTC API is sadly no longer supported, since these chips don't have retained memory.
2018-03-26 20:32:55 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "FLASH"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"device_name": "EFM32LG990F256",
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "48000000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "21000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of _CMU_HFRCOCTRL_BAND_28MHZ, _CMU_HFRCOCTRL_BAND_21MHZ, _CMU_HFRCOCTRL_BAND_14MHZ, _CMU_HFRCOCTRL_BAND_11MHZ, _CMU_HFRCOCTRL_BAND_7MHZ, _CMU_HFRCOCTRL_BAND_1MHZ. Be sure to set hfrco_clock_freq accordingly!",
"value": "_CMU_HFRCOCTRL_BAND_21MHZ",
"macro_name": "HFRCO_FREQUENCY_ENUM"
[EFM32] Move board controller pin setting to config system
2016-10-28 06:21:39 +00:00
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PF7",
"macro_name": "EFM_BC_EN"
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
}
}
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 17:50:01 +00:00
},
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"EFM32WG990F256": {
"inherits": ["EFM32"],
Stop using device_has for non-mbed options As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
2017-03-17 12:01:50 +00:00
"extra_labels_add": ["EFM32WG", "256K", "SL_AES"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFM32WG990F256", "TRANSACTION_QUEUE_SIZE_SPI=4"],
[EFM32] Add IAR support for remaining Silicon Labs targets Added startup files and IAR memory map files for the remaining Silicon Labs targets as part of the mbed enabled criteria.
2016-09-14 15:06:21 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32WG990F256",
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
},
"EFM32WG_STK3800": {
"inherits": ["EFM32WG990F256"],
HUGE COMMIT WARNING device.h defines -> target.json features one problem: [WARNING] device APPNEARME_MICRONFCBOARD did not have an associated entry in targets.json
2016-06-02 20:05:27 +00:00
"progen": {"target": "efm32wg-stk"},
Re-implement RTC for Silicon Labs targets mbed RTC specifications now dictate that the RTC needs to retain and keep on counting through reset. On Silicon Labs parts, this means the RTC API can not be backed by the Silicon Labs RTC peripheral, since that doesn't provide retention functionality. Therefore: * On EFM32GG, EFM32WG, EFM32LG: mbed RTC API is now backed by BURTC. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: mbed RTC API is now backed by RTCC. * On EFM32ZG, EFM32HG: mbed RTC API is sadly no longer supported, since these chips don't have retained memory.
2018-03-26 20:32:55 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "FLASH"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "48000000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "21000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of _CMU_HFRCOCTRL_BAND_28MHZ, _CMU_HFRCOCTRL_BAND_21MHZ, _CMU_HFRCOCTRL_BAND_14MHZ, _CMU_HFRCOCTRL_BAND_11MHZ, _CMU_HFRCOCTRL_BAND_7MHZ, _CMU_HFRCOCTRL_BAND_1MHZ. Be sure to set hfrco_clock_freq accordingly!",
"value": "_CMU_HFRCOCTRL_BAND_21MHZ",
"macro_name": "HFRCO_FREQUENCY_ENUM"
[EFM32] Move board controller pin setting to config system
2016-10-28 06:21:39 +00:00
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PF7",
"macro_name": "EFM_BC_EN"
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
}
}
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 17:50:01 +00:00
},
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"EFM32ZG222F32": {
"inherits": ["EFM32"],
Stop using device_has for non-mbed options As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
2017-03-17 12:01:50 +00:00
"extra_labels_add": ["EFM32ZG", "32K", "SL_AES"],
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 17:50:01 +00:00
"core": "Cortex-M0+",
"default_toolchain": "uARM",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFM32ZG222F32", "TRANSACTION_QUEUE_SIZE_SPI=0"],
[EFM32] Add IAR support for remaining Silicon Labs targets Added startup files and IAR memory map files for the remaining Silicon Labs targets as part of the mbed enabled criteria.
2016-09-14 15:06:21 +00:00
"supported_toolchains": ["GCC_ARM", "uARM", "IAR"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"device_name": "EFM32ZG222F32",
"public": false
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 17:50:01 +00:00
},
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"EFM32ZG_STK3200": {
"inherits": ["EFM32ZG222F32"],
Re-implement us_ticker and lp_ticker for Silicon Labs targets Re-implemented both us_ticker and lp_ticker to match the new API and specifications. Details: * On EFM32GG, EFM32WG, EFM32LG, EFM32HG, EFM32ZG: Use the RTC peripheral to back lp_ticker, and a TIMER to back us_ticker. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: Use the RTCC peripheral to back lp_ticker (dual-purpose, also used to back RTC), and a TIMER to back us_ticker.
2018-03-27 08:55:46 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"forced_reset_timeout": 2,
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "24000000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "21000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of _CMU_HFRCOCTRL_BAND_21MHZ, _CMU_HFRCOCTRL_BAND_14MHZ, _CMU_HFRCOCTRL_BAND_11MHZ, _CMU_HFRCOCTRL_BAND_7MHZ, _CMU_HFRCOCTRL_BAND_1MHZ. Be sure to set hfrco_clock_freq accordingly!",
"value": "_CMU_HFRCOCTRL_BAND_21MHZ",
"macro_name": "HFRCO_FREQUENCY_ENUM"
[EFM32] Move board controller pin setting to config system
2016-10-28 06:21:39 +00:00
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PA9",
"macro_name": "EFM_BC_EN"
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
}
}
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
},
"EFM32HG322F64": {
"inherits": ["EFM32"],
Stop using device_has for non-mbed options As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
2017-03-17 12:01:50 +00:00
"extra_labels_add": ["EFM32HG", "64K", "SL_AES"],
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 17:50:01 +00:00
"core": "Cortex-M0+",
"default_toolchain": "uARM",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFM32HG322F64", "TRANSACTION_QUEUE_SIZE_SPI=0"],
[EFM32] Add IAR support for remaining Silicon Labs targets Added startup files and IAR memory map files for the remaining Silicon Labs targets as part of the mbed enabled criteria.
2016-09-14 15:06:21 +00:00
"supported_toolchains": ["GCC_ARM", "uARM", "IAR"],
Make selection of c library used consistent. * rename "default_build" property into "default_lib" * rename "standard" value for "default_build" into "std".
2016-08-17 12:16:07 +00:00
"default_lib": "small",
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"device_name": "EFM32HG322F64",
"public": false
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 17:50:01 +00:00
},
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"EFM32HG_STK3400": {
"inherits": ["EFM32HG322F64"],
Re-implement us_ticker and lp_ticker for Silicon Labs targets Re-implemented both us_ticker and lp_ticker to match the new API and specifications. Details: * On EFM32GG, EFM32WG, EFM32LG, EFM32HG, EFM32ZG: Use the RTC peripheral to back lp_ticker, and a TIMER to back us_ticker. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: Use the RTCC peripheral to back lp_ticker (dual-purpose, also used to back RTC), and a TIMER to back us_ticker.
2018-03-27 08:55:46 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"forced_reset_timeout": 2,
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "24000000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "21000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of _CMU_HFRCOCTRL_BAND_21MHZ, _CMU_HFRCOCTRL_BAND_14MHZ, _CMU_HFRCOCTRL_BAND_11MHZ, _CMU_HFRCOCTRL_BAND_7MHZ, _CMU_HFRCOCTRL_BAND_1MHZ. Be sure to set hfrco_clock_freq accordingly!",
"value": "_CMU_HFRCOCTRL_BAND_21MHZ",
"macro_name": "HFRCO_FREQUENCY_ENUM"
[EFM32] Move board controller pin setting to config system
2016-10-28 06:21:39 +00:00
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PA9",
"macro_name": "EFM_BC_EN"
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
}
}
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
},
"EFM32PG1B100F256GM32": {
"inherits": ["EFM32"],
Stop using device_has for non-mbed options As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
2017-03-17 12:01:50 +00:00
"extra_labels_add": ["EFM32PG", "256K", "SL_CRYPTO"],
Revert part of the FPU change We keep target.core names, it defines if CPU contains FPU, as it's common - Cortex M4F/M7F. We add Cortex M7FD for double precision FPU.
2016-07-08 15:16:12 +00:00
"core": "Cortex-M4F",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFM32PG1B100F256GM32", "TRANSACTION_QUEUE_SIZE_SPI=4"],
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 17:50:01 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32PG1B100F256GM32",
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
[EFM32] Use targets.json to improve directory structure Now that we have targets.json, we get target inheritance and can use it to clean up the EFM32 folder structure. * In the top-level EFM32 folder, there are now folders per MCU family (Giant, Leopard, ...) * Those family folders contain the CMSIS headers in the 'device' subfolder, as well as global family headers (i.e. mapping of pins to peripherals) * Inside of the family folder, there is a per-target folder containing target settings. In the future, we'll want to get rid of those by using the config system provided by targets.json
2016-10-22 16:31:07 +00:00
},
"EFM32PG_STK3401": {
"inherits": ["EFM32PG1B100F256GM32"],
Re-implement RTC for Silicon Labs targets mbed RTC specifications now dictate that the RTC needs to retain and keep on counting through reset. On Silicon Labs parts, this means the RTC API can not be backed by the Silicon Labs RTC peripheral, since that doesn't provide retention functionality. Therefore: * On EFM32GG, EFM32WG, EFM32LG: mbed RTC API is now backed by BURTC. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: mbed RTC API is now backed by RTCC. * On EFM32ZG, EFM32HG: mbed RTC API is sadly no longer supported, since these chips don't have retained memory.
2018-03-26 20:32:55 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "FLASH"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "40000000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "32000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of cmuHFRCOFreq_1M0Hz, cmuHFRCOFreq_2M0Hz, cmuHFRCOFreq_4M0Hz, cmuHFRCOFreq_7M0Hz, cmuHFRCOFreq_13M0Hz, cmuHFRCOFreq_16M0Hz, cmuHFRCOFreq_19M0Hz, cmuHFRCOFreq_26M0Hz, cmuHFRCOFreq_32M0Hz, cmuHFRCOFreq_38M0Hz. Be sure to set hfrco_clock_freq accordingly!",
"value": "cmuHFRCOFreq_32M0Hz",
"macro_name": "HFRCO_FREQUENCY_ENUM"
[EFM32] Move board controller pin setting to config system
2016-10-28 06:21:39 +00:00
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PA5",
"macro_name": "EFM_BC_EN"
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
}
}
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
},
[EFR32] fix typo in targets.json
2016-11-08 09:49:02 +00:00
"EFR32MG1P132F256GM48": {
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"inherits": ["EFM32"],
Upgrade RAIL to v2.1.1
2017-11-24 11:30:00 +00:00
"extra_labels_add": ["EFR32MG1", "EFR32_1", "256K", "SL_RAIL", "SL_CRYPTO"],
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"core": "Cortex-M4F",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFR32MG1P132F256GM48", "TRANSACTION_QUEUE_SIZE_SPI=4"],
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
"release_versions": ["2", "5"],
[EFR32] fix typo in targets.json
2016-11-08 09:49:02 +00:00
"device_name": "EFR32MG1P132F256GM48",
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
},
"EFR32MG1P233F256GM48": {
"inherits": ["EFM32"],
Upgrade RAIL to v2.1.1
2017-11-24 11:30:00 +00:00
"extra_labels_add": ["EFR32MG1", "EFR32_1", "256K", "SL_RAIL", "SL_CRYPTO"],
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"core": "Cortex-M4F",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFR32MG1P233F256GM48", "TRANSACTION_QUEUE_SIZE_SPI=4"],
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
"release_versions": ["2", "5"],
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
},
"EFR32MG1_BRD4150": {
[EFR32] fix typo in targets.json
2016-11-08 09:49:02 +00:00
"inherits": ["EFR32MG1P132F256GM48"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "FLASH"],
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"forced_reset_timeout": 2,
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "38400000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "32000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of cmuHFRCOFreq_1M0Hz, cmuHFRCOFreq_2M0Hz, cmuHFRCOFreq_4M0Hz, cmuHFRCOFreq_7M0Hz, cmuHFRCOFreq_13M0Hz, cmuHFRCOFreq_16M0Hz, cmuHFRCOFreq_19M0Hz, cmuHFRCOFreq_26M0Hz, cmuHFRCOFreq_32M0Hz, cmuHFRCOFreq_38M0Hz. Be sure to set hfrco_clock_freq accordingly!",
"value": "cmuHFRCOFreq_32M0Hz",
"macro_name": "HFRCO_FREQUENCY_ENUM"
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PA5",
"macro_name": "EFM_BC_EN"
}
},
"public": false
},
[Silicon Labs] Rename targets Due to limitation in the mbed website backend (board names need to be <= 19 characters), we are shortening the CLI target names from THUNDERBOARD to TB. @screamerbg
2017-03-28 18:14:16 +00:00
"TB_SENSE_1": {
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"inherits": ["EFR32MG1P233F256GM48"],
Re-implement RTC for Silicon Labs targets mbed RTC specifications now dictate that the RTC needs to retain and keep on counting through reset. On Silicon Labs parts, this means the RTC API can not be backed by the Silicon Labs RTC peripheral, since that doesn't provide retention functionality. Therefore: * On EFM32GG, EFM32WG, EFM32LG: mbed RTC API is now backed by BURTC. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: mbed RTC API is now backed by RTCC. * On EFM32ZG, EFM32HG: mbed RTC API is sadly no longer supported, since these chips don't have retained memory.
2018-03-26 20:32:55 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "FLASH"],
First pass on TB Sense (and EFR32MG12) support
2017-03-13 17:10:00 +00:00
"forced_reset_timeout": 5,
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "38400000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "32000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of cmuHFRCOFreq_1M0Hz, cmuHFRCOFreq_2M0Hz, cmuHFRCOFreq_4M0Hz, cmuHFRCOFreq_7M0Hz, cmuHFRCOFreq_13M0Hz, cmuHFRCOFreq_16M0Hz, cmuHFRCOFreq_19M0Hz, cmuHFRCOFreq_26M0Hz, cmuHFRCOFreq_32M0Hz, cmuHFRCOFreq_38M0Hz. Be sure to set hfrco_clock_freq accordingly!",
"value": "cmuHFRCOFreq_32M0Hz",
"macro_name": "HFRCO_FREQUENCY_ENUM"
}
}
Add new target EFM32PG12
2017-03-14 13:16:52 +00:00
},
Bugfix for EFM32PG12 and EFR32MG12 * Off by one error in the linker scripts reserved one word too little for the vector table * Re-apply uvisor changes to emlib. To allow uvisor to run, we should make accesses to the romtable through uvisor's secure read gateway * Copypasta in target name (EFM32PG12, not EFR32PG12) * Copypasta in the pin definitions (thanks @akselsm) * Forgot to update PortName for extra ports on MG/PG12
2017-03-14 16:00:44 +00:00
"EFM32PG12B500F1024GL125": {
Add new target EFM32PG12
2017-03-14 13:16:52 +00:00
"inherits": ["EFM32"],
Stop using device_has for non-mbed options As asked by @0xc0170 in PR #3934, we won't be using device_has for indicating RF/Crypto features any longer. RF config options moved to the SL_RAIL lib.json, crypto config options will come with mbedTLS integration.
2017-03-17 12:01:50 +00:00
"extra_labels_add": ["EFM32PG12", "1024K", "SL_CRYPTO"],
Add new target EFM32PG12
2017-03-14 13:16:52 +00:00
"core": "Cortex-M4F",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFM32PG12B500F1024GL125", "TRANSACTION_QUEUE_SIZE_SPI=4"],
Add new target EFM32PG12
2017-03-14 13:16:52 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
"release_versions": ["2", "5"],
Add missing device_name for targets with bootloader
2017-10-25 08:40:10 +00:00
"device_name": "EFM32PG12B500F1024GL125",
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
Add new target EFM32PG12
2017-03-14 13:16:52 +00:00
},
"EFM32PG12_STK3402": {
Bugfix for EFM32PG12 and EFR32MG12 * Off by one error in the linker scripts reserved one word too little for the vector table * Re-apply uvisor changes to emlib. To allow uvisor to run, we should make accesses to the romtable through uvisor's secure read gateway * Copypasta in target name (EFM32PG12, not EFR32PG12) * Copypasta in the pin definitions (thanks @akselsm) * Forgot to update PortName for extra ports on MG/PG12
2017-03-14 16:00:44 +00:00
"inherits": ["EFM32PG12B500F1024GL125"],
Re-implement RTC for Silicon Labs targets mbed RTC specifications now dictate that the RTC needs to retain and keep on counting through reset. On Silicon Labs parts, this means the RTC API can not be backed by the Silicon Labs RTC peripheral, since that doesn't provide retention functionality. Therefore: * On EFM32GG, EFM32WG, EFM32LG: mbed RTC API is now backed by BURTC. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: mbed RTC API is now backed by RTCC. * On EFM32ZG, EFM32HG: mbed RTC API is sadly no longer supported, since these chips don't have retained memory.
2018-03-26 20:32:55 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "TRNG", "FLASH"],
Add new target EFM32PG12
2017-03-14 13:16:52 +00:00
"forced_reset_timeout": 2,
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "40000000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "32000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of cmuHFRCOFreq_1M0Hz, cmuHFRCOFreq_2M0Hz, cmuHFRCOFreq_4M0Hz, cmuHFRCOFreq_7M0Hz, cmuHFRCOFreq_13M0Hz, cmuHFRCOFreq_16M0Hz, cmuHFRCOFreq_19M0Hz, cmuHFRCOFreq_26M0Hz, cmuHFRCOFreq_32M0Hz, cmuHFRCOFreq_38M0Hz. Be sure to set hfrco_clock_freq accordingly!",
"value": "cmuHFRCOFreq_32M0Hz",
"macro_name": "HFRCO_FREQUENCY_ENUM"
},
"board_controller_enable": {
"help": "Pin to pull high for enabling the USB serial port",
"value": "PA5",
"macro_name": "EFM_BC_EN"
}
}
First pass on TB Sense (and EFR32MG12) support
2017-03-13 17:10:00 +00:00
},
Added support for ADI EV-COG-AD4050LZ platform.
2017-09-20 04:37:22 +00:00
"EFR32MG12P332F1024GL125": {
First pass on TB Sense (and EFR32MG12) support
2017-03-13 17:10:00 +00:00
"inherits": ["EFM32"],
Upgrade RAIL to v2.1.1
2017-11-24 11:30:00 +00:00
"extra_labels_add": ["EFR32MG12", "EFR32_12", "1024K", "SL_RAIL", "SL_CRYPTO"],
First pass on TB Sense (and EFR32MG12) support
2017-03-13 17:10:00 +00:00
"core": "Cortex-M4F",
Apply feedback by @Patater
2017-11-11 18:38:54 +00:00
"macros_add": ["EFR32MG12P332F1024GL125", "TRANSACTION_QUEUE_SIZE_SPI=4"],
First pass on TB Sense (and EFR32MG12) support
2017-03-13 17:10:00 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
"release_versions": ["2", "5"],
Add missing device_name for targets with bootloader
2017-10-25 08:40:10 +00:00
"device_name": "EFR32MG12P332F1024GL125",
[Silicon Labs] Add bootloader support * Make memory sections configurable in linker files * Dynamically determine vector location in flash for NVIC relocation * Advertise bootloader support in targets.json
2017-03-27 13:00:59 +00:00
"public": false,
"bootloader_supported": true
First pass on TB Sense (and EFR32MG12) support
2017-03-13 17:10:00 +00:00
},
Added support for ADI EV-COG-AD4050LZ platform.
2017-09-20 04:37:22 +00:00
"TB_SENSE_12": {
First pass on TB Sense (and EFR32MG12) support
2017-03-13 17:10:00 +00:00
"inherits": ["EFR32MG12P332F1024GL125"],
Adding device_name for TB_SENSE_12. device_name key is required to add Cloud Client support / enable bootloader support for this target.
2017-11-09 17:33:12 +00:00
"device_name": "EFR32MG12P332F1024GL125",
Re-implement RTC for Silicon Labs targets mbed RTC specifications now dictate that the RTC needs to retain and keep on counting through reset. On Silicon Labs parts, this means the RTC API can not be backed by the Silicon Labs RTC peripheral, since that doesn't provide retention functionality. Therefore: * On EFM32GG, EFM32WG, EFM32LG: mbed RTC API is now backed by BURTC. * On EFM32PG, EFR32MG, EFM32PG12, EFR32MG12: mbed RTC API is now backed by RTCC. * On EFM32ZG, EFM32HG: mbed RTC API is sadly no longer supported, since these chips don't have retained memory.
2018-03-26 20:32:55 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LPTICKER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "USTICKER", "TRNG", "FLASH"],
[EFR32] fix typo in targets.json
2016-11-08 09:49:02 +00:00
"forced_reset_timeout": 5,
[EFR32] Add initial support for EFR32 Adding target definitions and the HAL implementation for EFR32 Mighty Gecko
2016-10-28 06:26:27 +00:00
"config": {
"hf_clock_src": {
"help": "Value: HFXO for external crystal, HFRCO for internal RC oscillator",
"value": "HFXO",
"macro_name": "CORE_CLOCK_SOURCE"
},
"hfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "38400000",
"macro_name": "HFXO_FREQUENCY"
},
"lf_clock_src": {
"help": "Value: LFXO for external crystal, LFRCO for internal RC oscillator, ULFRCO for internal 1KHz RC oscillator",
[EFM32] Move clock configuration to target settings Moving the per-board clock configuration (which oscillators are available on the board, their frequencies, and which ones to use) as config options to the target database. This way, they're more easily overridable when third parties start creating boards with EFM32 MCUs
2016-10-22 20:26:29 +00:00
"value": "LFXO",
"macro_name": "LOW_ENERGY_CLOCK_SOURCE"
},
"lfxo_clock_freq": {
"help": "Value: External crystal frequency in hertz",
"value": "32768",
"macro_name": "LFXO_FREQUENCY"
},
"hfrco_clock_freq": {
"help": "Value: Frequency in hertz, must correspond to setting of hfrco_band_select",
"value": "32000000",
"macro_name": "HFRCO_FREQUENCY"
},
"hfrco_band_select": {
"help": "Value: One of cmuHFRCOFreq_1M0Hz, cmuHFRCOFreq_2M0Hz, cmuHFRCOFreq_4M0Hz, cmuHFRCOFreq_7M0Hz, cmuHFRCOFreq_13M0Hz, cmuHFRCOFreq_16M0Hz, cmuHFRCOFreq_19M0Hz, cmuHFRCOFreq_26M0Hz, cmuHFRCOFreq_32M0Hz, cmuHFRCOFreq_38M0Hz. Be sure to set hfrco_clock_freq accordingly!",
"value": "cmuHFRCOFreq_32M0Hz",
"macro_name": "HFRCO_FREQUENCY_ENUM"
}
}
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 17:50:01 +00:00
},
"WIZWIKI_W7500": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"extra_labels": ["WIZNET", "W7500x", "WIZwiki_W7500"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
add to support gcc & iar
2017-04-28 05:25:35 +00:00
"supported_toolchains": ["uARM", "ARM", "GCC_ARM", "IAR"],
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 17:50:01 +00:00
"inherits": ["Target"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Modifying the code to support mbed OS 5 -> add mbed_rtx.h Modifying the code for mbed ci shield test -> analogin_api.c, W7500x_adc.c, gpio_irq_api.c, W7500x_gpio.c Modifying the code for fix bug -> W7500x_uart.c(register control driver problem), W7500x_uart.h, pinmap.c(pullup, pulldown problem)
2017-04-25 23:52:04 +00:00
"release_versions": ["2", "5"]
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 17:50:01 +00:00
},
"WIZWIKI_W7500P": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"extra_labels": ["WIZNET", "W7500x", "WIZwiki_W7500P"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
add to support gcc & iar
2017-04-28 05:25:35 +00:00
"supported_toolchains": ["uARM", "ARM", "GCC_ARM", "IAR"],
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 17:50:01 +00:00
"inherits": ["Target"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Modifying the code to support mbed OS 5 -> add mbed_rtx.h Modifying the code for mbed ci shield test -> analogin_api.c, W7500x_adc.c, gpio_irq_api.c, W7500x_gpio.c Modifying the code for fix bug -> W7500x_uart.c(register control driver problem), W7500x_uart.h, pinmap.c(pullup, pulldown problem)
2017-04-25 23:52:04 +00:00
"release_versions": ["2", "5"]
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 17:50:01 +00:00
},
"WIZWIKI_W7500ECO": {
"inherits": ["Target"],
"core": "Cortex-M0",
"extra_labels": ["WIZNET", "W7500x", "WIZwiki_W7500ECO"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
add to support gcc & iar
2017-04-28 05:25:35 +00:00
"supported_toolchains": ["uARM", "ARM", "GCC_ARM", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Modifying the code to support mbed OS 5 -> add mbed_rtx.h Modifying the code for mbed ci shield test -> analogin_api.c, W7500x_adc.c, gpio_irq_api.c, W7500x_gpio.c Modifying the code for fix bug -> W7500x_uart.c(register control driver problem), W7500x_uart.h, pinmap.c(pullup, pulldown problem)
2017-04-25 23:52:04 +00:00
"release_versions": ["2", "5"]
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 17:50:01 +00:00
},
"SAMR21G18A": {
"inherits": ["Target"],
"core": "Cortex-M0+",
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"macros": ["__SAMR21G18A__", "I2C_MASTER_CALLBACK_MODE=true", "EXTINT_CALLBACK_MODE=true", "USART_CALLBACK_MODE=true", "TC_ASYNC=true"],
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 17:50:01 +00:00
"extra_labels": ["Atmel", "SAM_CortexM0P", "SAMR21"],
"supported_toolchains": ["GCC_ARM", "ARM", "uARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "ATSAMR21G18A"
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 17:50:01 +00:00
},
"SAMD21J18A": {
"inherits": ["Target"],
"core": "Cortex-M0+",
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"macros": ["__SAMD21J18A__", "I2C_MASTER_CALLBACK_MODE=true", "EXTINT_CALLBACK_MODE=true", "USART_CALLBACK_MODE=true", "TC_ASYNC=true"],
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 17:50:01 +00:00
"extra_labels": ["Atmel", "SAM_CortexM0P", "SAMD21"],
"supported_toolchains": ["GCC_ARM", "ARM", "uARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
Fix formatting in targets/targets.json
2017-03-31 09:47:50 +00:00
"device_name": "ATSAMD21J18A"
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 17:50:01 +00:00
},
"SAMD21G18A": {
"inherits": ["Target"],
"core": "Cortex-M0+",
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"macros": ["__SAMD21G18A__", "I2C_MASTER_CALLBACK_MODE=true", "EXTINT_CALLBACK_MODE=true", "USART_CALLBACK_MODE=true", "TC_ASYNC=true"],
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 17:50:01 +00:00
"extra_labels": ["Atmel", "SAM_CortexM0P", "SAMD21"],
"supported_toolchains": ["GCC_ARM", "ARM", "uARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "ATSAMD21G18A"
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 17:50:01 +00:00
},
"SAML21J18A": {
"inherits": ["Target"],
"core": "Cortex-M0+",
auto-formatted target.json
2016-06-01 19:37:49 +00:00
"macros": ["__SAML21J18A__", "I2C_MASTER_CALLBACK_MODE=true", "EXTINT_CALLBACK_MODE=true", "USART_CALLBACK_MODE=true", "TC_ASYNC=true"],
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 17:50:01 +00:00
"extra_labels": ["Atmel", "SAM_CortexM0P", "SAML21"],
"supported_toolchains": ["GCC_ARM", "ARM", "uARM"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "ATSAML21J18A"
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 17:50:01 +00:00
},
"SAMG55J19": {
"inherits": ["Target"],
"core": "Cortex-M4",
"extra_labels": ["Atmel", "SAM_CortexM4", "SAMG55"],
"macros": ["__SAMG55J19__", "BOARD=75", "I2C_MASTER_CALLBACK_MODE=true", "EXTINT_CALLBACK_MODE=true", "USART_CALLBACK_MODE=true", "TC_ASYNC=true"],
"supported_toolchains": ["GCC_ARM", "ARM", "uARM"],
"default_toolchain": "ARM",
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"default_lib": "std",
"device_name": "ATSAMG55J19"
Support for Blue Pill
2016-06-29 08:05:27 +00:00
},
Makes room for old NRF51 implementation. the unified target for NRF51 has been renamed MCU_NRF51_UNIFIED and hal implementation has been moved from TARGET_MCU_NRF51822 to TARGET_MCU_NRF51822_UNIFIED. In the process, the only real taget kept for NRF51 based targets is NRF51_DK. It is too risky at this stage to switch NRF51822 (16K target) to the new softdevice. The overhead of the RTOS is already too huge.
2016-07-20 23:02:44 +00:00
"MCU_NRF51_UNIFIED": {
"inherits": ["Target"],
"core": "Cortex-M0",
"OVERRIDE_BOOTLOADER_FILENAME": "nrf51822_bootloader.hex",
More formatting changes in targets.json
2016-10-05 01:34:45 +00:00
"macros": [
"NRF51",
"TARGET_NRF51822",
"BLE_STACK_SUPPORT_REQD",
"SOFTDEVICE_PRESENT",
"S130",
Enable CMSIS_VECTAB_VIRTUAL for Nordic platforms This change is part of CMSIS5 update. Enabling CMSIS_VECTAB_VIRTUAL for Nordic platform is necessary to preserve platform specific NVIC ops.
2017-05-15 09:12:41 +00:00
"TARGET_MCU_NRF51822",
"CMSIS_VECTAB_VIRTUAL",
Add tickless support for devices without SysTick Some Cortex-M0 devices, such as the nrf51, don't have the SysTick. Instead, these targets use a software interrupt to simulate SysTick. Add the hooks in the tickless code to support these devices. Targets which do not have SysTick should now define NO_SYSTICK in targets.json and implement mbed_get_m0_tick_irqn to add os suport. This patch also removes os tick handling from the existing devices (nrf51) since this is now handled in common code.
2017-08-30 01:48:39 +00:00
"CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\"",
Enable us/lp ticker support for NRF51_DK board
2018-01-18 06:59:36 +00:00
"NO_SYSTICK",
"MBED_TICKLESS"
More formatting changes in targets.json
2016-10-05 01:34:45 +00:00
],
Makes room for old NRF51 implementation. the unified target for NRF51 has been renamed MCU_NRF51_UNIFIED and hal implementation has been moved from TARGET_MCU_NRF51822 to TARGET_MCU_NRF51822_UNIFIED. In the process, the only real taget kept for NRF51 based targets is NRF51_DK. It is too risky at this stage to switch NRF51822 (16K target) to the new softdevice. The overhead of the RTOS is already too huge.
2016-07-20 23:02:44 +00:00
"MERGE_BOOTLOADER": false,
Reorganize TARGET_MCU_NRF51822_UNIFIED directories The unified NRF51 target and feature BLE directories have been reorganized to follow the naming and directory structure of the NRF52 implementation. This reorganization does not include TARGET_MCU_NRF51822 and derived targets.
2018-04-23 17:12:40 +00:00
"extra_labels": [
"NORDIC",
"MCU_NRF51",
"MCU_NRF51822_UNIFIED",
"NRF5x",
"NRF51",
"SDK_11"
],
Makes room for old NRF51 implementation. the unified target for NRF51 has been renamed MCU_NRF51_UNIFIED and hal implementation has been moved from TARGET_MCU_NRF51822 to TARGET_MCU_NRF51822_UNIFIED. In the process, the only real taget kept for NRF51 based targets is NRF51_DK. It is too risky at this stage to switch NRF51822 (16K target) to the new softdevice. The overhead of the RTOS is already too huge.
2016-07-20 23:02:44 +00:00
"OUTPUT_EXT": "hex",
"is_disk_virtual": true,
Set correct compiler support for NRF51 and NRF52 based targets.
2016-07-20 23:10:52 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
Makes room for old NRF51 implementation. the unified target for NRF51 has been renamed MCU_NRF51_UNIFIED and hal implementation has been moved from TARGET_MCU_NRF51822 to TARGET_MCU_NRF51822_UNIFIED. In the process, the only real taget kept for NRF51 based targets is NRF51_DK. It is too risky at this stage to switch NRF51822 (16K target) to the new softdevice. The overhead of the RTOS is already too huge.
2016-07-20 23:02:44 +00:00
"public": false,
"MERGE_SOFT_DEVICE": true,
"EXPECTED_SOFTDEVICES_WITH_OFFSETS": [
{
"boot": "",
"name": "s130_nrf51_2.0.0_softdevice.hex",
"offset": 110592
}
],
"detect_code": ["1070"],
"post_binary_hook": {
"function": "MCU_NRF51Code.binary_hook",
"toolchains": ["ARM_STD", "GCC_ARM", "IAR"]
},
"program_cycle_s": 6,
"features": ["BLE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"config": {
Minor formatting changes
2016-10-05 00:34:52 +00:00
"lf_clock_src": {
"value": "NRF_LF_SRC_XTAL",
More formatting changes in targets.json
2016-10-05 01:34:45 +00:00
"macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_SRC"
},
Introduce uart hardware flow control configuration using mbed configuraton system for nrf5x base-targets
2016-08-24 09:02:19 +00:00
"uart_hwfc": {
"help": "Value: 1 for enable, 0 for disable",
"value": 1,
"macro_name": "MBED_CONF_NORDIC_UART_HWFC"
Makes room for old NRF51 implementation. the unified target for NRF51 has been renamed MCU_NRF51_UNIFIED and hal implementation has been moved from TARGET_MCU_NRF51822 to TARGET_MCU_NRF51822_UNIFIED. In the process, the only real taget kept for NRF51 based targets is NRF51_DK. It is too risky at this stage to switch NRF51822 (16K target) to the new softdevice. The overhead of the RTOS is already too huge.
2016-07-20 23:02:44 +00:00
}
Add device_has to all nrf51 devices Move common device_has attributes into MCU_NRF51 and MCU_NRF51_UNIFIED. This ensures all nrf51 devices have the correct features enabled. Any devices that want to explicitly disable features should use device_has_remove.
2016-09-13 17:57:37 +00:00
},
Enable support for NRF51 boards. Make it consistent with master.
2018-05-18 05:38:21 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"]
Makes room for old NRF51 implementation. the unified target for NRF51 has been renamed MCU_NRF51_UNIFIED and hal implementation has been moved from TARGET_MCU_NRF51822 to TARGET_MCU_NRF51822_UNIFIED. In the process, the only real taget kept for NRF51 based targets is NRF51_DK. It is too risky at this stage to switch NRF51822 (16K target) to the new softdevice. The overhead of the RTOS is already too huge.
2016-07-20 23:02:44 +00:00
},
"MCU_NRF51_32K_UNIFIED": {
"inherits": ["MCU_NRF51_UNIFIED"],
"extra_labels_add": ["MCU_NORDIC_32K", "MCU_NRF51_32K"],
"macros_add": ["TARGET_MCU_NORDIC_32K", "TARGET_MCU_NRF51_32K"],
"public": false
},
"NRF51_DK": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_UNIFIED"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
Enable support for NRF51 boards.
2018-05-17 05:58:59 +00:00
"release_versions": ["2", "5"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "nRF51822_xxAA"
Makes room for old NRF51 implementation. the unified target for NRF51 has been renamed MCU_NRF51_UNIFIED and hal implementation has been moved from TARGET_MCU_NRF51822 to TARGET_MCU_NRF51822_UNIFIED. In the process, the only real taget kept for NRF51 based targets is NRF51_DK. It is too risky at this stage to switch NRF51822 (16K target) to the new softdevice. The overhead of the RTOS is already too huge.
2016-07-20 23:02:44 +00:00
},
NORDIC - Update NRF51_DONGLE target to takes advantage of the NRF5 implementation of BLE and device drivers.
2016-09-22 12:36:57 +00:00
"NRF51_DONGLE": {
"inherits": ["MCU_NRF51_32K_UNIFIED"],
"progen": {"target": "nrf51-dongle"},
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "LPTICKER", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
Enable support for NRF51 boards.
2018-05-17 05:58:59 +00:00
"release_versions": ["2", "5"]
NORDIC - Update NRF51_DONGLE target to takes advantage of the NRF5 implementation of BLE and device drivers.
2016-09-22 12:36:57 +00:00
},
move OSHCHIP to be with other nRF51 boards
2018-01-23 21:22:10 +00:00
"OSHCHIP": {
"inherits": ["MCU_NRF51_32K_UNIFIED"],
move device_has to OSHCHIP specifically and define device name. These should probably move to the unified target at some point but is outside the scope of this PR
2018-02-06 05:23:26 +00:00
"overrides": {"lf_clock_src": "NRF_LF_SRC_RC"},
Enable support for NRF51 boards. Make it consistent with master.
2018-05-18 05:38:21 +00:00
"device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
move device_has to OSHCHIP specifically and define device name. These should probably move to the unified target at some point but is outside the scope of this PR
2018-02-06 05:23:26 +00:00
"device_name": "nRF51822_xxAC"
move OSHCHIP to be with other nRF51 boards
2018-01-23 21:22:10 +00:00
},
Change target.json to use new SDK and folder structure for NRF52
2018-01-17 20:43:04 +00:00
"MCU_NRF52832": {
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
"inherits": ["Target"],
"core": "Cortex-M4F",
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
"macros": [
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"BOARD_PCA10040",
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
"NRF52",
"TARGET_NRF52832",
"CMSIS_VECTAB_VIRTUAL",
"CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\"",
"MBED_TICKLESS"
],
"device_has": [
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"ANALOGIN",
Flash storage for NRF52 Add fstorage and fds from Nordic SDK for SoftDevice compatible flash storage. Mbed HAL flash API mapped to use fstorage API to ensure write and erase doesn't conflict with BLE operation.
2018-02-18 04:10:41 +00:00
"FLASH",
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"I2C",
"I2C_ASYNCH",
"INTERRUPTIN",
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"ITM",
NRF52_DK: Enable lp ticker and us ticker support
2018-05-21 07:02:46 +00:00
"LPTICKER",
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"PORTIN",
"PORTINOUT",
"PORTOUT",
"PWMOUT",
"SERIAL",
"SERIAL_ASYNCH",
"SERIAL_FC",
"SPI",
"SPI_ASYNCH",
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"STCLK_OFF_DURING_SLEEP",
Disable boards which does not fulfil new sleep standards. These boards will be re-enabled when sleep driver for them is ready. Note: This operation is done by removing "SLEEP" feature from target's "device_has" list (in targets.json config file). For NRF52_DK removing of "SLEEP" feature causes some timing issues which have influence on tests. In order to successfully disable this board we need to disable also related features like "USTICKER", "LOWPOERTIMER" and slightly modify ticker tests, so they will not be executed if usticker support is not available (by default all targets support us ticker).
2017-12-21 09:52:40 +00:00
"TRNG",
"USTICKER"
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
],
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
"extra_labels": [
"NORDIC",
"NRF5x",
"NRF52",
"SDK_14_2",
"SOFTDEVICE_COMMON",
Add NRF52 support for building bootloader and updateable firmware New directory structure: * TARGET_SOFTDEVICE_COMMON * TARGET_SOFTDEVICE_S112 * TARGET_SOFTDEVICE_S132_FULL (MBR + SoftDevice, default) * TARGET_SOFTDEVICE_S132_OTA (SoftDevice only, for firmware updates) * TARGET_SOFTDEVICE_S132_MBR (MBR only, for bootloader builds) * TARGET_SOFTDEVICE_S140_FULL (MBR + SoftDevice, default) * TARGET_SOFTDEVICE_S140_OTA (SoftDevice only, for firmware updates) * TARGET_SOFTDEVICE_S140_MBR (MBR only, for bootloader builds) * TARGET_SOFTDEVICE_NONE The X_OTA and X_MBR binaries are obtained from the original x_FULL SoftDevice by splitting it in an MBR part and a SoftDevice part. The MBR is needed for the bootloader and the SoftDevice for firmware updates. Build application without SoftDevice: "target_overrides": { "*": { "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_X_FULL"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Build application for firmware update using SoftDevice X: "target_overrides": { "*": { "target.extra_labels_remove": ["SOFTDEVICE_X_FULL"], "target.extra_labels_add": ["SOFTDEVICE_X_OTA"] } } Build bootloader without SoftDevice X: "target_overrides": { "*": { "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_X_FULL"], "target.extra_labels_add": ["SOFTDEVICE_X_MBR"] } }
2018-05-14 06:02:02 +00:00
"SOFTDEVICE_S132_FULL"
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
],
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"config": {
"lf_clock_src": {
"macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_SRC",
"help": "Select Low Frequency clock source. Options: NRF_LF_SRC_XTAL, NRF_LF_SRC_SYNTH, and NRF_LF_SRC_RC",
"value": "NRF_LF_SRC_XTAL"
},
"lf_clock_rc_calib_timer_interval": {
"macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_CALIB_TIMER_INTERVAL",
"value": 16
},
"lf_clock_rc_calib_mode_config": {
"macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_CALIB_MODE_CONFIG",
"value": 0
}
},
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
"OUTPUT_EXT": "hex",
"is_disk_virtual": true,
Set correct compiler support for NRF51 and NRF52 based targets.
2016-07-20 23:10:52 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
"public": false,
Update detection code for NRF52.
2016-06-15 10:26:53 +00:00
"detect_code": ["1101"],
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
"program_cycle_s": 6,
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"bootloader_supported": true
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
},
"NRF52_DK": {
"supported_form_factors": ["ARDUINO"],
Change target.json to use new SDK and folder structure for NRF52
2018-01-17 20:43:04 +00:00
"inherits": ["MCU_NRF52832"],
NRF52_DK: Enable lp ticker and us ticker support
2018-05-21 07:02:46 +00:00
"release_versions": ["5"],
Additional device names. mbed_targets.md update
2016-09-21 19:36:21 +00:00
"device_name": "nRF52832_xxAA"
DELTA_DFBM_NQ620 platform porting DELTA_DFBM_NQ620 inherit to MCU_NRF52 HW config is the same with NRF52_DK Only change on serial pin config in PinNames.h
2016-09-09 09:45:08 +00:00
},
Update targets.json
2016-11-18 16:15:08 +00:00
"UBLOX_EVA_NINA": {
Change target.json to use new SDK and folder structure for NRF52
2018-01-17 20:43:04 +00:00
"inherits": ["MCU_NRF52832"],
Enable us lp ticker support for entire MCU_NRF52832 family
2018-05-23 11:58:46 +00:00
"release_versions": ["5"],
Target: Add new target UBLOX_EVK_NINA_B1 Based on nrf51 MCU.
2016-11-28 11:06:51 +00:00
"device_name": "nRF52832_xxAA"
},
"UBLOX_EVK_NINA_B1": {
"supported_form_factors": ["ARDUINO"],
Change target.json to use new SDK and folder structure for NRF52
2018-01-17 20:43:04 +00:00
"inherits": ["MCU_NRF52832"],
Enable us lp ticker support for entire MCU_NRF52832 family
2018-05-23 11:58:46 +00:00
"release_versions": ["5"],
Update targets.json
2016-11-18 16:15:08 +00:00
"device_name": "nRF52832_xxAA"
},
Adding MTB ublox NINA-B1 as a new target
2018-01-12 13:08:27 +00:00
"MTB_UBLOX_NINA_B1": {
Renamed MCU_NRF52832 inheritance in MTB_UBLOX_NINA_B1
2018-01-31 19:11:58 +00:00
"inherits": ["MCU_NRF52832"],
Enable us lp ticker support for entire MCU_NRF52832 family
2018-05-23 11:58:46 +00:00
"release_versions": ["5"],
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"device_name": "nRF52832_xxAA"
Adding MTB ublox NINA-B1 as a new target
2018-01-12 13:08:27 +00:00
},
Adding Laird BL652 as new target
2018-02-22 11:49:58 +00:00
"MTB_LAIRD_BL652": {
Updated target MTB_LAIRD_BL652 to use SDK 14.2
2018-03-26 10:38:49 +00:00
"inherits": ["MCU_NRF52832"],
Enable us lp ticker support for entire MCU_NRF52832 family
2018-05-23 11:58:46 +00:00
"release_versions": ["5"],
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"device_name": "nRF52832_xxAA"
Adding Laird BL652 as new target
2018-02-22 11:49:58 +00:00
},
DELTA_DFBM_NQ620 platform porting DELTA_DFBM_NQ620 inherit to MCU_NRF52 HW config is the same with NRF52_DK Only change on serial pin config in PinNames.h
2016-09-09 09:45:08 +00:00
"DELTA_DFBM_NQ620": {
"supported_form_factors": ["ARDUINO"],
Change target.json to use new SDK and folder structure for NRF52
2018-01-17 20:43:04 +00:00
"inherits": ["MCU_NRF52832"],
Enable us lp ticker support for entire MCU_NRF52832 family
2018-05-23 11:58:46 +00:00
"release_versions": ["5"],
Additional device names. mbed_targets.md update
2016-09-21 19:36:21 +00:00
"device_name": "nRF52832_xxAA"
Merge commit 'ce830296d0297a8da543c24134bf859710fd7698' into epr_integration Merge the EPR tag and the nordic branch together.
2016-07-13 11:06:02 +00:00
},
+ description of the NRF52840_DK target + mbed RTx setings for nRF52840 fix build of test for NRF52840 + few sdk's missing filess - few sdk's unvanted files corect mbed HAL implementation to changes made in sdk v13
2016-12-19 10:31:15 +00:00
"MCU_NRF52840": {
"inherits": ["Target"],
"core": "Cortex-M4F",
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
"macros": [
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"BOARD_PCA10056",
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
"NRF52840_XXAA",
"TARGET_NRF52840",
"CMSIS_VECTAB_VIRTUAL",
"CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\"",
Change target name Apply the CC changes to TARGET_MCU_NRF52840 , and not to the DK target alone
2018-05-22 06:24:37 +00:00
"MBED_TICKLESS",
"MBEDTLS_CONFIG_HW_SUPPORT"
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
],
Change target name Apply the CC changes to TARGET_MCU_NRF52840 , and not to the DK target alone
2018-05-22 06:24:37 +00:00
"features": ["CRYPTOCELL310"],
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
"device_has": [
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"ANALOGIN",
Flash storage for NRF52 Add fstorage and fds from Nordic SDK for SoftDevice compatible flash storage. Mbed HAL flash API mapped to use fstorage API to ensure write and erase doesn't conflict with BLE operation.
2018-02-18 04:10:41 +00:00
"FLASH",
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"I2C",
"I2C_ASYNCH",
"INTERRUPTIN",
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"ITM",
NRF52840_DK: Enable lp us ticker support
2018-05-24 07:25:18 +00:00
"LPTICKER",
[MAX32625PICO] Add new platform This platform is available with or without Bootloader.
2018-04-30 21:11:03 +00:00
"PORTIN",
"PORTINOUT",
"PORTOUT",
"PWMOUT",
"RTC",
"SERIAL",
"SERIAL_ASYNCH",
"SERIAL_FC",
"SLEEP",
"SPI",
"SPI_ASYNCH",
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"STCLK_OFF_DURING_SLEEP",
Disable boards which does not fulfil new sleep standards. These boards will be re-enabled when sleep driver for them is ready. Note: This operation is done by removing "SLEEP" feature from target's "device_has" list (in targets.json config file). For NRF52_DK removing of "SLEEP" feature causes some timing issues which have influence on tests. In order to successfully disable this board we need to disable also related features like "USTICKER", "LOWPOERTIMER" and slightly modify ticker tests, so they will not be executed if usticker support is not available (by default all targets support us ticker).
2017-12-21 09:52:40 +00:00
"TRNG",
"USTICKER"
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
],
"extra_labels": [
"NORDIC",
"NRF5x",
"NRF52",
"SDK_14_2",
"SOFTDEVICE_COMMON",
Add NRF52 support for building bootloader and updateable firmware New directory structure: * TARGET_SOFTDEVICE_COMMON * TARGET_SOFTDEVICE_S112 * TARGET_SOFTDEVICE_S132_FULL (MBR + SoftDevice, default) * TARGET_SOFTDEVICE_S132_OTA (SoftDevice only, for firmware updates) * TARGET_SOFTDEVICE_S132_MBR (MBR only, for bootloader builds) * TARGET_SOFTDEVICE_S140_FULL (MBR + SoftDevice, default) * TARGET_SOFTDEVICE_S140_OTA (SoftDevice only, for firmware updates) * TARGET_SOFTDEVICE_S140_MBR (MBR only, for bootloader builds) * TARGET_SOFTDEVICE_NONE The X_OTA and X_MBR binaries are obtained from the original x_FULL SoftDevice by splitting it in an MBR part and a SoftDevice part. The MBR is needed for the bootloader and the SoftDevice for firmware updates. Build application without SoftDevice: "target_overrides": { "*": { "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_X_FULL"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Build application for firmware update using SoftDevice X: "target_overrides": { "*": { "target.extra_labels_remove": ["SOFTDEVICE_X_FULL"], "target.extra_labels_add": ["SOFTDEVICE_X_OTA"] } } Build bootloader without SoftDevice X: "target_overrides": { "*": { "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_X_FULL"], "target.extra_labels_add": ["SOFTDEVICE_X_MBR"] } }
2018-05-14 06:02:02 +00:00
"SOFTDEVICE_S140_FULL"
Optional SoftDevice for the NRF52 series Ability to swap SoftDevices using the mbed configuration system. For example, build NRF52840_DK without SoftDevice: "target_overrides": { "*": { "target.MERGE_SOFT_DEVICE": false, "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"], "target.extra_labels_add": ["SOFTDEVICE_NONE"] } } Pinned down vector table to beginningn of RAM.
2018-02-01 20:02:11 +00:00
],
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"config": {
"lf_clock_src": {
"macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_SRC",
"help": "Select Low Frequency clock source. Options: NRF_LF_SRC_XTAL, NRF_LF_SRC_SYNTH, and NRF_LF_SRC_RC",
"value": "NRF_LF_SRC_XTAL"
},
"lf_clock_rc_calib_timer_interval": {
"macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_CALIB_TIMER_INTERVAL",
"value": 16
},
"lf_clock_rc_calib_mode_config": {
"macro_name": "MBED_CONF_NORDIC_NRF_LF_CLOCK_CALIB_MODE_CONFIG",
"value": 0
}
},
+ description of the NRF52840_DK target + mbed RTx setings for nRF52840 fix build of test for NRF52840 + few sdk's missing filess - few sdk's unvanted files corect mbed HAL implementation to changes made in sdk v13
2016-12-19 10:31:15 +00:00
"OUTPUT_EXT": "hex",
"is_disk_virtual": true,
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
"public": false,
"detect_code": ["1101"],
"program_cycle_s": 6,
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"bootloader_supported": true
+ description of the NRF52840_DK target + mbed RTx setings for nRF52840 fix build of test for NRF52840 + few sdk's missing filess - few sdk's unvanted files corect mbed HAL implementation to changes made in sdk v13
2016-12-19 10:31:15 +00:00
},
"NRF52840_DK": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF52840"],
NRF52840_DK: Enable lp us ticker support
2018-05-24 07:25:18 +00:00
"release_versions": ["5"],
Reorganize targets.json for NRF52 based targets * Consolidated device_has and macros to the main MCU targets. * Moved errata configuration to mbed_lib.json for HAL implementation. * Moved clock configuration to mbed_lib.json for HAL implementation. * Moved UART configuration to mbed_lib.json for HAL implementation.
2018-04-05 14:58:29 +00:00
"device_name": "nRF52840_xxAA"
+ description of the NRF52840_DK target + mbed RTx setings for nRF52840 fix build of test for NRF52840 + few sdk's missing filess - few sdk's unvanted files corect mbed HAL implementation to changes made in sdk v13
2016-12-19 10:31:15 +00:00
},
Rename "generic" -> "bluepill" (common name)
2016-06-09 08:36:13 +00:00
"BLUEPILL_F103C8": {
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"inherits": ["FAMILY_STM32"],
Support for Blue Pill
2016-06-29 08:05:27 +00:00
"core": "Cortex-M3",
"default_toolchain": "GCC_ARM",
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"extra_labels_add": ["STM32F1", "STM32F103C8"],
Support for Blue Pill
2016-06-29 08:05:27 +00:00
"supported_toolchains": ["GCC_ARM"],
STM32 : targets.json file simplification "FAMILY_STM32" has been creeated with all common features. All STM32 devices can now inherit from it. This will simplify readability and maintainability.
2017-06-21 08:48:19 +00:00
"device_has_add": [],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has_remove": ["STDIO_MESSAGES"]
Support NUMAKER_PFM_NUC472
2016-07-22 05:04:53 +00:00
},
"NUMAKER_PFM_NUC472": {
"core": "Cortex-M4F",
"default_toolchain": "ARM",
[M487/NUC472] Support new EMAC feature, built OK
2018-05-04 12:34:39 +00:00
"extra_labels": ["NUVOTON", "NUC472", "NU_XRAM_SUPPORTED", "FLASH_CMSIS_ALGO", "NUVOTON_EMAC"],
Support NUMAKER_PFM_NUC472
2016-07-22 05:04:53 +00:00
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
[NUC472/M453] Move target configuration from mbed_lib.json to targets.json
2017-07-25 09:06:23 +00:00
"config": {
"gpio-irq-debounce-enable": {
"help": "Enable GPIO IRQ debounce",
"value": 0
},
"gpio-irq-debounce-enable-list": {
"help": "Comma separated pin list to enable GPIO IRQ debounce",
"value": "NC"
},
"gpio-irq-debounce-clock-source": {
"help": "Select GPIO IRQ debounce clock source: GPIO_DBCTL_DBCLKSRC_HCLK or GPIO_DBCTL_DBCLKSRC_IRC10K",
"value": "GPIO_DBCTL_DBCLKSRC_IRC10K"
},
"gpio-irq-debounce-sample-rate": {
"help": "Select GPIO IRQ debounce sample rate: GPIO_DBCTL_DBCLKSEL_1, GPIO_DBCTL_DBCLKSEL_2, GPIO_DBCTL_DBCLKSEL_4, ..., or GPIO_DBCTL_DBCLKSEL_32768",
"value": "GPIO_DBCTL_DBCLKSEL_16"
}
},
Support NUMAKER_PFM_NUC472
2016-07-22 05:04:53 +00:00
"inherits": ["Target"],
[NUC472] Conform to mbed TLS H/W acceleration support
2017-05-19 09:10:21 +00:00
"macros_add": ["MBEDTLS_CONFIG_HW_SUPPORT"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "STDIO_MESSAGES", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "TRNG", "CAN", "FLASH", "EMAC"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
Targets- NUMAKER_PFM_NUC47216 remove mbed 2 crypto failures due to mbedtls dependency
2016-10-27 08:36:24 +00:00
"release_versions": ["5"],
[NUC472/M453] Support bootloader
2017-03-22 10:07:19 +00:00
"device_name": "NUC472HI8AE",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
HEXIWEAR: Enable the entropy collector for use in mbed TLS Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-23 15:15:41 +00:00
},
Adding NCS36510 support in mbed-os5.1
2016-08-16 11:51:48 +00:00
"NCS36510": {
"inherits": ["Target"],
"core": "Cortex-M3",
"extra_labels": ["ONSEMI"],
Configuration of user trim moved to targets.json
2016-11-08 11:59:32 +00:00
"config": {
"mac-addr-low": {
Modified user trim default values.
2016-11-09 11:42:35 +00:00
"help": "Lower 32 bits of the MAC extended address. All FFs indicates that factory programmed MAC address shall be used. In order to override the factory programmed MAC address this value needs to be changed from 0xFFFFFFFF to any chosen value.",
"value": "0xFFFFFFFF"
Configuration of user trim moved to targets.json
2016-11-08 11:59:32 +00:00
},
"mac-addr-high": {
Modified user trim default values.
2016-11-09 11:42:35 +00:00
"help": "Higher 32 bits of the MAC extended address. All FFs indicates that factory programmed MAC address shall be used. In order to override the factory programmed MAC address this value needs to be changed from 0xFFFFFFFF to any chosen value.",
"value": "0xFFFFFFFF"
Configuration of user trim moved to targets.json
2016-11-08 11:59:32 +00:00
},
"32KHz-clk-trim": {
"help": "32KHz clock trim",
Modified user trim default values.
2016-11-09 11:42:35 +00:00
"value": "0x39"
Configuration of user trim moved to targets.json
2016-11-08 11:59:32 +00:00
},
"32MHz-clk-trim": {
"help": "32MHz clock trim",
Modified user trim default values.
2016-11-09 11:42:35 +00:00
"value": "0x17"
Configuration of user trim moved to targets.json
2016-11-08 11:59:32 +00:00
},
"rssi-trim": {
"help": "RSSI trim",
"value": "0x3D"
},
"txtune-trim": {
"help": "TX tune trim",
Modified user trim default values.
2016-11-09 11:42:35 +00:00
"value": "0xFFFFFFFF"
Configuration of user trim moved to targets.json
2016-11-08 11:59:32 +00:00
}
},
mbed OS 5.5.3, including the changes needed to enable 640k. Includes the proposed changes by Mac. 7/25/17
2017-07-25 23:37:14 +00:00
"OUTPUT_EXT": "hex",
Adding NCS36510 support in mbed-os5.1
2016-08-16 11:51:48 +00:00
"post_binary_hook": {"function": "NCS36510TargetCode.ncs36510_addfib"},
Turn off tickless for the NCS36510 The NCS36510 is not suitable for tickless, since its LP ticker cannot be scheduled fast enough. This is because it takes four 32KHz clock cycles before these writes take effect - ~120us.
2017-09-10 01:37:58 +00:00
"macros": ["CM3", "CPU_NCS36510", "TARGET_NCS36510", "LOAD_ADDRESS=0x3000"],
Adding NCS36510 support in mbed-os5.1
2016-08-16 11:51:48 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has": ["ANALOGIN", "SERIAL", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "TRNG", "SPISLAVE"],
Formatting code according to ARM guidelines. Ran pylint and astyle. Rebased latest ARMmbed-os code.
2016-08-26 11:22:11 +00:00
"release_versions": ["2", "5"]
Support NUMAKER_PFM_M453
2016-08-09 01:58:33 +00:00
},
"NUMAKER_PFM_M453": {
"core": "Cortex-M4F",
"default_toolchain": "ARM",
[NUC472/M453] Support flash
2017-03-20 06:26:05 +00:00
"extra_labels": ["NUVOTON", "M451", "NUMAKER_PFM_M453", "FLASH_CMSIS_ALGO"],
Support NUMAKER_PFM_M453
2016-08-09 01:58:33 +00:00
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
[NUC472/M453] Move target configuration from mbed_lib.json to targets.json
2017-07-25 09:06:23 +00:00
"config": {
"gpio-irq-debounce-enable": {
"help": "Enable GPIO IRQ debounce",
"value": 0
},
"gpio-irq-debounce-enable-list": {
"help": "Comma separated pin list to enable GPIO IRQ debounce",
"value": "NC"
},
"gpio-irq-debounce-clock-source": {
"help": "Select GPIO IRQ debounce clock source: GPIO_DBCTL_DBCLKSRC_HCLK or GPIO_DBCTL_DBCLKSRC_LIRC",
"value": "GPIO_DBCTL_DBCLKSRC_LIRC"
},
"gpio-irq-debounce-sample-rate": {
"help": "Select GPIO IRQ debounce sample rate: GPIO_DBCTL_DBCLKSEL_1, GPIO_DBCTL_DBCLKSEL_2, GPIO_DBCTL_DBCLKSEL_4, ..., or GPIO_DBCTL_DBCLKSEL_32768",
"value": "GPIO_DBCTL_DBCLKSEL_16"
}
},
Support NUMAKER_PFM_M453
2016-08-09 01:58:33 +00:00
"inherits": ["Target"],
"progen": {"target": "numaker-pfm-m453"},
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "STDIO_MESSAGES", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "CAN", "FLASH"],
[M453] Add device_name into targets.json
2016-10-07 05:46:24 +00:00
"release_versions": ["2", "5"],
[NUC472/M453] Support bootloader
2017-03-22 10:07:19 +00:00
"device_name": "M453VG6AE",
Removes FLASH capabilities for the ARCH_PRO. This platform is failing a flash test at this time. This commit disables the capability (and therefore the test) until it is fixed.
2017-05-10 15:41:58 +00:00
"bootloader_supported": true
Add u-blox Sara-N target.
2016-10-13 13:01:30 +00:00
},
[NANO] Alpha support
2017-04-13 03:32:51 +00:00
"NUMAKER_PFM_NANO130": {
"core": "Cortex-M0",
"default_toolchain": "ARM",
[NANO130] Fix issues in Greentea test
2017-05-09 02:24:05 +00:00
"extra_labels": ["NUVOTON", "NANO100", "NANO130KE3BN"],
[NANO] Alpha support
2017-04-13 03:32:51 +00:00
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
[NANO130] Move target configuration from mbed_lib.json to targets.json
2017-09-13 03:50:11 +00:00
"config": {
"gpio-irq-debounce-enable": {
"help": "Enable GPIO IRQ debounce",
"value": 0
},
"gpio-irq-debounce-enable-list": {
"help": "Comma separated pin list to enable GPIO IRQ debounce",
"value": "NC"
},
"gpio-irq-debounce-clock-source": {
"help": "Select GPIO IRQ debounce clock source: GPIO_DBCLKSRC_HCLK or GPIO_DBCLKSRC_IRC10K",
"value": "GPIO_DBCLKSRC_IRC10K"
},
"gpio-irq-debounce-sample-rate": {
"help": "Select GPIO IRQ debounce sample rate: GPIO_DBCLKSEL_1, GPIO_DBCLKSEL_2, GPIO_DBCLKSEL_4, ..., or GPIO_DBCLKSEL_32768",
"value": "GPIO_DBCLKSEL_16"
}
},
[NANO] Alpha support
2017-04-13 03:32:51 +00:00
"inherits": ["Target"],
Fixes for targets with invalid HardFault_Handler implementation and review/other fixes
2018-01-26 16:19:49 +00:00
"macros": ["CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\"","MBED_FAULT_HANDLER_DISABLED"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "STDIO_MESSAGES", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH"],
[NANO] Alpha support
2017-04-13 03:32:51 +00:00
"release_versions": ["5"],
"device_name": "NANO130KE3BN"
},
Add u-blox Sara-N target.
2016-10-13 13:01:30 +00:00
"HI2110": {
"inherits": ["Target"],
"core": "Cortex-M0",
"default_toolchain": "GCC_ARM",
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
"extra_labels": ["ublox"],
Define CMSIS_VECTAB_VIRTUAL for M0 targets Define CMSIS_VECTAB_VIRTUAL for the M0 targets which have a corresponding driver. The only M0 target missing this is the LPC4330_M0 which is not part of the 2 or 5 release.
2017-06-09 03:31:41 +00:00
"macros": ["TARGET_PROCESSOR_FAMILY_BOUDICA", "BOUDICA_SARA", "NDEBUG=1", "CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
Add u-blox Sara-N target.
2016-10-13 13:01:30 +00:00
"public": false,
"target_overrides": {
"*": {
"core.stdio-flush-at-exit": false
}
},
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has": ["INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SLEEP", "STDIO_MESSAGES"],
Add u-blox Sara-N target.
2016-10-13 13:01:30 +00:00
"default_lib": "std",
Disable platfroms that fail without LPTICKER
2018-03-22 17:12:50 +00:00
"release_versions": []
Add u-blox Sara-N target.
2016-10-13 13:01:30 +00:00
},
"SARA_NBIOT": {
"inherits": ["HI2110"],
"extra_labels": ["ublox", "HI2110"],
"public": false
},
"SARA_NBIOT_EVK": {
"inherits": ["SARA_NBIOT"],
"extra_labels": ["ublox", "HI2110", "SARA_NBIOT"]
Update targets.json
2017-02-16 03:48:04 +00:00
},
"REALTEK_RTL8195AM": {
Add Arduino pins
2017-03-10 10:21:44 +00:00
"supported_form_factors": ["ARDUINO"],
Update targets.json
2017-02-16 03:48:04 +00:00
"core": "Cortex-M3",
"default_toolchain": "GCC_ARM",
"inherits": ["Target"],
Add support for mbed exporter (uvision, gcc_arm, iar)
2017-05-22 11:17:13 +00:00
"detect_code": ["4600"],
add-rtl8195am-feature-emac (#6904) rtl8195am feature emac implementation.
2018-05-18 09:57:51 +00:00
"extra_labels": ["Realtek", "AMEBA", "RTL8195A", "RTW_EMAC"],
Fixes for targets with invalid HardFault_Handler implementation and review/other fixes
2018-01-26 16:19:49 +00:00
"macros": ["__RTL8195A__","CONFIG_PLATFORM_8195A","CONFIG_MBED_ENABLED","PLATFORM_CMSIS_RTOS","MBED_FAULT_HANDLER_DISABLED"],
Update targets.json
2017-02-16 03:48:04 +00:00
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SPI", "TRNG", "FLASH", "EMAC"],
Remove IPV4 from features in targets.json
2017-02-28 03:10:04 +00:00
"features": ["LWIP"],
Update targets.json
2017-02-16 03:48:04 +00:00
"post_binary_hook": {
"function": "RTL8195ACode.binary_hook",
"toolchains": ["ARM_STD", "GCC_ARM", "IAR"]
},
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"release_versions": ["5"],
"overrides": {
"network-default-interface-type": "ETHERNET"
}
Add support for VBLUno51 board [TARGET_VBLUNO51] + VBLUno51 board: Nordic nRF51822 Bluetooth Low Energy DAPLink interface Arduino UNO pinout compatible 4 Power + Wiki: https://vngiotlab.github.io/vbluno/ + Pass all test case in mbed test suite Signed-off-by: iotvietmember <robotden@gmail.com>
2017-06-25 13:16:58 +00:00
},
"VBLUNO51_LEGACY": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K"],
Add detect_code=0xC006 to the VBLUNO51 boards configuration. Add detect_code=0xC006 to the VBLUNO51 boards configuration. Disbale UART Hard flow control feature. Signed-off-by: iotvietmember <robotden@gmail.com>
2017-10-17 05:07:18 +00:00
"detect_code": ["C006"],
"overrides": {"uart_hwfc": 0},
Add support for VBLUno51 board [TARGET_VBLUNO51] + VBLUno51 board: Nordic nRF51822 Bluetooth Low Energy DAPLink interface Arduino UNO pinout compatible 4 Power + Wiki: https://vngiotlab.github.io/vbluno/ + Pass all test case in mbed test suite Signed-off-by: iotvietmember <robotden@gmail.com>
2017-06-25 13:16:58 +00:00
"extra_labels_add": ["VBLUNO51"]
},
"VBLUNO51_BOOT": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_BOOT"],
Add detect_code=0xC006 to the VBLUNO51 boards configuration. Add detect_code=0xC006 to the VBLUNO51 boards configuration. Disbale UART Hard flow control feature. Signed-off-by: iotvietmember <robotden@gmail.com>
2017-10-17 05:07:18 +00:00
"detect_code": ["C006"],
"overrides": {"uart_hwfc": 0},
Add support for VBLUno51 board [TARGET_VBLUNO51] + VBLUno51 board: Nordic nRF51822 Bluetooth Low Energy DAPLink interface Arduino UNO pinout compatible 4 Power + Wiki: https://vngiotlab.github.io/vbluno/ + Pass all test case in mbed test suite Signed-off-by: iotvietmember <robotden@gmail.com>
2017-06-25 13:16:58 +00:00
"extra_labels_add": ["VBLUNO51"],
"macros_add": ["TARGET_VBLUNO51"]
},
"VBLUNO51_OTA": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_OTA"],
Add detect_code=0xC006 to the VBLUNO51 boards configuration. Add detect_code=0xC006 to the VBLUNO51 boards configuration. Disbale UART Hard flow control feature. Signed-off-by: iotvietmember <robotden@gmail.com>
2017-10-17 05:07:18 +00:00
"detect_code": ["C006"],
"overrides": {"uart_hwfc": 0},
Add support for VBLUno51 board [TARGET_VBLUNO51] + VBLUno51 board: Nordic nRF51822 Bluetooth Low Energy DAPLink interface Arduino UNO pinout compatible 4 Power + Wiki: https://vngiotlab.github.io/vbluno/ + Pass all test case in mbed test suite Signed-off-by: iotvietmember <robotden@gmail.com>
2017-06-25 13:16:58 +00:00
"extra_labels_add": ["VBLUNO51"],
"macros_add": ["TARGET_VBLUNO51"]
},
"VBLUNO51": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF51_32K_UNIFIED"],
Add detect_code=0xC006 to the VBLUNO51 boards configuration. Add detect_code=0xC006 to the VBLUNO51 boards configuration. Disbale UART Hard flow control feature. Signed-off-by: iotvietmember <robotden@gmail.com>
2017-10-17 05:07:18 +00:00
"detect_code": ["C006"],
"overrides": {"uart_hwfc": 0},
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["USTICKER", "LPTICKER", "ANALOGIN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
Add support for VBLUno51 board [TARGET_VBLUNO51] + VBLUno51 board: Nordic nRF51822 Bluetooth Low Energy DAPLink interface Arduino UNO pinout compatible 4 Power + Wiki: https://vngiotlab.github.io/vbluno/ + Pass all test case in mbed test suite Signed-off-by: iotvietmember <robotden@gmail.com>
2017-06-25 13:16:58 +00:00
"release_versions": ["2"],
"device_name": "nRF51822_xxAC"
Add support for the VBLUno52 board Fix ERROR_PATTERN in VBLUNO52 config Signed-off-by: iotvietmember <robotden@gmail.com>
2017-07-22 04:23:51 +00:00
},
DISCO_L496AG: add platform in targets.json file
2018-03-05 15:01:05 +00:00
"DISCO_L496AG": {
"inherits": ["FAMILY_STM32"],
DISCO_L496AG: remove morpho connector in targets.json
2018-03-06 09:39:15 +00:00
"supported_form_factors": ["ARDUINO"],
DISCO_L496AG: add platform in targets.json file
2018-03-05 15:01:05 +00:00
"core": "Cortex-M4F",
"extra_labels_add": ["STM32L4", "STM32L496AG", "STM32L496xG"],
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
},
Rename LOWPOWERTIMER to LPTICKER after merge
2018-04-19 10:36:22 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
DISCO_L496AG: add platform in targets.json file
2018-03-05 15:01:05 +00:00
"value": 1
}
},
"detect_code": ["0822"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
DISCO_L496AG: add platform in targets.json file
2018-03-05 15:01:05 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32L496AG"
},
Add BSP files for NUCLEO_L496ZG
2017-06-27 12:19:00 +00:00
"NUCLEO_L496ZG": {
NUCLEO_L496ZG target inherits from FAMILY_STM32
2017-06-28 15:49:36 +00:00
"inherits": ["FAMILY_STM32"],
Add BSP files for NUCLEO_L496ZG
2017-06-27 12:19:00 +00:00
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M4F",
NUCLEO_L496ZG target inherits from FAMILY_STM32
2017-06-28 15:49:36 +00:00
"extra_labels_add": ["STM32L4", "STM32L496ZG", "STM32L496xG"],
NUCLEO_L496ZG JSON Clock Configuration
2017-07-25 10:21:54 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC (need HW patch) | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI | USE_PLL_MSI",
"value": "USE_PLL_MSI",
"macro_name": "CLOCK_SOURCE"
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
},
Rename DEVICE_LOWPOWERTIMER to DEVICE_LPTICKER That's to match DEVICE_USTICKER.
2018-03-13 17:11:18 +00:00
"lpticker_lptim": {
"help": "This target supports LPTIM. Set value 1 to use LPTIM for LPTICKER, or 0 to use RTC wakeup timer",
STM32 LOWPOWERTIMER : introduce LPTIM feature STM32L0, L4, F7 and few F4 chip are supporting LPTIM feature. We propose to allow user to use LPTIM for MBED LowPowerTimer API instead of using RTC wakeup timers. By default, all targets that are supporting this feature have been configured.
2018-01-09 13:10:14 +00:00
"value": 1
NUCLEO_L496ZG JSON Clock Configuration
2017-07-25 10:21:54 +00:00
}
},
Add BSP files for NUCLEO_L496ZG
2017-06-27 12:19:00 +00:00
"detect_code": ["0823"],
STM32 LPTICKER : enable all STM32 targets supporting the feature (All STM32 except F1 and F2 families)
2018-03-28 12:50:41 +00:00
"device_has_add": ["ANALOGOUT", "CAN", "CRC", "SERIAL_ASYNCH", "SERIAL_FC", "TRNG", "FLASH"],
NUCLEO_L496ZG add mbedOS 2 compatibility
2017-06-27 14:56:31 +00:00
"release_versions": ["2", "5"],
Add BSP files for NUCLEO_L496ZG
2017-06-27 12:19:00 +00:00
"device_name": "STM32L496ZG"
},
NUCLEO_L496ZG_P support
2017-11-03 10:05:54 +00:00
"NUCLEO_L496ZG_P": {
"inherits": ["NUCLEO_L496ZG"],
"detect_code": ["0828"]
},
Add support for the VBLUno52 board Fix ERROR_PATTERN in VBLUNO52 config Signed-off-by: iotvietmember <robotden@gmail.com>
2017-07-22 04:23:51 +00:00
"VBLUNO52": {
"supported_form_factors": ["ARDUINO"],
Change target.json to use new SDK and folder structure for NRF52
2018-01-17 20:43:04 +00:00
"inherits": ["MCU_NRF52832"],
Enable us lp ticker support for entire MCU_NRF52832 family
2018-05-23 11:58:46 +00:00
"release_versions": ["5"],
Add support for the VBLUno52 board Fix ERROR_PATTERN in VBLUNO52 config Signed-off-by: iotvietmember <robotden@gmail.com>
2017-07-22 04:23:51 +00:00
"device_name": "nRF52832_xxAA"
[M487] Support NuMaker-PFM-M487 board
2016-12-13 06:05:08 +00:00
},
"NUMAKER_PFM_M487": {
"core": "Cortex-M4F",
"default_toolchain": "ARM",
[M487/NUC472] Support new EMAC feature, built OK
2018-05-04 12:34:39 +00:00
"extra_labels": ["NUVOTON", "M480", "FLASH_CMSIS_ALGO","NUVOTON_EMAC"],
[M487] Support NuMaker-PFM-M487 board
2016-12-13 06:05:08 +00:00
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
[M487] Move target configuration from mbed_lib.json to targets.json
2017-07-25 09:22:28 +00:00
"config": {
"gpio-irq-debounce-enable": {
"help": "Enable GPIO IRQ debounce",
"value": 0
},
"gpio-irq-debounce-enable-list": {
"help": "Comma separated pin list to enable GPIO IRQ debounce",
"value": "NC"
},
"gpio-irq-debounce-clock-source": {
"help": "Select GPIO IRQ debounce clock source: GPIO_DBCTL_DBCLKSRC_HCLK or GPIO_DBCTL_DBCLKSRC_LIRC",
"value": "GPIO_DBCTL_DBCLKSRC_LIRC"
},
"gpio-irq-debounce-sample-rate": {
"help": "Select GPIO IRQ debounce sample rate: GPIO_DBCTL_DBCLKSEL_1, GPIO_DBCTL_DBCLKSEL_2, GPIO_DBCTL_DBCLKSEL_4, ..., or GPIO_DBCTL_DBCLKSEL_32768",
"value": "GPIO_DBCTL_DBCLKSEL_16"
},
"usb-device-hsusbd": {
"help": "Select high-speed USB device or not",
"value": 1
},
"ctrl01-enable": {
"help": "Enable control_01",
"value": 0
}
},
[M487] Support NuMaker-PFM-M487 board
2016-12-13 06:05:08 +00:00
"inherits": ["Target"],
[M487] Conform to mbed TLS H/W acceleration support released with mbed OS 5.3
2017-05-24 07:11:47 +00:00
"macros_add": ["MBEDTLS_CONFIG_HW_SUPPORT"],
Turn off RTC until updated Turn off RTC for all devices. When support for a device is added this should be re-enabled.
2017-10-12 18:08:15 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "STDIO_MESSAGES", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "TRNG", "FLASH", "CAN", "EMAC"],
[M487] Revise EMAC to fulfill real-chip
2017-06-15 08:18:58 +00:00
"features": ["LWIP"],
[M487] Support NuMaker-PFM-M487 board
2016-12-13 06:05:08 +00:00
"release_versions": ["5"],
[M487] Add back device_name in target description
2017-08-03 05:53:48 +00:00
"device_name": "M487JIDAE",
Add NetworkInterface::get_default_instance() Provide an initial framework to make it easier to find a default network interface.
2018-02-15 12:46:11 +00:00
"bootloader_supported": true,
"overrides": {
"network-default-interface-type": "ETHERNET"
}
Added Support for Toshiba TMPM066
2017-08-01 05:56:58 +00:00
},
"TMPM066": {
"inherits": ["Target"],
"core": "Cortex-M0",
"is_disk_virtual": true,
"extra_labels": ["TOSHIBA"],
"macros": ["__TMPM066__", "CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""],
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SLEEP", "I2C", "I2CSLAVE", "STDIO_MESSAGES", "PWMOUT"],
Added Support for Toshiba TMPM066
2017-08-01 05:56:58 +00:00
"device_name": "TMPM066FWUG",
"detect_code": ["7011"],
"release_versions": ["5"]
add target TARGET_SAKURAIO_EVB_01.
2017-10-12 08:47:21 +00:00
},
"SAKURAIO_EVB_01": {
"inherits": ["FAMILY_STM32"],
"supported_form_factors": [],
"core": "Cortex-M4F",
"extra_labels_add": ["STM32F4", "STM32F411xE", "STM32F411RE"],
Fix missmatch between targets.son
2018-05-25 18:52:53 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
add target TARGET_SAKURAIO_EVB_01.
2017-10-12 08:47:21 +00:00
"config": {
"clock_source": {
"help": "Mask value : USE_PLL_HSE_EXTC | USE_PLL_HSE_XTAL (need HW patch) | USE_PLL_HSI",
"value": "USE_PLL_HSI",
"macro_name": "CLOCK_SOURCE"
}
},
Disable boards which does not fulfil new ticker standards.
2017-12-19 12:26:28 +00:00
"device_has_add": ["SERIAL_ASYNCH", "SERIAL_FC", "FLASH"],
add target TARGET_SAKURAIO_EVB_01.
2017-10-12 08:47:21 +00:00
"release_versions": ["2"],
"device_name": "STM32F411RE"
Added Support for Toshiba TMPM46B
2018-01-22 12:16:19 +00:00
},
"TMPM46B": {
"inherits": ["Target"],
"core": "Cortex-M4",
"is_disk_virtual": true,
"extra_labels": ["TOSHIBA"],
"macros": ["__TMPM46B__"],
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
"device_has": ["ANALOGIN", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SERIAL_FC", "SPI", "I2C", "STDIO_MESSAGES", "TRNG", "FLASH", "SLEEP"],
"device_name": "TMPM46BF10FG",
"detect_code": ["7013"],
"release_versions": ["5"],
"bootloader_supported": true
FastModels: enable FVP_MPS2 targets for mbed os add ARM_FM top level category add second level parent FVP_MPS2 inherits ARM_FM add each target ( M0 M0P M3 M4 M7 ) inherits FVP_MPS2
2018-05-14 10:40:21 +00:00
},
"ARM_FM": {
"inherits": ["Target"],
"public": false,
"extra_labels": ["ARM_FM"]
},
"FVP_MPS2": {
"inherits": ["ARM_FM"],
"public": false,
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
"OUTPUT_EXT": "elf",
"device_has": ["AACI", "ANALOGIN", "CLCD", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "TSC"],
"release_versions": ["5"]
},
"FVP_MPS2_M0": {
"inherits": ["FVP_MPS2"],
"core": "Cortex-M0",
"macros": ["CMSDK_CM0","CMSIS_VECTAB_VIRTUAL", "CMSIS_VECTAB_VIRTUAL_HEADER_FILE=\"cmsis_nvic.h\""]
},
"FVP_MPS2_M0P": {
"inherits": ["FVP_MPS2"],
"core": "Cortex-M0+",
"macros": ["CMSDK_CM0plus"]
},
"FVP_MPS2_M3": {
"inherits": ["FVP_MPS2"],
"core": "Cortex-M3",
"macros": ["CMSDK_CM3"]
},
"FVP_MPS2_M4": {
"inherits": ["FVP_MPS2"],
"core": "Cortex-M4",
"macros": ["CMSDK_CM4"]
},
"FVP_MPS2_M7": {
"inherits": ["FVP_MPS2"],
"core": "Cortex-M7",
"macros": ["CMSDK_CM7"]
Support NUMAKER_PFM_M453
2016-08-09 01:58:33 +00:00
}
targets - remove ulib template armcc provides command line option for choosing a lib type, and we use this, thus a template is not needed.
2016-06-13 23:33:09 +00:00
}