This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

More speed, faster clock, interrupt latency, jitter

Hi.  I have been using F2812 for a few years and I like it.  I do custom laboratory instrument development. My applications often involve waveform synthesis where I do GPIO in an interrupt service routine (ISR) or compare output in which I reconfigure the compare match register after every match and underflow interrupt at speeds up to 1MHz.

I could definitely use more speed!  When will TI develop and release C2000 devices with higher clock speeds?  I have debated this over at comp.arch.embedded, where some folks thought that TI is unlikely to increase the speed.  I doubt this and think that the market would welcome increases to 200, 225, 233, 250, 300MHz, or more!

 Of course, the flash is a limiting factor.  However, I think that the benefit of higher speed would be worthwhile even if the device could only run at full speed in SARAM code.  This is the case already, but with higher clocks just the ratio of full speed to flash speed would be greater.  It is typical to structure applications for these devices with small code and data segments that need full speed allocated to SARAM and the bulk of application not needing full speed allocated to flash.  Thus, I expect that the target market for C2000: power conversion, motion/motor control, etc. would benefit enough from faster SARAM execution to make this desireable for TI.

 Does anyone know what TI will do about this?  Will there be faster devices anytime soon?

Another issue is interrupt latency and latency jitter.  When an interrupt occurs, there is at present a variation of about 7 cycles in the latency (the time from interrupt flag through to CPU to actual ISR first instruction execution that is affected by the pipeline flush.  The distribution of the latency jitter is weighted toward 4 cycles pk-pk, but up to 7 are observed with much lower statistical probability.  I propose that a "force max pipeline flush cycles on interrupt" configuration bit should be added to the device which would allow jitter-free interrupt latency.  Yes, this would also mean that all interrupts would occur with the worst-case latency, but this is a trade off.  In applications that could benefit from zero-jitter interrupts, this would be acceptable.

Since most faster architectures use cache, this also leads to less interrupt latency determinism.  A faster C2000 would appeal to designers of power conversion blocks with ever increasing switching speeds by offering some of the fastest interrupt response times possible.  A jitter-free mode would be an added bonus.

 Any thoughts?

  • Stay tuned on more MHz, you won't be disappointed.

    As for reduced interrupt latency and latency jitter. Stay tuned also, we have some new stuff coming down the pipe that adresses this issue.

    I can't say more otherwise our marketing guys will be out of a job :-)

    Cheers,

    Alex Tessarolo

  • Thanks for the reply, Alex!

  • Any timeline for new C2x product releases? 

  • You probably have seen the announcement this week of the Piccolo family of devices. Of interest would be the CLA (Control Law Accelerator) which is basiccaly a mini programmable FPU that can run independently of the main C28 CPU core. It can access the ADC and PWM peripherals and respond to interrupts independent of the main CPU. One purpose of this is to minimize interrupt jitter and reduce sample to output delay (time taken from ADC sample, do control code calculations and output new PWM value). Basically, the CLA offloads the main CPU from doing the very time critical control loops. Floating-Point is used (32-bit IEEE format) because it is easier  and because floating-point enables better quality of MIPS. For example the CLA can do a division (true division i.e. 2.3456/13.9876 = 0.167691384) in 9 cycles.

    The CLA concept will be extended to future families in our roadmap.

    As for higher MHz devices, look for an announcement around 1Q09.

  • Yes, I have seen this, and downloaded SPRT493.pdf "TMS320F2803x and TMS320F2802x MCU Technical Brief."  This device isn't particularly exciting to me in particular since it's likely to be more complex to program.  Though I expect the CLA concept is a good one for control loop compensation applications.  I'm hoping to see simply higher clock speed versions of F2812 or similar soon.

    The new 210MHz Atmel ARM SAM9XE is starting to look interesting.  ;-)

  • Hi,

    I see that you understand f2812 very well, maybe you can help me. When I programmed flash one problem appears. My crystal is 30MHz but it works on 10Mhz. Did anyone have that problem? I do not know does it softwere or hardwere problem. Can you help me?

    Thanks,Fill

  • fill said:

    When I programmed flash one problem appears. My crystal is 30MHz but it works on 10Mhz. Did anyone have that problem? I do not know does it softwere or hardwere problem. Can you help me?


    Would you be able to provide additional details on your issue?  It isn't clear what problem you are reporting.

    From what you have mentioned, the crystal you have connected to the F2812's X1/X2 terminals is 30MHz, correct?
    What is the 10MHz you mentioned?  Where is this measured?