SSC-32-USB

Let's Make Robots Project Ideas
1

Hi Mike, I thought this was a better place to discuss this than email.

I have talked myself out of the SSC-32 without any com and making USB / DB9 / Zigbee daughter boards for it. I think it would be better to just put the USB right on the board. We could make a daughter board for Xbee that plugs into a header. I can’t think of a single reason to retain the DB9 connector.

I have not found a schematic for it yet, but I’m still looking for it. I just can’t ask Dale for it after posting this… lynxmotion.net/viewtopic.php?f=3&t=7313" onclick="window.open(this.href);return false; Not sure if it even exists…

2

Jim,

I searched my email history and found some old emails where you attached the design files including schematic. Here is the zip file from the last one, dated Feb 13, 2009.

SSC-32a.zip (404 KB)

Mike

3

Jim,

I modified a Sparkfun FT232RL breakout board to match the schematic in the zip file (i.e. the FT232RL and the ATMega168 are both powered from the VL supply), configured the chip appropriately (I think) for self-powered mode, and connected it to an SSC-32. It works well until power is removed from the SSC-32, at which time the serial port disappears. Lynxterm does not handle that gracefully.

Next I will try a configuration in which the FT232RL is bus powered but the ATMega168 is powered by the VL supply. I expect that to work better.

Maybe we should implement a “best battery” source for 5V. The problem with that is that the simplest method to do it is to use diodes to select the supply voltage, which would make the SSC-32 more sensitive to low-battery issues. A jumper to allow the user to select USB or VL as the logic source could be another solution.

Mike

4

Jim,

I modified the test setup to have the FT232RL powered from the bus, and the VCCIO voltage taken from the 5V VCC on the SSC-32. I configured the chip for bus-powered mode. It seems to work well in this configuration. Normal serial communication is good, and when the SSC-32 is powered down the COM port is still active and Lynxterm doesn’t get confused.

This can be duplicated on the board you have by doing the following:

  • Unsolder Pin 20 (VCC) of the FT232RL and lift it away from its pad. (Unfortunately it is connected to a polygon, so it is not as simple as cutting a trace.)
  • Cut the trace connected to Pin 19 of the FT232RL (or remove resistors R35 and R37).
  • Connect a fly wire from Pin 20 of the FT232RL to the “top” pad of R35 (just below the “2” of the SSC-32 silkscreen). This causes the FT232RL to be powered from VBUS of the USB port.
  • Use the MPROG or FTPROG utility from FTDI to configure the FT232RL for bus-powered mode.

If you don’t want to do this but would like to have the board modified for your testing, then I can make the modifications.

Mike

5

Jim,

Based on my tests this weekend, it looks like the SSC-32-USB can be made to work with a minor modification to the Eagle files. You would need to decide on any silk-screen changes for the updated board (name change, etc.). I think we should also consider changing the power connectors to the larger ones used on the Propeller board.

There are a range of options:

  1. Make minimal changes to the board, i.e. bus-powered FT232RL, silk-screen changes if desired, and connector change.
  2. The above, but also change to an ATmega328 processor. If we did this, I would feel confident of having enough memory to port to GCC and give the code a much needed clean-up.
  3. The above, but make the ATmega328 and the EEPROM surface mount parts.
  4. Make a more significant update to the design to make the servo ports capable of acting as inputs for digital servo feedback, etc.

I know that getting something out there with USB support is very important to you. Options 1 and 2 would be low-risk. Option 3 would be higher-risk but not bad. I think option 4 could be completed in your timeframe, but it is the highest risk. I am thinking that we should get option 1 or 2 to the point of pulling the trigger, and then work on one of the other options in parallel if you are interested.

Let me know how you would like to proceed.

Mike

6

Hi Mike,

Sounds great to me, personally I would go with the Option 3, but that is me. At a minimum go with Option 2 as it would be nice for you to have enough room that maybe there is only one version (both hex sequence and GP) and it would be good if you could use GCC or at a minimum be made compatible with current versions of codevision. But again I prefer GCC as it is free…

