Give TI Your Feedback on C2000

ChrisClearman said:

- provide "compact" documentation. Now I need 10 different pdf for a 28035 (main datasheet, and separate datasheet for every peripheral) . that way i've to jump between documents, and I have to check for updates for every document.. 

controlSUITE solves the bulk of this (www.ti.com/controlsuite ) by pointing you to all the latest material.  But this is a good idea, we can look at adding a revision number / date here so you can easily see if anything has been updated recently.  Having a single document makes revisions and errata a complete pain, we really don't want to go down this path.

I just tried controlsuite, but I got an error when I install it. Error is (translated form italian) "impossile to open installation package. Verify presence of ackage and to have access rights or contact application provider to verify thay windows installer package is valid".

For the documentation, I think you should at least add registers map in the main datasheet and link to the specific datasheet in every section. 

ChrisClearman said:

- provide libraries for all peripheral, and document all options in example code (maybe in comments), not just the options used in the example. 

Can you expand on this?  We have examples for every peripheral, APIs for most common modes, and Macros for application specific modes.  Obviously we can't include an example for every single mode option on every single device.

for 28035 I found just examples package, that is a good starting point. When I modify example to match my duty, I have to jump between datasheet and code to find registers to set. When you came back to the project after some month, you have to study again datasheet to avoid missing something

It would be useful to have a template showing all available, a kind of quickguide and checklist in the same time. 

I did it for myself for some peripherals I worked more, it is a part of the one for the PWM. 

[..]

// ----- Counter-Compare Submodule Registers -----

// CMPA: Counter-Compare A Register (CMPA)

// CMPA 16bit, The value in the active CMPA register is continuously compared to the time-base counter (TBCTR). 

// When the values are equal, the counter-compare module generates a "time-base counter equal to counter compare A" event.

// It can trigger events like toggling pwm output pin, starting a conversion (SOC) or an interrupt. See AQCTLA and B regs. 

// Can be shadowed (default) using CMPCTL[SHDWAMODE].

// CMPB: Counter-Compare B Register (CMPB)

// see CMPA. 

// NOTE!! that CMPB can trigger the _SYNC event_. see TBCTL[SYNCOSEL].

// CMPCTL: Counter-Compare Control Register (CMPCTL)

// SHDWAFULL Counter-compare A (CMPA) Shadow Register Full Status Flag (This bit self clears once a load-strobe occurs)

// SHDWBFULL Counter-compare B (CMPB) Shadow Register Full Status Flag (This bit self clears once a load-strobe occurs)

// 0= CMPB shadow FIFO not full yet ; 1 fifo is full, nex write will overwrite nex shadow value

// SHDWAMODE Counter-compare A (CMPA) Register Operating Mode

// SHDWBMODE Counter-compare B (CMPB) Register Operating Mode

// 0= Shadow mode. Operates as a double buffer. All writes via the CPU access the shadow register.

// 1= Immediate mode. Only the active compare B register is used. All writes and reads directly access the active register for immediate compare action.

// LOADAMODE Active Counter-Compare A (CMPA) Load From Shadow Select Mode. This bit has no effect in immediate mode (CMPCTL[SHDWAMODE] = 1).

// LOADBMODE Active Counter-Compare B (CMPB) Load From Shadow Select Mode. This bit has no effect in immediate mode (CMPCTL[SHDWBMODE] = 1).

// 00 Load on CTR = Zero: Time-base counter equal to zero (TBCTR = 0x0000)

// 01 Load on CTR = PRD: Time-base counter equal to period (TBCTR = TBPRD)

// 10 Load on either CTR = Zero or CTR = PRD

// 11 Freeze (no loads possible)

// CMPAHR: Compare A High Resolution Register (CMPAHR)

// CMPAM: Counter-Compare A Mirror Register (CMPAM)

// If shadow active, reads give the actual "real" CMPA, while reading CMPA it gives back the  shadow register value. 

// Writing behaviour is the same as CMPA. 

