mbed-os/tools/targets.py

418 lines
18 KiB
Python
Raw Normal View History

2013-08-06 13:38:00 +00:00
"""
mbed SDK
Copyright (c) 2011-2016 ARM Limited
2013-08-06 13:38:00 +00:00
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
2013-08-06 13:38:00 +00:00
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
"""
CORE_LABELS = {
"ARM7TDMI-S": ["ARM7", "LIKE_CORTEX_ARM7"],
"Cortex-M0" : ["M0", "CORTEX_M", "LIKE_CORTEX_M0"],
"Cortex-M0+": ["M0P", "CORTEX_M", "LIKE_CORTEX_M0"],
"Cortex-M1" : ["M1", "CORTEX_M", "LIKE_CORTEX_M1"],
"Cortex-M3" : ["M3", "CORTEX_M", "LIKE_CORTEX_M3"],
"Cortex-M4" : ["M4", "CORTEX_M", "RTOS_M4_M7", "LIKE_CORTEX_M4"],
"Cortex-M4F" : ["M4", "CORTEX_M", "RTOS_M4_M7", "LIKE_CORTEX_M4"],
"Cortex-M7" : ["M7", "CORTEX_M", "RTOS_M4_M7", "LIKE_CORTEX_M7"],
"Cortex-M7F" : ["M7", "CORTEX_M", "RTOS_M4_M7", "LIKE_CORTEX_M7"],
"Cortex-A9" : ["A9", "CORTEX_A", "LIKE_CORTEX_A9"]
}
import os
import binascii
import struct
import shutil
from tools.patch import patch
from paths import TOOLS_BOOTLOADERS
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
import json
import inspect
import sys
from tools.utils import json_file_to_dict
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
########################################################################################################################
# Generic Target class that reads and interprets the data in targets.json
# A simple class that represents all the exceptions associated with hooking
class HookError(Exception):
pass
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
# A simple decorator used for automatically caching data returned by a function
caches = {}
def cached(func):
def wrapper(*args, **kwargs):
if not caches.has_key(func):
caches[func] = func(*args, **kwargs)
return caches[func]
return wrapper
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
class Target:
# Cumulative attributes can have values appended to them, so they
# need to be computed differently than regular attributes
__cumulative_attributes = ['extra_labels', 'macros', 'device_has', '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
# {target_name: target_instance} map for all the targets in the system
__target_map = {}
# List of targets that were added dynamically using "add_py_targets" (see below)
__py_targets = set()
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
# Load the description of JSON target data
@staticmethod
@cached
def get_json_target_data():
return json_file_to_dict(os.path.join(os.path.dirname(os.path.abspath(__file__)), '..', 'hal', 'targets.json'))
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
# Get the members of this module using Python's "inspect" module
@staticmethod
@cached
def get_module_data():
return dict([(m[0], m[1]) for m in inspect.getmembers(sys.modules[__name__])])
# Return the order in which target descriptions are searched for attributes
# This mimics the Python 2.2 method resolution order, which is what the old targets.py module used
# For more details, check http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path
# The resolution order contains (name, level) tuples, where "name" is the name of the class and "level"
# is the level in the inheritance hierarchy (the target itself is at level 0, its first parent at level 1,
# its parent's parent at level 1 and so on)
def __get_resolution_order(self, target_name, order, level = 0):
if not target_name in [l[0] for l in order]: # the resolution order can't contain duplicate target names
order.append((target_name, level))
parents = self.get_json_target_data()[target_name].get("inherits", [])
for p in parents:
order = self.__get_resolution_order(p, order, level + 1)
return order
# Modify the exporter specification ("progen") by changing all "template" keys to full paths
@staticmethod
def __add_paths_to_progen(data):
out = {}
for key, value in data.items():
if isinstance(value, dict):
out[key] = Target.__add_paths_to_progen(value)
elif key == "template":
out[key] = [os.path.join(os.path.dirname(__file__), 'export', v) for v in value]
else:
out[key] = value
return out
# Comute the value of a given target attribute
def __getattr_helper(self, attrname):
tdata = self.get_json_target_data()
if attrname in self.__cumulative_attributes:
# For a cumulative attribute, figure out when it was defined the last time (in attribute
# resolution order) then follow the "_add" and "_remove" data fields
for idx, t in enumerate(self.resolution_order):
if attrname in tdata[t[0]]: # the attribute was defined at this level in the resolution order
def_idx = idx
break
else:
raise AttributeError("Attribute '%s' not found in target '%s'" % (attrname, self.name))
# Get the starting value of the attribute
v = (tdata[self.resolution_order[def_idx][0]][attrname] or [])[:]
# Traverse the resolution list in high inheritance to low inheritance level, left to right order
# to figure out all the other classes that change the definition by adding or removing elements
for idx in xrange(self.resolution_order[def_idx][1] - 1, -1, -1):
same_level_targets = [t[0] for t in self.resolution_order if t[1] == idx]
for t in same_level_targets:
data = tdata[t]
# Do we have anything to add ?
if data.has_key(attrname + "_add"):
v.extend(data[attrname + "_add"])
# Do we have anything to remove ?
if data.has_key(attrname + "_remove"):
# Macros can be defined either without a value (MACRO) or with a value (MACRO=10).
# When removing, we specify only the name of the macro, without the value. So we need
# to create a mapping between the macro name and its value. This will work for
# extra_labels and other type of arrays as well, since they fall into the "macros
# without a value" category (simple definitions without a value).
name_def_map = {}
for crtv in v:
if crtv.find('=') != -1:
temp = crtv.split('=')
if len(temp) != 2:
raise ValueError("Invalid macro definition '%s'" % crtv)
name_def_map[temp[0]] = crtv
else:
name_def_map[crtv] = crtv
for e in data[attrname + "_remove"]:
if not e in name_def_map:
raise ValueError("Unable to remove '%s' in '%s.%s' since it doesn't exist" % (e, self.name, attrname))
v.remove(name_def_map[e])
return v
# Look for the attribute in the class and its parents, as defined by the resolution order
v = None
for t in self.resolution_order:
data = tdata[t[0]]
if data.has_key(attrname):
v = data[attrname]
break
else: # Attribute not found
raise AttributeError("Attribute '%s' not found in target '%s'" % (attrname, self.name))
# 'progen' needs the full path to the template (the path in JSON is relative to tools/export)
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
return v if attrname != "progen" else self.__add_paths_to_progen(v)
Target K64F addition. Squashed commit of the following: commit db3c9f7682083abeb291e01df31e67e4c50845b3 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Apr 2 09:52:00 2014 +0200 K64F - KSDK - Warnings fixes commit a639a5cdff889c13509c954b0a34ebac861c1361 Merge: 67a2c2a f3de345 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Apr 1 12:48:35 2014 +0200 Merge branch latest 'master' into dev_target_k64f Conflicts: libraries/rtos/rtx/RTX_Conf_CM.c workspace_tools/build_api.py commit 67a2c2aeb976f264db52ea10d18fea9de0d7685f Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Mar 30 13:19:51 2014 +0200 K64F - PinName for buttons (SW2, SW3) commit 957573e2cd42d5c73ed99477abb98c8b883695b2 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 25 11:46:57 2014 +0100 K64F - pins addition to mbed HAL, uart - 4 instances, fix i2c instance which was not stored commit 2347a6d03984e297190910a250f2771032ae6327 Author: sg- <sam.w.grove@gmail.com> Date: Mon Mar 24 15:20:51 2014 -0500 Added wait to i2c stop commit b7b4a9c72e8724087a44078c41a2cb33e4c8d5e3 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 24 19:28:16 2014 +0100 K64F - I2c - ack flag retreive correction (logic inverted in ksdk hal) commit 46c875251263029e32463c3b48473b10496088d9 Author: sg- <sam.w.grove@gmail.com> Date: Mon Mar 24 13:16:18 2014 -0500 Added I2C Pinnames commit b71c7a0dfba7025662f9a9d176494ce4dc86273e Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 18 17:02:34 2014 +0100 K64F Arduino pinNames update commit d41b0ee493263d1d80fcb72b3f0d4d788359c7c9 Merge: 9c0a982 e2574eb Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 18 14:57:57 2014 +0100 Merge remote-tracking branch 'upstream/master' into dev_target_k64f. K64F gpio changed according to the latest mbed master. Conflicts: libraries/rtos/rtx/RTX_CM_lib.h workspace_tools/export/uvision4.py commit 9c0a9822ab14263fff5e3b6459b7c2b4a77ce30c Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 17 21:08:17 2014 +0100 K64F - sleep support commit 5edcf3603d2e7b00eedbb377203a054b7a01e51d Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Mar 16 18:19:55 2014 +0100 K64F - pullup/down corrections, LED1 - R, LED2 - G, LED3 - B commit a2b3b53a1474d32779654765cd1ce2ba2c6b2186 Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Mar 13 20:55:39 2014 +0100 K64F - SPI - delays are set, pin definition for tests commit 1f3b3abe16f4afaaf1b75cb4bf3e3a9d5b6e50a7 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 11 21:26:00 2014 +0100 K64F - DAC update - tested with test a8 - internal reference set to VDDA - PinName DAC0_OUT commit 26d8cf47f8c0786b290ae659beb022901029b313 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 11 08:31:44 2014 +0100 KSDK - drivers layer removal, mbed HAL using only KSDK HAL - ADC corrections with channels, and clock configuration commit 67ebe14f5c88725033ea0fb135d94b6bf9a00fdb Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 10 12:46:08 2014 +0100 K20 copy files removed, targets.py - vertical alignment for K64F definition commit be5c562d513c808e5bd425195a4fb1c71f47a57e Merge: 696a713 fe0aca9 Author: Emilio Monti <emilmont@gmail.com> Date: Mon Mar 10 11:14:55 2014 +0000 Merge branch 'rtos_support' into dev_target_k64f commit 696a713751194b4762f1cdf6c17c0786decd7808 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 10 12:05:30 2014 +0100 [FIX] K64F - adc, sgtl driver updates commit fe0aca9940bbdd5ee70a1a7341a0a2ad2abf912b Author: Emilio Monti <emilmont@gmail.com> Date: Mon Mar 10 11:04:16 2014 +0000 Add RTOS support for K64F commit 5c3edcbca6dbcce628c7cde51ac94a6fc6278ba5 Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Mar 9 20:43:38 2014 +0100 K64F - uvision templates update - uvision 5.10 supports K64F commit 33f18d11d0eadb9243f1be0ae96c5f82e2913d48 Merge: 26f7587 74e9b2e Author: 0xc0170 <c0170@rocketmail.com> Date: Sat Mar 8 10:34:25 2014 +0100 Update branch from mbed master - merge branch 'master' into dev_target_k64f Conflicts: libraries/USBDevice/USBDevice/USBEndpoints.h libraries/USBDevice/USBDevice/USBHAL_KL25Z.cpp workspace_tools/export/uvision4.py workspace_tools/targets.py commit 26f75872b19a1db2a3abb34c6e773bac56acb32f Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Mar 6 22:15:53 2014 +0100 K64F - USBDevice - MPU disable in init commit e54d6bbaa68827bd63058fbf2428e289d15ac1f7 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Feb 26 21:06:58 2014 +0100 K64F - clock setup 4 (usb clock enable) commit c4165732b9520cb31ae3d649d50c353d09dc9932 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Feb 26 20:01:47 2014 +0100 K64F - USBDevice addition commit 9fcdbb8562b1415561b04e902fcdbb4724add5af Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Feb 24 19:11:48 2014 +0100 K64F SPI HAL - initial version commit 8093df58fa7d17fcb5ad04872c958d5254ee1d8a Author: 0xc0170 <c0170@rocketmail.com> Date: Sat Feb 22 13:14:44 2014 +0100 K64F - RTC and I2C implementation (using KPSDK HAL) - instance correction in objects and peripherals names headers commit 7ef3fbda605c2bd53a86f37d0676c0393b2e2949 Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Feb 14 09:45:27 2014 +0100 mbed RTC HAL for K64F commit e40332fd2db8bf36b3e6cabac5729e013da40c28 Merge: e059f65 6bfcd87 Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Feb 13 14:20:20 2014 +0100 Merge branch 'master' into dev_target_k64f Conflicts: workspace_tools/build_api.py workspace_tools/export/uvision4.py workspace_tools/targets.py workspace_tools/toolchains/__init__.py commit e059f65fd09694418f9fa4f38da90954ab9decfe Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Feb 5 21:35:49 2014 +0100 pwm mbed HAL - using jusst ftm hal from KPSDK, not yet functional commit b784278872b1d66ce2940f4988e0479971de8bc0 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Feb 3 18:28:24 2014 +0100 uvision exporters for K64F, uticker - lptmr - lptmr - no hal neiter driver, quick implementation using registers and internal clock - exporters for K64F - using K60 1MB target, because K64F is not available in 4.7 yet commit 7a030693e025c2bd456563f3e6f4456033d3f644 Author: Bogdan Marinescu <bogdan.marinescu@arm.com> Date: Tue Jan 28 16:29:54 2014 +0200 Attempt to keep target's include directory structure commit a2445b383224125abf4ee23bd17f1e685010a4a5 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Jan 27 07:25:16 2014 +0100 Original KPSDK include directory structure for device commit 9c07c58bb9cf5e9d8be4c3bec117ee87a5ea81c0 Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Jan 24 16:51:17 2014 +0000 K64F ADC - initial commit - ADC using KPSDK driver commit 88e03ef8c5855a57887bb36cddfa5ab1491d400c Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Jan 24 12:18:14 2014 +0000 GPI IRQ - nvic vectors number correction - gpio irq HAL implementation commit e83f1108ae9f779ce240d6cdfe23532bfa00a55e Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Jan 24 10:06:44 2014 +0000 PORT HAL implementation - using gpio hal port commit 75c21943200c8240d1edaf0a67f84b9f3b43db7f Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Jan 23 16:02:36 2014 +0000 Serial (only 8bit at the moment), using KPSDK HAL commit 296e79def617f005918cd8e2aa574f2908a362ca Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Jan 23 08:35:50 2014 +0000 Folder structure correction for K64F - KPSDK - scripts reverted, only new macro is available - K64F specific headers are in HAL in device folder commit f236b1ffcb9c8b443ad8483bca8b0e564a63f004 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Jan 22 16:07:30 2014 +0100 update KPSDK to RC1 - the update causes few more dependences which were reported. Will be removed later (usb, boards) - pit timer - hal use , pit driver uses us period commit f02c5353d4920e885f803ad235e5e82001e97b94 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Jan 21 09:45:55 2014 +0100 KPSDK In/out declaration removal commit 8c88e098b4dc4901753309f1e6db4adb8aca4384 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Jan 21 09:12:41 2014 +0100 gpio_t struct only needs pinName - gpio_init creates init objects on stack commit 6b96d4ea2c5a6a2cb13571d740ffb679a62f8f3d Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Jan 20 19:59:03 2014 +0100 us ticker - pit implementation (not functional yet) - pit driver in KPSDK - added sdk prefix to needed functions commit 098e60a3846abcd4c9c00bd199b01d4b1899807f Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Jan 20 13:01:58 2014 +0100 GPIO HAL - gpio_set implementation commit 2bfebbfc75dcd08c20297ba42dc0cc82e5381a40 Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Jan 19 20:46:55 2014 +0100 GPIO KPSDK changes - gpio driver - sdk prefix, no lookuptable, input/output declaration, refactoring, set MUX to GPIO - gpio api in mbed implementation, tested on blue led commit d083733c485fbdd79ed9ce87100df9fee82294a7 Author: 0xc0170 <c0170@rocketmail.com> Date: Sat Jan 18 17:14:09 2014 +0100 Update folder structure for KPSDK - drivers addition - usb (needed by drivers - needs to be fixed) - utilities - hal folder - drivers/flash removed (needs to be fixed) - usb host removed (needs to be fixed) commit 9abcf3d94a2cc849cd6e586c1bad650b6a340a0c Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Jan 16 11:06:16 2014 +0100 Initial commit for K64F - KPSDK addition - CMSIS + HAL for K64F - HAL is not yet implemented - scripts - target contain macros, ignore folders, cmsis copy folders
2014-04-02 12:39:01 +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
# Return the value of an attribute
# This function only computes the attribute's value once, then adds it to the instance attributes
# (in __dict__), so the next time it is returned directly
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
def __getattr__(self, attrname):
v = self.__getattr_helper(attrname)
self.__dict__[attrname] = v
return v
# Add one or more new target(s) represented as a Python dictionary in 'new_targets'
# It it an error to add a target with a name that exists in "targets.json"
# However, it is OK to add a target that was previously added via "add_py_targets"
# (this makes testing easier without changing the regular semantics)
@staticmethod
def add_py_targets(new_targets):
crt_data = Target.get_json_target_data()
# First add all elemnts to the internal dictionary
for tk, tv in new_targets.items():
if crt_data.has_key(tk) and (not tk in Target.__py_targets):
raise Exception("Attempt to add target '%s' that already exists" % tk)
crt_data[tk] = tv
Target.__py_targets.add(tk)
# Then create the new instances and update global variables if needed
for tk, tv in new_targets.items():
# Is the target already created?
old_target = Target.__target_map.get(tk, None)
# Instantiate this target. If it is public, update the data in
# in TARGETS, TARGET_MAP, TARGET_NAMES
new_target = Target(tk)
if tv.get("public", True):
if old_target: # remove the old target from TARGETS and TARGET_NAMES
TARGETS.remove(old_target)
TARGET_NAMES.remove(tk)
# Add the new target
TARGETS.append(new_target)
TARGET_MAP[tk] = new_target
TARGET_NAMES.append(tk)
# Update the target cache
Target.__target_map[tk] = new_target
# Return the target instance starting from the target name
@staticmethod
def get_target(name):
if not Target.__target_map.has_key(name):
Target.__target_map[name] = Target(name)
return Target.__target_map[name]
Target K64F addition. Squashed commit of the following: commit db3c9f7682083abeb291e01df31e67e4c50845b3 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Apr 2 09:52:00 2014 +0200 K64F - KSDK - Warnings fixes commit a639a5cdff889c13509c954b0a34ebac861c1361 Merge: 67a2c2a f3de345 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Apr 1 12:48:35 2014 +0200 Merge branch latest 'master' into dev_target_k64f Conflicts: libraries/rtos/rtx/RTX_Conf_CM.c workspace_tools/build_api.py commit 67a2c2aeb976f264db52ea10d18fea9de0d7685f Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Mar 30 13:19:51 2014 +0200 K64F - PinName for buttons (SW2, SW3) commit 957573e2cd42d5c73ed99477abb98c8b883695b2 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 25 11:46:57 2014 +0100 K64F - pins addition to mbed HAL, uart - 4 instances, fix i2c instance which was not stored commit 2347a6d03984e297190910a250f2771032ae6327 Author: sg- <sam.w.grove@gmail.com> Date: Mon Mar 24 15:20:51 2014 -0500 Added wait to i2c stop commit b7b4a9c72e8724087a44078c41a2cb33e4c8d5e3 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 24 19:28:16 2014 +0100 K64F - I2c - ack flag retreive correction (logic inverted in ksdk hal) commit 46c875251263029e32463c3b48473b10496088d9 Author: sg- <sam.w.grove@gmail.com> Date: Mon Mar 24 13:16:18 2014 -0500 Added I2C Pinnames commit b71c7a0dfba7025662f9a9d176494ce4dc86273e Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 18 17:02:34 2014 +0100 K64F Arduino pinNames update commit d41b0ee493263d1d80fcb72b3f0d4d788359c7c9 Merge: 9c0a982 e2574eb Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 18 14:57:57 2014 +0100 Merge remote-tracking branch 'upstream/master' into dev_target_k64f. K64F gpio changed according to the latest mbed master. Conflicts: libraries/rtos/rtx/RTX_CM_lib.h workspace_tools/export/uvision4.py commit 9c0a9822ab14263fff5e3b6459b7c2b4a77ce30c Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 17 21:08:17 2014 +0100 K64F - sleep support commit 5edcf3603d2e7b00eedbb377203a054b7a01e51d Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Mar 16 18:19:55 2014 +0100 K64F - pullup/down corrections, LED1 - R, LED2 - G, LED3 - B commit a2b3b53a1474d32779654765cd1ce2ba2c6b2186 Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Mar 13 20:55:39 2014 +0100 K64F - SPI - delays are set, pin definition for tests commit 1f3b3abe16f4afaaf1b75cb4bf3e3a9d5b6e50a7 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 11 21:26:00 2014 +0100 K64F - DAC update - tested with test a8 - internal reference set to VDDA - PinName DAC0_OUT commit 26d8cf47f8c0786b290ae659beb022901029b313 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Mar 11 08:31:44 2014 +0100 KSDK - drivers layer removal, mbed HAL using only KSDK HAL - ADC corrections with channels, and clock configuration commit 67ebe14f5c88725033ea0fb135d94b6bf9a00fdb Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 10 12:46:08 2014 +0100 K20 copy files removed, targets.py - vertical alignment for K64F definition commit be5c562d513c808e5bd425195a4fb1c71f47a57e Merge: 696a713 fe0aca9 Author: Emilio Monti <emilmont@gmail.com> Date: Mon Mar 10 11:14:55 2014 +0000 Merge branch 'rtos_support' into dev_target_k64f commit 696a713751194b4762f1cdf6c17c0786decd7808 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Mar 10 12:05:30 2014 +0100 [FIX] K64F - adc, sgtl driver updates commit fe0aca9940bbdd5ee70a1a7341a0a2ad2abf912b Author: Emilio Monti <emilmont@gmail.com> Date: Mon Mar 10 11:04:16 2014 +0000 Add RTOS support for K64F commit 5c3edcbca6dbcce628c7cde51ac94a6fc6278ba5 Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Mar 9 20:43:38 2014 +0100 K64F - uvision templates update - uvision 5.10 supports K64F commit 33f18d11d0eadb9243f1be0ae96c5f82e2913d48 Merge: 26f7587 74e9b2e Author: 0xc0170 <c0170@rocketmail.com> Date: Sat Mar 8 10:34:25 2014 +0100 Update branch from mbed master - merge branch 'master' into dev_target_k64f Conflicts: libraries/USBDevice/USBDevice/USBEndpoints.h libraries/USBDevice/USBDevice/USBHAL_KL25Z.cpp workspace_tools/export/uvision4.py workspace_tools/targets.py commit 26f75872b19a1db2a3abb34c6e773bac56acb32f Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Mar 6 22:15:53 2014 +0100 K64F - USBDevice - MPU disable in init commit e54d6bbaa68827bd63058fbf2428e289d15ac1f7 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Feb 26 21:06:58 2014 +0100 K64F - clock setup 4 (usb clock enable) commit c4165732b9520cb31ae3d649d50c353d09dc9932 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Feb 26 20:01:47 2014 +0100 K64F - USBDevice addition commit 9fcdbb8562b1415561b04e902fcdbb4724add5af Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Feb 24 19:11:48 2014 +0100 K64F SPI HAL - initial version commit 8093df58fa7d17fcb5ad04872c958d5254ee1d8a Author: 0xc0170 <c0170@rocketmail.com> Date: Sat Feb 22 13:14:44 2014 +0100 K64F - RTC and I2C implementation (using KPSDK HAL) - instance correction in objects and peripherals names headers commit 7ef3fbda605c2bd53a86f37d0676c0393b2e2949 Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Feb 14 09:45:27 2014 +0100 mbed RTC HAL for K64F commit e40332fd2db8bf36b3e6cabac5729e013da40c28 Merge: e059f65 6bfcd87 Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Feb 13 14:20:20 2014 +0100 Merge branch 'master' into dev_target_k64f Conflicts: workspace_tools/build_api.py workspace_tools/export/uvision4.py workspace_tools/targets.py workspace_tools/toolchains/__init__.py commit e059f65fd09694418f9fa4f38da90954ab9decfe Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Feb 5 21:35:49 2014 +0100 pwm mbed HAL - using jusst ftm hal from KPSDK, not yet functional commit b784278872b1d66ce2940f4988e0479971de8bc0 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Feb 3 18:28:24 2014 +0100 uvision exporters for K64F, uticker - lptmr - lptmr - no hal neiter driver, quick implementation using registers and internal clock - exporters for K64F - using K60 1MB target, because K64F is not available in 4.7 yet commit 7a030693e025c2bd456563f3e6f4456033d3f644 Author: Bogdan Marinescu <bogdan.marinescu@arm.com> Date: Tue Jan 28 16:29:54 2014 +0200 Attempt to keep target's include directory structure commit a2445b383224125abf4ee23bd17f1e685010a4a5 Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Jan 27 07:25:16 2014 +0100 Original KPSDK include directory structure for device commit 9c07c58bb9cf5e9d8be4c3bec117ee87a5ea81c0 Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Jan 24 16:51:17 2014 +0000 K64F ADC - initial commit - ADC using KPSDK driver commit 88e03ef8c5855a57887bb36cddfa5ab1491d400c Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Jan 24 12:18:14 2014 +0000 GPI IRQ - nvic vectors number correction - gpio irq HAL implementation commit e83f1108ae9f779ce240d6cdfe23532bfa00a55e Author: 0xc0170 <c0170@rocketmail.com> Date: Fri Jan 24 10:06:44 2014 +0000 PORT HAL implementation - using gpio hal port commit 75c21943200c8240d1edaf0a67f84b9f3b43db7f Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Jan 23 16:02:36 2014 +0000 Serial (only 8bit at the moment), using KPSDK HAL commit 296e79def617f005918cd8e2aa574f2908a362ca Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Jan 23 08:35:50 2014 +0000 Folder structure correction for K64F - KPSDK - scripts reverted, only new macro is available - K64F specific headers are in HAL in device folder commit f236b1ffcb9c8b443ad8483bca8b0e564a63f004 Author: 0xc0170 <c0170@rocketmail.com> Date: Wed Jan 22 16:07:30 2014 +0100 update KPSDK to RC1 - the update causes few more dependences which were reported. Will be removed later (usb, boards) - pit timer - hal use , pit driver uses us period commit f02c5353d4920e885f803ad235e5e82001e97b94 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Jan 21 09:45:55 2014 +0100 KPSDK In/out declaration removal commit 8c88e098b4dc4901753309f1e6db4adb8aca4384 Author: 0xc0170 <c0170@rocketmail.com> Date: Tue Jan 21 09:12:41 2014 +0100 gpio_t struct only needs pinName - gpio_init creates init objects on stack commit 6b96d4ea2c5a6a2cb13571d740ffb679a62f8f3d Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Jan 20 19:59:03 2014 +0100 us ticker - pit implementation (not functional yet) - pit driver in KPSDK - added sdk prefix to needed functions commit 098e60a3846abcd4c9c00bd199b01d4b1899807f Author: 0xc0170 <c0170@rocketmail.com> Date: Mon Jan 20 13:01:58 2014 +0100 GPIO HAL - gpio_set implementation commit 2bfebbfc75dcd08c20297ba42dc0cc82e5381a40 Author: 0xc0170 <c0170@rocketmail.com> Date: Sun Jan 19 20:46:55 2014 +0100 GPIO KPSDK changes - gpio driver - sdk prefix, no lookuptable, input/output declaration, refactoring, set MUX to GPIO - gpio api in mbed implementation, tested on blue led commit d083733c485fbdd79ed9ce87100df9fee82294a7 Author: 0xc0170 <c0170@rocketmail.com> Date: Sat Jan 18 17:14:09 2014 +0100 Update folder structure for KPSDK - drivers addition - usb (needed by drivers - needs to be fixed) - utilities - hal folder - drivers/flash removed (needs to be fixed) - usb host removed (needs to be fixed) commit 9abcf3d94a2cc849cd6e586c1bad650b6a340a0c Author: 0xc0170 <c0170@rocketmail.com> Date: Thu Jan 16 11:06:16 2014 +0100 Initial commit for K64F - KPSDK addition - CMSIS + HAL for K64F - HAL is not yet implemented - scripts - target contain macros, ignore folders, cmsis copy folders
2014-04-02 12:39:01 +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
def __init__(self, name):
self.name = name
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
# Compute resolution order once (it will be used later in __getattr__)
self.resolution_order = self.__get_resolution_order(self.name, [])
# Create also a list with only the names of the targets in the resolution order
self.resolution_order_names = [t[0] for t in self.resolution_order]
def program_cycle_s(self):
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
try:
return self.__getattr__("program_cycle_s")
except AttributeError:
return 4 if self.is_disk_virtual else 1.5
def get_labels(self):
labels = [self.name] + CORE_LABELS[self.core] + self.extra_labels
# Automatically define UVISOR_UNSUPPORTED if the target doesn't specifically
# define UVISOR_SUPPORTED
if not "UVISOR_SUPPORTED" in labels:
labels.append("UVISOR_UNSUPPORTED")
return labels
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
# For now, this function only allows "post binary" hooks (hooks that are executed after
# the binary image is extracted from the executable file)
def init_hooks(self, hook, toolchain_name):
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
# If there's no hook, simply return
try:
hook_data = self.post_binary_hook
except AttributeError:
return
# A hook was found. The hook's name is in the format "classname.functionname"
temp = hook_data["function"].split(".")
if len(temp) != 2:
raise HookError("Invalid format for hook '%s' in target '%s' (must be 'class_name.function_name')" % (hook_data["function"], self.name))
class_name, function_name = temp[0], temp[1]
# "class_name" must refer to a class in this file, so check if the class exists
mdata = self.get_module_data()
if not mdata.has_key(class_name) or not inspect.isclass(mdata[class_name]):
raise HookError("Class '%s' required by '%s' in target '%s' not found in targets.py" % (class_name, hook_data["function"], self.name))
# "function_name" must refer to a static function inside class "class_name"
cls = mdata[class_name]
if (not hasattr(cls, function_name)) or (not inspect.isfunction(getattr(cls, function_name))):
raise HookError("Static function '%s' required by '%s' in target '%s' not found in class '%s'" % (function_name, hook_data["function"], self.name, class_name))
# Check if the hook specification also has target restrictions
toolchain_restrictions = hook_data.get("toolchains", [])
if toolchain_restrictions and (toolchain_name not in toolchain_restrictions):
return
# Finally, hook the requested function
hook.hook_add_binary("post", getattr(cls, function_name))
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this 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 specific code goes in this section
# This code can be invoked from the target description using the "post_binary_hook" key
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
class LPCTargetCode:
@staticmethod
def lpc_patch(t_self, resources, elf, binf):
t_self.debug("LPC Patch: %s" % os.path.split(binf)[1])
patch(binf)
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
class LPC4088Code:
@staticmethod
def binary_hook(t_self, resources, elf, binf):
if not os.path.isdir(binf):
# Regular binary file, nothing to do
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
LPCTargetCode.lpc_patch(t_self, resources, elf, binf)
return
outbin = open(binf + ".temp", "wb")
partf = open(os.path.join(binf, "ER_IROM1"), "rb")
# Pad the fist part (internal flash) with 0xFF to 512k
data = partf.read()
outbin.write(data)
outbin.write('\xFF' * (512*1024 - len(data)))
partf.close()
# Read and append the second part (external flash) in chunks of fixed size
chunksize = 128 * 1024
partf = open(os.path.join(binf, "ER_IROM2"), "rb")
while True:
data = partf.read(chunksize)
outbin.write(data)
if len(data) < chunksize:
break
partf.close()
outbin.close()
# Remove the directory with the binary parts and rename the temporary
# file to 'binf'
shutil.rmtree(binf, True)
os.rename(binf + '.temp', binf)
t_self.debug("Generated custom binary file (internal flash + SPIFI)")
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
LPCTargetCode.lpc_patch(t_self, resources, elf, binf)
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
class TEENSY3_1Code:
2015-01-15 19:11:40 +00:00
@staticmethod
def binary_hook(t_self, resources, elf, binf):
from intelhex import IntelHex
binh = IntelHex()
binh.loadbin(binf, offset = 0)
2015-01-15 19:11:40 +00:00
with open(binf.replace(".bin", ".hex"), "w") as f:
binh.tofile(f, format='hex')
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
class MTSCode:
@staticmethod
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
def _combine_bins_helper(target_name, t_self, resources, elf, binf):
loader = os.path.join(TOOLS_BOOTLOADERS, target_name, "bootloader.bin")
target = binf + ".tmp"
if not os.path.exists(loader):
print "Can't find bootloader binary: " + loader
return
outbin = open(target, 'w+b')
part = open(loader, 'rb')
data = part.read()
outbin.write(data)
outbin.write('\xFF' * (64*1024 - len(data)))
part.close()
part = open(binf, 'rb')
data = part.read()
outbin.write(data)
part.close()
outbin.seek(0, 0)
data = outbin.read()
outbin.seek(0, 1)
crc = struct.pack('<I', binascii.crc32(data) & 0xFFFFFFFF)
outbin.write(crc)
outbin.close()
os.remove(binf)
os.rename(target, binf)
@staticmethod
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
def combine_bins_mts_dot(t_self, resources, elf, binf):
MTSCode._combine_bins_helper("MTS_MDOT_F411RE", t_self, resources, elf, binf)
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
@staticmethod
def combine_bins_mts_dragonfly(t_self, resources, elf, binf):
MTSCode._combine_bins_helper("MTS_DRAGONFLY_F411RE", t_self, resources, elf, binf)
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
class MCU_NRF51Code:
@staticmethod
def binary_hook(t_self, resources, elf, binf):
# Scan to find the actual paths of soft device
sdf = None
for softdeviceAndOffsetEntry in t_self.target.EXPECTED_SOFTDEVICES_WITH_OFFSETS:
for hexf in resources.hex_files:
if hexf.find(softdeviceAndOffsetEntry['name']) != -1:
t_self.debug("SoftDevice file found %s." % softdeviceAndOffsetEntry['name'])
sdf = hexf
if sdf is not None: break
if sdf is not None: break
if sdf is None:
t_self.debug("Hex file not found. Aborting.")
return
# Look for bootloader file that matches this soft device or bootloader override image
blf = None
if t_self.target.MERGE_BOOTLOADER is True:
for hexf in resources.hex_files:
if hexf.find(t_self.target.OVERRIDE_BOOTLOADER_FILENAME) != -1:
t_self.debug("Bootloader file found %s." % t_self.target.OVERRIDE_BOOTLOADER_FILENAME)
blf = hexf
break
elif hexf.find(softdeviceAndOffsetEntry['boot']) != -1:
t_self.debug("Bootloader file found %s." % softdeviceAndOffsetEntry['boot'])
blf = hexf
break
2014-02-21 15:05:21 +00:00
# Merge user code with softdevice
from intelhex import IntelHex
binh = IntelHex()
binh.loadbin(binf, offset=softdeviceAndOffsetEntry['offset'])
if t_self.target.MERGE_SOFT_DEVICE is True:
t_self.debug("Merge SoftDevice file %s" % softdeviceAndOffsetEntry['name'])
sdh = IntelHex(sdf)
binh.merge(sdh)
if t_self.target.MERGE_BOOTLOADER is True and blf is not None:
t_self.debug("Merge BootLoader file %s" % blf)
blh = IntelHex(blf)
binh.merge(blh)
2014-03-18 10:16:16 +00:00
with open(binf.replace(".bin", ".hex"), "w") as f:
binh.tofile(f, format='hex')
2014-03-18 10:16:16 +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
########################################################################################################################
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
# Instantiate all public targets
TARGETS = [Target.get_target(name) for name, value in Target.get_json_target_data().items() if value.get("public", True)]
# Map each target name to its unique instance
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this 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_MAP = dict([(t.name, t) for t in TARGETS])
TARGET_NAMES = TARGET_MAP.keys()
# Some targets with different name have the same exporters
Moved target definitions to JSON format (long commit message ahead. Sorry about that, it can't be helped.) This commit changs targets definition from Python to JSON format, as part of the configuration mechanism implementation. There is a new file under workspace_tools/ called "targets.json" which contains the target definitions. "targets.py" remains, but becomes a wrapper on top of "targets.json", with the same interface as before. This has the advantage of not requiring code changes outside "targets.py". Most of the JSON definitions of targets were automatically generated by a script (available upon request since it doesn't make a lot of sense to include it here), only those targets that had more than one parent in the Python implementation were converted by hand. The target definitions should be pretty self-explanatory. A number of things are different in the JSON implementation (this is just a summary, check docs/mbed_targets.md (also part of this PR) for a more complete description): - "program_cycle_s" is now a value (as opposed to a function in the Python implementation), since it only returned a number in all the Python target implementations. The main definition that actually contains some code (in class "Target") remains in target.py - array values in "macros" and "extra_labels" can be modified dynamically. Values can be added using "macros_add" and "extra_labels_add" or removed using "macros_remove" and "extra_labels_remove". This mechanism is available for all attributes with a list type, but it's currently enabled only for "macros" and "extra_labels" to keep things simple. - "init_hooks"/"binary_hook" are now implemented in terms of a single JSON key valled "post_binary_hook". The corresponding code is also in "targets.py", under the various TargetCode classes (see for example LPC4088Code in targets.py). Just like in the Python implementation, a target can inherit from zero, one or more targets. The resolution order for the target's attributes follows the one used by the Python code (I used http://makina-corpus.com/blog/metier/2014/python-tutorial-understanding-python-mro-class-search-path as a reference for the implementation of resolution order). This is obviously a very dangerous commit, since it affects all targets. I tested compilation for a number of targets (K64F, LPC1768, NRF51822) but there's definitely a lot more to be done in terms of testing. I also tried to test in a different way: I wrote a script that imports the old (Python) and the new (JSON) implementations and verifies that the attributes in the old implementations exist and have the same values in the new implementations (it also verifies that the attribute resolution order is the same in the two implementations). If you're interested, the script is here: https://gist.github.com/bogdanm/c9d8cf34214109a4b9079befed6b3c0c And the results of running the script are below (note that the script outputs only the target names that were found to be problematic): NRF51_MICROBIT_BOOT: Resolution order is different in old and new old: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_BOOT', 'MCU_NRF51_16K_BOOT_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BOOT_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_BOOT', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BOOT', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_BOOT', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT: Resolution order is different in old and new old: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT', 'MCU_NRF51_16K_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NRF51_16K_S110', 'MCU_NORDIC_16K', 'MCU_NRF51_16K'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_NRF_LFCLK_RC'] NRF51_MICROBIT_OTA: Resolution order is different in old and new old: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target', 'MCU_NRF51_S110'] new: ['NRF51_MICROBIT_OTA', 'MCU_NRF51_16K_OTA_S110', 'MCU_NRF51_S110', 'MCU_NRF51_16K_OTA_BASE', 'MCU_NRF51_16K_BASE', 'MCU_NRF51', 'Target'] 'extra_labels' has different values in old and new old: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_OTA', 'MCU_NRF51_16K_S110', 'NRF51_MICROBIT'] new: ['NORDIC', 'MCU_NRF51', 'MCU_NRF51822', 'MCU_NORDIC_16K', 'MCU_NRF51_16K', 'MCU_NRF51_16K_S110', 'MCU_NRF51_16K_OTA', 'NRF51_MICROBIT'] 'macros' has different values in old and new old: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] new: ['NRF51', 'TARGET_NRF51822', 'TARGET_MCU_NORDIC_16K', 'TARGET_MCU_NRF51_16K', 'TARGET_MCU_NRF51_16K_S110', 'TARGET_MCU_NRF51_16K_OTA', 'TARGET_OTA_ENABLED', 'TARGET_NRF51_MICROBIT', 'TARGET_NRF_LFCLK_RC'] NOT OK: ['NRF51_MICROBIT', 'NRF51_MICROBIT_BOOT', 'NRF51_MICROBIT_OTA'] The reasons for the above output are subtle and related to the extremely weird way in which we defined target data in the Python implementation: we used both class attributes and instance attributes. This can complicate resolution order quite a bit and those two levels don't exist in JSON: there's only one attribute type (equivalent to Python's instance attributes). To make that work, I had to change the inheritance order of the above targets (that use multiple inheritance) which in turn changed the order of some macros and extra_labels (and of course the resolution order). No harm done: the values are the same, only their ordering is different. I don't believe this causes any problems for 'extra_labels' and 'macros'. This method of testing has its limitations though; in particular, it can't test the hooks. I'm opened to ideas about how to test this better, but I think that we need to remember that this commit might break some targets and keep an eye out for "weird errors" in the future.
2016-05-17 17:50:01 +00:00
EXPORT_MAP = {}
# Detection APIs
def get_target_detect_codes():
""" Returns dictionary mapping detect_code -> platform_name
"""
result = {}
for target in TARGETS:
for detect_code in target.detect_code:
result[detect_code] = target.name
return result