Jump to content
Anguel

C2000 Launchpad: Which ports are usable?

Recommended Posts

Hi!

 

I am looking at the interesting C2000 Launchpad and just discovered this forum :-)

 

My question is regarding serial communication with external chips. I see that the Launchpad's C2000 has only 1 x SCI, 1 x SPI and 1 x I2C. Then I discovered that the SCI seems to be already occupied with the USB chip on the Launchpad (ok, one can turn off USB but I want to use it). So my question is what other serial buses can be still used on the board. As far as I can see I should be able to use SPI only but I2C is not usable as it seems to use the same pins as the SCI. Is this correct or did I overlook something?

 

Any tips and comments are welcome :-) Thank you in advance!

 

Regards,

Anguel

Share this post


Link to post
Share on other sites

Anguel,

Good question!

You are correct the LaunchPad has 1 SCI (UART)  1 SPI and 1 I2c.  SCI can either be connected to the USB/UART present on the FTDI device (using the big switch) or to an external device through the header pins.  You are also correct that SPI and I2c are connected to the same pins.  This was done to maintain compatibility with the MSP430 LaunchPad.  They can however both be used simultaneously.  You'll notice in the schematic there are a set of jumpers before the actual pins these functions are connected to.  The footprint of these jumpers is an 0402 resistor with a trace between the two pads (i.e. they are shorted together).  These jumpers can be cut with a knife to allow the I2c and SPI functions to be separated out.  They can also be jumpered after the fact using 0 ohm resistors.

 

Does that answer your question?

Share this post


Link to post
Share on other sites

Tray,

 

Thank you very much for the fast reply. Now I understood how it works :-) Very clever design.

 

