The Pinouts Book: Pinout functions for 130 commonly used components(pinouts.org)
pinouts.org
The Pinouts Book: Pinout functions for 130 commonly used components
https://pinouts.org/
44 comments
Welcome to why those of us who build PCBs NEVER use a parts library other than our own.
Nobody will ever take the care to maintain a parts library unless there is money involved.
The KiCAD libraries are about as good as it gets as long as you stick with common parts.
Nobody will ever take the care to maintain a parts library unless there is money involved.
The KiCAD libraries are about as good as it gets as long as you stick with common parts.
I never understood this mentality myself. I use parts libraries all the time.
Whether or not I drew the symbol, I still have to double check it as it's not like every symbol I every drew comes out perfectly the first time. So if I need to check it, why not save myself the step of drawing the rough draft of it?
For example I've never had an issue with a snapeda schematic symbol. Even free tier. Although sometimes I rearrange them for esthetic reasons. I've definitely had to adjust their footprints for DFM reasons. But IMHO it's much faster to tweak someone else's work than start from scratch.
Whether or not I drew the symbol, I still have to double check it as it's not like every symbol I every drew comes out perfectly the first time. So if I need to check it, why not save myself the step of drawing the rough draft of it?
For example I've never had an issue with a snapeda schematic symbol. Even free tier. Although sometimes I rearrange them for esthetic reasons. I've definitely had to adjust their footprints for DFM reasons. But IMHO it's much faster to tweak someone else's work than start from scratch.
There's also a nasty gotcha in the Pi Pico pinout. Pins 1-20 are listed from top to bottom, in the same order they appear in the board image. Pins 21-40 are listed in a second column, also from top to bottom; unfortunately, this is the reverse of their physical position in the board image.
> The pinout for the Arduino Due is wrong.
> Once you realize that documentation should be laughed at, peed upon, put on fire, and just ridiculed in general, THEN, and only then, have you reached the level where you can safely read it and try to use it to actually implement a driver.Sounds like a Linus Torvalds qoute.
And he is not wrong
And he is not wrong
Indeed it is:
>
> It works perfectly and exactly as it is defined to work by the rules.
> Getting the rules correct == 'the concept of "working"'.
Don't be silly.
You're entirely ignoring the concept of hardware bugs. Which is one very likely reason for this whole discussion in the first place.
ANYBODY who does driver development without taking the real world into account is a dangerous person. Stacks of papers, diagrams and rules are absolutely WORTHLESS if you can't just understand the fact that documentation is nothing more than a guide-line.
Once you realize that documentation should be laughed at, peed upon, put on fire, and just ridiculed in general, THEN, and only then, have you reached the level where you can safely read it and try to use it to actually implement a driver.
I'm continually amazed and absolutely scared silly by your blind trust in paperwork, whether it be standards or committees or vendor documentation.
>
> It works perfectly and exactly as it is defined to work by the rules.
> Getting the rules correct == 'the concept of "working"'.
Don't be silly.
You're entirely ignoring the concept of hardware bugs. Which is one very likely reason for this whole discussion in the first place.
ANYBODY who does driver development without taking the real world into account is a dangerous person. Stacks of papers, diagrams and rules are absolutely WORTHLESS if you can't just understand the fact that documentation is nothing more than a guide-line.
Once you realize that documentation should be laughed at, peed upon, put on fire, and just ridiculed in general, THEN, and only then, have you reached the level where you can safely read it and try to use it to actually implement a driver.
I'm continually amazed and absolutely scared silly by your blind trust in paperwork, whether it be standards or committees or vendor documentation.
Linus
Ha! I remember a somewhat similar issue with the Arduino Nano where one pin was erroneously marked as PWM and one not. A customer had designed electric motor drivers controlled by a socketed Nano and I was tasked with writing software for it. They never looked at the actual ATmega pinouts but used the one available on various hobbyist sites all over the net. I ended up cutting traces and soldering jumper wires on the first batch of devices.
Recommendations to the author:
1) As others have said, a version with black on white illustrations would be massively useful for printouts.
2) Bookmarks/Table of Contents. While I was happy to see the headings in the ToC in the book itself were clickable, there's only one bookmark in the PDF and that's randomly for page 298.
3) Why distribute it as a zip file, 3.8 MB vs 3.5 MB doesn't seem worth the hassle.
4) A miniature lineart on the pinout chart pages would be nice too.
5) USB Type Micro B is listed 3.0 then 2.0, but the other USB ports are listed 2.0 then 3.0, likewise the Micro B appears before all the other types, but Mini B is after the USB B connectors
6) You have firewire 6 pin, but not 8 pin or 4 pin
7) The board on page 264 looks like it should be a Rock Pro 64, but it's labeled Rock 64 like the previous board
Because I don't like to just complain, I've created a bookmarks text file that can be applied to the PDF using JPdfBookmarks and includes some of the corrections I've noted above. There doesn't appear to be a feedback/suggestions link on the site, so here's a link to a repo instead
https://gitlab.com/tpmoney/pinouts.org-pdf-bookmarks
1) As others have said, a version with black on white illustrations would be massively useful for printouts.
2) Bookmarks/Table of Contents. While I was happy to see the headings in the ToC in the book itself were clickable, there's only one bookmark in the PDF and that's randomly for page 298.
3) Why distribute it as a zip file, 3.8 MB vs 3.5 MB doesn't seem worth the hassle.
4) A miniature lineart on the pinout chart pages would be nice too.
5) USB Type Micro B is listed 3.0 then 2.0, but the other USB ports are listed 2.0 then 3.0, likewise the Micro B appears before all the other types, but Mini B is after the USB B connectors
6) You have firewire 6 pin, but not 8 pin or 4 pin
7) The board on page 264 looks like it should be a Rock Pro 64, but it's labeled Rock 64 like the previous board
Because I don't like to just complain, I've created a bookmarks text file that can be applied to the PDF using JPdfBookmarks and includes some of the corrections I've noted above. There doesn't appear to be a feedback/suggestions link on the site, so here's a link to a repo instead
https://gitlab.com/tpmoney/pinouts.org-pdf-bookmarks
This is cool, but it mostly doesn't have what I would call components. When I think about components, I think about discrete parts, like resistors, diodes, IC's etc. most of what they have I would call connectors, cables, modules, or circuit cards. If you look at the wikipedia article on Electrical components you can see what I mean.
https://en.wikipedia.org/wiki/Electronic_component
https://en.wikipedia.org/wiki/Electronic_component
This is incredibly pedantic. Sure that's the definition in electronics, but everything described in the book a perfectly viable system "component" (https://en.wikipedia.org/wiki/System)
For language to have meaning, it must be used in context. And within the context of electronic design, these would be called subassemblies, not components.
I agree - I was expecting to see components like the NE555, CD4047, etc [1] featured
[1] https://docs.google.com/spreadsheets/d/e/2PACX-1vQu1REgWnmUO...
[1] https://docs.google.com/spreadsheets/d/e/2PACX-1vQu1REgWnmUO...
Agreed, the first thing I typed into the search was 741, the second, 555.
This book is so much less useful than it could be by being mostly black. I'd print this out and use it, if it wouldn't waste an entire black cartridge to print.
Maybe they (or you could while you wait) invert the colors.
Obligatory shameless plug of https://pinout.xyz where I’ve been maintaining an interactive Raspberry Pi SBC pinout for some years, and the newer https://pico.pinout.xyz where I’ve tried to do the same for the Raspberry Pi Pico board. The latter also became a command-line pinout via the Python package “picopins”
I feel- and of course I’m biased- that if anything is worth bringing to the table for device pinouts it’s interactivity and accessibility. The latter, in particular, is lost in static images. I really leaned into this with the Pico Pinout, including everything from visual accessibility accommodations (avoiding low contrast text background colours), to markup for screen readers to the ability to turn off labels and reduce noise. I’m still unsure if I actually achieved my goal, but it’s been fun.
I feel- and of course I’m biased- that if anything is worth bringing to the table for device pinouts it’s interactivity and accessibility. The latter, in particular, is lost in static images. I really leaned into this with the Pico Pinout, including everything from visual accessibility accommodations (avoiding low contrast text background colours), to markup for screen readers to the ability to turn off labels and reduce noise. I’m still unsure if I actually achieved my goal, but it’s been fun.
I love the pico version! Especially the rear view option is super useful! Now I wish to see the same for all the various ESP* dev boards out there.
What I'd love to see is something like a "common building block" library. Something like open-source designs for common problems: how to implement a battery management system, how to integrate USB-C/PD, that kind of stuff.
This already exists! Vendors often have demo boards of their parts, with complete schematics and design files, so it is pretty easy to find what you need.
Of course. The problem with these is that the license is most often best described at "it's unclear"... so if you're designing a piece of "open hardware", you can't just go and slap together stuff from implementer guides and datasheets. I mean, you can, stuff will usually work out on a technical level, but as it's not your work but someone else's you can get into trouble with copyright law.
A fully, truly open library of building blocks under actual open source licenses however? That would be a dream.
A fully, truly open library of building blocks under actual open source licenses however? That would be a dream.
A good example of form over function. It's very pretty and I enjoyed skimming through the pages. I would never use it as a reference though. I rarely have access to a large desktop display when I'm prototyping at a bench. More common to look up the pins on my phone and have it nearby. It's also cumbersome to unpack a zip file and get the resulting pdf into a mobile context. Also, the forced aspect ratio of that pdf and type size make it mobile hostile.
When I saw the title, I thought it might be cool to print it out for a maker lab for common use. Then I actually looked through it. Pretty sure this is a graphic design project and not something made by actual users.
When I saw the title, I thought it might be cool to print it out for a maker lab for common use. Then I actually looked through it. Pretty sure this is a graphic design project and not something made by actual users.
Nice (the design is superb), but googling is far faster than using this -- finding the doc, opening it, and searching for the device, and finding the page which isn't entirely in alpha order.
It would be handy to feed info like this (and datasheets) into an LLM, but unfortunately the risk of hallucinating AI is pretty high!
Good looking, visually striking document, but not particularly useful for everyday use. It could be reduced by half the number of pages if the description was on the same page as the diagram. The black pages make it unprintable (though I don't print much anymore)
Very cool and useful!
Suggestion: Create a mailing list that anyone can subscribe to. Then, whenever you add new content, you could send reminders to re-download. Additionally, you'll have a good platform to advertise when you decide to launch a Kickstarter for the printed version.
Suggestion: Create a mailing list that anyone can subscribe to. Then, whenever you add new content, you could send reminders to re-download. Additionally, you'll have a good platform to advertise when you decide to launch a Kickstarter for the printed version.
not trying to be negative but: who is the audience that cares when random new components are added to an arbitrary collection?
I suppose it's me. When I'm working on something on the bench, I don't like having to Google the pinouts. A well-curated printed book would be ideal. But, yeah, I can see how that might be very niche.
I feel like an RSS feed would be more appropriate
Sites like Pinouts.ru is more useful than a static document.
[deleted]
Kinda annoyed that the download is a zip and not the PDF
Beautiful case of form over function. Why in the world would you do this as white on black? That's not even comfortable to read.
It's their style. https://n-o-d-e.net/
Dark mode?
That's understandable for a website, read late at night on a device-with-too-bright-screen.
But who wants white text on black pages while soldering electronics kit under bright ambient conditions? Makes no sense.
Looks like form over function? I'll pass.
That's understandable for a website, read late at night on a device-with-too-bright-screen.
But who wants white text on black pages while soldering electronics kit under bright ambient conditions? Makes no sense.
Looks like form over function? I'll pass.
The paragraph of footnotes under USB C is quite amusing.
Would absolutely pay $50 for a book.
It is not. That is pin D71, SCL1 (emphasis on the 1) - the Due has two indepdendent i2c busses. It makes a similar error regarding pin D70, just below it.
It also fails to note that D10 = D77 and D4 = D87, and that both of those pins (in addition to D2, D3, D4, D5, D11, D12) support PWM. Frankly the listing of the PWM column is confusing, in general, for the Due, with what is labelled and what isn't.
Contrast: https://forum.arduino.cc/t/due-pinout-diagram/129258
Admittedly, these are carrying forward errors in the official documentation, but these errors have been known for a very long time (they were updated in the unofficial pinout I link in 2013).
Unfortunately, offering only a monochrome (yet unprintable) view, leaving pins (connectors in the center of the board) unlabeled, and carrying errors forward means I don't see a particular use for this document.