msptest6

Enjoy



LAUNCHXL-F28027.zip

VC5505 eZdsp USB Stick Development Tool (TMDX5505EZDSP) - USE COUPON CODE: C5000KITONE
C5515 eZdsp USB Stick Development Tool (TMDX5515EZDSP) - USE COUPON CODE: C5000KITTWO

Should be fixed now, Trey.

I found this in "development_kits/~SupportFiles/F2802x_headers/" along with the PeripheralHeaderIncludes.h file.
 
I compiled, loaded and ran the program without errors - though have not yet actually tested functionality
I tried restarting CCS (and my machine) to see if this would induce the indexer to re-index the _Comp header file, but no change, never mind.
Thanks for the EALLOW mention, hadn't thought about that!
Cheers
 
P.S. I'll cross-post my solution to the e2e for anyone looking for a solution there also
 
P.P.S. Have somewhat confirmed my changes by comparing the F2803x _Comp.h (as Devin suggested) in which the ramp registers ARE defined, and also has no mention in the relevant PeripheralAddress_ASM.h so I guess I dont need to add anything there.
 
Also fixed the indexer issue by 1) exporting my preferences 2) restarted CCS with the -clean arg, then closed CCS again 3) Cleaned my workspace 4) Re-opened CCS and imported my preferences and project (had to re-setup my perspectives also). 5) Bingo!
Instructions for the steps can be found on the TI wiki here. Step 2 is probably redundant but I tried it just to be sure!
 
Also, on comparison to F2803x header I changed my DAC_CTL bit 14:15 from FREE to FREE_SOFT

Just to throw this out there, I did some work with bldc motors using msp430. See images below. In my opinion c2000 is a little over kill especially for sensored motor control but agreeably cool.
 

 

 

Now if only it flew haha...
 
I managed to get a form of instaspin bldc running on msp430g2553 on the first board but haven't touched it in awhile to optimize. My big problem was running the advice fast enough for high KV motors. I think I have a scheme now just need time to implement.

Hi!
 
Yes, there are differences between these files.  The f2802x_common directory contains drivers and some helper files like linker command files.  The F2802x_headers directory contains header files that can be used to access the peripherals using structures.
 
You shouldn't need to use anything in the GEL directories.  CCS will automatically take care of this.
 
adc.h is not identical to F2802x_adc.h.  adc.h is a header file for the driver library while f2802x_adc.h is header for some legacy driver code.
 
Try starting out by importing some of the examples and figuring out how they work.

Here is a Eagle library for a C2000 Booster Pack template.
Not tested! Simple straight through board.
TIC2000Launchpad.zip

I found a really good tutorial.  Download the C2000 Teaching ROM... it is a bunch of pdfs from a university class.

w00t w00t!
If you have any questions on USB on the F2806x...send them my way!  I was responsible for porting the USB stack and examples to the 28x architecture.  FYI, the USB controller is VERY similar to the Stellaris USB controller.

Pheo,
Your edit is 100% correct.  I actually reviewed this boosterpack prior to manufacturing to make sure it would work with the C2000 LaunchPad.

INV15OFF

NFC surely looks interesting ... would be even more interesting if we could program devices using NFC ... maybe in the future.
 
EDIT: ... future might be nearer than I thought, see http://www.ti.com/lit/an/sloa160/sloa160.pdf
 
Looks like an NFC version of the RFBSL (bootstraploader) has allready been worked out ...

This function is declared in _DEBUG scope.
 
Only is visible if the _DEBUG is declared on compile / link steps.
 
To enable the _DEBUG define, go to :
 
Project -> properties -> Build -> C2000 Compiler -> Advanced Options -> Predefined Symbols
 
and include the _DEBUG symbol on Pre-define Name field.
 
good luck

Hi Skinny,
 
Sorry for your troubles, these examples and the driver they use are relatively new and I've had very little help testing and making sure everything works.  I sincerely apologize for any bugs you may find, and I'm happy to work with you to fix them.
 
On to your problem:
There are a few minor issues that need fixed before the example will work.  I'll file a bug for these and get this fixed in the next release.
Warnings: SCI_read and SCI_write are functions defined in sci_io.c.  These were added to allow me to register the SCI as a STDOUT stream.  This allows us to use the printf functionality present in the RTS library with the SCI.  The warning is there because these functions are not properly declared in a header file.  I added these late in the game and they never got declared.  You can fix this by switching these calls to SCI_getData and SCI_putData, the arguments to the functions are the same so it should be a drop in replacement. Hardware: Make sure the serial connection switch S4 is in the up position.  This connects the SCI peripheral's gpios to the USB/UART connection on the FTDI chip. Baud Rate: This example was originally written for the F2802x0 devices which have a max speed of 50Mhz.  Two things need to be done to fix the baud rate.Change the PLL to setup the device for 60Mhz     PLL_setup(myPll, PLL_Multiplier_12, PLL_DivideSelect_ClkIn_by_2); Replace the baudrate setup code with this: #if (CPU_FRQ_60MHZ)
    SCI_setBaudRate(mySci, SCI_BaudRate_9_6_kBaud);
#elif (CPU_FRQ_50MHZ)
    SCI_setBaudRate(mySci, (SCI_BaudRate_e)129);
#elif (CPU_FRQ_40MHZ)
    SCI_setBaudRate(mySci, (SCI_BaudRate_e)129);
