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?