// Shadow is active as default. If disabled, CMPAM and CMPA ae equivalent. 

// NOTE: CMPBM doesn't exist!! 

// CMPAHRM: Compare A High-Resolution Mirror Register (CMPAHRM)

// ----- Action-Qualifier Submodule Registers -----

If you are having trouble with your controlSUITE install

We placed the entire controlSUITE Image (the folder structure that controlSUITE installer creates) into a zip on ti.com.  Simply download and extract to C:\, then run C:\ti\controlSUITE\controlSUITE.exe

 It's currently linked in the controlSUITE product folder

http://focus.ti.com/docs/toolsw/folders/print/controlsuite.html#Support Software

Good idea on the tool. Let me discuss with the SW team.  Are you aware that for motor control and power supplies we have APIs (macros) for different PWM topologies already created?  Look at the Libraries - Application Libraries for the examples.

Hello,

I wood like to see a hardware function for averaging of A/D-converter samples for C2000 MCU. It would be very usefull for noice reduction of A/D samples. For ex.: now I need to make software averaging (AVG(void).

At maximum A/D speed I need to call ISR function AVG() at ~150kHz speed.  So that only averaging  takes a much CPU time. May be it is possible to make it by hardware?

 Best regards, Alexander.

Hi Loriano,

Yes you right. I make some inaccuracy, I mean to make this option for C2000 without CLA (for ex PICCOLO F2802x). Some time to reach only one noisy bit it is need to make 10 or more averaging-out. So if we use 12-bit A/D it is possible to use last 4 bit  to make 16 hardware sum operations.

Bye.

It would be very helpful for us if internal SARAM size increased

Piccolo has an excellent ADC, PWM and Analog comparator. I think that Texas should keep this peripherals and change the C28x CPU for the Cortex-M4F.  

Tim,

Look for an announcement on 1/11 that should make you happy :)

Ari,

Can you please expand on your reasoning?  We already have a native FPU instruction set (for the past 4 years) and a suite of SW and examples.  We also are already integrated with meta tools such as Simulink and VisSim.  

As for performance on DSP algos, the 28xFPU is 2-3x faster than M4F on 16/32-bit FFT and 7x more code efficient.

ARM MCU has its place (communications, general purpose control).  But if you want maximum performance you can't use a general purpose architecture, even one that will have an FPU extension.

But if you have decided on ARM, TI's Stellaris family has some new additions coming in 2011 which will be a nice compliment to the Piccolo product line.

You hit the spot!

We moved from the legacy TMS2000 architecture to a Cortex-M3 based solution in my company and we are not looking back. The only thing we miss from the TMS2000 is the fast ADC. The CM3 uses like 5% of the power of a TMS2000 in standby running with all peripherals on.

Freescale is coming out with the Kinetis chips that implement the CM4 and have also a versatile PWM peripheral. If TI could come up with something similar that would be bliss.

 "The CM3 uses like 5% of the power of a TMS2000 in standby running with all peripherals on."

- The 5% is simply not true, and it also has nothing to do with the CPU core (the size of the two cores is reasonably similar).  Power use is dictated by process technology, flash technology, number of gates, and special power domains.  For C2000 applications historically standby power use has been almost non existent, and active power use would be dwarfed by the power stage.  Obviously this is changing as people become more green aware, try to squeeze out every % of efficiency, and Piccolo class devices are being used in lower power conversion topologies (Telecom/Server DC-DC, solar DC-AC, Electrified Transportation, etc).  We are working on these items for next gen devices.

"Freescale is coming out with the Kinetis chips that implement the CM4 and have also a versatile PWM peripheral. If TI could come up with something similar that would be bliss."

- TI Stellaris will also have CM4F support in products in 2011.  I recommend you discuss with your local TI Sales Person.

"The 5% is simply not true"

Well, I should have been more specific. 5% was off the top of my head when I first measured the differences at the beginning of our development. But this is what I currently get with our very similar products:

