We just finished revising our shield-shield design. I’m attaching the Eagle schematic and PCB layout files for you folks to take a look and review. Tell us what you think.
Here is a summary:
Logic level translator on all digital I/O pins. Analog pins are directly connected and are only limited to a max of 3.3V input.
On board 5V power regulator with a safe input voltages from 7V - 12V DC
Would it be better to connect the OE of the level translators to the /RESET line, so that when the device gets reset, all of the I/O are HI-Z as well… just like they would be coming from the Arduino if it were reset.
As a general rule of thumb, it is a good idea to not put vias under IC’s if it is fairly easy to do so. For U1 and U2, it would be pretty easy. This allows you access to both sides of the trace if you are modding the circuit, and also if the vias were un-tented it reduces the risk of shorts under IC’s.
Unfortunately the heat sink on the 5V regulator is the 5V output and not GND, but because of this the heatsinking is reduced because the copper pour for the 5V node is not very large. I would recommend increasing it because you have a ton of board space there that could be naturally used as a heat sink. At least 1 square inch or more is appropriate for that size part.
I never understood why the VIN was not diode protected on the arduino. I know you are just following their design, and I can’t think of a better option that is FREE.
C4 and C5 decoupling caps should be closer to their 3.3V inputs on the IC’s
Might as well stitch the GND planes together around the outside edge more since it’s basically free.
A3, A4, A5 labels are missing.
Since +Vin and VIN are on separate nets, they should be labeled differently. Maybe label the +Vin one that looks to be a JST connector footprint “BATT+” ?
LED should be labeled “PWR” or “POWER” instead of “ON” because ON looks like NO upside down
Are the mounting holes on any kind of a grid? Maybe add some dimensions to them to help people plan out a mounting scheme.
@BDub Excellent inputs sir.
I'm going to incorporate most of it.
These follow the same dimensions as the Arduino design. We could add measurement markings on the PCB file if necessary.
Since the Core does not have enough I/Os, we have decided to provide only 2 ADC channels. I'm thinking of marking A3, A4, A5 as NC to avoid confusion, since they are not connected to anything.
Since the Core does not have enough I/Os, we have decided to provide only 2 ADC channels. I'm thinking of marking A3, A4, A5 as NC to avoid confusion, since they are not connected to anything.
I was under the impression the core had
8 digital I/O pins
4 PWM pins
8 analog I/O pins
as it says on the Kickstarter project page. That adds to 20 I/O pins, the exact number of I/O pins there are on the ATMega328, which is the uC that powers the Arduino Uno, the board you're basing this shield on. Why have you marked 6 PWM ports on the shield when the Core only has 4 and why are there only 3 ADC channels when the Core has 8?
Also, I’d like to make a suggestion for the Shield-Shield, a built-in u.FL to RP-SMA adapter and maybe a little antenna for people who have chosen their cores to be shipped without the built-in antenna.
Re: A3, A4, A5… the Spark Core has A0 - A7 so I figured it had an abundance of Analog Inputs.
Re. “8 analog I/O pins” on the kickstarter page, should this just be “8 analog inputs”? I believe the 4 PWM pins (or is is 6?) are the “analog outputs”, right?
@henriquepss
Sorry about the confusion there: The Core is designed around the STM32 microcontroller and currently has a total of 16 I/Os available to the user. The 4 PWM pins are multiplexed with these standard I/Os and aren't available separately. It's my bad that I marked 6 instead of 4 as PWM channels. Thanks for that catch!
The easiest way to achive this is to connect an adapter to the uFL connector on the Core directly. There is no provision to get the RF signal onto the shield and then to an antenna.
Yes, the Core has 8 analog inputs but some of them are multiplexed with SPI and we chose SPI over analog as its going to be more advantageous. If the user really does want all ADC channels available while sacrificing SPI, we provided header pads for all I/Os which can be tapped into separately.
I suppose we need a better way to indicate these differences.