Evaluate (and criticize) New Part SN74HC32N

Hello Kjell @kjellm and Peter @vanepp,

Could I please trouble you to review the attached Fritzing part, a quad OR-Gate SN74HC32N? I’m new to Fritzing, and am using an older “free” version (0.9.3b) to evaluate.

SN74HC32N Quad OR Gate.fzpz (6.1 KB)

A bit of background: I’m mentoring a high school robotics team, and the team chose to use the Raspberry Pi Pico W (WiFi) for their project. I needed a schematic/breadboard tool for the Pico, and the Raspberry Pi Foundation released a Fritzing part for it.

Our circuit(s) are relatively simple, but I needed two additional parts (a 24-pin DIP and a 14-pin DIP) not in the inventory. I used the parts editor to create the first, then took a look at the underlying .fzp and .svg files and found some strange constructs.

DIPS “usually” have only one pin 1 marker - either notch, indent, paint stripe, paint dot, etc - depending on manufacturer preferences. It appears that only a few devices show both notch and indent at the same time, and this ended up the Fritzing default. When I took a look at the actual .svg code that displayed the DIP, I found a bunch of useless-to-Fritzing tags, ID’s, and other stuff. In the case of DIP’s, there’s also very clumsy and inefficient graphics showing the chip coloration and the pin 1 notch.

Using the built-in parts editor and/or inkscape/illustrator without any subsequent text editing of the .svg’s results in duplicating all this unnecessary bloat.

I elected to hand-edit the .svg’s to clean them up.

Cleaner (smaller file size) .svg’s I think would be helpful, both from a maintenance as well as a performance standpoint. If Fritzing could deal with embedded CSS blocks within the .svg’s, that would go a long way to reducing .svg file size. Static graphics (e.g. text) would benefit from this. Pin, terminal and other connection points probably need to remain individually defined for Fritzing to be able to locate, highlight/unhighlight, etc.

The first thing I found was the breadboard units were all screwed up - still in points, not inches or millimeters. “Points” is the typesetter size unit, 72 points per inch - this is probably the standard for Illustrator, as that is their target audience. For recalculating all the DIP graphics I used AutoCAD; I subsequently used this for the schematic re-write as well. The PCB footprint was sound enough to just clean up by hand-editing the .svg.

Since inches and mils (“milliinches”) are the traditional standard in America for component size and layout, I elected to use units of inches and mils for the DIPs. I later found this was recommended in the online parts creation documentation, and strongly echo this recommendation.

The actual chips I’m using only have a notch,

so I commented out the circular depression pin 1 marker. I also cleaned up the notch and encapsulation graphics to reduce file size and modestly improve performance. I added a commented-out ink stripe and ink dot graphic, in case this .svg ends up being used as a template for other devices. I also ordered in the .svg the pin numbers in conventional order - pin0 to pin13 in this case. This actually makes hand-editing the breadboard .svg very simple as all of the repeated graphics are just 100 mils different than the previous - just one digit to change for each set of entries.

For the icon .svg, I elected to truncate the DIP illustration and only show six pins with a large 4-char text of the the meaningful portion of the device number. Simply duplicating the breadboard .svg (with all its faults) for the icon substantially reduces the usability - one 14-pin DIP with a blurry number looks like every other 14-pin DIP with a blurry number.

I added the notch graphic to the PCB silkscreen, and very slightly increased the pad outside diameter. For Fritzing, I doubt the users would attempt to sneak a trace between two adjacent pads, that’s a more advanced technique and requires knowledge of the current, copper weight, and trace width.

For the schematic, I elected to show the logic symbols as an aid to the students. The schematic width and height from the Fritzing part I used as a template was suitable for this. I again used AutoCAD to lay out the logic symbols, and reserved space for the “not” circle and the “exclusive” symbol, neither of which is shown on this standard “OR” chip, but results in the schematic routing within the chip outline to show jogs. It will be a trivial exercise to convert this schematic to “XOR” or “XNOR” version.

On a different forum there was a complaint that the logic symbols didn’t reflect the IEEE/IEC defined symbols. In drawing up the proper symbols as a test I found:

  1. If placed within the chip outline they’re much too large for the information they convey on the schematic, and
  2. Even the manufacturers deviate from the standard.

Sizing them down to a reasonable size slightly distorts them from the IEEE/IEC definition without affecting their symbology and conserves space on the schematic, so I chose this technique.

[ Side note: If you review the Texas Instruments datasheet for this SN74HC32N device, you can clearly see that their logic symbols deviate from the IEEE/IEC definition, as well as contain some “scrambled” graphics if you zoom in closely. ]

The older version of Fritzing I’m using doesn’t have a simulation feature, so I have not included any <spice> directives. It does look like the “copy an existing part to create a new part” paradigm might need to omit the <spice> directives. For example, it looks like the Huzzah_ESP8266 part has the <spice> directive from the Analog Devices AD8210 part. And by the way, double check the AD8210 <spice> directive - I think one of the pins is N/C so the AD8210.cir file only has seven parameters on the .subckt card.

I would think better / more enhanced part creation documentation, especially with respect to “Properties” and how they link the .fzp to the .svg’s would be beneficial. For example, I don’t think the official documentation lists some of the requirements (e.g. schematic terminal graphic) that Peter has posted separately in the forum.

