Mail Archives: geda-user/2021/04/25/14:06:48
It's a good appreciated effort. As manufacturers make available BSDL
files for components I however think it's a good idea to mention
something about them.
Syntax is different from yours but they are text files. Looking into one
or a few: there is pin label similar to your last column, pin type
similar to your second last column, there is a pin map string and there
are also other information probably not usable in symbols.
Nicklas Karlsson
Den 2021-04-25 kl. 13:43, skrev karl AT aspodata DOT se [via
geda-user AT delorie DOT com]:
> In http://aspodata.se/git/openhw/pdftosym/pintosym.pl
> I have a program that generates symbols.
>
> It takes lists of pinnumber vs pinlabels like:
>
> LQFP100 LQFP64 TFBGA64 LQFP48
> ...
> 6 1 B2 1 pwr VBAT
> 7 2 A2 2 io PC13 TAMPER_RTC
> 8 3 A1 3 pas PC14 OSC32_IN
> 9 4 B1 4 pas PC15 OSC32_OUT
> 10 - - - pwr VSS_5
> 11 - - - pwr VDD_5
> 12 5 C1 5 pas OSC_IN
> 13 6 D1 6 pas OSC_OUT
> ...
>
> where a function is on different pins for different packages.
> I.e. VBAT is a pwr pin, which is pin 1 in the LQFP48 package,
> and B2 in the bga package.
>
> That works quite nice, and for e.g. the power pins I can make them
> line up as in:
> http://aspodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.LQFP100.sym
> http://aspodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.LQFP48.sym
> http://aspodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.LQFP64.sym
> http://aspodata.se/git/openhw/share/gschem/_mcu/stm32f100lm.power.TFBGA64.sym
> so for theese symbols Vdd_3 is in the same position regardless of
> package type, so I can swap the symbol, and all things that were
> connected to Vdd_3 will still be. Compare theese two for example:
> http://aspodata.se/git/openhw/share/gschem/_sub_page/stm32f100lm.power.LQFP48_10u.sch
> http://aspodata.se/git/openhw/share/gschem/_sub_page/stm32f100lm.power.LQFP100_10u.sch
> they depends on symbols in directories:
> http://aspodata.se/git/openhw/share/gschem/_graphical/
> http://aspodata.se/git/openhw/share/gschem/_discrete/
> and the above stm32f1xxx.sym's.
>
> So that works just nice if the pin label stays the same.
>
> ///
>
> But now I'm looking at the smarc standard:
> https://sget.org/standards/smarc/
>
> There you have the same pin, but differnt names/functions depending on
> which generation, also later generations might add alternate functions.
>
> A) same function but the name is changed
> E.g. for pin P26, in Embedian T335X (smarc v1p0?) it is named EthRX-,
> in sget standard for v1p0 and v1p1 it is named GBE_MDI1-, and lastly
> in v2p0,v2p1,v2p1.1 it is named GBE0_MDI1-. I.e. Eth -> GBE -> GEB0
> is the same thing under different names.
>
> B) alternate functions dropped or added
> Se e.g.
> http://aspodata.se/git/openhw/share/gschem/_module/smarc_pinout.txt
> https://sget.org/wp-content/uploads/2020/05/SMARC_V211.pdf p.96..
>
> Take pin S32, between v1p1 - v2p0 there is a function change, and
> between v2p0 - v2p1 an alt.func. was added.
> $ head -1 smarc_pinout.txt ; grep 'S32' smarc_pinout.txt
> pin | SMARC v1.0 | SMARC v1.1 | SMARC v2.0 | SMARC v2.1 (and 2.1.1)
> S32 | SDMMC_D6 | SDMMC_D6 | PCIE_D_RX+ | PCIE_D_RX+ SERDES_0_RX+
>
> Pin P77 was dropped in v2p0, and oops, readded in v2p1.
> $ head -1 smarc_pinout.txt ; grep 'P77' smarc_pinout.txt
> pin | SMARC v1.0 | SMARC v1.1 | SMARC v2.0 | SMARC v2.1 (and 2.1.1)
> P77 | PCIE_B_CKREQ# | PCIE_B_CKREQ# | RSVD | PCIE_B_CKREQ#
>
> What is a good way to handle that ?
>
> Regards,
> /Karl Hammar
>
>
- Raw text -