Here is a preview of the new SSC-32U.
We have completed the draft design for the USB version of the SSC-32. 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.