causually bumps the thread
Oh yeah! More analog and serial ports is always good. 
It might allow me to use this board for some Ham Radio projects I have in mind once I get my license. Many Ham radios can be controlled via a commands to a serial port.
8-Dale
Jim reminded me that it has been a while since I posted here, so here’s the current progress report.
As indicated in a previous post, I was heading down the ATmega1280 path for the microcontroller. A very capable chip. Then a few weeks ago I got distracted by the dsPIC30 line from Microchip. This has been raised in the forum as a candidate for the NG controller, but I preferred to stay with the familiar AVR processors.
The dsPIC30 and ATMega processors both meet some minimum criteria, specifically:
- 5V I/O, a necessity for servo control
- availability of inexpensive development tools (especially a gcc compiler)
- relatively large amounts of flash (>=128K) and RAM (>=4K) available
- 16 A/D inputs
- self-programming ability, to support a bootloader
The dsPIC30 has a few significant advantages:
- it is much more powerful, with 16-bit math and DSP operations
- it supports nested prioritized interrupts
- it has relatively low overhead interrupt support, including shadow registers and a fast multi-register PUSH instruction
- the A/D converter is significantly faster than the AVR
Of course, there are a few areas where the AVR is better:
- it has 4 UARTS (compared with 2 in the dsPIC30)
- I am very familiar with the AVR architecture
- I already have a bootloader for AVRs
- I already have library and application code for AVRs
Most of the AVR advantages are related to learning curve and getting started quickly with development. I was ready to take the plunge and try out the dsPIC (specifically, the dsPIC30F6014) but decided to take a look at the errata first to see if there would be any difficulties. Well, it turns out that it has some serious errata, especially with the I2C peripheral. There is a bug in the I2C slave operation that causes lost data bytes when operating in interrupt-driven slave mode. I am in the process of evaluating the work-around suggested by Microchip. It seems fairly likely that this and other errata in the dsPIC will cause me to return to the ATmega processor, but that is still up in the air. I welcome comments.
The reason I2C errata matters is that one of the features that has been requested by users for the NG, and that I had planned to incorporate in the design, has been I2C operation. Can those who want I2C comment on the operational mode (master/slave) and maximum Baud rate desired? That might help in this decision.
Thanks, and I am sorry it has been so long since my last update.
Mike
Hi Mike
Glad to see the ssc32ng is still being developed.
I am really looking forward to the 16 a/d inputs especially analog for fsr’s
Wayne
Mike,
Have you looked at any of the ARM7TDMI core controllers from Atmel or NXP as a processor option? With the onboard PLL some of them run upwards of 70MIPS, and they have a ton of hardware peripherals. We have used a couple of these on projects here lately and although we were not tasked with coding I did not get the impression they spent a lot of time wrangling with limitations of the chip instead of working on application development.
EB
:mrgreen:
Eddie,
Thanks for the input. I have looked at ARMs, and in fact would love to use one for the NG, but (and this is a big but), the ARM processors I have found are 3.3V only. I think that rules them out for servo control. I would be delighted to find out that my assumed 5V requirement was incorrect, or to have a pointer to a 5V ARM part.
Mike
I’m assuming you are referring to the servo signal/control line only. I’ve been researching that as well recently. I can find nothing authoritative, but I’ve come across a lot of anecdotal evidence that a 3.3v PWM signal is sufficient for most, if not all, rc servos. I’ve also read that Futuba PCM receivers have always only put out a 3.3v servo control signal. If someone knows something more authoritative on this though, I’d been interested in hearing it as well.
if no one beats me to it I will test it on Monday. I know the Atom Pro has a couple 3v I/O pins. I’ve probably used servos on all of them at one point or another…
Recently I have been playing with the Propeller Chip as well and it is also 3.3v. The boards I have played with have both a 3.3v and a 5.0v regulator on them. I believe that most implementions for servos recommend putting in a resistor on the IO line. For example the servo32 code you can download recommend a 4.7k resistor.
…
Kurt
It has been a long time since I was active on this forum… And SSC32-NG is still not in the store. I don’t need to make my own anymore, since I won a Axon microcontroller from Society Of Robots. This one uses ATmega640, has 4 hardware serial ports, 16 analog ports with 5v power (3 pin headers) and 34 digital ports with unregulated power, for servo controll, I2C bus, user LED and push button (different pins). There are a few more pins that were not brought out to headers, but still, I think it is a good robot controller. Maybe you guys are considering the same chip for your NG?
You guys know that there are many cheap level shifting chips out there (both for normal and pullup style data lines) that will shift from 3.3V uC levels to 5V levels?
There are even some that are bi-directional without giving them any form of direction pin. They are limited to slow speeds, like less then 5MHz or whatnot, but for servos, thats way excessive!
Look at things like the TI TXB0104 or the TXS0104.
OK, I’ve spent way too much time contemplating and researching. Here is my current concept for the NG. Please comment.
The processor is a PIC24FJ256GA in a 64 or 80 pin package. It has a lot of great features and processing power. The only drawback is 3.3V operation, but that seems like it might not be as big an issue as I had feared. Hitec documentation indicates that their servos operate with 3-5V pulse signals. I want to test the bidirectional communication with digital servos to make sure it works at 3.3V.
The PIC24 has 16 pins that are capable of analog input or digital I/O. These pins are 3.3V only, not 5V tolerant. The non-analog pins are 3.3V output, 5V tolerant on input. I have lined the analog pins on the right side (0-15) and the digital pins on the left (16-31).
Along the top are the communication connectors. The USB connector will implement a standard USB-to-serial port on board (using an FTDI chip). The AX-12+ is a 3-pin connector using TTL-level serial. The AX-12+ documentation indicates that it needs 5V, so there will probably be some level shifting necessary. The I2C connector will have data/clock/power/gnd. I would prefer to not level shift this, but am interested in comments.
On the left and right sides of the board are the standard 3-pin servo connectors. To enhance usability, there will be jumper blocks to allow the center pin to be connected to either the servo voltage input, or to a regulated supply. 3.3V on the right side, 5V on the left (but there will probably be a jumper to select 3.3V for the left side). The voltage selection will be on banks of 8. The blocks in the lower left and right corners indicate the voltage selection jumpers.
I’ll use larger and more robust power connectors than on the SSC-32. I am seriously considering having only a single servo power connection. Does anybody actually use the VS2 connector on the SSC-32, or do you all just jumper it to VS1?
The “LEDs/Button” block represents a pushbutton and a small number of LEDs. The button will be used to select Baud rate in the default application, and the LEDs will indicate the rate selected. The button and LEDs can also be used for other purposes based on the application requirements.
What have I forgotten or got wrong?
Thanks in advance for your comments.
Mike
Hi Mike,
Sounds like the NG is gone be a awesome servo controller! 8)
I didn’t read the whole topic so I’m sorry if I missed something… 
Is the AX-12+ connection also the connection that can be used to connect it to the BB2?
Is it possible to switch between the pc (USB) input and TTL-Serial input without replacing a jumper or something. Maybe with a software switch or just connect the both together. It would be great once the SSC in mounted inside the bot.
What’s the maximal baud-rate for the TTL input?
I think it’s a good idea to use a larger power connector. And nope, I’ve never used the VS2 connector but I’m using the same kind of servos. It might come in handy if you mix up different servos that need another voltage. But I think that there are also other ways to solve that.
Does it remember the baud-rate after a power-down?
Thanks,
Xan
Hi Mike,
Looks very nice. It should be a pretty powerful servo controller and I assume robot controller. One concern I do have is the non 5v tollerant pins as I can see someone very easily feeding 5V back. It is good that your power select for these pins is only VS or 3.5v. I have two different boards with propellers on them. They both took two different approachs to the voltage issue. If I remember correctly the one from Parallax through two jumpers allowed you to choose VS or 3.3 or 5V to go to the pins. Then for each of their library functions they told you to somehow add some resistor or another to a breadboard… Another one through a kit had each IO pin come up to jumper that you then jumpered to the IO pin blocks, where you could use a jumper wire to get the voltage straight through or a resistor if needed. This is very flexible but tedious…
I think Xan sort-of asked this, but is there some way for something like an Atom or a Prop, or bluetooth, or Zigbee, or… to communicate with this board using serial communications? I very much like the idea that for controlling this from a PC you can use a USB connection. But also would like the ability for serial, possibly both TTL and maybe level shifted.
I need to learn more about this PIC to give reasonable comments. Some quick looks at the spec looks interesting. Like I think it has 4 UARTS and you can map most any of the IO pins to the function you want it to be. (IE you can say I want a UART on pins 10,11…
If the idea is like before where you will start off with a library of code that several of us can contribute to and make it custom to our own needs, what type of programming support is there? Will we need some form of programmer, what language/IDE, will there be some form of boatloader?
Any form of debug support?
That is all for now.
Kurt
Since the processor has 4 UARTs, I would like to have separate headers for each serial I/O function if there is room on the board. So ideally the USB, TTL serial, and AX-12+ can coexist simultaneously.
Max standard baud rate would probably be 230.4k. Above that it will be non-standard.
The baud rate will be retained across power cycles. I haven’t worked out the UI details yet, but it will be something like: press the button briefly to cycle through the rates; hold it for 2 seconds to store the current rate.
Mike
The 3.3V limit concerns me. I am trying to get some information from Microchip about that. Specifically, I would like to install current-limiting resistors on the board if that can protect the inputs against accidental shorts to 5V. The SSC-32 uses 220 Ohm series resistors without affecting the ability to drive servos, and for inputs the resistance shouldn’t matter functionally. If there is no way to protect the inputs against accidents, then that might be a show-stopper for this processor, which would be a bummer because it has a lot of good features. The backup might be a dsPIC30, but as discussed previously it has a different set of issues. ARMs have a great architecture, but are behind Microchip in the range of peripherals available.
Pin mapping is a really cool feature of the PIC24 that I plan to use. All of the Digital I/O pins will be selected from the mappable set.
I will provide a bootloader like on the SSC-32 for firmware downloads. I plan to use the C30 compiler from Microchip. The student version is a decent gcc compiler, it just doesn’t support the heavy-duty optimization. But with 256K bytes of flash, optimization might not be so important. I don’t know if I will be able to fit an ICD2 connector–probably not as I expect the board to be tight. But maybe I can sneak on some pads to wire up the debugger on a separate board.
Mike
Mike are you shooting for a 2-layer or 4-layer PCB?
Don’t forget a jumper for being able to input a user selectable analog reference voltage.
I know the dual power connector is used by some. If you go to one connector will the board still be able to handle 30 amps? I’m ok with a single servo power connector as long as it doesn’t negatively impact the capability of the board.
Just wanted to point out Atmel has a line fo 5v ARM processors.