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.

timer interrupt in TMS320C674X

Hii ,

I designed a TaskScheduler consisting of 3 tasks of which one is TaskIdle().

For time being,I am using Timer Interrupts for producing a maskable interrupt(INT4).

After executing Task1,TaskIdle will run during which interrupts occur.Interrupts are serviced using an ISR during which PGIE = 1 and GIE = 0.Samples are demodulated during each interrupt.I have 1152 samples to demodulate.

When interrupt is serviced and TaskIdle is resumed, PGIE = GIE =1..After demodulating 672 samples,I am making Task2 ready through ISR.And when TaskIdle is run,it will check whther any higher priority task is ready to run.And here comes my problem...At this point,the value of GIE is not copied correctly to PGIE,which means PGIE =1 and GIE = 0,which is wrong.

and after this,Task2() will run.Inside TASK2(),PGIE and GIE = 0.But both should be set to 1.Is it because the stack is not being properly loaded and stored?

After executing Task2(),I want interrupts to occur so that I can demodulate rest of the samples.But Interrupts does not occur after that.because GIE and PGIE is 0.

In this case,can I enable GIE to my choice? If so,will it affect scheduling of tasks or other interrupts?

Looking forward for the reply,

Regards,

James

 

 

  • James,

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others have asked on similar topics.

    There are many different support categories in the forum, and some may be more suited for different questions you may have. I am not really sure in which forum your question would be best served, but I do think the correct answer is simple.

    Use SYS/BIOS. You should never have to get involved in your code to the level of looking at GIE and PGIE. SYS/BIOS will take care of this part of handling interrupts.

    Please go to the Wiki and search for SYS/BIOS Training. The 1.5 day workshop is a great place to start, and you will find additional levels of training that will be helpful to continue with after that.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • Hi Randy,

    Was disappointed that nobody replied to my question.Thank you very much for your kind reply.

    But I am  expected to do my RTOS on CCS.

    Regards,

    James

  • James,

    This is an interesting trend. There have been other requests lately for low-level support like yours, and like you the others have stated that they were being expected to do this work by whoever assigned the task. And this is the case even though TI provides the solution at no charge by offering the DSP/BIOS and SYS/BIOS products.

    If you want to develop a product or application, or if you want to prototype a new idea, you will be able to do it quicker if you use the tools we provide for you. If you have a competitor who wishes to do the same thing as you, but they restrict themselves by trying to write in assembly code and develop their own scheduling, you will get to market first by using these tools we provide.

    I have been unable to convince any of the other people requesting this level of support. Perhaps you can lead the way by changing the definition of your task using logical discussion.

    I am interested about why you are expected to write your own RTOS. If you have time between debugging and reading through the CPU & Instruction Set Reference Guide, please explain whatever you are willing to share.

    15-20 years ago, we taught DSP classes by going through each assembly instruction and explaining all the bits in the control registers. As the DSP architectures became more complex, as our customers' product became more complex, and as our number of customers increased, we invested more in our C compiler and CCS and the BIOS operating system. We acquired a company that had developed a popular RTOS for our DSPs so that we would not have to do that initial development ourselves, and we offer the ever-improving descendants of that RTOS so that you do not have to do that initial development by packaging DSP/BIOS and SYS/BIOS with the other development support.

    Regards,
    RandyP