Added logic to fix-pins.py to shift off-grid pins to next grid line

[zeroping]

These changes try to move the pin to the previous 100-mil grid line. It checks for overlaps, and rejects moving pins that would then overlap with other pins.

This was just used to fix up the stm32 library, and that was my primary test case.

-Scott

[CarlPoirier]

Hi,

I did some testing on the Altera and ttl_ieee libraries. I did not see any shifting happening even though it should have. Can you check this?

Thanks!

[zeroping]

I see it fixing some pins in both libraries, but not in 100% of components. It bails out on components with more than one rectangle (which is fair - it has no idea what's going on in that situation), and also seems to bail out on multi-unit parts with pins in the same x,y coordinate.

My pin-overlap detecting hack doesn't even consider these multiple-unit parts, and that's why it gives up on those. An example is the 74S140 in the ttl-ieee libarary.

I can work on fixing the multi-unit part issue, but are you seeing it not work on other parts? Can you give specific part examples? Does running with -v give you any more info? (Example: "shifting pin causes overlap: ~ (5) from -500,-150 to -500,-200'")

-Scott

[CarlPoirier]

Hi Scott,

If you can fix the multi-unit part issue, I'll merge it then. For the next part, I still see two more issues. First, it moves pins of non-black-box symbols which we don't want, and also it moves pins at the end of a box such as this:

In this case, I think we could simply extend the rectangle to accomodate the new position.

[poeschlr]

@SchrodingersGat or @jkriege2 is this already implemented in the current scripts? (In other words: can this pull request be closed because the contribution does already exist?)

[SchrodingersGat]

It is not included currently. However this is probably a case where manual fix is required, rather than implementing a "best guess"?

[Ratfink]

I agree that trying to automatically fix unaligned pins seems like something best done manually. This script could only possibly be used for hand-crafted symbols, since if a generator script produced unaligned pins, the generator should be fixed. If a script is used to fix this issue on a hand-crafted symbol, the output of the script would have to be checked manually anyway, and further work could easily be required.

EDIT: wouldn't it be best to rewrite all of fix-pins.py as the fix method in rules/S4_1.py anyway?