Give TI Your Feedback on C2000

For us, Piccolo B (28035) is already well-fitting.

What we could need is:

- Higher speed than 60MHz

- More internal RAM

- More flexible CLA RAM usage (actually it always uses 4K of the available 10k)

- eventually an external memory interface

- internal EEProm would be nice...

- all the above of course at the same power consumption and at a similar price as the existing 28035.... [;)]

It would be great to have a small flash sector to be used as parameter recording area, 32K is way to big to dedicate to it. I had to include a SPI flash memory (2K) to be used.

A eeprom area as Stephan already mentioned.

Marcelo

It would be nice to have RTC module.

Thanks for the feedback so far, I was about to think everything was perfect in C2000 land :)

Vasily
Re: Power Consumption
- Certainly understand the request, do you have any rough targets for active or standby?  With the flash process and the size of some of our high performance peripherals there are certainly challenges currently, but we have some things in the works.

Stephan
Re: Piccolo F2803x enhancements
- Higher speed (80? 100? 120?), more RAM, EMIF...got it. That's certainly a common request from F2803x customers and something we are looking at to fill out the higher end fo the Piccolo portfolio. (also requested often is a bit more flash 256-512KB and USB).

energy_freak & Stephan
Re: Small flash sector / EEPROM
- Another common request. Some technical challenges with the flash technology we currently use (large pump requires larger sectors for cost effectiveness) as far as very small sectors, but there is some good news as it relates to EEPROM. Have you seen this AppNote?: http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprab69
- To go along with this, we are very close to being able to update all of the F28xx datasheets for increased flash w/e endurance.  Probably to 50k typical.  It took quite a long time to run this qualification, but we are almost done.
- We of course are also looking at some new non-volatile memory options moving forward for C2000

Arefeen
Re: RTC module
- A semi-common request that we see from specific applications, and once we are able to reduce our overall power consumption it's certainly a must-have IMO.  I'm interested to understand the use case that you have today for this.  In what use case do you need to know how long the device has been in RTC mode?  Is this a raw timer, or do you want an actual calendar function built in as well?

Thanks, and please tell us more!

Chris -

A raw timer is utilized when a RTC module is not available. A common feature of many industrial drives is to keep trip history and a RTC module with real calendar is useful to implement an useful operational history. C2000 should seriously look at integrating RTC - IMHO.

We are using TMS320F28335, and the most welcomed enhancements would be:

- more RAM!

- even higher speed,

- higher speed SPI, 12.5MHz in Master-receiver is simply not enough,

- integrated USB,

- GPIOs with programmable drive strength and slew rate,

- maybe SDRAM od DDR memory interface.

About TMS320F28335 I was not satisfied with:
1. low onboard memory size( I think it has to be at least doubled in size)
2. relatively slow Flash(i.e. flash pipeline is not always can help). Flash size is OK.
3. Power consumption(but I already voted about this)

