Open RobertRostohar opened 4 days ago
Historically all provides
and consumes
connections
are validated following the spec rules regardless of which connect
they belong.
The concept of an optional connect
does not exist yet.
To achieve this enhancement the connections
validation must be reworked to consider additionally the connect
parent node.
Similarly as in layer
, should it have an optional
flag as in the schema? It seems the layer's optional flag is not yet documented.
I don't see the need for an optional
flag for connect
.
Introduced an "active" state for connections:
in *.clayer.yml
files.
See here: https://github.com/ReinhardKeil/cmsis-toolbox/blob/main/docs/YML-Input-Format.md#connect
The introduced "active" state is a good approach and should solve this problem.
Describe the bug When none of the
provides:
from aconnect:
are used (consumed) then also theconsumes:
from thatconnect:
should not be required. With other words the wholeconnect:
should be ignored. This is currently not the case. Even when none of theprovides:
are used, theconsumes:
are still required. This defeats the purpose of having multiple connections that are flexible and scalable.To Reproduce The following sensor example shows a solution with two projects:
sensor.csolution.yml
Project
test1
uses the sensor via I2C but does not require the sensor interrupt line. This is indicated withconnections
.test1.cproject.yml
Project
test2
also uses the sensor via I2C but also the interrupt line. This is also indicated withconnections
.test2.cproject.yml
The sensor is described in the
Shield
layer. It uses twoconnect:
, one for the I2C interface (mandatory) and optional interrupt line.Shield.clayer.yml
The
Board
layer provides the required connections for the sensor on the shield. HoweverARDUINO_UNO_D2
is not provided which means that the sensor interrupt line is not supported.Board.clayer.yml
Detecting valid layer combinations will mark the following valid combination as invalid:
csolution list layers sensor.csolution.yml -d
:This combination is however valid since the sensor only requires I2C and does not require the interrupt line. The
connect: Sensor Interrupt
withprovides: SENSOR_INT
is not used (consumed) and it'sconsumes: ARDUINO_UNO_D2
is not required. Thisconnect:
should be ignored and the combination should be then valid.Environment: