Generic ICs with oblong/rectangular pads?

I started from a different footprint that I had modified (incorrectly it turns out :slight_smile: ) for someone else a while back. I’ve been testing and fixing things I found wrong until I think these are good enough for now. For others reading this, I want to change the parts factory to use this as the standard IC (and possibly header too) footprints so if you see issues, speak up. In any case here are the three footprints you wanted. As usual the forum doesn’t like the svg, so they are posted as fzp files that you need to download then rename to .svg.

svg.pcb.8_pin_300mil_pin_1_pcb.fzp (8.3 KB)

edit: this one is wrong, it is a copy of the 28 pin. I’ll correct it in a bit. Corrected now.

svg.pcb.18_pin_300mil_pin_1_pcb.fzp (16.1 KB)

svg.pcb.28_pin_300mil_pin_1_pcb.fzp (22.7 KB)

As well a png of the footprint so others can see what this is about without downloading:

8dip_pcb

edit: (aug 2020) someone requested a 16 pin and 40 pin version appended here

DIP-16-oblong-pads.fzpz (6.2 KB)

edit: reloaded a correct 600 mil spacing 40pin socket …

DIP-40-oblong-pads-600mil.fzpz (9.4 KB)

You can route a standard size trace between the pins without causeing a DRC error with standard settings. Pin 1 is marked by a squarer pin.

Peter

Hello Peter.
Thank you again for your efforts. I’m not sure if I should like the squared pin 1, but hey, your graphics - your rules :wink:

May I kindly ask you some questions as I would like to learn more about part design?

a) How do you achieve the grid alignment in Fritzing?
I see that the top/left pin is at 50/50 (I assume 51.041668 is just some mismatch) but what measure keeps it perfect in the 100/100 mil grid of the PCB view? Based on the numbers I would expect, that the part aligns in the middle of the box - not at the corner. I don’t find any hint in the XML to get that offset from 50 to 100. How do you do that?

b) Is there any reason why you draw the parts in “landscape” not in “portrait” dimensions? Portrait mode will give pin 1 the position top left.

c) hole measurements in general are miracle to me
the holes are circles defined with r=22.5 with stroke 10. That should be 22.5*2=45mil Minus 5 for half the stroke (?) leaves 40mil = 1,016 mm as drilling hole? Is that correct ? The fab will produce a 1mm hole?

The reason I want to clarify: I want to make a part with two rows in line (100mil) and the oblong pads are to large for a 100mil grid. Even the round standard header holes are to large for routing standard wires between them. So what would be the best hole definition for a 1mm header? To be precise: the header measures 0.64mm/0.025mil. Should I just take the r=22.5 with 10mm stroke - but that’s against the “fritzing graphic standards” as they suggest 20mils at least. source: http://fritzing.org/fritzings-graphic-standards/
03tworows

d) i found that the hole in the pad is not really a circle, it’s more like a Easter egg ;-). I know it’s already in the very first sparkfun part, but just want to warn you if you want to do more parts with that pins (and I see even my generator generates Easter eggs).
03pad

If you don’t like the square pin, in a text editor (or the Inkscape XML editor) just copy the d parameter of the path for pin 1 in to the d parmeter of the path for pin 0 and change the first parameter after the m to 1 less (from 151 to 51 if I recall correctly) and you will have all the same pads. I usually like pin 1 to be different so chip alignment is obvious. That is one of the nice things about Fritzing, if you don’t like a part you have the source and can change it suit you better.

Sure, that’s how I learned parts design (as there isn’t much good documentation around) and pretty much the only way so far to learn the various corner cases.

Usually with difficulty and often by trial and error :slight_smile: . This is one of Fritzing’s oddnesses and I haven’t yet dug in to the source to see what really happens. In theory alignment is thought to start at pin 0, but tests tell me it is more complex that that. There seems to be some kind of voting operation (or possibly a bug) that means if you take a 4 pin chip in .1 in alignment and move pin 0 (which I would expect to change the other 3 pins alignment relative to other pads on the board which is the usual case I’m dealing with), only pin 0 changes alignment. At some point of moving the other pins does change alignment relative to the rest of the board, but I haven’t figured out how yet. The other part to this (and I think what you are actually asking here) is that Inkscape aligns to the edge of the graphic where fritzing aligns on the center of the graphic. Meaning that if you need to horizontally align graphics with different widths you need to calculate the position of the center of the graphic and make sure that is the distance that Fritzing is expecting. The usual case where pads are all identical width is easy, just make the start of each graphic the offset distance you desire, except that in Fritzing there will be a 1/2 width offset to where the part starts compared to what Inkscape displays, but that usually won’t matter as long as the drawing is internally consistent. You just need to remember that the coordinate systems are based differently.

