Hi Guys -
Need your expert feedback on the Due board we are designing.
We wanted to build a smallest possible footprint Due-compatible board for embedding into our products (such as our Open Source EV Charging stations, EV chargers, etc - some info for the curious ones: http://www.emotorwerks.com/products/online-store/product/show/44-emw-juicebox-level-2-15kw-ev-charging-station-kit-or-assembled-unit).
We have sifted through all the posts I could find on various relevant topics to try to collect all gotchas (e.g., errors in Schematics, suboptimal I2C pullup resistor values). We have also looked for various types of user feedback to help us design a board that can not only be useful for us but also could be interesting for others making small production runs based on SAM3X8E. E.g. we have added a 64Kbit EEPROM on board, broken out AREF pin, etc.
At this moment, we were able to get a 4-layer layout containing LQFP-144 package to fit into a 1.2"x1.4" footprint. It would have an external programming board with Due programming circuit on it. This way small production runs are way more economical as you don’t have to spend all that $$ and board space on programmer circuits you don’t use in production.
See the screenshot below for some details. The picture is admittedly a bit messy with all layers visible - SAM chip is mounted on top of board, all other components - on the bottom. 68 .1" pins on perimeter. Main design objective was the smallest footprint while maximizing the number of peripheral types broken out. The trade-off is a smaller number of broken-out Digital I/O pins. You will also notice there are no reset / erase buttons. Again, we do not expect those to be useful in production environment. And they would take a huge amount of space + cost of electromech components is non-trivial.
In addition to general feedback, would be cool to hear your opinion on some open questions we still have:
What should we do with VBUS / UOTGVBOF / VBG lines? We are NOT breaking out Native USB at this point so none of the USB hardware would actually be used but I am wondering what we need to keep from the original Due schematics so the system still works. E.g., should we provide VCC to VBUS input? Should we still have an RC network on VBG pin? Etc.
Should we try to break out native USB? The reason it’s not on right now is that a micro-AB slot would take 20% of our board space and in fact would make the board at least 40% larger. Soon enough the space benefit from having this MicroDue board is diminished. So unless one can see extremely high utility for native USB, we would keep it out. IMO given that there is going to be a separate programmer board, native USB is ONLY useful for USB HOST mode. I am just not sure what % of target users this will be important for. Maybe I am missing some uses other than USB HOST?
Are there any other gotchas we should be aware of?
Thoughts? Would you want something like this?