• Internal EEPROM. I am still wondering why this is not there.
• Improved Flash technology: faster execution and faster programming times. I feel like aging every time I flash a device.
• More internal RAM. 2x will do for me.
• Modern peripherals (USB).
• Cleaner peripheral design accompanied by adequate examples (eg I2C implementation is a mess, poorly documented and buggy).
• Improved debugger support. I guess the functionality is there, but emulators for the TMS are far more unreliable that for other architectures I have used (eg ARM - compare TI's trace implementation to theirs. What were they thinking?!).
• Better compiler support. Specifically, native byte access. It's OK if you want to support legacy code, but don't impose that on newer parts that can access 8-bit data and where you can recompile all libraries. This breaks any 3rd party library that assumes byte storage is possible.

All these are in the top of my list.

Thanks for the additional feedback. Most of this is not a surprise, and much of it is being addressed.

Interesting to see that it is almost all chip hardware related, very little tools, software or system applications.

Hello Chris

Well if you are looking for additional application ideas in motor drives area then C2000 should focus on parameter identification techniques for various motors so that the drive can self calibrate for vector control operation. Many industrial drives utilize auto-tuning and C2000 devices can greatly increase the speed and accuracy of this process.

hello Chris

From an actual system application point of view - C2000 application team can also look at crane systems. I believe C2000 devices will offer many benefits for these systems. I don't expect C2000 team to implement a complete crane system [:)] but if you study the system and show/implement various modules using C2000 then a system integrator can take those modules to shorten development cycle.

Okay, to add some tool-related requests:

- I would second the byte addressing request - this would reduce RAM usage and would enable code reuse.

- faster tool (compiler/linker) speed. Since moving from cgtools 4.1.3 to 5.x, the time for a make has nearly doubled. I know that many features are added, but the time waiting for the end of a build is really wasted and should be reduced.

Oh, and I forgot my vote for higher execution speed when running from flash: This is actually really poor and one reason for the request for bigger RAM - we simply can't live with the slow execution speed from flash for many routines and have to run them from RAM.

In addition, the datasheet should show the slower speed from flash somehow to prepare beginners - we were very surprised when detecting that the controllers execute only at 60..80% of their speed when running from flash.

I would like to see more training material to get people started, like the material posted for the "C2000 Piccolo One-Day Workshop".

To reply to some of the additional feedback posted.

Stephan,
- I've forwarded on your requests regarding bye access and compiler times. The byte access is tied to the architecture itself, and can't be undone, we'll look into the compiler times.
- Regarding flash speed, part of the penalty you pay is due to the deep pipeline, which allows us to run 100, 150, 200, and 300 MHz on some of the products, unlike some other 32-bit MCUs.  Part is the pre-fetch architecture that we have chosen as a good middle ground, and part is the inherent flash technology of the TI fab process used in the current F28x devices.  We are certainly deeply involved in new non volatile memory technologies which will accelerate access times.
- On the documentation topic, we probably should make it more clear in the datasheets themselves, or at least give some examples of waitstate usage. Much of it is code dependent, but we could give some examples on both sides of the spectrum.

Vasily,
- A small piece of flash/eeprom/OTP is often requested. We're figuring out a cost effective way to do this with our process technologies.

eischerik,
- Any specific topics?  We are rolling out new 1/3-day workshops on Piccolo and Delfino next year. We have a new in-person DPS workshop that's running this week in Irvine. A Motor Control workshop is planned for early 2010, with the intent of breaking it into modules and posting as videos.
- I am still trying to get the Delfino/F28335 1-day workshop material posted on-line
- Any other feedbak on the content and method for delivery is appreciated

Chris,

- I appreciate the effords regarding flash speed, documentation and compiler execution time.

- I don't understand your comment regarding byte access. Of course the architecture itself only supports 16 and 32 bit accesses, but it should be no problem for a modern compiler (with some processing overhead) to address bytes by accessing 16 bit and taking only part of it!? It is clear that it can't be done without overhead and that this should be remembered by the software developer, but it is not impossible.

I know of other 16/32 bit architectures (avr32) where byte access is done only via compiler, without architecture support, via bitwise AND and OR operations. This should be possible for the C2000 compiler, too!!??

Stephan,

From our compiler experts:

Adding an 8-bit C integer type is very much a non-starter on an architecture without byte addressability.  The crucial point is that an implementation would be required to support pointers to entities of such an 8-bit type, even though hardware addresses are for 16-bit words.  You would need to add an extra bit (indicating high-byte or low-byte) to pointers and then interpret all the accesses through these plus-extra-bit pointers.  That is obviously a disaster both in terms of implementation and run-time performance.

In case you are thinking maybe they could do without pointers to 8-bit integers, keep in mind arrays use pointers, so no arrays of 8-bit data either.  And there are some other complications.

If you are doing basic accesses to bytes there are a couple of compiler intrinsics that can help:

__byte() and __mov_byte() described in Section 7.4.4

http://www.ti.com/lit/spru514

Cheers

- Lori

After a quick look on the web it appears to me that avr32 has a byte-addressable memory.  As Chris's message mentions, byte-addressability is the key to providing an 8-bit integer type in C.

Some questions/comments:

1) Note I am assuming you are asking about having an 8-bit integer type, so that among other things one can easily port C code written for ARM to C2000.  If you mean the ability to pluck an 8-bit bit-field from a structure, the TI compiler can already do that (using masking and shifting).

2) Am I right about the byte-addressable memory on avr32?  I'm not sure why ANDs and ORs would be used for byte accesses since at least the latest avr32 seems to have byte loads and stores available.  Perhaps that was a later addition to the ISA.

3) If you (or anyone else out there) knows of a 16/32 bit architecture with a word-addressable memory (like C2000) and that supports what you are talking about I would be very interested in hearing about it.

