Symphony Studio

Bentech · ‎03-27-2008

Hey all,
I am just new to both freescale DSPs and these forums. I have a good background with microcontroller programming, and I have just purchased the soundbite dev board and am using Symphony Studio.

My first quesion is with regards to interrupts. I have noticed that in the "Eight-channel-C-template" sample code (avaliable here) the author has done a manual push and pop in the interrupt routines for the ESAI. I am confused as in my experience the compiler should instert the required code to push and pop the necessary registers for the ISRs. Although this is not a problem by itself, when I use a variable inside the ISR, my application stops working! For example, I am simply passing audio through the board at the moment, and one line in the ISR is as follows:
data.inBuffR[0] = *(YREG M_RX1_1);
Of course, data.inBuffR is my buffer array, and *(YREG M_RX1_1) is reading the RX1_1 register. However, if I change this to the following:
index = 0;
data.inBuffR[index] = *(YREG M_RX1_1);
where index is a global variable, my application stops working! index is set to zero so it should not change anything. I do not know the problem, but another problem I found is this...

In the same ISR, using code I know works, if i put "int i;" at the start before the registered are pushed, it also stops my application from working! I DO know why. It is because this line generates an extra push at the start of the routine, however because I seem to have to do a manual "RTI" at the end, the final pop is not executed! The compiler only does a "RTS" at the end instead of a "RTI"! WHY DOES THE COMPILER NOT GENERATE THE CORRECT CODE?

Now, it is clear to me that the author of the sample code, who must be a freescale technician KNOWS about this problem, which is why the manual "RTI' was inserted. However, why are these problems not fixed?

Yes, I am new to this compiler, so if there are solutions to these problems, or reason why it is happening that I do not know about, I would LOVE sometone to explain.

Cheers,
Carl

Bentech · ‎03-27-2008

Ok,
I have realised that the problem why it stops workign when I use a variable (even global) for the index is because it adds an extra push at the start of the ISR (move (r6)+). However, the "RTI" is called before the final matching pop is called so we get an unbalanced stack. Ok, so the question is...

Why do we have to do a manual "RTI" at the end of an interrupt routine?! The compiler puts a "RTS" which is a return from function not return from interrupt! This is very poor of the compiler and causes the problem described! Does anyone have any suggestions?

Carl

david_dicarlo · ‎03-28-2008

The manual inclusion of the "RTI" is required because the GNU C compiler port, as it is, has not mechanism for signaling the compiler that the subroutine is an interrupt service routine and not just another plain subroutine.

ISRs require the RTI so they return to where they came from - the state of the processor and PC needs to be returned to what it was before the interrupt. It appears that the signal() and raise() functions can take care of handling interrupts without manually including the RTI, but the example C code did not take advantage of it.

--david

Bentech · ‎03-28-2008

David,
Thank you for your reply. Yes I relised the compiler does not know its a subroutine. I could not find any way to tell it that. It seems it does not have a "interrupt" keyword etc.
The problem is that if you use a global variable within the interrupt routine the compiler includes code to manage that such as saving and restoring from the SSH etc. However, if you have an RTI at the end of the routine, you cut off all the compilers code at the end!
I found that if you do a manual "move ssl,sr" at the end, it effectively changes the RTS into an RTI as that is the only difference. However, when you use global variables, call other routines or basically do anything that will cause the compiler to insert extra code at the start and end of the ISR, then the code will fail!

To me, it seems clear that the fact that the compiler does not handle an ISR as it should is a major flaw, and I am interested to find out how others get around this problem. I am shocked that such a problem would exist in the first place. Interrupt routines are a major part of embedded programming and many designers want to use C these days.

David, you mentioned signal and raise functions. Can you explain how these may fix the problem?

Cheers,
Carl

david_dicarlo · ‎03-28-2008

The g563c user's manual mentions that these functions are used to handle interrupts within the context of the C environment. (See http://www.freescale.com/files/dsp/doc/user_guide/DSP563CCUG.pdf). I am not sure if these have been updated for the Symphony DSPs, since the C compiler is not a recent port.

I'm not a very proficient C programmer, so I'm afraid I can't be of much more help than that. Nearly everything I write is in assembly.

--david

Bentech · ‎04-01-2008

David,
Ok thank you heaps for your help. Symphony Studio is a great peice of software, its just a bit of a shame the compiler is lacking in this respect. This is something I expect a compiler to do, or at least have the ability to insert a #pragma directive to tell it that its an interrupt. Maybe in the future this will be the case.

It seems I will be writing my interrupt routines in assembler. This is no problem as I have done this in other projects. I just dont know how anyone is expected to write a decent interrupt routine reliably in C with this compiler.

Anyway, I have been using the soundbite board for only a week and I am already making good progress. Now to give the enhanced filter coprocessor a try...

Cheers again.

Carl

david_dicarlo · ‎04-01-2008

I am glad to hear you are making good progress with the SoundBite.

I have written to the Studio developers to see if there is a better way to handle ISRs completely in C. I think there is but not being much of a C programmer, I'm not of much help. When I get a reply, I'll post it back here.

What is your end application for the SoundBite? Would you be willing to share your application source code once it's working to provide more examples for other users of the SoundBite?

Regards,
david

Bentech · ‎04-01-2008

David,
Oh thank you very much I look forward to getting that reply.

I am currently doing research on digital amplifier design and I intend to use the DSP in the end design. I dont know if I can post the end source code but I will definately be keen to post some examples. I found that there are not enough examples avaliable at the moment so I would be happy to help.

Cheers
Carl

Bentech · ‎05-20-2008

David,
Did you get a reply by any chance?

Cheers,
Carl