Hrm, been studying the Due’s schematic for the past few days and seeing all the shortcuts that the Arduino team took with it. One of the biggest complaint is the built-in RTC. Because of how they wired the reset line, it also resets the backup region which takes with it the RTC. Also, without hardware changed, there is no way to add a backup battery. Doing that would require cutting traces and resoldering the reset line different. So that’s one thing I would do right on my design.
But, something else I realized last night: the physical size of the AT91SAM3X8E. At 22mm x 22mm (with leads), fitting it inside of a 3/4" ID tube is a no-go. Even a 1" ID tube won’t leave much room to run traces along the edges. So either I’m going to go larger, or I’ll need to use the smaller, 100 pins version with less capabilities. Memory remains the same, hardware changes a bit. Things like no NFC, 63 PIO, no shutdown pin, only 4 DMA, and 15 PDC channels. It also appears that the smaller version does not have the different external bus interfaces, 16-bit data, 8 chip selects, and 23-bit address.
Ah well, compromises … OR, use the BGA version as that’s only 10mmx10mm. But, to be honest with you, I’m not even sure I can do that. That’s a lot of pins to route through a dual layer board. I don’t know that I can get traces running between the contacts on the upper layer.
Dan and I were just discussing this. Apparently, with most chips, if you soak them in acetone overnight, you can safely fold them in the morning.
OK, well, we were discussing the large form factor chip problem, but I don’t know about the acetone trick, since I just made that up. (Dan and I are currently on Cape Canaveral , Florida, recovering from the giddy high of witnessing the NASA “MAVEN” mission to Mars launch. You have no idea how many LEDs they needed to use to get flame effects like that…)
Kidding aside for the moment, this is all about tricky trade-offs, eh?
He and I were musing that there’s no such thing as ONE ‘dream board’; there are at least two: a dream dev board, and a dream deployment board. The Dev board, you want lots of easy to get at pins, connectors, power options, etc., as you fool around to figure out what you want to do. The Deployment board is probably much smaller and has fewer options for playing around. We noodled around with the details a little, but didn’t have any firm conclusions – except that we’re both kind of excited at the idea of boards made specifically for driving LEDs!
Well yeah, I quickly realized that as well. One thing he said that stuck with me, is the need for something with multiple MCUs on it. Well, Atmel has already done that. It’s called the STK600. One “motherboard” with the ability to plug in several different series of AVR. Something like that would have it’s advantages as one can develop on several AVRs. It can be specific to just driving LEDs of course, as opposed to all of what the STK does.
At the other end is what you referred to as the deployment board. That one will have to be more specific for the task, and yet have the ability to add options. For example, someone may just want an MCU. Another might want an MCU and a charging circuit only. Yet someone else might want to add an accelerometer to it … in the end, you have to break that down and look for the minimum we’d want to provide and go from there. Those who want options we can work with and figure out what makes sense.
Things that make you go ‘Hmmmm…’
By the way, the MAVEN was designed and built right here where I am. 
Cool! Well, y’all did a good job. Amazing actually.
It’s hard sometimes for me because I have friends that work at Ball Aerospace, at CU’s Engineering Department, and at Lockheed-Martin …