Peripheral instances with different feature sets not supported

[chris-durand]

I'm currently updating the I2C peripheral information. On some controllers (F0, L0) the features of the stm32-extended IP depend on the peripheral instance. I would have expected the DFG to generate multiple <driver> tags for the different instances.

Output:

     <driver name="i2c" type="stm32-extended">
        <feature value="dnf"/>
        <feature device-name="30|70" device-pin="c" value="fmp"/>
        <feature device-name="70" device-pin="r" value="fmp"/>
        <instance value="1"/>
        <instance value="2"/>
     </driver>

Expected:

     <driver name="i2c" type="stm32-extended">
       <feature value="dnf"/>
       <feature value="fmp"/>
       <instance value="1"/>
     </driver>
     <driver name="i2c" type="stm32-extended">
       <feature value="dnf"/>
       <instance value="2"/>
     </driver>

[salkinium]

The merging happens on per-node basis, it has no semantic understanding of its content. The difference is therefore kept as local as possible and doesn't propagate this to upward nodes.

The issue here is that the instance is treated as a list, and can't have any children. I think this needs to be changed, since #1 has similar issues, where some data is scoped by instance, but can't intuitively be added as children to it.

Then you'd add common features as children to the driver node and the instance specific features to the instance.

[chris-durand]

@salkinium Are you planning to implement that?

As a short-term solution I'll remove the features for the stm32-extended IP. We don't support fast mode plus or SMBus right now.

[salkinium]

@salkinium Are you planning to implement that?

No, not in the short term. I think that would be like modm-devices v2.0, since this would most likely break the modm .lb usage. But yeah, there are a couple of things I want to add to modm-devices like BSP data (e.g. Nucleo pinouts) and common algorithms for accessing this data (like GPIO alternate function mappings). But that's future stuff.

As a short-term solution I'll remove the features for the stm32-extended IP. We don't support fast mode plus or SMBus right now.

No, leave them in. The raw information is good, just the "passing" on currently lacks.

The feature tag was intended to distinguish small, purely additive differences of the peripheral memory maps, and the protocol tag was supposed to help with selecting the approriate testing waveform for hwut (in future), but both haven't been completely thought through. The feature tag is only used in the SPI driver at the moment.