“Pin 7 is the enable” is not a fact about a component. It is a fact about a component in a package, and a datasheet that covers four packages contains four different answers, sometimes printed in one table with four columns.
The package is part of the key
A pinout table has to be keyed on the pair of package and pin designator. Where a datasheet covers several packages it presents them one of three ways, and each has a different failure.
- Separate tables per package, each preceded by a heading naming the package. The risk is that the heading is not captured with the table, so two tables merge into one and pin 1 appears twice with different functions.
- One table with a pin-number column per package. The most compact and the most dangerous, because the column headers are package names and a naive row-to-object mapping produces a record with several conflicting pin numbers and no idea which is which. That is a multi-entity schema problem, not a table problem.
- One table plus a note saying that a package variant differs in some enumerated respect. Prose that modifies a table is the case a table extractor structurally cannot see.
The package name itself is not always reliable as a key. Names encode a body type and usually a pin count — an eight-pin small outline package, a sixteen-pin quad flat no-lead — but the same name is used for different body sizes by different manufacturers, and the authoritative identity is the package outline drawing at the back of the datasheet together with the manufacturer’s own package code. Store the printed package string verbatim and resolve it later rather than normalising during extraction.
How pins are numbered
For dual in-line and gull-wing packages the convention is a counterclockwise sequence viewed from above, starting at the pin marked by the package’s pin-1 indicator — a dot, a notch, or a bevelled corner. The pinout diagram states its own viewing direction, and it matters: a diagram labelled as a bottom view is mirrored relative to a top view, so a model reading the picture rather than the table must also read the view label or it will hand back a mirrored pinout.
Grid array packages use an alphanumeric designator instead — a row letter and a column number, so A1, A2, B1. The row letters are not a contiguous alphabet: characters that can be confused with digits are skipped, exactly as they are in drawing revision sequences, and after the single letters are exhausted the scheme continues with doubled letters. The precise set of omitted letters is specified in the package outline registration rather than being universal, so do not hard-code an alphabet. Instead, take the row letters from the document itself and assert that they form a consistent, non-repeating sequence, and assert that the number of designators equals the ball count stated for the package.
The consequence for validation is the useful part: a pinout for ann-pin package should contain exactly n distinct designators with none missing and none repeated. That is a complete structural check, and it catches the two most common extraction failures — a dropped row and a duplicated row — without any reference data at all.
The pin that is not in the pin count
No-lead packages have a large exposed metal pad on the underside for heat conduction, and it is frequently a connection as well as a thermal path — usually to ground, occasionally to a supply, occasionally required to be left floating. It is named inconsistently: a thermal pad, an exposed pad, EP, PAD, pin 0, or a pin number one higher than the package’s nominal count, so a sixteen-pin part lists a pin 17.
That breaks the count assertion above, which is a good reason to make the assertion aware of it rather than to abandon it. Expect between zero and one non-numeric or out-of-range designator, classify it as a pad, and check the remaining designators against the package count.
The pad is also frequently documented outside the pinout table altogether — in the package drawing, in an applications section about thermal design, or in a single sentence under the table. An extraction that returns the table faithfully and omits the pad has omitted the connection that most often causes a board to fail thermal testing.
Pin names are compound, NC is ambiguous
Pin names on anything programmable are multiplexed: one physical pin carries several alternate functions, printed as a slash-separated list such as a port bit, an analogue input and a timer channel. That is one pin with a list of functions, not a name string, and searching a flattened string for a function works until a function name is a substring of another.
Active-low signalling is marked with an overbar in the printed name and the overbar is drawn geometry, not a character. It disappears in text extraction, so a reset that is asserted low and a reset that is asserted high extract to the same string. Where the datasheet also uses a textual convention — a leading letter, a trailing hash, a leading slash — prefer the textual form and record that polarity was inferred when only the overbar was available.
Then there are the three abbreviations that look interchangeable and are not. NC conventionally means no internal connection, and such a pin can usually be tied to a plane or left open. DNC means do not connect, and such a pin is internally connected to something — test circuitry, a die pad — so connecting it can damage the part or change its behaviour. RESERVED generally means the manufacturer specifies a required treatment, often tie to ground. Collapsing them into “unused” discards a real instruction, and it is exactly the kind of semantic flattening a model will do cheerfully if the schema offers it a boolean.
Table failures specific to pinouts
- Multiple pins with the same name. Ground and supply pins repeat, deliberately. A schema keyed on pin name silently drops all but one, and the dropped ones are the ones that carry current.
- Merged cells spanning rows. A type column reading “Power” once for four consecutive pins is a vertical merge. Extracted per row it leaves three empty type fields; the fill direction is downward and it has to be applied explicitly.
- Ranges in the pin number column.
3-6in a pin number cell means four pins. Expanding it is correct; storing the literal string is a row that never matches a lookup. - The diagram and the table disagree. Both are in the document and they are maintained separately. When they conflict, the table is conventionally authoritative, but the conflict itself is the most valuable output — it means one of them is wrong in the source, not in your parse.
- Errata elsewhere. A pinout correction may live in a separate errata document that the datasheet does not reference. No extraction of a single file can see this, and a pipeline that presents its output as authoritative rather than as “what this revision of this document says” is overclaiming. Record the document revision alongside every extracted pin, in the per-field audit trail.
Top comments (0)