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.
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.
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.
> 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.
> 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.
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.
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.
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.
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
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.
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.
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 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.
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 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.
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)
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.
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.
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.