- 12V power supply reading of board based on TMS320F2809 @ 100Mhz, just running the main loop of our app and IOs (LEDs): ~600mW

- 12V power supply reading of board based on STM32F103 @ 72MHz, running: PWM, ADC, USB, RTC, IOs: ~63mW

Both boards use a high efficiency switcher for the voltage input and it's a different device on the 2809 since we also need 1.8V. Also, to be fair, we are taking advantage of the CM3 sleeps modes but not in the F2809.

63 / 600 ~ 11%. So true, not 5% but quite an improvement. Unfortunately I am not able to measure directly the exact device consumption in the current board designs. I guess Flash technology and sleep modes play a big part in the difference.

Regards.

Chris,

Interesting to see this post getting lit up again...

Most of the c2000 users are there because of the ADC and ePWM. I'd like to see 'from scratch' doc and demo project of a minimal DSP/BIOS (maybe SYS/BIOS) that would fit onto the Piccolo ControlStick, run using the Core License CCS v4x (read, free setup), allow basic debugging (ie. runs out of ram, xds100). In moving from c6000 to c2000, the BIOS docs are sub-par, the only example, spra958 is not good enough. A bare DSP/BIOS for the Piccolo/Delfino would be great for those that need to separate ADC tasks &/or ePWM tasks with a basic handler.

TI makes you work 'software' harder to use these great parts. Listen to the Luminary guys - they figured it out.

Steve

For several years, we have been using the 150MHz TMS320F2812 in a motor control application.  Our board has 512K x 16 external RAM and 512K x 16 external Flash connected to the TMS320F2812.  Now we are in the process of migrating this product to the TMS320F28035 because of cost and size constraints.  We are finding this migration very difficult because of the limited amount of RAM in the TMS320F28035.  Here is our wish list for the TMS320F28035, listed in order of highest to lowest priority:

- more RAM; 10Kx16 is not enough; would like (at least) 512K x 16

- more FLASH; would like 512K x 16

- Faster operation; would like at least 150MHz operation, preferably 300 MHz

- Internal EEProm

- FPU (unrelated to the CLA)

- Double-Precision FPU (see previous line)

- Ethernet connectivity

- Integrated CAN transceiver (TI SN65HVD233D)

With the first 4 line items above, migrating to the TMS320F28035 would have been a fairly simple task.

Eric,

A couple of questions/comments

- Half of meg of on-chip RAM would be VERY expensive. SRAM is the largest digital area on our chips.  Even as we shrink the process it is still a large adder, especially when only a small percentage of customers would use or pay for that much (everyone always wants just enough, never more)

- Why double precision FPU?  We have this capability but when we ask our current customers they nearly all say it doesn't bring them any / enough value.

Most of the other items will be addressed in the first 6 months of 2011.

Advantages of Cortex-M4 or M4F:

float intruction in one cylce. C28x, 2 cycles.

32x32->64 bits in one cycle. C28x, 2 cycles. (when result in ACC)

Allow up to 120 MIPS running from flash. (C28x need wast sram to run above 60 MIPS)

Nesting interrups by hardware.(C28x need wast ISR cycles to do it)

Much more hardware breakpoints.

More memory and CPU speed for the same cost.

Less power consuption.

Byte addressing, less memory wast with strings, easy to port communications stacks.

Lower cost per MHZ an per Memory.

I think C28x is only better than Cortex-M4 for the Delfino family, because Cortex-Mx run slower when the code need to run from SRAM. ( above 120 MIPS)

Ari,

On Float Perfromance CM4F vs C28-FPU: I think you are missinterpreting the cycle information. There are different ways to document such information, the real data is often in the fine print. You need to consider pipeline stalls and combinations of instructions.

Both the CM4F and C28-FPU take 2 pipeline cycles to perform a floating-point MPY (similarly with ADD/SUB). Both of them can issue a MPY (ADD or SUB) operation every cycle. If the next instruction uses the result of the previous instruction, then you take a 1 cycle stall.

