I have completed the draft design for the USB version of the SSC-32 and Jim suggested I post it here for comment. Here are the changes to note:
SMT processor (ATmega328) and EEPROM.
USB mini-B connector and FT232RL chip.
Support for bit-bang programming of fuses and bootloader over the USB port.
XBEE socket, with antenna hanging off the right edge of the board (as specified in the datasheet). 3.3V regulator and level shifter to communicate reliably with the 5V processor.
TTL level TX/RX header.
Series resistors on XBEE and TTL RX, so the USB port will dominate if connected.
6 LEDs in 0603 packages (1/4 the size of the LEDs used in SSC-32 and Botboard). PWR in lower left corner, USB TX/RX in upper right corner, XBEE RSSI (Received Signal Strength Indicator) in lower right corner, and general A/B status LEDs next to the crystal.
“Baud” button near the A/B LEDs. Used to select baud rate, and to keep the processor in the bootloader on reset. This replaces the Baud jumpers on the old SSC-32.
It is possible to reset the processor and keep it in the bootloader using the USB connections. This can be an enhancement to the firmware loading process.
8 analog input pins (A-H) on 3-pin headers. 2 are analog input only, the other 6 can also do digital I/O.
2 of the analog input pins can be I2C with software-selectable pullups.
Larger terminals (same as BBduino).
SMT regulator, the same one as used in the BBduino. Lower dropout voltage than the one previously used on the SSC-32.
Pads for 440uF capacitance on logic power to help with brownout.
Schottky diodes from Vservo1 and Vlogic to logic power to make the capacitors effective. These act as a best-battery select between Vservo1 and Vlogic. The VS=VL jumper bypasses the diode if the user doesn’t want the diode drop, but makes the capacitors less effective.
An extra 5V/GND header in the upper right corner. This can be used for anything, but one of the things I was thinking was to connect a large capacitor to help with brownouts.
Note that there is no provision for the board to be powered by USB. That would have been much more difficult with (I think) minimal benefit. USB is not sufficient to power servos in a real application, and if servo power is applied, it will power the processor.
Looks great. Will be fun to play with. I am assuming that this will have a 14.xxx mhz crystal or the like to handle the default baud rates like 115200. Might be nice to have the option to run at 16 or 20, especially if lots of the time will be connecting to other processors running at that speed, so baud rates like 125000 would work better.
Yes, I had planned to stick with the 14.7456 MHz crystal. The only way I can think of to support 115200 and 125000 is to socket the crystal. Maybe there is a crystal frequency that will do both–probably worth a look.
My guess is that no one crystal will work completely for both baud rates. Not sure if a 18.4320mhz one would be any better. It also gives 0 error for the standard baud rates.
The XBEE outline is for the regular version. The pro version will overlap the LEDs and button. Here is the board with the top documentation layer turned on showing the extension for the pro version. I don’t know if the button will interfere with plugging in an XBEE pro.
Not sure if you’ve thought about this very much but if an Xbee pro can be put on the board you need to make sure you have a beefy 3.3v regulator as some of the pros can draw a peak up to 500mA. Just putting that out there.
I had a successful weekend of testing, and have placed an order for another set of boards. I also ordered a solder stencil so that I can build up several quickly for your and my testing, and my continued firmware development. While I am waiting on the boards I will order additional parts to populate them.
I tested the power supply, basic I/O (button, LEDs, servo outputs, etc.), EEPROM, and serial connections. I verified that each of the serial connections work at 115.2 kBaud (USB, XBEE, and TTL). In addition, I verified that if the USB is connected it “wins” over the other two even if they are connected. There are current limiting resistors to prevent damage if multiple sources are trying to drive the serial port at the same time.
In order to get the FT232 chip to play nicely I had to use a best-battery type circuit to keep it powered up all the time. (This is what has had me scratching my head for quite a while.) It handles the following scenarios:
VCC (from servo/logic power input) is present but USB is not connected. In this case the FT232 is powered from VCC but held in reset so it has no effect on the rest of the circuit.
VCC is present and USB is connected. In this case the FT232 is powered from VCC and is operational.
USB is present but there is no VCC. In this case the FT232 is powered from the USB port and is operational.
This means that you can disconnect the servo/logic power and the FT232 will remain enumerated on the PC. The microprocessor will not be powered, so there will be no serial communication, but the COM port will still be valid on the PC.
I am attaching a photo of my test setup in case you are interested. I ended up with lots of fly wires. The circuit on top of the USB connector is the best-battery circuit that I was testing. The little board off to the side is the programming header for the ATmega328P (much better than a bootloader for doing software development work).
