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

2022 lines
95 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,
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"
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 simple documentation generation
2016-07-26 21:23:04 +00:00
"Super_Target": {
"inherits": ["Target"],
"core": "Cortex-M4",
Add supported_toolchains to super_target
2016-10-03 20:08:35 +00:00
"features_add": ["UVISOR", "BLE", "CLIENT", "IPV4", "IPV6"],
"supported_toolchains": ["ARM"]
Add simple documentation generation
2016-07-26 21:23: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
"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"],
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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "CAN", "ERROR_PATTERN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
"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"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
"macros": ["TARGET_LPC11U24"],
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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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"],
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"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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": "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"],
"macros": ["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"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX", "MCU_LPC11U35_501"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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_Y5_MBUG": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC11UXX", "MCU_LPC11U35_501"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
"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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"],
"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"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
"inherits": ["LPCTarget"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
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
"device_has": ["ANALOGIN", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PWMOUT", "RTC", "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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +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"],
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
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "INTERRUPTIN", "PWMOUT", "RTC", "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"],
"device_name": "lpc1549"
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",
"extra_labels": ["NXP", "LPC176X", "MBED_LPC1768"],
"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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SEMIHOST", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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"],
"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
},
"ARCH_PRO": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
"extra_labels": ["NXP", "LPC176X"],
"macros": ["TARGET_LPC1768"],
"inherits": ["LPCTarget"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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"],
"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
},
"UBLOX_C027": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
"extra_labels": ["NXP", "LPC176X"],
"macros": ["TARGET_LPC1768"],
"inherits": ["LPCTarget"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ERROR_RED", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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"],
"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
},
"XBED_LPC1768": {
"inherits": ["LPCTarget"],
"core": "Cortex-M3",
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR", "IAR"],
"extra_labels": ["NXP", "LPC176X", "XBED_LPC1768"],
"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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SEMIHOST", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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
},
"LPC2368": {
"inherits": ["LPCTarget"],
"core": "ARM7TDMI-S",
"extra_labels": ["NXP", "LPC23XX"],
Targets - LPC23678 ARM fails to build, remove from supported toolchains Tracking issue: https://github.com/mbedmicro/mbed/issues/2108
2016-07-06 08:41:27 +00:00
"supported_toolchains": ["GCC_ARM", "GCC_CR"],
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
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOCALFILESYSTEM", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SEMIHOST", "SERIAL", "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
},
"LPC2460": {
"inherits": ["LPCTarget"],
"core": "ARM7TDMI-S",
"extra_labels": ["NXP", "LPC2460"],
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"],
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
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "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
},
"LPC810": {
"inherits": ["LPCTarget"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
"extra_labels": ["NXP", "LPC81X"],
"is_disk_virtual": true,
"supported_toolchains": ["uARM", "IAR", "GCC_ARM"],
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
"device_has": ["ERROR_RED", "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"],
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
"device_has": ["ERROR_RED", "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"],
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
"device_has": ["ANALOGIN", "ERROR_RED", "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"],
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
"device_has": ["ANALOGIN", "ERROR_RED", "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
},
"LPC4088": {
"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": {
"function": "LPC4088Code.binary_hook",
"toolchains": ["ARM_STD", "ARM_MICRO"]
},
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "DEBUG_AWARENESS", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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": "LPC4088FBD144"
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": {
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"inherits": ["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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "DEBUG_AWARENESS", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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"],
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": ["ANALOGIN", "ANALOGOUT", "DEBUG_AWARENESS", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "DEBUG_AWARENESS", "ERROR_RED", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "GCC_CR"],
"inherits": ["LPCTarget"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
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
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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"],
Remove support for the RTC. Only early versions of the interface firmware provided a clock for the RTC that was used. This has long been depreciated since it also routed the same pin to an ADC on the arduino connector which caused wiring conflicts
2016-07-26 03:40:22 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SEMIHOST", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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+",
"extra_labels": ["Freescale", "KLXX"],
"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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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": "MKL46Z256xxx4"
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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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
},
"K22F": {
"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"],
"extra_labels": ["Freescale", "KSDK2_MCUS", "FRDM", "KPSDK_MCUS", "KPSDK_CODE"],
"is_disk_virtual": true,
"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"],
K64F/K22F: Implement HAL lp_timer API API implemented using hybrid approach with RTC for longer periods and LPTMR for subsecond ones.
2016-08-16 09:55:30 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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": "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
},
"KL27Z": {
"inherits": ["Target"],
"core": "Cortex-M0+",
"extra_labels": ["Freescale", "KSDK2_MCUS", "FRDM"],
"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"],
Enable PORTIN, PORTOUT and PWMOUT for KL27 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-06-28 20:09:16 +00:00
"device_has": ["ANALOGIN", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTOUT", "PWMOUT", "RTC", "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"],
"extra_labels": ["Freescale", "KSDK2_MCUS", "FRDM"],
"macros": ["CPU_MKL43Z256VLH4", "FSL_RTOS_MBED"],
"is_disk_virtual": true,
"inherits": ["Target"],
"detect_code": ["0262"],
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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
},
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 a K64F target with uVisor enabled Also, remove UVISOR_SUPPORTED from the other targets.
2016-06-08 10:00:41 +00:00
"extra_labels": ["Freescale", "KSDK2_MCUS", "FRDM", "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,
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"],
HAL - RNG rename to TRNG
2016-09-21 15:44:19 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "STORAGE", "TRNG"],
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"],
"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
},
"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"],
Target hexiwear - add mcu_k64f label
2016-08-11 14:02:07 +00:00
"extra_labels": ["Freescale", "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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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",
Target hexiwear - add mcu_k64f label
2016-08-11 14:02:07 +00:00
"extra_labels": ["Freescale", "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"],
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
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
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"],
"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
},
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"],
"extra_labels": ["Freescale", "KSDK2_MCUS", "FRDM"],
"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"],
HAL - RNG rename to TRNG
2016-09-21 15:44:19 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name" : "MK66FN2M0xxx18"
Add support for FRDM K66 Signed-off-by: Mahadevan Mahesh <Mahesh.Mahadevan@nxp.com>
2016-08-09 13:05:48 +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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F0", "STM32F030R8"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0725"],
STM32F0 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F070RB - NUCLEO_F072RB - NUCLEO_F091RC
2016-09-09 12:28:35 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["STM", "STM32F0", "STM32F031K6"],
STM32F0 - Rename RTC_LSI
2016-09-26 14:46:03 +00:00
"macros": ["RTC_LSI=1"],
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", "IAR", "GCC_ARM"],
"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": ["0791"],
[STM32] Move RTC_LSI to macros instead of device_has device_has is a control list for generic apis, while macros can be used more freely. DEVICE_RTC_LSI being STM32 specific, it is moved to macros.
2016-08-17 09:06:46 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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": "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": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"default_toolchain": "uARM",
"extra_labels": ["STM", "STM32F0", "STM32F042K6"],
STM32F0 - Rename RTC_LSI
2016-09-26 14:46:03 +00:00
"macros": ["RTC_LSI=1"],
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", "IAR", "GCC_ARM"],
"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": ["0785"],
[STM32] Move RTC_LSI to macros instead of device_has device_has is a control list for generic apis, while macros can be used more freely. DEVICE_RTC_LSI being STM32 specific, it is moved to macros.
2016-08-17 09:06:46 +00:00
"device_has": ["ANALOGIN", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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": "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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F0", "STM32F070RB"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0755"],
[STM32F0] Enable asynchronous serial
2016-08-10 08:45:21 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "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": "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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F0", "STM32F072RB"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0730"],
[STM32F0] Enable asynchronous serial
2016-08-10 08:45:21 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "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": "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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F0", "STM32F091RC"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0750"],
[STM32F0] Enable asynchronous serial
2016-08-10 08:45:21 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "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": "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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M3",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F1", "STM32F103RB"],
"supported_toolchains": ["ARM", "uARM", "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": ["0700"],
More formatting changes in targets.json
2016-10-05 01:34:45 +00:00
"device_has": ["ANALOGIN", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "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": "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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M3",
"default_toolchain": "ARM",
"extra_labels": ["STM", "STM32F2", "STM32F207ZG"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"inherits": ["Target"],
"detect_code": ["0835"],
STM32F2xx - Enable Serial Flow Control
2016-09-05 09:37:16 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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"],
"device_name" : "STM32F207ZG"
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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F3", "STM32F302R8"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0705"],
STM32F3 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F302R8 - NUCLEO_F303K8 - NUCLEO_F303RE - NUCLEO_F334R8 - DISCO_F334C8 - DISCO_F303VC
2016-09-06 14:02:12 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F3", "STM32F303K8"],
STM32F3 - Rename RTC_LSI
2016-09-26 14:52:59 +00:00
"macros": ["RTC_LSI=1"],
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", "IAR", "GCC_ARM"],
"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": ["0775"],
Rebase to replace "default_build" into "default_lib"
2016-08-26 09:30:31 +00:00
"default_lib": "small",
STM32F3 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F302R8 - NUCLEO_F303K8 - NUCLEO_F303RE - NUCLEO_F334R8 - DISCO_F334C8 - DISCO_F303VC
2016-09-06 14:02:12 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "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": "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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F3", "STM32F303RE"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0745"],
STM32F3 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F302R8 - NUCLEO_F303K8 - NUCLEO_F303RE - NUCLEO_F334R8 - DISCO_F334C8 - DISCO_F303VC
2016-09-06 14:02:12 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "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": "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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
[NUCLEO_F303ZE] test / export scripts update
2016-07-07 15:31:22 +00:00
"core": "Cortex-M4F",
[NUCLEO_F303ZE] MBED-OS5 capability
2016-09-23 07:24:23 +00:00
"default_toolchain": "ARM",
[NUCLEO_F303ZE]Add Hal Target
2016-07-07 15:31:22 +00:00
"extra_labels": ["STM", "STM32F3", "STM32F303ZE"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"inherits": ["Target"],
[NUCLEO_F303ZE] MBED-OS5 capability
2016-09-23 07:24:23 +00:00
"detect_code": ["0747"],
[NUCLEO_F303ZE]Add Hal Target
2016-07-07 15:31:22 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
Additional device names. mbed_targets.md update
2016-09-21 19:36:21 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F303RE"
[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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F3", "STM32F334R8"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0735"],
STM32F3 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F302R8 - NUCLEO_F303K8 - NUCLEO_F303RE - NUCLEO_F334R8 - DISCO_F334C8 - DISCO_F303VC
2016-09-06 14:02:12 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F4", "STM32F401RE"],
"supported_toolchains": ["ARM", "uARM", "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": ["0720"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
[dev_asynch_i2c] Extend asynch I2C to STM32F4 boards Move i2c_s to common_objects.h Introduce I2C Master/Slave asynch test Test I2C asynch master/slave on STM32F4 boards
2016-09-02 13:30:51 +00:00
"device_has": ["ANALOGIN", "ERROR_RED", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
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
},
"NUCLEO_F410RB": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "ARM",
[RNG for STM32F4 family] fix build issue by modifying labels
2016-08-18 15:25:33 +00:00
"extra_labels": ["STM", "STM32F4", "STM32F410RB","STM32F410Rx"],
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"],
"inherits": ["Target"],
Modify mbedtls scripts to add config-no-entropy.h
2016-09-15 13:57:18 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
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 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F411RE - NUCLEO_F401RE - DISCO_F429ZI - NUCLEO_F446RE - NUCLEO_F410RB - DISCO_F469NI - NUCLEO_F446ZE - B86B_F446VE
2016-09-14 13:36:04 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "TRNG"],
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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F4", "STM32F411RE"],
"supported_toolchains": ["ARM", "uARM", "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": ["0740"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
STM32F4 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F411RE - NUCLEO_F401RE - DISCO_F429ZI - NUCLEO_F446RE - NUCLEO_F410RB - DISCO_F469NI - NUCLEO_F446ZE - B86B_F446VE
2016-09-14 13:36:04 +00:00
"device_has": ["ANALOGIN", "ERROR_RED", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "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": "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
},
"ELMO_F411RE": {
"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",
"extra_labels": ["STM", "STM32F4", "STM32F411RE"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM"],
"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": ["----"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "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": "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": {
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"],
[STM32F4xx][NUCLEO_F429ZI] Add on for NUCLEO_F429ZI export and tests
2016-07-04 13:04:58 +00:00
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "ARM",
[RNG for STM32F4 family] fix build issue by modifying labels
2016-08-18 15:25:33 +00:00
"extra_labels": ["STM", "STM32F4", "STM32F429", "STM32F429ZI", "STM32F429xx"],
[STM32F4xx][NUCLEO_F429ZI] Add on for NUCLEO_F429ZI export and tests
2016-07-04 13:04:58 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"progen": {"target": "nucleo-f429zi"},
STM32F4 - Rename RTC_LSI
2016-09-29 07:58:58 +00:00
"macros": ["RTC_LSI=1", "TRANSACTION_QUEUE_SIZE_SPI=2"],
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_RED", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "TRNG"],
[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"],
"device_name" : "STM32F429ZI"
[STM32F4xx][NUCLEO_F429ZI] Add on for NUCLEO_F429ZI export and tests
2016-07-04 13:04:58 +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": {
"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",
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
"default_toolchain": "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
"extra_labels": ["STM", "STM32F4", "STM32F446RE"],
"supported_toolchains": ["ARM", "uARM", "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": ["0777"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
STM32F4 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F411RE - NUCLEO_F401RE - DISCO_F429ZI - NUCLEO_F446RE - NUCLEO_F410RB - DISCO_F469NI - NUCLEO_F446ZE - B86B_F446VE
2016-09-14 13:36:04 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_RED", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F446RE"
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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "ARM",
[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
"extra_labels": ["STM", "STM32F4", "STM32F446ZE"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"inherits": ["Target"],
"detect_code": ["0778"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
STM32F4 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F411RE - NUCLEO_F401RE - DISCO_F429ZI - NUCLEO_F446RE - NUCLEO_F410RB - DISCO_F469NI - NUCLEO_F446ZE - B86B_F446VE
2016-09-14 13:36:04 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_RED", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F4", "STM32F446VE"],
"supported_toolchains": ["ARM", "uARM", "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": ["0840"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
STM32F4 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F411RE - NUCLEO_F401RE - DISCO_F429ZI - NUCLEO_F446RE - NUCLEO_F410RB - DISCO_F469NI - NUCLEO_F446ZE - B86B_F446VE
2016-09-14 13:36:04 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
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": {
"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-M7F",
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": ["STM", "STM32F7", "STM32F746", "STM32F746ZG"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
rebase and adding ARM_STD config, all F7 use ARM as default toolchain - changing device.h -> targets.json after rebase - adding startup and config files for ARM_STD toolchain - changing all STM32F7xx targets to ARM as default toolchain (instead of uARM before)
2016-06-08 14:53:45 +00:00
"default_toolchain": "ARM",
[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"],
targets - add TRNG device_has to STM32F7 targets
2016-09-27 07:48:58 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
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"],
Updated device name for nucleo_f746zg and disco_f746ng
2016-09-26 18:32:48 +00:00
"device_name": "STM32F746ZG"
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
},
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": {
"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-M7FD",
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
"extra_labels": ["STM", "STM32F7", "STM32F767", "STM32F767ZI"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"default_toolchain": "ARM",
"detect_code": ["0818"],
targets - add TRNG device_has to STM32F7 targets
2016-09-27 07:48:58 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
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"],
"device_name" : "STM32F767ZI"
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": {
"inherits": ["Target"],
"core": "Cortex-M0+",
"extra_labels": ["STM", "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"],
"detect_code": ["0780"],
STM32L0 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_L053R8 - NUCLEO_L073K8 - NUCLEO_L011K4 - NUCLEO_L031K6 - DISCO_L053C8
2016-09-15 12:00:38 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "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": "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": {
"inherits": ["Target"],
"core": "Cortex-M0",
"extra_labels": ["STM", "STM32L0", "STM32L031K6"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"default_toolchain": "uARM",
"supported_form_factors": ["ARDUINO"],
"detect_code": ["0790"],
STM32L0 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_L053R8 - NUCLEO_L073K8 - NUCLEO_L011K4 - NUCLEO_L031K6 - DISCO_L053C8
2016-09-15 12:00:38 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "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": "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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0+",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32L0", "STM32L053R8"],
"supported_toolchains": ["ARM", "uARM", "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": ["0715"],
STM32L0 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_L053R8 - NUCLEO_L073K8 - NUCLEO_L011K4 - NUCLEO_L031K6 - DISCO_L053C8
2016-09-15 12:00:38 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M0+",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32L0", "STM32L073RZ"],
"supported_toolchains": ["ARM", "uARM", "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": ["0760"],
Enable TLS entropy in targets.json for STM32L4 and STM32L0 products
2016-08-23 13:18:18 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"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": {
"supported_form_factors": ["ARDUINO", "MORPHO"],
"core": "Cortex-M3",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32L1", "STM32L152RE"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0710"],
STM32L1 - Enable the low power timer Enable the low power timer for the NUCLEO_L152RE
2016-09-15 13:18:18 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "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": "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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "ARM",
[NUCLEO_L432KC] Add to build and export scripts
2016-06-06 08:16:22 +00:00
"extra_labels": ["STM", "STM32L4", "STM32L432KC"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"inherits": ["Target"],
"detect_code": ["0770"],
Enable TLS entropy in targets.json for STM32L4 and STM32L0 products
2016-08-23 13:18:18 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "CAN", "STDIO_MESSAGES", "TRNG"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name" : "STM32L432KC"
[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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32L4", "STM32L476RG"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
"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": ["0765"],
Enable TLS entropy in targets.json for STM32L4 and STM32L0 products
2016-08-23 13:18:18 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "stm32l476rg"
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
},
"STM32F3XX": {
"inherits": ["Target"],
"core": "Cortex-M4",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F3XX"],
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"supported_toolchains": ["ARM", "uARM", "GCC_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
},
"STM32F407": {
"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
"extra_labels": ["STM", "STM32F4", "STM32F4XX"],
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"]
},
"ARCH_MAX": {
"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,
"extra_labels": ["STM", "STM32F4", "STM32F407", "STM32F407VG"],
"macros": ["LSI_VALUE=32000"],
"inherits": ["Target"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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": "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": {
"inherits": ["Target"],
"core": "Cortex-M0",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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": {
"inherits": ["Target"],
"core": "Cortex-M3",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F3", "STM32F303", "STM32F303VC"],
STM32F3 - Rename RTC_LSI
2016-09-26 14:52:59 +00:00
"macros": ["RTC_LSI=1"],
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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
"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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32F3", "STM32F334C8"],
STM32F3 - Rename RTC_LSI
2016-09-26 14:52:59 +00:00
"macros": ["RTC_LSI=1"],
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", "IAR", "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": ["0810"],
STM32F3 - Rename RTC_LSI
2016-09-26 14:52:59 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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": {
"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
"extra_labels": ["STM", "STM32F4", "STM32F407", "STM32F407VG"],
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"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
More formatting changes in targets.json
2016-10-05 01:34:45 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "ARM",
[RNG for STM32F4 family] fix build issue by modifying labels
2016-08-18 15:25:33 +00:00
"extra_labels": ["STM", "STM32F4", "STM32F429", "STM32F429ZI", "STM32F429xx"],
STM32F4 - Rename RTC_LSI
2016-09-29 07:58:58 +00:00
"macros": ["RTC_LSI=1","TRANSACTION_QUEUE_SIZE_SPI=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
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
HAL - RNG rename to TRNG
2016-09-21 15:44:19 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_RED", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES", "TRNG"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "STM32F429ZI"
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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "ARM",
[RNG for STM32F4 family] fix build issue by modifying labels
2016-08-18 15:25:33 +00:00
"extra_labels": ["STM", "STM32F4", "STM32F469", "STM32F469NI", "STM32F469xx"],
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", "IAR", "GCC_ARM"],
"inherits": ["Target"],
Modify mbedtls scripts to add config-no-entropy.h
2016-09-15 13:57:18 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
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"],
STM32F4 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_F411RE - NUCLEO_F401RE - DISCO_F429ZI - NUCLEO_F446RE - NUCLEO_F410RB - DISCO_F469NI - NUCLEO_F446ZE - B86B_F446VE
2016-09-14 13:36:04 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
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": {
"inherits": ["Target"],
"core": "Cortex-M0+",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32L0", "STM32L053C8"],
"supported_toolchains": ["ARM", "uARM", "IAR", "GCC_ARM"],
STM32L0 - Enable the low power timer Enable the low power timer for the following targets: - NUCLEO_L053R8 - NUCLEO_L073K8 - NUCLEO_L011K4 - NUCLEO_L031K6 - DISCO_L053C8
2016-09-15 12:00:38 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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_F746NG": {
"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-M7F",
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": ["STM", "STM32F7", "STM32F746", "STM32F746NG"],
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
rebase and adding ARM_STD config, all F7 use ARM as default toolchain - changing device.h -> targets.json after rebase - adding startup and config files for ARM_STD toolchain - changing all STM32F7xx targets to ARM as default toolchain (instead of uARM before)
2016-06-08 14:53:45 +00:00
"default_toolchain": "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": ["0815"],
targets - add TRNG device_has to STM32F7 targets
2016-09-27 07:48:58 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
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"],
Updated device name for nucleo_f746zg and disco_f746ng
2016-09-26 18:32:48 +00:00
"device_name": "STM32F746NG"
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": {
"inherits": ["Target"],
"core": "Cortex-M7FD",
"extra_labels": ["STM", "STM32F7", "STM32F769", "STM32F769NI"],
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"default_toolchain": "ARM",
"detect_code": ["0817"],
STM32F7 - Add low power timer Enable the low power timer for the following targets: - NUCLEO_F746ZG - NUCLEO_F767ZI - DISCO_F746NG - DISCO_F767ZI
2016-09-16 08:44:51 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
Additional device names. mbed_targets.md update
2016-09-21 19:36:21 +00:00
"release_versions": ["2"],
"device_name": "STM32F769NI"
[disco_f769ni] adding target
2016-08-20 18:14:32 +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": {
"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",
[STM32XX] Fix default build
2016-07-05 09:21:18 +00:00
"default_toolchain": "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
"extra_labels": ["STM", "STM32L4", "STM32L476VG"],
"supported_toolchains": ["ARM", "uARM", "IAR", "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": ["0820"],
Enable TLS entropy in targets.json for STM32L4 and STM32L0 products
2016-08-23 13:18:18 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_name": "stm32l476vg"
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": {
"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", "uARM", "GCC_ARM", "IAR"],
"extra_labels": ["STM", "STM32F4", "STM32F405RG"],
"is_disk_virtual": true,
RTOS - Move per-target RTX config to mbed_rtx.h Disintegrate global RTX target config. Move per-target fragment to mbed_rtx.h under each vendor's directory. One mbed_rtx.h is defined for each vendor at this moment, however, the granularity of mbed_rtx.h can be per-chip, or per-board if necessary. Signed-off-by: Tony Wu <tung7970@gmail.com>
2016-08-30 15:40:31 +00:00
"macros": ["HSE_VALUE=26000000", "TRANSACTION_QUEUE_SIZE_SPI=2"],
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": "mts-mdot-f405rg"},
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
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": {
"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", "uARM", "GCC_ARM", "IAR"],
"extra_labels": ["STM", "STM32F4", "STM32F411RE"],
RTOS - Move per-target RTX config to mbed_rtx.h Disintegrate global RTX target config. Move per-target fragment to mbed_rtx.h under each vendor's directory. One mbed_rtx.h is defined for each vendor at this moment, however, the granularity of mbed_rtx.h can be per-chip, or per-board if necessary. Signed-off-by: Tony Wu <tung7970@gmail.com>
2016-08-30 15:40:31 +00:00
"macros": ["HSE_VALUE=26000000", "USE_PLL_HSE_EXTC=0", "VECT_TAB_OFFSET=0x00010000","TRANSACTION_QUEUE_SIZE_SPI=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
"post_binary_hook": {
"function": "MTSCode.combine_bins_mts_dot",
"toolchains": ["GCC_ARM", "ARM_STD", "ARM_MICRO"]
},
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
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": {
"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", "uARM", "GCC_ARM", "IAR"],
"extra_labels": ["STM", "STM32F4", "STM32F411RE"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["HSE_VALUE=26000000", "VECT_TAB_OFFSET=0x08010000","TRANSACTION_QUEUE_SIZE_SPI=2"],
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",
"toolchains": ["GCC_ARM", "ARM_STD", "ARM_MICRO"]
},
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
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
},
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": {
"inherits": ["Target"],
"core": "Cortex-M3",
"default_toolchain": "ARM",
"extra_labels": ["STM", "STM32L1", "STM32L151CC"],
[XDOT_L151] add IAR support
2016-09-27 21:09:15 +00:00
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
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
"progen": {"target": "xdot-l151cc"},
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
[XDOT_L151] include xDot in mbed 5 releases
2016-09-27 13:45:06 +00:00
"default_lib": "std",
"release_versions": ["5"]
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
},
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": {
"inherits": ["Target"],
"core": "Cortex-M3",
"default_toolchain": "uARM",
"extra_labels": ["STM", "STM32L1", "STM32L152RC"],
STM32L1 - Rename RTC_LSI
2016-09-26 14:47:52 +00:00
"macros": ["RTC_LSI=1"],
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", "IAR", "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": ["4100"],
[STM32] Move RTC_LSI to macros instead of device_has device_has is a control list for generic apis, while macros can be used more freely. DEVICE_RTC_LSI being STM32 specific, it is moved to macros.
2016-08-17 09:06:46 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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": "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": {
"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": "GCC_ARM",
"extra_labels": ["STM", "STM32F4", "STM32F401", "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"],
[STM32F4] enable SPI ASYNCH
2016-08-24 14:47:13 +00:00
"macros": ["TRANSACTION_QUEUE_SIZE_SPI=2"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ERROR_RED", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
"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
},
Changed name for the target UBLOX_C029 to UBLOX_EVK_ODIN_W2
2016-10-01 08:01:18 +00:00
"UBLOX_EVK_ODIN_W2": {
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",
Added u-blox C029 target
2016-09-12 11:41:38 +00:00
"default_toolchain": "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
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"extra_labels": ["STM", "STM32F4", "STM32F439", "STM32F439ZI"],
Added u-blox C029 target
2016-09-12 11:41:38 +00:00
"macros": ["HSE_VALUE=24000000", "HSE_STARTUP_TIMEOUT=5000", "CB_INTERFACE_SDIO","CB_CHIP_WL18XX","SUPPORT_80211D_ALWAYS","WLAN_ENABLED"],
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": ["Target"],
Added u-blox C029 target
2016-09-12 11:41:38 +00:00
"device_has": ["ANALOGIN", "CAN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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": ["5"],
"device_name": "STM32F439ZI"
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": {
"inherits": ["Target"],
"core": "Cortex-M3",
"default_toolchain": "uARM",
"program_cycle_s": 1.5,
"extra_labels": ["STM", "STM32L1", "STM32L151RC"],
STM32L1 - Rename RTC_LSI
2016-09-26 14:47:52 +00:00
"macros": ["RTC_LSI=1"],
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] Move RTC_LSI to macros instead of device_has device_has is a control list for generic apis, while macros can be used more freely. DEVICE_RTC_LSI being STM32 specific, it is moved to macros.
2016-08-17 09:06:46 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
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",
"macros": ["NRF51", "TARGET_NRF51822"],
"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"],
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"]
},
"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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "DEBUG_AWARENESS", "ERROR_PATTERN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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"]
},
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"],
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_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"]
},
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"],
[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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
"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,
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": ["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"],
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_CM0"],
Targets - add release boolean flag
2016-07-04 14:42:23 +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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +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_M1": {
"inherits": ["ARM_MPS2_Target"],
"core": "Cortex-M1",
"supported_toolchains": ["ARM"],
"extra_labels": ["ARM_SSG", "MPS2", "MPS2_M1"],
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_CM1"],
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": ["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_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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +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,
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": ["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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +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
},
[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"],
Beetle: Implement sleep API
2016-08-18 09:09:20 +00:00
"device_has": ["ANALOGIN", "CLCD", "I2C", "INTERRUPTIN", "LOWPOWERTIMER", "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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "beetle"
[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
},
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
"RZ_A1H": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-A9",
"program_cycle_s": 2,
"extra_labels": ["RENESAS", "MBRZA1H"],
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"inherits": ["Target"],
In targets.json, add the "IPV4" setting for RZ_A1H We added "IPV4" of Compile Macro in "targets.json" file. We failed in the reletion test of IPV4 because "IPV4" was not entered into our Build Target setting.
2016-06-29 06:31:07 +00:00
"device_has": ["ANALOGIN", "CAN", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
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"],
"device_name": "r7s721001"
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
},
"VK_RZ_A1H": {
"inherits": ["Target"],
"core": "Cortex-A9",
"extra_labels": ["RENESAS", "VKRZA1H"],
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"default_toolchain": "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
"program_cycle_s": 2,
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
"device_has": ["ANALOGIN", "CAN", "ERROR_PATTERN", "ETHERNET", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SPI", "SPISLAVE", "STDIO_MESSAGES"],
restructure - Added FEATURE_LWIP to __allowed_features
2016-09-30 23:36:26 +00:00
"features": ["LWIP"],
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",
Marked VK_RZ_A1H as release for mbed 2 and mbed 5 per @sg-
2016-08-03 20:01:58 +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
},
"MAXWSNENV": {
"inherits": ["Target"],
"core": "Cortex-M3",
"macros": ["__SYSTEM_HFX=24000000"],
"extra_labels": ["Maxim", "MAX32610"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_PATTERN", "I2C", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "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", "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
},
"MAX32600MBED": {
"inherits": ["Target"],
"core": "Cortex-M3",
"macros": ["__SYSTEM_HFX=24000000"],
"extra_labels": ["Maxim", "MAX32600"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_PATTERN", "I2C", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "STDIO_MESSAGES"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "max326000x85"
},
"MAX32620HSP": {
"inherits": ["Target"],
"core": "Cortex-M4F",
"extra_labels": ["Maxim", "MAX32620"],
"supported_toolchains": ["GCC_ARM", "IAR", "ARM"],
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI", "SPI_ASYNCH", "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", "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
},
"EFM32GG_STK3700": {
"inherits": ["Target"],
"core": "Cortex-M3",
"macros": ["EFM32GG990F1024"],
"extra_labels": ["Silicon_Labs", "EFM32"],
[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"],
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"},
[EFM32] Add delay after reset for greentea test runs. The host-test resets the target by sending a UART break. After this, it takes some time for the target to come back up. Without this timeout, the __sync packet sent by greentea would not be retransmitted by the interface chip (i.e. it would never reach the target). Testing on different devices indicates that 2 seconds delay is sufficient for the device to reset and the __sync packet to reach the target.
2016-06-14 15:38:05 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_PATTERN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32GG990F1024"
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
},
"EFM32LG_STK3600": {
"inherits": ["Target"],
"core": "Cortex-M3",
"macros": ["EFM32LG990F256"],
"extra_labels": ["Silicon_Labs", "EFM32"],
[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] Add delay after reset for greentea test runs. The host-test resets the target by sending a UART break. After this, it takes some time for the target to come back up. Without this timeout, the __sync packet sent by greentea would not be retransmitted by the interface chip (i.e. it would never reach the target). Testing on different devices indicates that 2 seconds delay is sufficient for the device to reset and the __sync packet to reach the target.
2016-06-14 15:38:05 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_PATTERN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32LG990F256"
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
},
"EFM32WG_STK3800": {
"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
"macros": ["EFM32WG990F256"],
"extra_labels": ["Silicon_Labs", "EFM32"],
[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"],
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"},
[EFM32] Add delay after reset for greentea test runs. The host-test resets the target by sending a UART break. After this, it takes some time for the target to come back up. Without this timeout, the __sync packet sent by greentea would not be retransmitted by the interface chip (i.e. it would never reach the target). Testing on different devices indicates that 2 seconds delay is sufficient for the device to reset and the __sync packet to reach the target.
2016-06-14 15:38:05 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "ERROR_PATTERN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32WG990F256"
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
},
"EFM32ZG_STK3200": {
"inherits": ["Target"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
[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"],
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": ["Silicon_Labs", "EFM32"],
"macros": ["EFM32ZG222F32"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "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",
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "EFM32ZG222F32"
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
},
"EFM32HG_STK3400": {
"inherits": ["Target"],
"core": "Cortex-M0+",
"default_toolchain": "uARM",
[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"],
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": ["Silicon_Labs", "EFM32"],
"macros": ["EFM32HG322F64"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "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",
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2"],
"device_name": "EFM32HG322F64"
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
},
"EFM32PG_STK3401": {
"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
"macros": ["EFM32PG1B200F256GM48"],
"extra_labels": ["Silicon_Labs", "EFM32"],
"supported_toolchains": ["GCC_ARM", "ARM", "uARM", "IAR"],
[EFM32] Add delay after reset for greentea test runs. The host-test resets the target by sending a UART break. After this, it takes some time for the target to come back up. Without this timeout, the __sync packet sent by greentea would not be retransmitted by the interface chip (i.e. it would never reach the target). Testing on different devices indicates that 2 seconds delay is sufficient for the device to reset and the __sync packet to reach the target.
2016-06-14 15:38:05 +00:00
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "STDIO_MESSAGES"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"forced_reset_timeout": 2,
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"device_name": "EFM32PG1B100F256GM32"
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"],
"supported_toolchains": ["uARM", "ARM"],
"inherits": ["Target"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "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
},
"WIZWIKI_W7500P": {
"supported_form_factors": ["ARDUINO"],
"core": "Cortex-M0",
"extra_labels": ["WIZNET", "W7500x", "WIZwiki_W7500P"],
"supported_toolchains": ["uARM", "ARM"],
"inherits": ["Target"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "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
},
"WIZWIKI_W7500ECO": {
"inherits": ["Target"],
"core": "Cortex-M0",
"extra_labels": ["WIZNET", "W7500x", "WIZwiki_W7500ECO"],
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": ["uARM", "ARM"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "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
},
"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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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" : "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"],
Targets - add release boolean flag
2016-07-04 14:42:23 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH"],
"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",
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
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "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",
"TARGET_MCU_NRF51822"
],
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,
"extra_labels": ["NORDIC", "MCU_NRF51", "MCU_NRF51822_UNIFIED", "NRF5"],
"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
},
"device_has": ["ANALOGIN", "ERROR_PATTERN", "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"],
Adding NRF52_DK and NRF51_DK to the v2 and v5 release
2016-07-27 19:52:51 +00:00
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"release_versions": ["2", "5"],
"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"},
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
"device_has": ["ERROR_PATTERN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
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
"release_versions": ["2", "5"]
},
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
"MCU_NRF52": {
"inherits": ["Target"],
"core": "Cortex-M4F",
Corection in macros for NRF5x devices Remove duplicated macro "BLE_STACK_SUPPORT_REQD" for MCU_NRF51 add macro "S132" for MCU_NRF52
2016-06-21 07:13:20 +00:00
"macros": ["NRF52", "TARGET_NRF52832", "BLE_STACK_SUPPORT_REQD", "SOFTDEVICE_PRESENT", "S132"],
Factorization of NRF51 and NRF52 targets. A new wbase target has been added (NRF5). In this target, commonalities between 51 and 52 will be shared.
2016-06-15 11:30:04 +00:00
"extra_labels": ["NORDIC", "MCU_NRF52", "MCU_NRF52832", "NRF5"],
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,
"MERGE_SOFT_DEVICE": true,
"EXPECTED_SOFTDEVICES_WITH_OFFSETS": [
{
"boot": "",
"name": "s132_nrf52_2.0.0_softdevice.hex",
"offset": 114688
}
],
"post_binary_hook": {
"function": "MCU_NRF51Code.binary_hook",
Fix: IAR build for NRF5x produce proper combined intel-hex file.
2016-07-14 14:37:02 +00:00
"toolchains": ["ARM_STD", "GCC_ARM", "IAR"]
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
},
Enable BLE feature on NRF51 and nrf52. Update softdevice references. Add BLE and softdevice related macros. Add specific macros for NRF52_DK.
2016-06-17 10:02:37 +00:00
"MERGE_BOOTLOADER": false,
Add configuration of LF clk source in targer.json for targets MCU_NRF51 & MCU_NRF52 Fix typo
2016-07-19 18:29:38 +00:00
"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"
Add configuration of LF clk source in targer.json for targets MCU_NRF51 & MCU_NRF52 Fix typo
2016-07-19 18:29:38 +00:00
}
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
}
Add NRF52 and NRF52_TARGETS.
2016-06-14 21:39:06 +00:00
},
"NRF52_DK": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF52"],
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +00:00
"macros_add": ["BOARD_PCA10040", "NRF52_PAN_12", "NRF52_PAN_15", "NRF52_PAN_58", "NRF52_PAN_55", "NRF52_PAN_54", "NRF52_PAN_31", "NRF52_PAN_30", "NRF52_PAN_51", "NRF52_PAN_36", "NRF52_PAN_53", "S132", "CONFIG_GPIO_AS_PINRESET", "BLE_STACK_SUPPORT_REQD", "SWI_DISABLE0", "NRF52_PAN_20", "NRF52_PAN_64", "NRF52_PAN_62", "NRF52_PAN_63"],
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
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
Additional device names. mbed_targets.md update
2016-09-21 19:36:21 +00:00
"release_versions": ["2", "5"],
"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
},
"DELTA_DFBM_NQ620": {
"supported_form_factors": ["ARDUINO"],
"inherits": ["MCU_NRF52"],
make "macros_add" as a single line make "macros_add" as a single line
2016-09-14 06:01:57 +00:00
"macros_add": ["BOARD_PCA10040", "NRF52_PAN_12", "NRF52_PAN_15", "NRF52_PAN_58", "NRF52_PAN_55", "NRF52_PAN_54", "NRF52_PAN_31", "NRF52_PAN_30", "NRF52_PAN_51", "NRF52_PAN_36", "NRF52_PAN_53", "S132", "CONFIG_GPIO_AS_PINRESET", "BLE_STACK_SUPPORT_REQD", "SWI_DISABLE0", "NRF52_PAN_20", "NRF52_PAN_64", "NRF52_PAN_62", "NRF52_PAN_63"],
Adding NRF52_DK and NRF51_DK to the v2 and v5 release
2016-07-27 19:52:51 +00:00
"device_has": ["ANALOGIN", "ERROR_PATTERN", "I2C", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SLEEP", "SPI", "SPI_ASYNCH", "SPISLAVE"],
Additional device names. mbed_targets.md update
2016-09-21 19:36:21 +00:00
"release_versions": ["2", "5"],
"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
},
Rename "generic" -> "bluepill" (common name)
2016-06-09 08:36:13 +00:00
"BLUEPILL_F103C8": {
Support for Blue Pill
2016-06-29 08:05:27 +00:00
"core": "Cortex-M3",
"default_toolchain": "GCC_ARM",
"extra_labels": ["STM", "STM32F1", "STM32F103C8"],
"supported_toolchains": ["GCC_ARM"],
"inherits": ["Target"],
Rename field in targets.json, missing features removed
2016-06-09 12:55:02 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "SERIAL", "SLEEP", "SPI", "SPISLAVE"]
Support NUMAKER_PFM_NUC472
2016-07-22 05:04:53 +00:00
},
"NUMAKER_PFM_NUC472": {
"core": "Cortex-M4F",
"default_toolchain": "ARM",
"extra_labels": ["NUVOTON", "NUC472", "NUMAKER_PFM_NUC472"],
"is_disk_virtual": true,
"supported_toolchains": ["ARM", "uARM", "GCC_ARM", "IAR"],
"inherits": ["Target"],
HAL - RNG rename to TRNG
2016-09-21 15:44:19 +00:00
"device_has": ["ANALOGIN", "I2C", "I2CSLAVE", "I2C_ASYNCH", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_ASYNCH", "SERIAL_FC", "SLEEP", "SPI", "SPISLAVE", "SPI_ASYNCH", "TRNG"],
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"],
"device_name": "NUC472HI8AE"
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"],
"post_binary_hook": {"function": "NCS36510TargetCode.ncs36510_addfib"},
"macros": ["REVD", "CM3", "CPU_NCS36510", "TARGET_NCS36510"],
"supported_toolchains": ["GCC_ARM", "ARM", "IAR"],
Formatting code according to ARM guidelines. Ran pylint and astyle. Rebased latest ARMmbed-os code.
2016-08-26 11:22:11 +00:00
"device_has": ["ANALOGIN", "SERIAL", "I2C", "INTERRUPTIN", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SERIAL_FC", "SLEEP", "SPI"],
"release_versions": ["2", "5"]
device_name in targets.json. Removed progen target
2016-09-08 19:34:07 +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
}