But this is where the similarity ends. The big difference between the C28-CPU and CM4F is the ability to perform say a MPY + ADD (MAC) + LOAD or STORE operation in single operation (2 pipeline cycles, 1 cycle execution). The CM4F cannot do such operations. It takes 3 cycles to do a MAC, the Load and store is a seperate operation which takes 2 cycles (on C28 load and store operatiosn are single cycle and you can convert integer to float as you load in a single cycle). There are many such differences that add up in real algorithms.

We recently completed the following DSP benchmark after someone obtained the following CM4 benchmark data (from one of our competitoes) and asked us to compare. The result pretty much highlights the DSP math performance capabilities between the two cores:

In the above specific benchmark, the C28-FPU is almost 3x the performance of CM4F and it is also 25% less cycles then the 16-bit Fix-Point CM4F capabilities.

There will be variations based on algorithm types, but what the above highlights is that reading data sheet cycle numbers is not a reliable guide on performance :-)

As for the rest of your inputs, they are valid (although current Flash performance is around 80MHz, not 60MHz) but even so, the CM4F has to run at much higher MHz to keep up.

But next year there will be announcements coming on new devices that will address many of the above issues plus some new innovative capabilities.

Cheers,

Alex T.

Ari,

Just to comment on some of your other notes

Allow up to 120 MIPS running from flash. (C28x need wast sram to run above 60 MIPS)

CC: What CM4F (or any CM) implementation is running 120 MHz 0 wait-state flash? I don't know of any. Regardless, this would be a flash implementation, not a CPU feature.  The C2834x runs 300 MHz 0-wait from RAM. The 28x architecture will always be able to run faster max MHz due to the deeper pipeline.

Nesting interrups by hardware.(C28x need wast ISR cycles to do it)

CC: You can nest interrupts on the C28x w/o wasting the ISR cycles, see here: http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/t/21121.aspx

More memory and CPU speed for the same cost.

CC: 28x implementations have better analog and more powerful PWMs.  If you are just buying on cost per KB at a given MHz, sure.

Less power consuption.

CC: As mentioned above, this has nothing to do with the CPU, it's the device implementation. Yes, 28x devices to date have not been competitive in this respect.

Byte addressing, less memory wast with strings, easy to port communications stacks.

CC: Absolutely, a place where Cortex-M shines

Lower cost per MHZ an per Memory.

CC: If all you care about is CPU speed and K bytes there are certainly many options for you, and ARM Cortex is a clear leader.  I hope you'll consider TI's Stellaris product line.

Hello,

The ADC with its triggering capabilities, the high resolution PWM and the CLA are unique in the C2000 family. Without these capabilities it would be imposible to control a high frequency power supply. The best microprocessor depends on the application.

I would like a Piccolo B with some more RAM and more serial interfaces. A slow sigma delta 16-bit ADC would be really nice.

Max

Chris.

I'm sure that the Piccolo is by far the best DSC for digital power applications. Thanks to its ADC and ePWM. But I think that would be even better if the CPU was a Cortex-M4 running at 80MHZ instead of C28x running at 60MHZ.  

Ability to DMA from ECAP registers.  Those ECAPs are great; I use them all the time, but I often have to babysit the registers so I don't miss anything.  Also, for extra credit, if you had some kind of hi-res timestamping capability, the input equivalent of the hires PWM, (possibly using similar hardware?) then the medical/scientific community would totally eat it up.

I also vote for an integrated ethernet MAC, but you would need to be careful about this.  You would have to support IEEE 1588, and make sure your MAC/PHY fully supports the various industrial ethernet specs still swarming around.

Then there is slave capability.  Imagine another processor being able to take over the external bus, and then use it to transfer data into shared memory in the C2000.

Jim,

curious, what would you use High-Res timestamping capability in the medical/scientific area?

PS: The technology exists, stay tuned :-)

Cheers,

Alex T.

Alex,

