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.

Interrupt Nesting without SYS/BIOS.

Goodmorning,

i have the necessity tu use the interrupt nesting with DSP C6457 without SYS/BIOS. Is possible this with CSL? There is an example about?

Thanks in advance

Fabio

 

 

 

  • Fabio,

    Since your question is explicitly about *not* using BIOS, it doesn't make sense for this question to be posted in the TI-RTOS forum.  I have moved it to the device forum in hopes that it will get a faster response there.

  • Fabio,

    The best advice I can give you is to go back to whoever told you to do this project without SYS/BIOS (now called TI-RTOS) and convince them to let you do the project with SYS/BIOS. We have support for you using SYS/BIOS. We have the graphical user interface to make it easy to use. We have the code structure in place to allow you to get your job done quickly and efficiently.

    The complaints about SYS/BIOS tend to be code size and performance overhead. The code size is completely under your control, and it starts small with the minimum needed to do the simple operations you want it to do. If you want it to do more, you can gradually add more support. None of it is very large. And most of the performance overhead is doing things that you have to do anyway, like saving and restoring context during interrupts, especially when you want to nest interrupts.

    TI has examples and support for using SYS/BIOS. This is what can be done by our team on the forum.

    TI does not have examples and support for non-SYS/BIOS like what you are talking about. It will be more time consuming and more fraught with errors and problems for you do try to do this yourself. That is why SYS/BIOS exists, to allow you to get the infrastructure components of your software done easily and quickly, but if you want to do it without SYS/BIOS, you can.

    To understand how the interrupts work and how you can handle nesting, you will need to study the C64x+ CPU & Instruction Set Reference Guide, the C6457 datasheet, and the C64x+ Megamodule Reference Guide. Many of the other manuals will also be useful or needed, but these three will be the first to start with. Read them from cover to cover to understand everything that will be involved with programming the lowest details of the processor.

    The CSL will be helpful for you to get direct access to the various system registers that you will have to manipulate.

    Sorry, but I will not be able to tell you every register to write to or every software issue to be careful of. You can search all of the CSL examples to see if there is any example that comes close to what you want to do. These things are all solved for you in SYS/BIOS, but if you want to take the time to do all of that work again by yourself, then your manager will be grateful for your job well done.

    In my opinion, if you are severely concerned with performance and code size, you should not be concerned with nesting interrupts. It may help you to go through one of our online or archived training classes to understand the ways we teach to meet real-time requirements in code and to avoid latency issues. You should never be staying inside an interrupt service routine long enough to care about latency and nesting. Instead, you should capture data or send data, then set a flag to be used outside of the ISR context for the bulk of the processing requirement. In SYS/BIOS, this means entering an Hwi hardware interrupt ISR, doing the quick I/O as needed, then either setting a Semaphore or starting a Swi software interrupt.

    In any case, you should start the project with SYS/BIOS so you can get the application tested quickly. Then you can evaluate the overhead due to SYS/BIOS and determine scientifically whether that overhead is too great or whether the project works as needed with the performance and code size required.

    In general, your stockholders will be more grateful for you using SYS/BIOS. But that is a business decision for you and your company to make.

    Best of luck.

    Regards,
    RandyP