Actually I was thinking that since the C2000 has a good ADC, which is one of the key features that differentiates it from other low cost TI micro-controllers, that it might be good for decoding Amateur Radio digital signals such as packet radio (APRS).
The hardware on the BoosterPack will not be able to support such high currents (connectors/sense resistors/traces/etc). Due to the size/cost/thermal limitations we are looking at it is simply not possible to support that much power. I would have to send you in the direction of this EVM http://www.ti.com/tool/drv8302-hc-c2-kit for that kind of hardware.
I'm sure you could a find a way to put different FETs on the BoosterPack but the results would be unpredictable.
This is a single inverter (DRV8302 + NEXFETs) for the BoosterPack. 24V 10A.
We have a different development board with two inverters (single controlCARD inferface), each 24V 10A that is also in progress. This one will also include an optional dyno bench, using one of the inverters as the dyno and the other under test/control.
Yes, I haven't registered as a TI employee on here yet but saw the post and thought I would chip in. If anyone has any suggestions/features they would like to see, feel free to chime in and I can pass the ideas along.
All XDS100 are fully capable. If you want, you can build your own from scratch, as TI has made all the schematics public.
There are three different versions of XDS100 (v1 - v3). If you want it for C2000 development with CCS4 or newer, it doesn't matter which one you get (go for the v2).
If you need a stand-alone XDS100 for C2000, chances are you have some skills in soldering etc... because you have build some hardware with at least one TQFP or smaller IC (the C2000... ). So why not modify a $17 LaunchPad instead of buying a $79 emulator?
Don't get me wrong, if I were in your position, I would buy the Spectrum one as well, because I can later use it with other TI processors... In fact, I have used mine to do some Linux Kernel debugging on a BeagleBoard. I just want to point out that you don't have to do it...
P.S.: to answer all those questions you never had about the XDS100: http://processors.wiki.ti.com/index.php/XDS100
This has been mentioned a few times before but as not too many people know about it I thought I would bring it up again with my particular spin on things.
It is a little known fact that the Launchpad can easily program external chips. In fact, I only programmed a chip in the Launchpad socket itself just a few times before connecting it to an external breadboard.
A picture is worth a thousand words, so here are some of my Launchpad-breadboard setup:
Very high resolution versions of the image are available through the "Image Options" menu.
Physically, the breadboard is taped (double-sided foam tape) to a piece of scrap plastic. The Launchpad is held in place with a rubber band -- the ones that hold broccoli are perfect.
I didn't have any "proper" connectors, so I simply trimmed (cut and sanded) one of the 10-pin female connectors that comes with the Launchpad. I also didn't have any heat-shrink small enough, so I just "potted" the solder connections with epoxy. It's not pretty, but it works just fine.
To understand what is going on here, it is best to look at the schematic and PCB layout that is included in the Launchpad User's Guide:
It is important to note that the "Emulation" side is completely separate from the "EXP-MSP430G2" or "target" side. You can actually (physically) cut the board along the dashed line if you want. Aside from power and ground, all of the signals cross the dashed line via the jumper pins. If you remove the jumper pins, you have access to all of the signals required to program an external chip.
It may not be clear in the picture, but the jumpers are hanging off one pin on the target side -- that is the easiest way to keep from losing them when the external programming header is connected.
Many people also seem to be confused about the minimal support circuitry required for the MSP430, so that is definitely worth going over. The schematic in slau318 is nicely split on multiple pages to show G2/target side of things on a single page. This is essentially what you will be building on the breadboard.
Obviously the chip requires power and ground, and these are provided via the Launchpad. The power supply must be properly decoupled for proper operation. This involves a 10 uF cap (electrolytic or tantalum) somewhere on the breadboard and a 0.1 uF (a cheap ceramic is just fine) as close to the MSP430 as possible.
The RST line must be held high with a 47 k resistor. If you wish to reset the chip, just apply a jumper from RST to ground. You could use a switch, but a simple wire works just fine when needed.
I have a watch crystal on XIN-XOUT, but this is not necessary. My xtal requires two 22 pF caps for proper loading, but I have not used these, instead enabling the internal 14 pF caps on the MSP430. The xtal seems to oscillate just fine with the improper loading, but I am certain that it effects the frequency. I don't have a frequency counter, so I don't know how far off it really is. The important thing is that oscillator does not seem to fault even when I touch it with the case ungrounded.
If you don't want to use an xtal, you can use the pins as GPIOs.
It is important to note that the chip is programmed over the TEST/RST lines, *not* the TX/RX serial lines. If you do not need serial communication, TX/RX do not need to be connected to the launchpad, and the pins can be used as GPIOs. Even more important to note is that the TX/RX lines used by the chips with a hardware UART (The 2xx3 chips) are *reversed* from the pins used for software serial! The breadboard in the photograph is populated with a 2553, so TX from the 2553 goes to RX on the jumper block and vice-versa.
The only real "application circuit" here is the LED/resistor on P1.0 -- which happens to match LED1 on the Launchpad.
As you can see, this leaves quite a fair bit of board space to experiment with, even with a small 400 pin breadboard.
These little breadboards can be had for just a little more than two bucks when you get 10 of them, and it's really nice to be able to leave multiple small circuits all wired up at the same time. It's also useful to wire up each board as a discrete function, just like a "shield" on an Arduino. For example, you can wire a 2x16 LCD display for 2-pin serial display, and then easily connect that among multiple other boards.
Hopefully this will be helpful to others just getting started!
Could the msp not be processing fast enough? If the master is clocking the spi line before the msp has processed the data and loaded the usi buffer (same buffer for in and out, right?), the msp is just sending back whatever is in the buffer?
I think you need to send 4 bytes. The first 16 bits are shifted out when you send 2 bytes from the
bus pirate. That returns your initial 0x0000 value. The next 16 bits will be returned when you send
another 16 bits. Typically people use a dummy byte of 0xFF. You want to transfer 16 bits so you need
to send 0xFFFF.