Pumpkin, Inc.

Pumpkin User Forums

Interrupt Latency

For issues specific to TI's TMS320C2000 DSPs, including TI's Code Composer Studio.

Interrupt Latency

Postby Unregistered User » Fri Jul 11, 2003 7:04 am

We are considering using your RTOS on a TI TMS302 F2812 but have very strict requirements for the interrupt latency, which is why we are not using the TI BIOS.

Reading your online documentation I have not been able to get any actual interrupt latency times for this processor.
Could you sent me the min/max interrupt latency times please.

Unregistered User
Posts: 36
Joined: Thu Aug 09, 2001 11:00 pm

Re: Interrupt Latency

Postby aek » Fri Jul 11, 2003 7:21 am


I will answer your question in 2 parts -- please be sure to read both.


Because Salvo is so highly configurable, with e.g. different libraries for different configurations, it doesn't make much sense for us to specify minimum interrupt latencies. Your best bet is always to create a test program with Salvo Lite that closely approximates your real-world conditions.

If you then assume that interrupts are disabled for the duration of each Salvo API service cal, you will obtain results that are even more conservative than the actual worst-case numbers.

We had a third party evaluate Salvo on the '2812 a while back -- here is what he found when testing with a small test program he wrote ... he was having some hardware issues, but resolved them:

now it is working, 4 eyes see more than 2 eyes.

My problem was to use the external RAM on the EVAL-Board for the programm code.
This was my fault. If I put the programm code in the internal RAM like H0SRAM, I got a
latency of 2,56us!!!

This is very fast, faster than the TI DSP/BIOS. The TI code use internal SRAM too.

Thanks for your support, if the next customer has the same problem, know you can ask him what kind of RAM he use :-)

I believe the code looked something like this:
int nMySema = 0;

interrupt xxxx (void)
nMySema = 1;

task (xxx)
for( ; ;) {
while (nMySema == 0) {

But what you're really asking, I believe,relates more to hard real-time issues, which I'll cover in Part 2.

[This message has been edited by aek (edited July 11, 2003).]

Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: Interrupt Latency

Postby aek » Fri Jul 11, 2003 7:36 am


For critical timing requirements that I suspect you need (looking at your signature), it's important to step back and realize that Salvo was not designed as a hard-real-time OS, in part because of its mission to minimize RAM usage.

So, what to do?

Well, since Salvo is very light on resources and is very non-invasive, the thing to do (if it suits your overall design) is to split up your timing requirements into those that cannot tolerate much jitter (the hard-real-time ones), and those that can. Then, what you do is (re-)configure Salvo so that it only disables those interrupt sources that are not associated with your hard-real-time interrupts.

IOW, you end up with zero interrupt latency, because Salvo is not disabling your interrupts of interest at all.

As an example, we have a customer on the PIC18 who needed essentially zero jitter so that his interrupt-driven DSP algorithm ran at exactly 1280Hz. So, the Salvo solution for that particular chip (which has two interrupt priority levels) was to put the DSP stuff on the high-priority interrupt, and the rest on the low-priority interrupt, and configure Salvo to only disable low-priority interrupts in its critical sections.

This, it turns out, was very easy for that particular target and compiler -- just a small header file to build a custom library with the desired behavior. 5 minutes' work.

The restriction put on this scheme is that he cannot make calls to the Salvo API from within any high-priority interrupts. But that's not a big issue, as it's pretty easy to come up with simple schemes to pass information from the high-priority interrupt to, say, mainline code, where the Salvo API can be called. A simple binary semaphore (implemented by the user, not one of Salvo's) sufficies in most case.

The same idea can be done with Salvo's port to the TMS320C2000 processors -- you would replace our OSSaveGIE() and OSRestoreGIE() with your own, recompile, and be done with it.

This approach, a sort of split-level one that removes any worries about RTOS intrusion and effects on critical timing, is the one I recommend for Salvo users who have extremely critical timing requirements.



[This message has been edited by aek (edited July 31, 2003).]

Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Return to TI's TMS320C2000 DSPs

Who is online

Users browsing this forum: No registered users and 0 guests