is there an easy way to get a (generic) IC with “oblong” / rectangular - non round - through the hole pads to enable routing of small wires between the pads?
Currently I need ICs 300mil with 28pins (atmega328p), 18pins (mcp2515), 8pins (mcp2551) but a more generic IC part with more pin possibilities and even in 600mils are appreciated.
I spent a day making a 30pin ESP30 already, but I hope that someone has already available ICs or can point out where I can find them with rectangular holes!
Depends on your definition of easy. There are parts around (some of the Sparkfun ones as I recall) that have rectangular pads. It is likely easiest to pull up parts in inspector and look at the pcb thumbnail til you find an appropriate pad layout (for instance max7219 in Sparkfun digital which is 300 mil 24 pin with oblong pads. From there you would need an svg editor such as Inkscape to modify the pads to the configuration that you desire (with pin designations that match the part you want to use the footprint in). Simple enough if you already understand parts creation, but there is a steep learning curve to parts creation. If you can’t make it work, post your footprint here and I’ll have a poke at it (probably best with both the part you want the footprint to fit and the footprint).
Edit: Note that you need to check that the hole size generated by the gerber is both created and the correct size. The Sparkfun parts are likely OK, but others from the net may not be correct. Some of these parts have issues …
Peter
thanks Peter. I tried my best and did the 3 parts. In the gerber viewer the parts are looking ok so far. I will let produce a test pcb and if the parts are ok I’ll publish them.
You want to look at the drill.txt file from the gerber output and check the drill sizes are correct. For ICs they are usually .035 in I think. If you want to post the parts I can have a look for common problems as well.
Peter
hello Peter
as you noticed in the esp32 thread, the sparkfun holes are not correct.
is there a chance to support me in generating the pcb files (28pins, 18pins, 8pins) with the correct diameter?
Sure, they are easy to do, I’m guessing you want 300 mil spacing for the 8 pin probably 400mil for 18 (which are usually wider than 300 mil and 300mil and 600 mil for the 28 (giving narrow and wide). One complication is pin numbering. Various parts use various pin/pad and starting numbers but changing them is a simple matter of editing the svg and changing the designation to match the part.
Peter
Please give me some minutes, I will google the datasheets.
edit:
MCP2515
18-Lead PDIP (300mil)
Page 75
mcp2551
8-Lead PDIP (300 mil)
Page 15
atmega328
28P3
E = 7,62mm --> 300 mil
Page 439
Add on:
Isn’t there a possibility to adopt the “generic” IC including all possibilities (pins and width) but with the nicer pads?
Yes, but that requires a code change and currently development is broken. I’m working on fixing that, but its unclear if we can do a release as Qt (the underlying framework) currently has a problem on 32 bit Windows. For now pads that can be imported are going to be the fastest solution. I was mistaking the 18 pin for some of the old 22 pin ICs that are 400 mils. I’ll make a set of svgs for the common sizes and post them in a bit.
Peter
Peter, I’m preparing a small php script. I could provide generated SVG files for lit. “any” pinnumber and pinwidth. Case-Drawing and viewBox need manual correction in inkscape, but at least the pads should be fine.
(it seems I can’t upload svgs?)
You can, but there are sometimes problems. The forum renders the svg (rather than shows it as a file) and sometimes does it wrong. We (as I will with my collection of footprints) usually upload svgs as .fzpz and then tell people it is really an svg so rename it. I’m just doing a 24 and 40 pin 600 mil footprint and will upload a really zipped .fzp file with 4, 6, 8 , 14, 16, 20, 24 and 28 300 mil and 24, 28 and 40 600 mil footprints.
Peter
if you wanna play around:
http://werner.rothschopf.net/fritzing/part.html
as mentioned, case (silkscreen) and viewbox is not fine so far…
I started from a different footprint that I had modified (incorrectly it turns out 
) 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:
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 
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/
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).
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 
. 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 . 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 , 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 ). 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 .
Peter
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.
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.