Generically, imagine scanning a beam of energy -- laser, x-rays, electrons, etc.-- over a surface and logging the backscattered photons or what-have-you to create an image.  You need to know the exact time of arrival (say, to 0.1nsec) in order to know where the scanning beam was, and therefore what part of the surface emitted the photon.  This is not some bit of esoteric science; it's the future of non-invasive imaging.

Specifically, check out places like Picoquant:

http://www.picoquant.com/

and Acam:

http://www.acam-usa.com/

for scientific applications.  They make a pretty penny in the time-to-digital converter market.

Moving back into industry and the C2000's target markets, a good frequency counter is as important for an industrial microcontroller as a good ADC.  More important, I would argue.  Whenever I have to measure a sensor, be it position, temperature, pressure, etc., if at all possible I will convert the parameter to frequency, because I know that I can get that frequency across a noisy factory floor, through galvanic isolation, etc., and into my microcontroller, and it will still be the same frequency that it started out at.  The C2000's inability to DMA from ECAPs was a bit of a bummer, but I've managed to work around it, for the most part.  The Delfino has six of the best frequency counters out there.  I didn't come to the C2000 because of the ECAPs, but I'm staying here because of them.

-Jim MacA.

This is also my biggest issue with these parts - prototyping stock (and forget about production) is non-existent. 

Hi-speed debugging / data-logging via JTAG - XDS560 support (unless it exists already).

Tim

- A real compare unit. Now I have to sacrifice PWM1 for compare, because it is the only channel that can synchronize ecap. Also the PWM timer is only 16bit so I have to use prescaler to be able to make 50Hz PLL.

- More RAM

-To be able to program CLA with C

- CCS4 crashes too often. I really hate JAVA.

Given the architecture of the CLA, I would not waste even 1 minute on providing the capability to program the CLA in C. Given the applications for the CLA, it would actually take more effort to program in C (and evaluate the compiler's output) and it wouldn't eliminate the need to debug at the assembler/pipeline level. Yes, those who can't or don't want to learn to use assembler need some help to be able to benefit from the CLA but automatically translating C to CLA Assembly isn't the answer. A better solution would be to put some effort into providing a LARGE number of example CLA program snippets and examples that communicate back and forth between C28 and CLA code. Also a MACRO library for things like SQRT might be useful. A good CLA "cookbook" would be far more useful to real world CLA applications than a nearly useless C compiler and would provide a much more satisfying meal.

JHi said:

- CCS4 crashes too often. I really hate JAVA.

Especially when you are debugging in real-time your motor control application and it decides to garbage collect... What is that burning smell?!?!

Wally Ritchie said:

A better solution would be to put some effort into providing a LARGE number of example CLA program snippets and examples that communicate back and forth between C28 and CLA code. Also a MACRO library for things like SQRT might be useful. A good CLA "cookbook" would be far more useful to real world CLA applications than a nearly useless C compiler and would provide a much more satisfying meal.

Hi Wally,

If you haven't taken a look at the CLAmath library then I'd like to suggest it to you - it is in the controlSUITE (www.ti.com/controlsuite) download under

C:\ti\controlSUITE\libs\math\CLAmath\

We are looking into adding more; at this time in V3 there are quite a few building blocks for CLA in this library - including SQRT.

Let us know your thoughts.

Regards,

-Lori

JHi said:

- CCS4 crashes too often. I really hate JAVA.

Hi JHi,

If you would, please post your experiences with CCS on the code composer forum.  It will help the developers of CCS understand the issues and work towards resolution.  In particular if you can provide any log files that resulted from the crash it is very valuable information.

There were many updates made in V4.1.3 that improved the C2000 experience so if you have an older version, then I suggest updating as well. 

The CCS forum is here:

http://e2e.ti.com/support/development_tools/code_composer_studio/default.aspx

Information on providing log files is here:

http://processors.wiki.ti.com/index.php/Troubleshooting_CCS#Information_for_Support

Thank you

Lori

pbk said:

- CCS4 crashes too often. I really hate JAVA.