I think it wouldn't be difficult to define a "byte" type and trap any byte usage or assignments as 8-bit accesses. If it *is* possible to do it manually with the __byte intrinsics (I do it all the time with my data structures) then the compiler should be able to do that internally. I know that in the end the byte values will end up in a 16-bit register and the pointer type could end up twice the size, but that is OK considering the space savings when the bytes are bundled in memory.

I even have __byte macros for my bundled ASCII strings and believe me, it makes a lot of difference when you have to store them in RAM (one project wouldn't even be possible without them).

Regards.

Paul, you got me.

I got the avr32 info from a fellow worker while discussing portability issues. Now after having a look at the av32 datasheet myself, I have to agree with you - the avr32 is a 32 bit architecture, but with byte (8 bit) addressability.

So sorry for the confusion. I can see your point regarding pointers to 8 bit values.

I would like to know  16/32 bit controllers/architectures with word-addressable DATA Memory other than C2000.

I think most others covered h/w ideas (I'll echo more RAM, RTC, USB). My beef with this line of DSP's is the code. I'm starting to warm to CCS v4, but most of the TI example code is substandard. I can't believe how many times we've had to rewrite DSP drivers for I2C, SPI, EMIF DMA, etc. Instead of offering clean documented callable functions for the embedded controllers per DSP, we find messy example projects. I'm using the f28335, and the I2C example project is disappointing, to say the least.

The TI software community should buy a cheap Cypress PSoC3 or 5 kit, install the IDE (Creator or Designer), and see what happens when you enable the embedded I2C controller.

Steve

Totally true. Or see how Atmel provides the at91lib library for their ARM devices. They provide a clean, common C API to access all the components, memories and peripherals of their chips, with proven working code.

Example code that shows how to use the ADC/DACs on the C28343 Experimenter Kit would be HIGHLY appreciated, been waiting for them for like 5 months or something (http://e2e.ti.com/forums/t/7412.aspx).

Robin.

Robin,

Matthew just posted an example of external ADC interface in this thread http://e2e.ti.com/forums/t/7412.aspx

As for the SW topics, you'll see a renewed focus from C2000 in 2010.  We have some things in the works. You'll see phase 1 shortly.

Hello,

I would like a 28035 with:

*Faster CPU clock: 100MHz.

*More serial ports (SPI and UART).

*More RAM (2x).

*More flexibility in the CLA: be able to use less RAM (a smaller block), access to other peripherals.

*Easier debugging for the CLA.

Thanks,

Max

Cool Javelin said:

I would like to see fewer "sticky" threads. and/or more threads on a page. Maybe a way of selecting the number of threads on a page with the default being 100.

Now, when I look at the threads, most of them are sticky, and to find new posts, I have to leaf through the pages.

Mark - I agree the new format of the forums is making it more difficult to find the new posts after the announcements and sticky posts.  We like to use those to emphasize releases or other announcements we feel are  important but I do understand the need to keep them to a minimum.   There has been some internal discussion regarding this part of the layout with the web team.

Cool Javelin said:

Also, at the top, having some counters for the number of threads shown on the page, and the total number of threads in the subsection of the forum would be helpful.

I will feed both of your suggestions back to the web team. Thank you for posting.

Happy coding :)

Regards

Lori

Are you using the 2802x or 2803x? On the 28035, you can use the LIN bus as second serial port.

Piccolo roadmap suggests that future Piccolo will have less performance than the TMS320F28035. Is that true? Will new Piccolos have 130nm silicon technology?

I think that Piccolo would be great with the 50MHZ flash speedy of Stellaris, 40KB of SRAM and running at 80MHZ or more. 

Hi Chris!

I would like to see in C2000 controllers the mechanism for protecting a FLASH  from accidental or erroneous permanent LOCK while FLASH programming.

Because it is well known that due to FLASH-programmer errors there was a lot of cases of C2000 permanent LOCK.

Thanks.

HELLO

I HOPE IN A GOOD  COMPILER NOT LIKE CCS4 BECAUSE IT'S DEPRESSING , CRAZY METHOD AND MANY PART NOT WORKING , HAVE A BAD IDE ,AND HAVE ALWAYS A LOTS OF TROUBLE , EMULATOR  DON'T CONNECT ,  EVERY TIME TO UPDATE THE RESULT IS WORST OF THE LAST.

I HAVE MORE THINGS TO TALK REGARDS THE IDE,,, AND YOUR SOLUTIONS..

I SPEND A LOT OF MONEY IN MORE EVM FOR NOTHING.

AT THIS POINT I DECIDE TO  LEAVE TI C2000 MCU AND TOMORROW I ORDER AN EVM OF ANOTHER DSP (NOT SURE TI)

I SEE A LOT OF POST OF MANY PEOPLE FULL OF PROBLEMS OF EVERY TYPE AND THE REPLY OF THE TI PEOPLE IT'S VERY POOR.

GOOD-BYE FROM A DISAPPOINT EX TI-MCU USER.

WHE YOU HAVE A SERIUS COMPILER LIKE OTHER MCU PLEASE TELL ME BUT NOT CCS 4.....

B.R.

MARIO

Mario:

I am a user of several TI EMV products, F2407, F2812, C6713, and others, and I really haven’t had much difficulty.

I do use an older version of the CCS (v2.1) because I am using WIN98 on the development machines, and for the C2000 series, I am using a parallel port cable to connect. (The C6000 uses a USB, and I do find that to be a little less reliable)

Try to find yourself an older version of the CCS.

I am able to do this because I am not using much of the "enhancement" tools. I find all those enhancements are generally less efficient then me doing the coding myself.

Also, I really need speed and even though the C compilers are pretty good, they are not efficient enough to really get the most out of the DSP's (Particularly the 6713.)

Good luck, Mark.

mario said:

I HOPE IN A GOOD  COMPILER NOT LIKE CCS4 BECAUSE IT'S DEPRESSING , CRAZY METHOD AND MANY PART NOT WORKING

Mario -

I'm sorry that you've had troubles using C2000.  I am interested in hearing more about the issues you had with the compiler and the IDE. 

Did the compiler generate incorrect code or was it missing features?  Please post in this forum or preferably the compiler forum:

http://e2e.ti.com/support/development_tools/compiler/f/343.aspx

Likewise with the CCS IDE - please post your feedback here or preferabily to the Code Composer Studio forum:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81.aspx

Thank you

Lori

How about some production 2802X and 2803X parts so that we don't have to design them out now that we've design in these wonderful but seemingly unavailable chips.

Wally,

We know this is a serious issue and have been working to improve the delivery issues. There is simply more demand than we have supply (this is across different products made, built, and tested in the same facilities).  Starting in Q409 we have been able to dramatically increase the C2000 share of this supply, and it is showing with the output starting in February.  It's going to take some time to fully catch-up to the backlog of demand, but we are doing everything in our power to get back to the on-time delivery that you expect with TI.  

On the additional roadmap comments/questions:

We will continue to extend the Piccolo family to meet the needs of our target markets, both upwards and downwards.  Based on the feedback on this thread alone I feel that many of you will be happy with the next generation devices to be announced later this year :)

I would really like to able to be trigger the uLaw coprocessor on an eCap input capture.  

I would also like to see the ePWM and eQEP use 32 bit timers rather than the 16 bit timers they currently have.

the eQEP does use a 32-bit time base.  why 32-bit on the PWM module? just for consistency?  with the use of the ePWM module in so many other devices and SW it would be difficult to change at this point.

I'm very curious to know how you would use an eCAP trigger for the CLA. are you looking to use the CLA to process capture inputs, or do you want to use the eCAP as a PWM output?

I should have been more specific - on the EQEP I would like to see 32 bit capture capability.  Although the timebase is 32 bit, the capture timer and latch registers are only 16 bit.  I found myself in a situation where I was short one eCAP and wanted to use the capture capability of the eQEP but it was not straightforward as it is only 16 bit vs. the 32 bits of the eCAP.  

I use the PWM functionality in non-standard ways and some times 16 bits just isn't enough and I end up having to dynamically alter the prescaler which takes too long.  I ended up having to go to an FPGA because of this.

As far as the CLA is concerned, I have to do statistical processing on pulse widths that I measure with the eCAP.  It would be nice to speed things up by being able to trigger the CLA on a capture and process the data in the CLA.  It is very time critical.

John

- make MCUs available, please! I've 5 boards waiting an IC replacement. From 2 months! 

- 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.. 

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

Regards, Loriano 

Loriano,

- make MCUs available, please! I've 5 boards waiting an IC replacement. From 2 months! 

We are putting tremendous effort into this, trust me, we want to meet demand as well.  TI is making a specific effort to move other devices into new fab and test facilities so that C2000 production can ramp at a rate to match our growth demands.  It has been painful for all of us, but especially our customers of course.  Things are getting incrementally better every month, and most devices will feel major relief by early in 2011.

- 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.

- 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.