Jerry Avins wrote:
> "Epriodic" is a new word for me. What does it mean? If it's a typo, I 
> can't think for what.
> 

periodic

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com    (603) 226-0404 x536
There's a fine line between clever and stupid

eeh wrote:
> 1. When tick rate=1000us or 100us, it works. When tick rate=10us or
> 1us, it does not work. That is, the periodic function does not break.
> 
> 2. No I am not doing audio decoding but data decoding. The data rate is
> 1MHz.

OK. Apriodic --> periodic; I should have guessed.

Your program runs in a loop, doing the same job repeatedly. If the time 
to execute the loop once including all ISRs exceeds repetition period, 
then it will fail. Since it works if the repetition rate is low enough, 
that is probably what is happening. Determining the rate at which the 
program breaks down -- not just going in powers of ten --  will tell you 
how much faster you need to make the loop run. From what you write, you 
need to speed up between 10 and 100 times. You might make it in assembler.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

eeh wrote:
> No, I do not clock it by ISR. The ADC is memory mapped. The epriodic
> function is just to use to read data.

"Epriodic" is a new word for me. What does it mean? If it's a typo, I 
can't think for what.

What is the tie between reading the ADC and subsequent filtering? I 
can't guess what you're doing, but you may be doing some easy thing a 
hard way.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

1. When tick rate=1000us or 100us, it works. When tick rate=10us or
1us, it does not work. That is, the periodic function does not break.

2. No I am not doing audio decoding but data decoding. The data rate is
1MHz.

No, I do not clock it by ISR. The ADC is memory mapped. The epriodic
function is just to use to read data.

eeh wrote:
> The problem is halfly solved. The PRD object uses a CLK object whose
> Microseconds/Int has been set to be 1. After modifying to be 1000, the
> interrupt is normal now.
> 
> However, I need very fast timer interrupt to do AD converter reading
> for filtering work.:(
> 
> Do I need to give up to use BIOS?

What is ADC rate?

How do you configure your hardware? I try to use an ADC with built-in 
clocking or provide clocking with external logic. The ADC interrupts the 
processor when a sample is ready, which then has nearly one sample 
period to read the data. If system specifications require that the 
interrupt latency may occasionally exceed the sample time, a shallow 
FIFO can accommodate that.

Some processors allow a timer to create a periodic waveform on a 
dedicated pin. You can clock the converter that way. Clocking the 
converter with an ISR is a terrible waste of resources.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

>Hi,
>
>I have written a test program to test the period object in DSP/BIOS
>which is running under TMS320 C6000 simulator. The program can be
>compiled successfully. I have set breakpoint in the beginning of the
>hooked function in PRD (Period) object. However, the program does not
>stop at there. The program is listed as followed.
>
>#include"Configuration1cfg.h"
>
>class PRD
>{
>	int id;
>	public:
>		PRD(int newId);
>		~PRD();                           // Destructor
>
>		void tick();
>};
>
>extern "C"
>{
>	void myPrd0(PRD prd);
>}
>
>PRD prd0(0);
>
>int main(void)
>{
>	unsigned int j;
>	unsigned int *i;
>	unsigned int *ii;
>	i=(unsigned int *)0xb0000000;//adc
>	ii=(unsigned int *)0xa0000000;//dac
>
>
>}
>
>PRD::PRD(int newId)
>{
>	id = newId;
>}
>
>PRD::~PRD()
>{
>
>}
>
>void myPrd0(PRD prd)
>{
>	prd.tick();//<---------------cannot break in here
>}
>
>void PRD::tick()
>{
>	LOG_printf(&LOG_system,"aaa");
>}
>
>The PRD0 Object properties are:
>
>period=1000
>mode=continous
>function=_myPrd0
>arg0=_prd0
>arg1=0
>
>Could anyone tell me some tips why the periodic object is not
>functional?
>
>Thnaks!

Is your problem that the periodic function doesnt fire or is it that the
break point does not kick-in? That detail is unclear from your message. If
you are asking if break points will work with periodic functions, then the
answer is- Yes it will work. 

On the other hand if you PRD is not firing then it could be due to a
number of reasons, but the most likely culprit is the overall timing
calculations made by you. 

Periodic interrupts are based on a tick rate that must be specified &#4294967295; the
default I think is 1000Microseconds/Tick which is 1ms. You can change it
to whatever you&#4294967295;d like. If you know the tick rate, then any periodic
function can be set up to trigger at any number of ticks. For example, if
you want some code to run every second, you can program the periodic
function to trigger this code every 1000 ticks. So,

1]What is your "tick rate" (as found under scheduling->Clock Manager)? I
think the default "tick rate"(grain of time as understood by BIOS) is 1000
Microseconds/Interrupt.

2] Do you know the default codec sampling rate for C6713/C6416 is 44.1khz
and not 48khz when using the simulator?

--Bhooshan

		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

The problem is halfly solved. The PRD object uses a CLK object whose
Microseconds/Int has been set to be 1. After modifying to be 1000, the
interrupt is normal now.

However, I need very fast timer interrupt to do AD converter reading
for filtering work.:(

Do I need to give up to use BIOS?

"eeh" <eehobbyist@yahoo.com.hk> writes:
> [...]

I'm not sure if it's related to your problem but you might want
to ensure you call CSLInit() somewhere early in your code. 

FWIW, I added a periodic task to my DM642 project fairly effortlessly.
The biggest problem was realizing you need to give the cdb dialog 
the assembly version of your periodic function (i.e., with the "_"
prefix), which I see you've already got right.

--RY

-- 
%  Randy Yates                  % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC            %                    and kiss her interface, 
%%% 919-577-9882                %            til then, I'll leave her alone."
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO   
http://home.earthlink.net/~yatescr

Hi,

I have written a test program to test the period object in DSP/BIOS
which is running under TMS320 C6000 simulator. The program can be
compiled successfully. I have set breakpoint in the beginning of the
hooked function in PRD (Period) object. However, the program does not
stop at there. The program is listed as followed.

#include"Configuration1cfg.h"

class PRD
{
	int id;
	public:
		PRD(int newId);
		~PRD();                           // Destructor

		void tick();
};

extern "C"
{
	void myPrd0(PRD prd);
}

PRD prd0(0);

int main(void)
{
	unsigned int j;
	unsigned int *i;
	unsigned int *ii;
	i=(unsigned int *)0xb0000000;//adc
	ii=(unsigned int *)0xa0000000;//dac


}

PRD::PRD(int newId)
{
	id = newId;
}

PRD::~PRD()
{

}

void myPrd0(PRD prd)
{
	prd.tick();//<---------------cannot break in here
}

void PRD::tick()
{
	LOG_printf(&LOG_system,"aaa");
}

The PRD0 Object properties are:

period=1000
mode=continous
function=_myPrd0
arg0=_prd0
arg1=0

Could anyone tell me some tips why the periodic object is not
functional?

Thnaks!