It would be great to share as much as possible with this and the Botboardduino design. The board is in pcfabexpress and should be sent out later this week. I did send them some updated files over the weekend, but I am not sure if I am too late to get changes for this go around, will see what they say probably tomorrow. One of the things I learned after I sent the files to them, is that if you make pins 6, 9, 10, 11 of the FT232RL chip available (I added .1" connector spacing for this), you can use the FT232RL as a BITBANG AVR programmer and you can have it program in your bootloader, (geocities.jp/arduino_diecimi … ex_en.html).

Kurt

7

Kurt,

I greatly prefer GCC as well. In my experience it does not optimize very well for space, and it doesn’t support some of the tricks I used in CodeVision, so I would want to make sure there is room to make it work before I go to the considerable effort of porting.

I have been debating how to program a surface-mount AVR with the bootloader and initial app. The SSC-32 has never had a programming header but I would add pads for it, with the intent of using pogo pins to connect for initial programming. Ideally, for production there would be a programming fixture with alignment pins arranged to fit the mounting holes. When you lower the board onto the alignment pins, the pogo pins would contact the programming and power pads. At that point a script would run to program the board. This is probably the fastest way to program the boards for production. If there is space on the board, I would use the standard 6-pin 0.1" arrangement for the programming pads so a user could solder in a programming header if desired. (There are a number of alternative possibilities for programming fixtures, but the main point is that they require just one quick connection to do the job.)

I have also considered connecting spare I/O pins on the FT232RL to the reset and programming pins. The programming pins are shared with the SPI peripheral, which is used to drive the shift registers, so I would include current-limiting resistors to prevent damage in the case of contention. This could be a useful backup to the programming fixture, but would probably be significantly slower to program the boards, and therefore not desirable for production runs. Great for prototypes and one-off boards though. I think I will add that capability. Thanks for the link detailing the process. That will save me a lot of work.

Mike

8

I like 3 or 4, as we have plenty of time. Assuming we don’t lose track of time… :unamused:

We need to fix the power terminals, that’s a given. I’m not sure why no ones used TTL output function on the extra outputs with the inputs as a method of expansion.

9

Mike, just got the quote from Allen. He’s at $2.15 for the Mega168 chip! He will be adding the chip on his end this time. My price is like $3.33 at 2500 so… Hopefully he can program at least the bootloader on them.

Looking good for the SM chip on the USB version. I think they are cheaper anyway…

10

Jim,

Sounds good on the M168 order. Will you be getting a sample from him for testing as in the past?

I’ll come up with a proposal for an Option 4 to see how you like it. If we don’t end up feeling comfortable with a substantial redesign, then I think we are looking at option 3, with SMT M328 and EEPROM.

Mike

11

Ok sounds great! Yes we will get a sample before they do all of them. :smiley:

12

Jim,

As promised, here is my proposal for an enhancement to the SSC-32 that would allow all servo pins to function as inputs. I have had this basic architecture in mind for quite a while but didn’t know if it was needed, as it overlaps the potential functionality of the ARC-32. But here goes.

Primary goals:

  • Bi-directional communication with Hitec servos to read position
  • Support as many analog inputs as possible
  • Change to larger, more robust connectors
  • Support USB instead of RS-232
  • 5V I/O on all pins
  • Identical command structure and behavior as the existing SSC-32, but with new commands for new capabilities
  • Less susceptibility to resets due to low battery voltage
  • Restructure code for easier maintenance
  • Use free development tools (e.g. GCC compiler)
  • Minimize BOM cost impact of enhancements

Anything beyond these goals is a bonus.

I think I will end this post here, as this captures what I see as the requirements. I’ll follow up with another post describing an architecture that I think meets these goals.

Mike

13

SSC-32 architecture update proposal, continued…

The 5V I/O requirement limits the choices of processor to connect to the I/O pins. Most of the newer high-powered processors are 3.3V (or less) designs. Many have 5V-tolerant I/O, but cannot emit a 5V pulse. Level shifters are possible, but will make it difficult to meet the requirement for analog inputs.

In order to have 5V I/O and maximize the number of analog inputs, I would use coprocessors for each bank of pins, similar to the shift registers in the current design. The one I am thinking of is the Microchip PIC16F720 in a 20-pin SSOP package, operating at 5V. I really don’t like the old PIC processors, but this is exactly the kind of application they are designed for, and the price is right. The connection to the coprocessors would be either SPI or I2C. Every I/O pin would be analog capable. The processors work down to 1.8V, so they will resistant to brown outs.

Using coprocessors like this has the additional advantage of greatly simplifying the code on the main processor. In the current SSC-32, the need to generate precise servo pulses dictated the software structure and imposed a number of difficult constraints. Moving the time-critical stuff to another processor would make it easier to maintain and upgrade the main processor software. The coprocessors would still have all the timing constraints, but they would not have to mix low-latency timing stuff with high-level command processing. Most maintenance and enhancements would probably focus on the main processor, so the coprocessors would probably not need to change very often if at all.

For the main processor, I would like to consider moving to something more powerful than the ATmega328. For this I have in mind a PIC24FJ32GA002 in a 28-pin SSOP package. It has considerably more horsepower than the ATmega328, at a comparable cost ($2.40 in quantities of 100 at Digi-Key). It has 32K of flash and 8K of RAM (nirvana!). No internal EEPROM, so I would need to work out a method to emulate that. It is a 3.3V part, but since the main I/O is handled by the coprocessors that won’t be a big issue. I will only need to level shift the serial communication lines. The external EEPROM and USB will be powered by 3.3V. The ABCD inputs will need a simple voltage divider to bring them to 3.3V.

The PIC24 family is programmed with Microchip’s MPLAB C30 compiler, which is GCC-based. There is a free version that is unrestricted. You can pay and get improved optimization, but that is not necessary. The free version is fully functional.

This is the main architectural change that I am proposing. Additional improvements I will consider as space permits:

  • Additional serial port, probably RS-485 or TTL selectable. This could be used to daisy-chain multiple SSC-32s, or or control external serial devices.
  • I2C port for external use
  • Footprint for 2mm XBEE sockets and jumpers to switch between USB and XBEE serial comms

Mike

14

SSC-32 architecture update proposal, continued…

So how does the proposal stack up versus the goals?

** Bi-directional communication with Hitec servos to read position.* Supported by the hardware. SMOP (Simple Matter of Programming :wink: ).

** Support as many analog inputs as possible.* Every I/O pin will be configurable as an analog input. SMOP.

** Change to larger, more robust connectors.* Independent of the architecture change. Check.

** Support USB instead of RS-232.* Independent of the architecture change. Check.

** 5V I/O on all pins.* The 32 servo I/O are driven by 5V parts. The ABCD inputs will connect to the main 3.3V processor via voltage dividers to bring them to 3.3V levels. Check.

** Identical command structure and behavior as the existing SSC-32, but with new commands for new capabilities.* SMOP.

** Less susceptibility to resets due to low battery voltage.* The main processor is specified to operate to 2.0V, and the coprocessors to 1.8V. Check.

** Restructure code for easier maintenance.* The main processor code will be made much less complex by moving the timing-critical stuff to the coprocessors. Check.

** Use free development tools (e.g. GCC compiler).* Check, with the free version of MPLAB C30. (The coprocessors would be coded using the free MPLAB assembler.)

** Minimize BOM cost impact of enhancements.* Depends. Here is a summary of the cost differences (at Digi-Key) in comparison with a USB board based on the ATmega328.

Q=25, ATmega328 = $2.40, PIC24FJ32GA002 = $2.60
Q=100, 74HC595 = $0.30, PIC16F720 = $0.88
Q=1000, 3.3V LDO, LP2981-33DBVR = $0.28, 3.3uF tantalum = $0.10
Q=1000, level shifter for I2C, dual BSS138 MOSFET = $0.15

I think I got the big items. There will be some resistors and caps that will add up to pennies. The totals are:

  • Main processor delta = $0.20 at very low quantities, will probably be much less at production quantities
  • Coprocessor delta = 4 * $0.58 = $2.32 at Q=100, will be somewhat less at production quantities
  • 3.3V regulator and output cap = $0.38
  • Level shifter = $0.15
  • TOTAL = $3.05

So the parts for this board will cost about $3 more than for a USB board based on the ATmega328 and shift registers. This is just a ballpark estimate. I suspect that once the China purchasing works it over, the number will decrease, but there is no guarantee.

For the additional $$ you get bi-directional servo comms, analog inputs, better low-voltage performance, a more powerful processor, and easier code maintenance/enhancements.

Let me know what you think.

Thanks,
Mike

15

Truth in advertising…

The PIC16F720 has an 8-bit A/D. Some people might object to the resolution as being insufficient. To me it seems like it will better than the noise present in whatever analog signal is likely to be connected. But I wanted to make sure people were aware of that. It is the lowest cost device I have found so far that has the 5V I/O needed, and has the ability to read/write its own program memory (thus allowing reprogramming using a bootloader).

Mike

16

Hi Mike sounds like it would definitely take the SSC-32 foreword. Personally 8 bit ADIN is good enough for most things I do, but…

Kurt

17

Something I forgot to put on the list: to really utilize the A/D converters there would need to be a way to select the voltage (per bank) between VS and VCC. This would be accomplished with jumpers.

Mike

18

Wow, this is a lot to take in. Custom programmable I/O controllers wrapped around a powerful processor. My only concern is the programming of the I/O controllers. Did I understand correctly that these will be programmable after installation by the main processor? Well anyway that’s the only concern I have.

Perhaps a combination of the two… Make 16 of the I/O go through the output only shift registers, and the rest go to the I/O controllers. No need to make all I/O capabler of being inputs… However if the big picture requires changing them all to bidi then I can see the usefulness. Scratch that. I can actually see the usefulness of an all input SSC-32. Will have to change the name. SSC-32 to UIOC-32 Usb I/O Controller. lol :slight_smile:

19

Jim,

The I/O processors would be reprogrammable, but with luck would never need to be reprogrammed. They would have the low-level functions necessary to emit servo pulses, read analog inputs, etc. Unless there was a bug or some major new function to be added, then they should not need to be reprogrammed. Reprogramming them would probably involve flashing a special application onto the main processor that would be strictly for the purpose of updating the I/O processors.

If 8-bit A/D is a problem, the PIC16F677 is a pin-compatible replacement for the PIC16F720 that offers 10-bit A/D, but it costs more.

One of the benefits of this architecture is simplification of the main processor code (removing the super time-critical stuff). That would not be possible if any of the servo outputs used the shift registers. So my preference for that reason is to have I/O processors for all servo outputs.

Mike

20

Yup I assumed all that you said. I like it really… Distributed programming is how it’s done nowadays. :wink: May not be able to keep the $40.00 price tag. We’ll see. Looking interesting!