Unfortunately it seems that the I2C drivers are not documented at all in the F2802x Peripheral Driver Library :-(

Also looking at the driver files there is something wrong: They contain "to be done comments" e.g. in the F2802x_I2C.c and it seems that one has to manually uncomment the pins there to use GPIO 32+33 instead of GPIO 28+29 which are occupied by the USB.

Do the I2C drivers work at all?

 

Best regards,

Anguel

Share this post


Link to post
Share on other sites

Anguel,

The driver in the F2802x_i2c.c file are limited at best, but they do work.  This isn't really a driver but more of a GPIO setup function.

 

The other i2c file is a driver, but it is not complete or fully tested.  I was the only one developing all the LaunchPad hardware and software and as such I ran out of time before release and haven't had a chance to revisit it.

Share this post


Link to post
Share on other sites

Sorry, I don't really understand: As far as I see the I2C drivers in the controlSUITE are the official I2C drivers for the F2802x MCUs and not some special drivers for the launchpad. Actually the launchpad is just forwarding the MCU signals. So these drivers should be normally completely tested and working. They seem to be almost identical or even identical for all C2000 MCUs. I just can't imagine that TI does not have working and tested I2C drivers for its real-time 32 bit MCUs. Or do I misunderstand something? The i2c.c files for your board and for the MCU are exactly the same.

Share this post


Link to post
Share on other sites

You are somewhat correct.  LaunchPad and F2802x software are basically the same. 

 

There are two sets of software in there, one new and one old.  The old stuff is prefixed with F2802x_XXX.c.  The new drivers are simply the module name.c.  All these drivers reside in the common folder. 

 

The new driver (i.e. i2c.c) is in fact untested.  I was working to get this done before release but this is one of the items that slipped through the cracks.

Share this post


Link to post
Share on other sites

Ok, now I am really confused. When I look into controlSUITE I see this folder: C:\ti\controlSUITE\device_support\f2802x\v210. This makes me think that the drivers are stable and in version 2.10. You tell me that some (or many?) of those drivers are untested :o

 

Where is it documented which drivers are tested and which are not? Or do we have to guess? And why does TI release untested drivers at all?

 

I really appreciate your help but I have the impression that you are the only engineer at TI who really cares about the C2000 and who is doing all the development for the hardware and for the software.

 

Released but untested drivers for the main MCU modules are something that really scares me. I really hope that TI does not target only amateurs with the C2000 MCUs. At least the things I see so far are far away from professional.

 

Regards,

Anguel

Share this post


Link to post
Share on other sites

Anguel,


Perhaps untested is not the right word...I think incomplete better describes the state of the I2c driver.  The other drivers are in fact tested and working, but are relatively new.  As with any new software we expect to find some bugs.  Please let me know if you find anything that I can improve/fix.

 

The C2000 LaunchPad is my baby (so to speak), and I do everything I can to support and improve support for it.  Other than the lack of a complete I2c driver, what do you find unprofessional about the C2000 LaunchPad.

Share this post


Link to post
Share on other sites

Thank you Tray. It is always a good thing to be able to discuss problems with someone like you and I am happy that you really care about your product.

 

I received your board yesterday and hope to be able to get started soon. Unfortunately, we are a small company and have many other projects running in parallel. What I really liked about your board is that it is very inexpensive and compact and has opto-isolation and an FTDI chip. And the C2000 chip also seems to be very nice. We plan to develop some electronics devices with it. Normally in our designs we will interface other SPI and I2C chips and therefore I was hoping for robust drivers, I got the impression that the Stellaris MCUs have wonderful drivers and somehow expected the same from the C2000 which does not contain so complex hardware. Additionally, TI now offers so much ready-to-go and integrated stuff with Concerto (which includes a C2000) and TI RTOS. Therefore I am now very confused that the basic drivers on the C2000 do not work reliably.

 

Previously I wanted to use a PIC32 board that has USB & Ethernet on board, but unfortunately it turned out that getting this to run reliably in software will simply take too much time we don't have. And IMHO software solutions are still not as robust as external chips like the FTDI. We are using the same FTDI chip on an FPGA board and like it. Besides that, Microchips USB and TCP/IP stacks are not completely bug free, although I must say that their complexity is not comparable to simple I2C drivers...

 

So is there any chance that the I2C drivers will work in the current state they are when you say that they are incomplete? I was really hoping that they will at least do something, as there is even an I2C EEPROM example included. What purpose should that example have if the drivers do not work?

 

Regards,

Anguel

Share this post


Link to post
Share on other sites

Hi Trey,

 

1. I recently posted a similar topic to this thread on the TI E2E forum at http://e2e.ti.com/support/embedded/bios/f/355/t/277108.aspx. Basically, I am trying to find out if there are plans for higher-level Mware style driver library APIs (part of TI-RTOS perhaps) for either F28027 or F28069 Piccolo in the works. The reply I got from Todd Mullanix was that completion of support for F28x drivers (particularly for TI-RTOS) is lower priority than driver library code for ARM, TIVA and Concerto.  

 

But now that I have searched the ControlSuite documentation a bit more, I see that there is an existing a set of driver APIs for the Launchpad F2802x Peripheral Driver Library which is not yet present or ported to the F2806x Piccolo. The F28069 Mware library for F28069 only supports PIE, Systick, UART and USB drivers currently. I think that the F28069 Piccolo driver library support needs improvement.   I think it is important to have a complete driver library supported on all the F28x chip platforms and available regardless of whether some developer wants to adopt the TI-RTOS or not (in my case I am using the Quantum Leaps QP platform for development). My point is that the driver code is useful even if an alternate kernel solution is used. I see that some of your drivers for the F2802x Launchpad Peripheral Driver Library are more formal driver API abstractions (rather than just sample code such as provided in the ControlSuite example code and header files. 

 

2. Like Anguel, I also would like to see the availability of tested I2C driver code and a revision to the F2802x Peripheral Driver Library documentation to include this I2C driver API. I'm also somewhat surprised that many of the C2000 ControlSuite user guides and manuals are not unbundled and available online as separate SPRxxxx PDF files (i.e. the developer has to download the entire ControlSuite to get the documentation). For TivaWare, StellarisWare and the CC2538 families, the Peripheral driver library guides are available as separate downloads from ControlSuite.

 

3. Are there any suggestions you may have if I attempt to port any of the F2802x drivers you have developed to the F28069 Piccolo ControlStick or ControlCard? Which ones would have to be changed for compatibility with F28069 on-chip peripherals? I assume that PWM and eCAP drivers might probably have to change because the F28069 uses the newer ePWM and eCAP modules instead of the older 281x Event Manager based-design. In addition, I assume that there may be driver changes to support the SOC (start of capture) based ADC instead of the older sequencer-based design. There may be other changes (memory map?) of which I am unaware. Please let me know if you have any other porting suggestions.

 

4. Also, are there F2802x examples which use the new driver-style APIs rather than the older header files, or do all the examples still use the older headers.

i.e. I am looking for complete examples which use something like the following ...

//Perform basic system initialization
WDOG_disable(myWDog);
CLK_enableAdcClock(myClk);
(Device_cal)();
//Select the internal oscillator as the clock source
CLK_setOscSrc(myClk,CLK_OscSrc_Internal);
//Setup the PLL for x10/2 which will yield 50Mhz=10Mhz or10/ 2
PLL_setup(myPll,PLL_Multiplier_10,PLL_DivideSelect_ClkIn_by_2);
//Disable the PIE and all interrupts
PIE_disable(myPie);
PIE_disableAllInts(myPie);
CPU_disableGlobalInts(myCpu);
CPU_clearIntFlags(myCpu);
rather than the older header version - e.g. 
// Step 1. Initialize System Control using example function is found in the F2806x_SysCtrl.c file.
InitSysCtrl();
// Step 2. Initalize GPIO using example found in the F2806x_Gpio.c file
InitGpio();
// Step 3. Clear all interrupts
DINT;
// Initialize PIE control registers to their default state as found in the F2806x_PieCtrl.c file.
InitPieCtrl();
// Disable CPU interrupts and clear all CPU interrupt flags:
IER = 0x0000;
IFR = 0x0000;
.
.
.
 

5. Since you are a TI developer who has developed some of the F2802x family drivers, I thought that you should be made aware of my interest in ongoing C2000 Piccolo driver library support and improvements. Please let me know if there are further releases of driver code planned or in the works!  

 

Cheers,

Gordon

Share this post


Link to post
Share on other sites

Gordon,

 

I appreciate the feedback and couldn't agree more.  Let me expand on a few point to let you know where we are going:

  1. The drivers that are available today for F2802x and LaunchPad were actually borrowed from MotorWare (another SW product for C2000 similar to controlSUITE but motor drive specific).  Originally the plan was to release these across all of the C2000 devices.  The F2806x drivers in the MWare directory are there mainly because of the USB peripheral on this device.  The USB is very similar to what was on the Stellaris devices so I ported  some of that software over to support that peripheral.  It was never intended to be a full driver API, only just to enable easy porting of the USB examples.
  2. I agree that I need to spend more time on the I2C driver.  Resources have been somewhat limited and my real job involves soooo much more than just supporting LaunchPad.  Funny story though, When the LaunchPad was released I had developed a controlSUITE-Lite package which only contained the LP software.  I wanted to release this, but some thought it would confuse customers so it was never released.  Fast-forward 1 year, people are starting to realize what a pain it is to download 800MB+ of SW just to get 10MB of what you need.  This is being seriously looked at and I would expect a resolution to this in the future.
  3. I thought the F2802x and F2806x had the same ADC and similar PWMs, but I could be mistaken (I'm more a SW guy).  That said there are already drivers in this same style for F2806x in motorware.  You can download this today from the ti site here.  The directory structure is different from controlSUITE so you may have to massage the include paths in the files, but otherwise the drivers in there should work out of the box.
  4. The latest F2802x device support has the full complement of examples in the driver style, but I had removed the header files style examples.  There is another release in the works which will include both the header file and driver API examples to show how the two correspond.
  5. I appreciate your interest and will let my management know.  We've kinda been hung up on the header file structures, but are moving toward developing real drivers for all our devices.

I'm curious which drivers you prefer more?  Stellaris/Tiva style or what is currently available for F2802x (MotorWare Style)?  Going forward its looking like we will develop Tiva style drivers for our new devices.  I don't think we will ever formally release drivers for the devices which have already been released, but new devices will definitely have a full driver library.

 

Thanks again for the feedback!  We are constantly trying to improve and make our devices easier to use.

Share this post


Link to post
Share on other sites
Hi Trey,
 
Thanks for your response. I'll address your comments (your original replies are in BLUE).
 
1. The drivers that are available today for F2802x and LaunchPad were actually borrowed from MotorWare (another SW product for C2000 similar to controlSUITE but motor drive specific).  Originally the plan was to release these across all of the C2000 devices.  The F2806x drivers in the MWare directory are there mainly because of the USB peripheral on this device.  The USB is very similar to what was on the Stellaris devices so I ported  some of that software over to support that peripheral.  It was never intended to be a full driver API, only just to enable easy porting of the USB examples.

 

Thanks for the great background information and the Motorware link (I was unaware that there was a set of similar drivers for the F2806x in the Motorware package). The complete F2806x driver GPIO enumerations for the GPIO1-GPIO58 in gpio.h is already one area where I see that the Motorware drivers improve upon the Launchpad gpio.h from the F28027 (which I had considered porting). I will do a diff comparison between Launchpad F2802x drivers and Motorware F2806x drivers to make sure I understand all the nuances of the differences.
 
2. I agree that I need to spend more time on the I2C driver.  Resources have been somewhat limited and my real job involves soooo much more than just supporting LaunchPad.  

 

I understand the resources may be scarce and your bandwidth is precious. Having said that, it would be great if at some point you might be able to get around to the i2c driver for the F28027 Launchpad just to complete the set.
 
Funny story though, When the LaunchPad was released I had developed a controlSUITE-Lite package which only contained the LP software.  I wanted to release this, but some thought it would confuse customers so it was never released.  Fast-forward 1 year, people are starting to realize what a pain it is to download 800MB+ of SW just to get 10MB of what you need.  This is being seriously looked at and I would expect a resolution to this in the future.

 

Yes, bundling everything in ControlSuite is just a confusing as an unbundled approach. I would advocate at least something in between -  using platform EVM devkit bundles (e.g. for the Launchpad) as long as all platform or device resources can be found within each bundle. This might mean incurring some redundancies where the same resources/files/tools are replicated in multiple bundles or places (but perhaps you could eliminate redundancy and include replicated resource instances by using references or links on your website). The one big advantage of having most C2000 stuff in ControlSuite was that I could search for everything in one place. As it was, I still missed finding the F28069 driver libraries in the Motorware suite bundle since it was separate from ControlSuite. 
 
3. I thought the F2802x and F2806x had the same ADC and similar PWMs, but I could be mistaken (I'm more a SW guy).  That said there are already drivers in this same style for F2806x in Motorware.  You can download this today from the ti site here.  The directory structure is different from controlSUITE so you may have to massage the include paths in the files, but otherwise the drivers in there should work out of the box.

 

Actually, I had a good look at all the various c2000 migration guides including the following:

spry208.pdf   - TMS320xF24xx to Piccolo F280xx Migration Overview

sprabj2.pdf    - TMS320F2802x and F2803x to TMS320F2806x Migration

sprab40b.pdf - TMS320F280x to TMS320F2802x or 2803x Migration

spraaq7b.pdf - TMS320x281x to TMS320x2833x or 2823x Migration

spraa58a.pdf - TMS320x281x to TMS320x280x or 2801x or 2804x Migration

Particularly in the sprabj2.pdf doc (F2802x/03x to F2806x migration), it would seem that there really aren't many differences between the F2802x and F2806x for on-chip peripherals. The ADC and ePWM/eCAP are pretty much the same. It is the older C281x devices that had the older EV event manager ePWM/eCAP and the older style ADC (sequence based). The DMA and CLA on the F2806x are really the biggest diffs.

4. The latest F2802x device support has the full complement of examples in the driver style, but I had removed the header files style examples.  There is another release in the works which will include both the header file and driver API examples to show how the two correspond.
 

 

It would be great to have both sets of examples in the workspace - project names might have to be renamed and qualified to avoid naming collisions in the workspace. I already created a driverlib_F28069 project for the supporting library for the examples. In my CCS workspace, I renamed the driverlib project for the F28027 to driverlib_F28027 so that there is no namespace collision. By the way, the CCS project import feature would be really improved if they would allow imported projects to be renamed at import time (rather than just greying out imported project names which collide with projects already in the workspace -- a suggestion for the CCS team. Right now, I have to first rename an existing project in my workspace before importing a new project which might have a conflicting name.
5. I appreciate your interest and will let my management know.  We've kinda been hung up on the header file structures, but are moving toward developing real drivers for all our devices.

 

 This comes back to my point about the usefulness of driver libraries - they are useful by themselves without needing to bundle with a DSPBIOS/SYSBIOS/TI-RTOS. I prefer the improved encapsulation of driver APIs over the older C2000 sample code. The older sample code might be useful for learning about the chip, but proper driver APIs and driver libraries are more useful to link with embedded code for production commercial projects

6. I'm curious which drivers you prefer more?  Stellaris/Tiva style or what is currently available for F2802x (MotorWare Style)?  Going forward its looking like we will develop Tiva style drivers for our new devices.  I don't think we will ever formally release drivers for the devices which have already been released, but new devices will definitely have a full driver library.
 

 

I'm not sure yet whether I prefer the Stellaris/TivaWare style driver APIs or what F802x MotorWare/Launchpad Style driver API.  I'll spend more time having a look at this over the next week and get back to you on this. BTW, I fully understand that it would only make sense to fully release drivers for the new devices (without doing a lot of work to back-propagate the same style drivers to older chips). 
 
Thanks again for your help.
 
Regards,
Gord

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...