Give TI Your Feedback on C2000

I need less power consumption.

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.

>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. I have same problem with TMS320F28335