The Pinouts Book: Pinout functions for 130 commonly used components
pinouts.org
pinouts.org
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.
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.
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.
> The pinout for the Arduino Due is wrong.
Lol. Once a famous man said > 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.And he is not wrong
>
> 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
https://lwn.net/2001/0118/a/lt-documentation.php31) 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
What would you propose as a better generic term?
[1] https://docs.google.com/spreadsheets/d/e/2PACX-1vQu1REgWnmUO...
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.
A fully, truly open library of building blocks under actual open source licenses however? That would be a dream.
Add the Teensy, please.
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.
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.
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.