"omalley.ronan@gmail.com" <omalley.ronan@gmail.com> wrote in 
news:1141933260.496829.288400@v46g2000cwv.googlegroups.com:

> ha ha,
> 
> Thanks Al, at least after the day i've had, i can come out with a
> smile! :)
> 
> "For example, if you are using secondary DAGs and Registers for ISRs
> (which is my perference), make sure that nesting is off or that the
> higher priority ISR preserves any registers and DAGs used by the lower
> priority interrupt. "
> 
> Im actually coding everything in C, could it be that the assembly
> generated for each of the ISR's is accessing the same registers?
> 
> pardon the pun but this is really bugging me,
> 
> Ronan
> 
> Ronan
> 

I never write C ISRs since they tend to save everything. I prefer short 
ISRs and therefore, I usually pass semaphores to the foreground loop to 
execute most everything. An assembly ISR looks like this (assuming no 
nesting):

PUSH STS;

// Enable secondary registers & DAGs 
BIT SET MODE1 SRRFL | SRRFH | SRD1L | SRD1H | SRD2L | SRD2H;   	 


assembly instructions.......

POP STS;
RTI;

The total overhead is three instructions not counting the return.

I doubt that the C ISR is accessing the same registers even with nesting. 
Try turning the nesting off, then they will always be independent. This 
will be a sanity check.

You might try posting to the adsp yahoo group.

-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

ha ha,

Thanks Al, at least after the day i've had, i can come out with a
smile! :)

"For example, if you are using secondary DAGs and Registers for ISRs
(which is my perference), make sure that nesting is off or that the
higher priority ISR preserves any registers and DAGs used by the lower
priority interrupt. "

Im actually coding everything in C, could it be that the assembly
generated for each of the ISR's is accessing the same registers?

pardon the pun but this is really bugging me,

Ronan

Ronan

ha ha,

Thanks Al, at least after the day i've had, i can come out with a
smile! :)

"For example, if you are using secondary DAGs and Registers for ISRs
(which is my perference), make sure that nesting is off or that the
higher priority ISR preserves any registers and DAGs used by the lower
priority interrupt. "

Im actually coding everything in C, could it be that the assembly
generated for each of the ISR's is accessing the same registers?

pardon the pun but this is really bugging me,

Ronan

Ronan

"omalley.ronan@gmail.com" <omalley.ronan@gmail.com> wrote in 
news:1141908665.342538.135700@i39g2000cwa.googlegroups.com:

> Hey,
> 
> Im working with an ADSP-21364 SHARC processor and EZKIT.
> 
> I have a problem when trying to integrate two programs that use the
> serial ports.
> 
> My first program is based on the "Block based talkthrough" example,
> SPORT0 is used
> to take audio input from the ADC and SPORT2 is used to output the
> processed audio to
> a DAC.  This stand-alone program functions correctly.
> 
> My second program implements a UART receive on serial port 3B, this is
> based on the
> Eng-to-Eng note EE-191.  Bytes are received through DAI pin 5 and
> stored in a
> buffer. This stand-alone program also functions correctly.
> 
> My problem comes when combining the two programs.     As the programs
> use different
> serial ports and different DAI pins I didn't think there would be a
> problem.
> 
> However when I combined the programs the audio processing works but the
> UART
> receiver does not. (Some random data received, no correct data).
> Through debugging I
> have traced the problem down to this line in the SRU config:
> 
> SRU(DAI_PB_07_O, DAI_PB_13_I);
> 
> When this line is commented out the UART receiver functions correctly
> but the audio
> processing program stops outputting audio.
> 
> I understand that this SRU config statement is connecting the ADC clk
> directly to
> the DAC clk, why would this interfere with my UART receive program?
> 
> Many Thanks,
> 
> Ronan O'Malley
> 
> 

If you are using different DAI lines, SPORTs etc., there shouldn't be a 
problem. Could you have a problem with interference between interrupt 
handlers?

For example, if you are using secondary DAGs and Registers for ISRs 
(which is my perference), make sure that nesting is off or that the 
higher priority ISR preserves any registers and DAGs used by the lower 
priority interrupt.

I have programs that use a variation of the UART from EE-191 with two 
independent sports running I2S. My application runs on a 21262 which is 
essentially the same for this discussion.

My guess is you just have the typical dumb mistake (the one that is 
obvious after you find it).

Clark's Law (Rule of 10):

    	All bugs take 10 seconds, 10 minutes, 10 hours or 10 days to solve     
	(and they're all dumb shits)

Clark's Law Reboot:

    	Clark's Law can be reset by going home. The problem is usually         
	resolved wthin 1 mile of the office.

Clark's Law Reminder:

    	When you are absolutely sure that you have done everything correct,     
	and are clearly moving toward the 10 hour metric, reread the errata. 

    	When the 10 hours have passed, you may be a future contributor to     
	the errata list, or of course, one of your peers shows you that it     
	was actually a dumb shit on your part. At this point, I am usually     
	more relieved than annoyed, and I usually owe someone a beer or two.


I claim all these laws as my own but I am sure they have been discovered 
and rediscovered many times before and after me.

Dave Clark's Law (my father):

    	Murphy was a god damned optimist!

I don't think he claims this is uniquely his observation either.

-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

Hey,

Im working with an ADSP-21364 SHARC processor and EZKIT.

I have a problem when trying to integrate two programs that use the
serial ports.

My first program is based on the "Block based talkthrough" example,
SPORT0 is used
to take audio input from the ADC and SPORT2 is used to output the
processed audio to
a DAC.  This stand-alone program functions correctly.

My second program implements a UART receive on serial port 3B, this is
based on the
Eng-to-Eng note EE-191.  Bytes are received through DAI pin 5 and
stored in a
buffer. This stand-alone program also functions correctly.

My problem comes when combining the two programs.     As the programs
use different
serial ports and different DAI pins I didn't think there would be a
problem.

However when I combined the programs the audio processing works but the
UART
receiver does not. (Some random data received, no correct data).
Through debugging I
have traced the problem down to this line in the SRU config:

SRU(DAI_PB_07_O, DAI_PB_13_I);

When this line is commented out the UART receiver functions correctly
but the audio
processing program stops outputting audio.

I understand that this SRU config statement is connecting the ADC clk
directly to
the DAC clk, why would this interfere with my UART receive program?

Many Thanks,

Ronan O'Malley