interrupt handler and alternate register set and non-nesting interrupt

I'm using ADSP21489. I'm trying to migrate CCES from VDSP++.

Now I have the next problem.

My VDSP++ project use the super-fast interrupt dispatcher (interrupts()) which uses the alternate register set and interrupt nesting is disabled.

I can't understand: What do I need that I get the non-nesting interrupt handler with alternate register set.

I'm stuck. If CCES can't support it I will return back VDSP++

  • 0
    •  Analog Employees 
    on Feb 26, 2013 1:17 PM

    Hi Eugene,

    CrossCore Embedded Studio for Analog Devices processors provides a coherent interrupt management mechanism which allows for the same interface to be used in RTOS and non-RTOS applications. This means that interrupt service routines in all RTOS applications (no-OS and µC/OS-III included) must be written in C and use the adi_int interface. Any thread-safety requirements or interactions with tasks are handled by the adi_int interface.  By making the same interface work in all environments and processors we hope that developers find it easier to develop code which is meant to work in more than one environment. The versions that get linked in in the RTOS case take care of the prolog and epilog which are required by µC/OS interrupts. This interface is also mentioned in the µC/OS-III release notes.

    If you are not using an RTOS, then it *should* be possible to include the relevant source files from VisualDSP++ as part of your project in CCES and continue to use the super-fast dispatcher in your application. Please note that we haven't tried this before, and it's not an officially supported technique. It's also likely to be quite a lot of work, with a fair bit of trial and error involved. If you're keen to try it, let us know and we'll provide some information to start you off.


  • I'm ready to try it. I'm ready to implement the interrupt handler from VDSP++ which can use the alternate register set.

    It's good that you provided a coherent interrupt management mechanism.

    But I want to use all feature of Sharc processors. I need the interrupt which uses alternate register set because my target system must work with 5us or 10us and my interrupt work like the semaphore and do the small part of the code.

    I don't need µC/OS-III.

    I need Eclipse IDE and new features of C/C++ compiler.

    For example, I need the native support of the fract type in C++. You include it in CCES compiler. If you include the native the fract type in C++ of VDSP++ I remain.

  • I think I must add to my project all files (.asm) which include labes from the file "signal.h".

    So signal.h say that I must include next files:








    These files say I must include next files:







    May be some files I missed

  • 0
    •  Analog Employees 
    on Mar 11, 2013 10:41 PM

    Hi Eugene,

    Sorry for the delay in replying. The files in your first list correspond to the following functions:

    clear_interrupt.asm     clear_interrupt()

    interrup.asm               interrupt()

    interrupnsm.asm          interruptnsm()

    raise.asm                    raise()

    raisensm.asm               raisensm()

    signal.asm                    signal()

    signalnsm.asm               signalnsm()

    So there might be some files that you don't need.

    From your second list, you'll only need int_cnss.asm and int_tabl.asm if you're using the superfast dispatcher. Unfortunately, you'll need a few other files as well, and that's what I'm now trying to work out. This process will be a bit complicated because there are some files in VisualDSP++ that are also in CCES, but the content of the functions has changed slightly. For example, you'll need the file set_c.asm from VisualDSP++ so that you have the function "___lib_setup_ints", but this file might not be compatible with the version that's in CCES. You'll also need to make changes to the interrupt vector table so that your interrupt uses the old mechanism instead of the new one.

    Are you planning to use the old (VisualDSP++) mechanism for some interrupts and the new (CCES) mechanism for other interrupts, or are you planning to use the old mechanism only?


  • I don't know. Only what I know that I need the non-nesting interrupt handler which use the shadow register set and the traditional handler.

    I use software interrupts like OS tasks so the interrupt handler save processor registers. Other interrupts are non-nesting interrupts and use the shadow register set. So I don't need OS.

    It work good in VDSP++ if I raise the software interrupt without using raise function and using sysreg_bit_set_nop(sysreg_IRPTL,SFTxI).

    If I'm using raise function my program fails.

    So I want to use CCES but I need the non-nesting interrupt handler which use the shadow register set.

    I can tune the old (VisualDSP++) mechanism if CCES (now and future) C/C++ Run-Time Model and Environment are same like VisualDSP++.

    Maybe you can add the non-nesting interrupt handler which use the shadow register set for CCES (for example you can add new #pragma superfastinterrupt). It hold to use CCES from VDSP++, but we want to go CCES because TI-processors and ARM-processors has Eclipse IDEs.