-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add condition
attribute to board
, device
and part
elements
#236
Comments
Hello @jkrech, (In case it is accepted, I can take charge of the PR.) |
Should we clarify what would mean adding conditions to board, devices, parts? |
Hi @mdortel-stm, These conditions should only help an user to identify potential issues. They, if not satisfied, should not be considered blocking issues. |
I think this may need some further discussion. Would you be able to provide some examples that could be used for testing? |
Hi, |
In light of the proposal to optionally describe a hardware project (here: 1178, I am wondering whether the above extension describing inter-dependencies of hardware needs to be reviewed or is no longer relevant? |
Hi, As you mention @jkrech, when an HW project is created, it can serve as a reference to find SW Components with matching H-conditions as a complement to D-conditions and B-conditions (= in short, conditions between SW and HW), but there is no need for "intra-HW" dependencies (= conditions between HW elements such as boards, devices and parts). On the other side, allowing for conditions at the HW-elements level could also be used to introduce a HW-to-SW dependency : an HW part could optionally have a condition to select a (set of) SW Component able to drive it. BR |
Could this be solved using requirements/targets instead? |
Using requirements/targets will only set the HW dependency at the full package level. This proposal aims at being more accurate than the package level when defining the dependencies between HW elements. Another example : a board element describing an X-Nucleo daughterboard could have a condition on a Nucleo motherboard, or to any board holding a male ST Morpho connector. |
The
condition
element can be used to create dependency rules using several attributes defined in the standard for other elements.E.g.:
Dvendor
,Dname
, … attributes can be used for creating a dependency rule on a<device>
elementCvendor
,Cbundle
, .. attributes can be used for creating a dependency rule on a<component>
elementBvendor
,Bname
, .. attributes can be used for creating a dependency rule on a<board>
elementHvendor
,Hname
attributes can be used for creating a dependency rule on a<part>
elementAt present, in the standard, among the
<device>
, the<component>
, the<board>
and the<part>
elements, only the<component>
has the attributecondition
.Hence, a
condition
can be used only to create a dependency rule between a<component>
element and the other elements (another<component>
, a<device>
, a<board>
and a<part>
).No other kind of dependencies can be created.
E.g.: there is no way to describe in the PDSC file the dependency between boards (e.g. a daughter board working only when mounted on a specific mother board) or between a board and a part or a device (and vice-versa).
Adding the
condition
attribute also toboard
,device
andpart
elements, could allow a pack developer to have all the tools in the standard for describing all the possible dependencies among the defined elements.The text was updated successfully, but these errors were encountered: