Pin positions #40
Pin positions #40
Conversation
"Pin" tags in the ST XML are a bit of a misnomer; they are more of a
logical pin than an actual physical one. Things like "PA", "PB", "VDD",
"VSS", "VREF+" are all examples of Pin names. This makes it clear that
the mapping from Pin names to physical positions on the chip footprint
is not 1:1 - they are not even 1:* or *:1.
For an example where the same Pin name is mapped to multiple physical
pins, see STM32H742V(G-I)Hx.xml where we have the following mappings:
<Pin Name="VDD" Position="D2" Type="Power"/>
<Pin Name="VDD" Position="F5" Type="Power"/>
<Pin Name="VDD" Position="K1" Type="Power"/>
Likewise, for an example where different Pin names are mapped to the
same physical pin, see STM32G031J(4-6)Mx.xml where we have the following
mappings:
<Pin Name="PC14-OSC32_IN (PC14)" Position="1" Type="I/O">
<Pin Name="PB7" Position="1" Type="I/O">
<Pin Name="PB8" Position="1" Type="I/O">
<Pin Name="PB9" Position="1" Type="I/O">
The latter case is a small-outline footprint and the SYSCFG component is
used to select which logical Pin is actually active on the physical pin
at any given time.
The good thing about this is that when there are non 1:1 mappings in the
XML, at least we get a separate Pin tag for each mapping instead of
having to do parsing of something like "PB7-PB8-PB9-PC14-OSC32_IN
(PC14)" which would be impractical.
The mapping of logical names to physical pins is useful for tasks such
as board layout tools. By recording it in a separate table in the
generated XML files, we avoid duplicating thousands of GPIO tags which
would all be identical except for a pin position attribute.
…ical position in the pin table.
The pin table maps logical pin names to physical pin locations, and it
also records the pin type ("Power", "I/O", "Reset", etc.). For the GPIO
pins, it would also be nice to provide a mapping into the separate GPIO
table so that design tools could start with a chip footprint, look at a
physical pin and then figure out what GPIO capabilities are present on
that pin.
This commit adds a copy of the GPIO table's "port" and "pin" attributes
to entries in the pin table that have GPIO functionality so that tools
can use them to make a separate query agains the GPIO table to find the
pin's logical characteristics.
The digital stalker in me I did 😅, hence my original comment ;-P Some more comments:
I'm thinking you could add a separate subtree per package, that might still lead to duplication but more readable duplication? Maybe at some later time we can merge similiar packages back together. <package name="TQFP64">
<pin port="a" pin="0" number="0"/>
...
</package> |
The schemas aren't currently used, mostly because the syntax is auto-generated by the generator anyways, so there won't be any syntactical errors. The much more interesting part of this is semantical errors, ie. data consistency errors and assumptions like "every pin signal must have a corresponding peripheral". But this must be done in Python unit-tests which I'm working on at #35. The schema will probably be removed at some point. |
|
Also sorry about the lack of documentation, only very recently have I gotten third-party (SAM, NRF) contributions to this repo , I'm working on making it better. |
|
Ping @tgree, any update on this? |
|
Implemented via #46 |
Hi @salkinium,
Here's the pull request that adds the physical pin table information to the XML. You were right about the duplicated gpio nodes (I'm not sure if you looked at my original tree or not) so I've reworked it so that the gpio nodes still have no knowledge of their physical pin locations, but the pin table has knowledge of gpio port/pin keys. Even with that change, the generated XML is now 44,352 lines longer (yikes).
I did notice that there is a file:
tools/device/modm_devices/resources/schema/device.xsd
which looks like it should probably be updated to include the new tags under the tag. I can try to do this as well if you like; I've never used .xsd files before though. It also didn't trigger anything when I did 'make generate-stm32' so maybe the file isn't even used?
I also took the liberty of adding *.swp to the .gitignore since it was getting a bit annoying always trying to add my vim swap files to the repository.
Thanks again for looking over these pull requests!