The pinout for the Arduino Due is wrong. The pdf indicates the pin nearest to the reset button (top right on the board, page 124 digital / 122 printed) is D21/SCL.<p>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.<p>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.<p>Contrast: <a href="https://forum.arduino.cc/t/due-pinout-diagram/129258" rel="nofollow noreferrer">https://forum.arduino.cc/t/due-pinout-diagram/129258</a><p>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).<p>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.
Recommendations to the author:<p>1) As others have said, a version with black on white illustrations would be massively useful for printouts.<p>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.<p>3) Why distribute it as a zip file, 3.8 MB vs 3.5 MB doesn't seem worth the hassle.<p>4) A miniature lineart on the pinout chart pages would be nice too.<p>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<p>6) You have firewire 6 pin, but not 8 pin or 4 pin<p>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<p>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<p><a href="https://gitlab.com/tpmoney/pinouts.org-pdf-bookmarks" rel="nofollow noreferrer">https://gitlab.com/tpmoney/pinouts.org-pdf-bookmarks</a>
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.<p><a href="https://en.wikipedia.org/wiki/Electronic_component" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Electronic_component</a>
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.
Obligatory shameless plug of <a href="https://pinout.xyz" rel="nofollow noreferrer">https://pinout.xyz</a> where I’ve been maintaining an interactive Raspberry Pi SBC pinout for some years, and the newer <a href="https://pico.pinout.xyz" rel="nofollow noreferrer">https://pico.pinout.xyz</a> 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”<p>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.
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.
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.<p>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.
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!<p>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.