#endif  
Once again, sorry for the trouble.  I've had a lot on my plate this year.  If you have any more questions don't hesitate to ask!

Via LarissaSwanland's twitter feed.
 

 
http://e2e.ti.com/bl...f-together.aspx

hello,
 
here are some bugs I have noticed.
 
1) controlSUITE/development_kits/C2000_LaunchPad/f2802x_examples/C2kLaunchPadDemo, project settings.
Some project paths are invalid for case-sensitive operating systems.
There is:
.../F2802x_common/...
There should be:
.../f2802x_common/...
 
2) controlSUITE/development_kits/C2000_LaunchPad/f2802x_common/cmd/F28027.cmd, line 117.
Linker command file typo.
There is:
.text : >> FLASHA | FLASHC | FLASHD. PAGE = 0
There should be:
.text : >> FLASHA | FLASHC | FLASHD, PAGE = 0
 
3) ~/controlSUITE/development_kits/C2000_LaunchPad/f2802x_common/source/spi.c. line 563.
Register name typo prevents from configuring FIFO interrupt level for SCI/Rx.
There is:
spi->SPIFFTX &= (~SPI_SPIFFRX_IL_BITS);
There should be:
spi->SPIFFRX &= (~SPI_SPIFFRX_IL_BITS);

i wrote a little code i would like to share:
http://www.djmetzler.net/2012/11/09/c2000-launchpad-assembly-only-software-pwm-tutorial/
cheers
-pheo

I was looking at the C2K Launchpad, and was sort of disappointed they didn't go with a board that uses CAN, so decided to possibly make my own.
 
Any ways, I did not route the LIN ports yet, I should have, but as you can see, there is quite a bit of fudging along to make it all work.
 
It is more or less pin compatible with the regular C2K LaunchPad, except I'm using the 2 NC pins on the lower right headers to break out the CAN pins. And using a JTAG port for programming and debugging.
 

 
It won't let me upload .brd files so I attached them to my website:
http://www.northernd.../files/main.brd
http://www.northernd.../files/main.sch
 
Dimitri (aka jim940 at 43oh)
main.brd
main.sch

I got hardware SPI working with the Nokia 5110 LCD.
I used a GPIO for the chip enable, and an interrupt for bringing CE high after transmission.
I've attached the code below and a small graphics library that I put together from various sources on the web.
 
One thing I found confusing was there seems to be no interrupt flag set when the SPITXBUF empties.
So in the situation like this one where the Rx of the SPI is not even being used, to get the interrupt to work
you still use the Rx ISR.
 
Here is my interpretation: Write data to SPITXBUF data shifts through SPIDAT and is transmitted out SPISIMO,
simultaneously the same data is shifted into SPIRXBUF and SPI INT FLAG is set. Then you use the Rx ISR to read
the SPIRXBUF and that clears the SPI INT FLAG.
 
Is this correct?
Also the documentation on the FIFO is somewhat vague for the inexperienced.
How would I go about using the FIFO for this example?
 
Here is a short video:


 
thanks
Tim
C2000_nokia5110.zip

I had a huge problem getting CCS setup with my new launchpad on Fedora, so i wrote a little tutorial to save anyone else some time.
 
http://www.djmetzler.net/2012/10/28/c2000-launchpad-on-fedora/

Quick Update:
I just wanted to make everyone aware that I am actively working to get get us open cross platform tools. The entire Energia team is aware of the issue and we are talking with the compiler and tools guys to see if we can find a solution. It might take some time for us to get to a full open source cross platform solution for the C2000 LaunchPad, BUT I think we will be able to come up with some interim solutions that can coexist with the Energia license a little quicker. I can't promise anything right now, but I wanted to let the community know that I am fighting for you.

Imp,
This is part of the design. The buffer on the LEDs are inverting buffers, so when you give it a logic high they put out a logic low which then sinks current from the LEDs.
 
Another thing which is kinda cool is that the buffers have a very high input impedance, so much so that you may have noticed when the buffers aren't driven that you can change the LEDs state by touching the GPIO pins. This was done intentionally to show users what a floating node looks like and how it acts.

Absolutely true. Dealing with multiple OSes can be painful but in this day and age it is necessary. Because the Energia project has a lot of backing within TI, I'm going to try to see if I can get some of the tools open sourced so they are easier to integrate with Energia (and easier to make cross platform).

Ok, first let me explain why ya'll were having trouble getting this running on the hardware SPI.
If you simply setup the code for hardware SPI and call:

PinLow(CS_PIN); // pull CS LOW SPI_write(LCDSpi, spidata); PinHigh(CS_PIN);
You'll end up seeing something like this on the bus:

The third trace is of course CS and you'll notice it goes high during the bitstream...no good.
For testing purposes I simply added a short delay after SPI_write and before I pulled CS high and sure enough the display started working.

I actually ended up cleaning up Lar's code quite a bit to make it more software friendly. All the functions are now in a c file and the prototypes are extern'ed in an associated header file. I also used an interrupt to tell me when to pull CS high. Check out glcd_hwSPI.c and .h
 
If you copy the folder in the zip file to C:\ti\controlSUITE\development_kits\C2000_LaunchPad\f2802x_examples the example should import and build without issue.
Example_F2802xLCD_SPI.zip