Not a good one :slight_smile: . I usually just go with whatever the drawing I started from uses as doing rotations (at least in Inkscape) usually causes transform/ translates. Common sense (but no actual measured data yet) tells me transform/ translates are undesirable, as at render time they incur a matrix multiplication which is a performance issue. I think it is worthwhile to remove the translates at part creation time (where it happens once) rather than at render time where it happens at every render (which Fritzing does a lot!).

It is pretty easy once someone explains it ( @steelgoose in this case) but it differs between editors. Luckily we both use Inkscape so there the equation is:

hole size = hole diameter (or radius *2) - (2 * stroke-width)

So for one of the 0.035 in holes in the pad with dimensions in inches, click on the circle in a pad and the length/width in the tool bar will be 0.055, from XML editor stroke-width is 10 thus

0.035 = 0.055 - (2 * 0.01)

It looks like you need to add the stroke width to the 2 * radius value from xml editor to come out right i.e (22.5 * 2) + 10 to get
to the correct 55 . That said, there is a twist because I think that Inkscape uses the python math library and the “almost equal” floating point compares which return equal from a percentage
range of values to avoid roundoff problems, so if you set the sizes with dimensions in inches and make all the circles the same size and spaced .1 in, then switch to px (which is finer resolution) you will discover the values vary by a bit. This translates in to a slight (and mostly insignifigant) variation in the gerber output coords. To get the coords exact as in these footprints I change the tool bar to px (the highest resolution Inkscape has) and make sure the intervals in px are all the same. The easier way to do this would be in a script, such as the part check python script, that adjusts the connectors (if requested) to be evenly spaced, but I haven’t done that yet.

My footprint actually violates the standard too :slight_smile: , it is the only way to get the pads to work, so yes if the 10mil stroke width works (and most importantly creates enough copper to allow the solder joint to support the connector on the board) then it should be just fine. To a large extent we are pushing Fritzing past where its original intent was, and sometimes the standard gets in the way. I would adjust the hole in the path that defines the oblong pad to move the hole that uncovers the hole in the circle closer to the edge of path so the hole moves toward the edge of the oblong (and the opposite direction on the facing pad) so you have the same pad area but with the holes better aligned. If this doesn’t make sense I can modify an svg to do what I mean and post it (a picture is worth 1000 words :slight_smile: ). I’m too lazy to generate a png file from this but here is the xml to replace the d field in a path to do what I mean:

m 150.5,317 c 15.18783,0 27.5,11.6406 27.5,26 v 52 c 0,14.3594 -12.31217,26 -27.5,26 v 0 c -15.18783,0 -27.5,-11.6406 -27.5,-26 v -53 c 0.56862,-13.96744 12.71582,-25.01034 27.5,-25 z m -18.7161,39.12924 c 0,8.83656 9.32726,16.85804 18.7161,16.85804 9.38884,0 17.85805,-13.16979 17.85805,-22.00635 0,-8.83656 -6.75311,-16.85804 -16.14195,-16.85804 -9.38884,0 -20.4322,13.16979 -20.4322,22.00635 z

If you replace the d value of a bottom pad on one of the footprints with this it should offset the pad down a bit in the way I intend which should make your header part work as you need (you would need to go the opposite way for the pins on top).

Yes I know. That is what the "I think these are good enough for now. " comment is about. The correct answer (again for performance reasons) is to eliminate the circle overlaying the path and adjust the path so the circle is a circle of the correct radius to generate the correct hole in the gerbers. That way we save the time to render a redundant circle and performance gets better (and the part file size gets slightly smaller, both good things). The difficulty is in the details though. I know that the gerber code can create holes from just a path (because I’ve seen parts that do it) but I don’t know enough about path creation to be able to do that yet and it looked like learning it was going to take too much time at the moment. If you have more questions feel free to ask. Doing this here helps anyone making new parts and more people making parts is good (more people interested in helping develop would be even better!).

Edit:

Well, it looks like I’m wrong. When fighting with python to improve the parts check script got too frustrating, I went back to trying to fix the path. With the path editor in Inkscape (and a lot of trial and error!) I can get a path with a pretty identical hole (probably not perfect, but close). So I tried that on one pin using just the path with a hole and the stroke-width set to 10. The gerber however doesn’t generate the hole for that pin (so it looks like it won’t in fact take a path and generate a hole from it like I though). When I went back in my notes and pulled up the part that I thought did this, it turns out there is a circle (just like this one) under the path, it just isn’t labelled as the connector. The path is what has the connector0pad label (which is what fooled me in to thinking the path was generating the hole) but it appears the circle is what is really generating the hole. I’ll probably modify the part check script to issue a warning that the label is in the wrong place (rather than the current “no hole will be generated” error), assuming I can find a way to make sure there is a circle in the correct place. As usual I learned a bunch though, even though it wasn’t what I wanted. Back to fighting with python I guess :slight_smile: .

Peter

1 Like

Umm? Isn’t that supposed to be just diameter - stroke-width ? The stroke is rendered centered over the edge, so half the width is inside, half outside. Since the inside exists on both sides of the circle, that becomes 1 times stroke-width. Did I miss something?

You want an Arduino Uno “board” part with oval pins in the pcb view? Where are you intending to use that? Normally shields are mounted on the board, but the board is seldom (to my knowledge) actually soldered onto a pcb. The oval pins are only useful if the pcb includes a circuit that has an Uno board soldered to it.

Also what help do you need? The posted image looks like it already has oval pins.

Which gets back to what scenario you have in mind that you want to solder to pins on a pcb with an Arduino Uno board footprint? The oval pins do really have more copper. They are also narrower, to make room for standard size traces between the pins.

Find a FZ part with oval pads.
Export that svg out of FZ.
Open it in Inkscape and copy that oval pad.
Paste it into a exported UNO svg and place them under the pads.
Substitute that svg into a UNO part.
Assign the pins.
Save as new part.

There are details here

So what you want is pieces to help create an Arduino Shield pcb. That will use male headers (or stackable female headers) to connect to an Arduino board below. You may also want a Fritzing part for the Arduino board that will accept the shield (once it is also turned into a part).

The Arduino board (part) itself does not need the oval pins. Neither does the shield when created as a part. The oval pins are needed when designing the pcb for the shield. That is doable. Though I will warn that there is not much room between the header pins and the physical edge of a standard sized Arduino shield to place traces.

As Old_Grey said, you could get an oval pad from one of the existing parts, once you find one with good sized ovals. I think the easiest way to do this, is to create new header parts that have the oval pads, then use those on the pcb. Or even create a part containing a single pad, and use lots of them. Note that an oval pad is really 2 pieces. One is a smaller circle that defines the drill hole size, with a small circular pad. The other is the oblong piece that overlaps the small circular pad, but has a cutout to not cover the hole. The connector id goes on the circle element.

You need to decide just how ‘oval’ you want the pads. Here is an (svg) example that is set to have a 40mil diameter hole, 5mil thick narrow edges, and a total (long) length of 90mil, with the hole directly in the center (it is possible to have the hole closer to one end). Those numbers can be adjusted (fairly) easily mathematically, by editing the sample oval pad svg with a text editor and changing a few numbers. This sample is designed so that 1 pixels is 1 mil. I needed to add a border around the single pad, to get the image big enough for the forum to upload, AND adjust the generate link so that it did not get displayed as a single pixel. I scaled the view here to 5 times actual. That won’t matter when downloading the image.

oval
The 2 pieces do not need to be together in the svg file. I use separate blocks for the circle and path (oval) elements. There is a common offset between them, so a single wrapper translate on each set (circles and paths) can keep the coordinates nice simple multiples of 0.1 inch. Or 100 px in my example

Note that when creating Fritzing parts, the concept of male and female headers is different than male and female connectors (pins). The way the Fritzing code works, Anything that accepts a connection is on the bottom, and is a female connector. Like the holes in a breadboard. The part that connects needs to have a male connector. That is true even if physically the receiving (bottom) part uses a male header, like the Arduino Uno ICSP headers. To be able to plug something onto them (by dragging a part over top), the connectors of the dragged part must be defined as male. Attaching a wire directly to a connector works either way.

you could start with the svg generator https://werner.rothschopf.net/fritzing/part.html : 36 pins, row distance 20000, pin distance 100 mil. You have to shift the pins GPIO8 to SCL and delete some pins on the other side, but at least it’s a start.