Lastly, I think it would be helpful to describe (maybe with a short tutorial and an example part) a Quality Control process to confirm any newly-created part has the desired and required features. Running Python scripts can identify all the technical issues (e.g. missing pin, terminal or other ID’s) but doesn’t help locate things like swapped graphic colors (e.g. “sparkfun speaker”) or swapped terminal text (e.g. “sparkfun voltage regulator LM317”). To this end I constructed a nonsensical circuit, connecting two NPN BJT’s to each side of this DIP, and an LED across the remaining two pins. This lets me confirm that the pin/terminal ID’s are in the correct location (otherwise the BJT or LED wires cross) as well as confirm all pins and terminals are accounted for, and the PCB matches the schematic which matches the breadboard.

SN74HC32N Quad OR Gate Part Verification.fzz (12.4 KB)

TIA for your review and feedback,

- Erik -

Logic chips are already in Fritzing core parts. Did you use these as starting point?

There is the 4071with logical arrangement in the schematic, and also with a physical arrangement:



Fritzing supports the TinySVG standard, which does not include CSS ( the CSS standard is way to complex )
Old Versions of Fritzing don´t deal well with inherited attributes, but newer versions do.
So you would typically set the font for the whole group, as an svg attribute, not with a CSS style.
Fritzing also support references within the document, so you could in theory use a ref instead of copying an element. This makes mostly sense if you use Logos or other complex graphics multiple times.
The viewbox needs physical dimensions, our QC pipeline (work in progress) will reject parts that don´t have them.
This is in conflict with some graphics tools, which notoriously remove them. Good practice would be to use mils or mm.
All the other elements (including the fonts) should be unit-less. This way, the viewbox will be the unambigious definition for mapping numbers to sizes.

The part looks very good, only thing that doesn´t pass: There should be a group with the id “breadboard” , “schematic” and “icon” , similar to “copper0, copper1 and silkscreen, silkscreen1” in the pcb view.

By using inherited attributes, I could reduce the size of the schematic SVG to about 50% (using the python tool “scour”)

  <text x="205" y="85"   text-anchor="start" font-size="50" font-family="Droid Sans" fill="#8C8C8C" stroke-width="0" stroke="#787878" >1A</text>
   <text x="205" y="185"  text-anchor="start" font-size="50" font-family="Droid Sans" fill="#8C8C8C" stroke-width="0" stroke="#787878" >1B</text>
   <text x="205" y="285"  text-anchor="start" font-size="50" font-family="Droid Sans" fill="#8C8C8C" stroke-width="0" stroke="#787878" >1Y</text>
   <text x="205" y="385"  text-anchor="start" font-size="50" font-family="Droid Sans" fill="#8C8C8C" stroke-width="0" stroke="#787878" >2A</text>
   <text x="205" y="485"  text-anchor="start" font-size="50" font-family="Droid Sans" fill="#8C8C8C" stroke-width="0" stroke="#787878" >2B</text>
   <text x="205" y="585"  text-anchor="start" font-size="50" font-family="Droid Sans" fill="#8C8C8C" stroke-width="0" stroke="#787878" >2Y</text>
   <text x="205" y="685"  text-anchor="start" font-size="50" font-family="Droid Sans" fill="#8C8C8C" stroke-width="0" stroke="#787878" >GND</text>


<g fill="#8C8C8C" font-family="Droid Sans" stroke="#787878" stroke-width="0">
     <g font-size="40" text-anchor="middle">
     <g font-size="50">
				<!-- ================= -->
				<!-- Left Pin Signals: -->
				<!-- ================= -->
				<text x="205" y="85">1A</text>
				<text x="205" y="185">1B</text>
				<text x="205" y="285">1Y</text>
				<text x="205" y="385">2A</text>
				<text x="205" y="485">2B</text>
				<text x="205" y="585">2Y</text>
				<text x="205" y="685">GND</text>

First always be lazy. A google search of the form “fritzing part 7432” leads to a pre existing (but not in core parts!) post in the forums here that has the 7432 as a multipart part (multipart means that the individual logic gate can be moved independently which is useful in logic.)

That said the only errors FritzingCheckPart.py (which checks parts for errors and can be found in this tutorial on parts making which you may have already seen as references to it are often posted here)

indicates are the ones that @KjellM has already noted the missing layerIds which will cause the part to not export as an image.

$ FritzingCheckPartw.py part.SN74HC32N_ewo_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.SN74HC32N_ewo_1.fzp

**** Starting to process file svg.breadboard.SN74HC32N_ewo_1_breadboard.svg.bak

**** Starting to process file svg.schematic.SN74HC32N_ewo_1_schematic.svg.bak

**** Starting to process file svg.pcb.SN74HC32N_ewo_1_pcb.svg.bak


This is a through hole part as both copper0 and copper1 views are present.
If you wanted a smd part remove the copper0 definition from line 44

Modified 3: File
At line 44

Silkscreen, converted stoke from white to black

Warning 4: File
At line 3

No referenceFile found in fzp file

Error 69: File
At line 26

Found a drawing element before a layerId (or no layerId)

Error 69: File
At line 36

Found a drawing element before a layerId (or no layerId)

It didn’t need to remove pxs from the svgs (which are added for CSS compliance but cause Fritzing to either set the font size large or to 0).


In addition I forgot I made a couple of parts for the pico w, I think the RPI site only wanted the THT version so the forums are probably the only place to find the SMD version if that is what you want. The parts are here

Looking for Raspberry Pi PICO part - #49 by vanepp