Apparently but I don’t know what :slight_smile: . @steelgoose gave me the formula a few years ago and it works. Using a 20 thou stroke width (at standard scale) a 0.038 hole for a header pin has a pad diameter of 0.078in which in turn is 0.078 - 40 (2 * 20 stroke-width) and creates a 0.038 hole in the gerber output. I actually don’t know why the stroke-width needs to be doubled, but it does. This varies by editor as well, Coral Draw (which @steelgoose uses) calculates the hole size differently and I don’t know how illustrator does it.

Peter

AH! The problem is (I think) mixing of the hole, pad, and svg element circle dimensions.

The pad is 78 mil diameter
The hole is 38 mil diameter
The stroke is 20 mil

But the svg circle element diameter is 58 mil (radius = 29 mil), with half of that 20 mill stroke outside, half inside the circle. Which makes the radius of the hole 29 - 10, and the radius of the pad 29 + 10. 19 * 2 = 38, 39 * 2 = 78, giving the 38 mil hole and 78 mil pad diameters.

The rest is the different ways the editors use information to generate the svg. They might treat the requested circle radius/diamater as (any of) the hole, pad, or svg element radius/diameter, and adjust to match the stroke size.

They are easy enough to do. You basically need an oblong path which contains a standard circular pad (with the connectorxpin label) in it so that the gerber code will find the circle to make the hole. I have not found a way to do that in a path. A circle specified as a path works, but an oblong path with a circle in it has not for me (the gerber code doesn’t find the path.) It is best to remove any translates in the pad because that sometimes breaks things. There are a number of example parts available both in core parts and in the forums.

Peter

I can do the circular hole cut in a path, but that does not help. The Fritzing code does not see it as a hole that needs to be included in the gerber export. It needs to be 2 separate svg elements. An actual circle element to get Fritzing to generate the hole for Gerber, and a path to get the desired pad shape.

I have a python script that will generate a row of them based on parameters. Work in progress. It currently generates valid svg, but only for pads centred over the hole. I want to be able to also offset the pad, so the hole is closer to one end, and generate a second row of pins with the offset the opposite direction. This does use transforms for simplification, but that is x,y translate only.

FZ only accepts circle, so you put that oblong pad under a normal circle pad. I think it’s in my last vid.

@Old_Grey That is what my python program does. Generates an array of circle and path elements.

The current version of my script will be able to generate contiguous sections of the oval connectors, but they will need to be manually merged. Looks like it would need 10 segments.

A future version (may be) able to generate the whole layout at once, but then the parameters to define what is needed are going to be complex. Another possible future version would generate sections (say the dip28), but instead of creating a new file, added the connectors to the file created by previous runs that built and added other sections. That should just need x,y offsets and a reference, to tell it where to insert the new connectors relative to the existing. As a bonus, building the layout up in segments, means each segment could potentially use different size and shape for the pads.

At some point (likely not soon :slight_smile: ) I intend on modifying the parts factory to do this when generating generic ICs and headers (and fix double row headers which are currently broken in breadboard.) I had started this a couple of years ago, and recently went back to it when I discovered there is code to deal with older Fritzing versions which makes this whole process much more complex. I think the way forward here is python as @microMerlin has done to prototype what we want to do more easily than changing the C++ source, and once we have a desirable set of tools modify the parts factory C++ code to implement it. I have a few parts, one example here:

with oblong pins for headers. I think there should be single row version as well although I couldn’t immediately find them. At present to get different sizes you need to edit the underlying svgs though there isn’t yet an automated tool in python.

Peter

Peter

I need a generic ic that has 40 pins, a pitch of 2.54mm and a pin row distance of 700 thousand, I have used the tool SVG Generator 0.2 but it has generated the svg, as I could now turn it into a fzpz?

There are several ways (I’m assuming you have done only pcb or both pcb and breadboard?) You can load a generic 40 pin IC in to the parts editor then select pcb view then File->Load Image for view and feed it your new svg. Then File->save as new part and the fzpz will appear in the mine parts bin. How I would do this is to edit the fzp file directly to add the new svg, the details of this can be found in this tutorial series:

this requires that you understand the underlying file formats for the svgs and the fzp file, if you don’t the parts editor may be easier (but much more limited!)

Peter

this SVG Generator does exactly what it’s named for: it generates a SVG.
Otherwise it would be named “fzpz” generator. :wink:

As Peter told already, start with a generic 40pin IC and change the SVG.