Hi.
Last time I asked about the reason of wrong number of ticks in one interruption
period. I spent a lot of time checking codec and DSP and I had the following
results:
-the sampling frequency in codec is 8kHz and it's mono for sure!
-the sync signal between codec and DSP is also 8kHz, one 16-bit sample is sent
or recieved every 125us
-however, the DSP puts one sample into PIP frame every 250us, what makes 4kHz
frequency. It seems that processor skips every second sample. I don't know
why.
I still work on c6711. DSP communicates with built-in codec AD535 via McBSP
port.
The main question is: What settings should I check/change in order to set the
proper frequency for reading and writing via McBSP?
Thanks in advance for Your response
Aleksandra
Ticks in SWI period-again
Started by ●July 28, 2008
Reply by ●July 28, 20082008-07-28
Aleksandra,
On Mon, Jul 28, 2008 at 8:24 AM, wrote:
> Hi.
> Last time I asked about the reason of wrong number of ticks in one
> interruption period. I spent a lot of time checking codec and DSP and I had
> the following results:
> -the sampling frequency in codec is 8kHz and it's mono for sure!
> -the sync signal between codec and DSP is also 8kHz, one 16-bit sample is
> sent or recieved every 125us
> -however, the DSP puts one sample into PIP frame every 250us,
Actually, "your code" puts one sample into PIP frame every 250us.
As a test, stub out your processing [bypass your processing of the
input data] and just stuff anything into your PIP frame. Measure the
frequency - it will probably be 8kHz - suggesting that your processing
is too slow. ...this seems like 'deja vu all over again'.
mikedunn
> what makes
> 4kHz frequency. It seems that processor skips every second sample. I don't
> know why.
> I still work on c6711. DSP communicates with built-in codec AD535 via McBSP
> port.
>
> The main question is: What settings should I check/change in order to set
> the proper frequency for reading and writing via McBSP?
>
> Thanks in advance for Your response
> Aleksandra
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Mon, Jul 28, 2008 at 8:24 AM, wrote:
> Hi.
> Last time I asked about the reason of wrong number of ticks in one
> interruption period. I spent a lot of time checking codec and DSP and I had
> the following results:
> -the sampling frequency in codec is 8kHz and it's mono for sure!
> -the sync signal between codec and DSP is also 8kHz, one 16-bit sample is
> sent or recieved every 125us
> -however, the DSP puts one sample into PIP frame every 250us,
Actually, "your code" puts one sample into PIP frame every 250us.
As a test, stub out your processing [bypass your processing of the
input data] and just stuff anything into your PIP frame. Measure the
frequency - it will probably be 8kHz - suggesting that your processing
is too slow. ...this seems like 'deja vu all over again'.
mikedunn
> what makes
> 4kHz frequency. It seems that processor skips every second sample. I don't
> know why.
> I still work on c6711. DSP communicates with built-in codec AD535 via McBSP
> port.
>
> The main question is: What settings should I check/change in order to set
> the proper frequency for reading and writing via McBSP?
>
> Thanks in advance for Your response
> Aleksandra
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
Reply by ●July 29, 20082008-07-29
Sorry to disappoint You, but the whole processing part contains only writing
from input to output and I don't think that such an operation would be too
much for 150MHz processor :) It is NOT the matter of slow processing.
I'll try to give another example: I performed a test with a 1kHz sine wave as an input. Samples of this sine were put into the frame and I checked the content of it. You can expect that there will be 8 samples in one period of the sine. There were 4. In the same time I watched the communication between AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It means that the half of these samples gone missing somewhere in the processor.
If you still have any doubts, please check "audio" project in CCS v2.10 examples for 6711 DSK. I use it without any changes. If you notice the same effect (or if everything is OK with this program), please let me know. Maybe something is wrong with my version.
Alexandra
I'll try to give another example: I performed a test with a 1kHz sine wave as an input. Samples of this sine were put into the frame and I checked the content of it. You can expect that there will be 8 samples in one period of the sine. There were 4. In the same time I watched the communication between AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It means that the half of these samples gone missing somewhere in the processor.
If you still have any doubts, please check "audio" project in CCS v2.10 examples for 6711 DSK. I use it without any changes. If you notice the same effect (or if everything is OK with this program), please let me know. Maybe something is wrong with my version.
Alexandra
Reply by ●July 29, 20082008-07-29
Alexandra-
> Sorry to disappoint You, but the whole processing part contains only writing
> from input to output and I don't think that such an operation would be too
> much for 150MHz processor :) It is NOT the matter of slow processing.
Good to see that you are persistent. But not good to see that you're not using some
creative ways to debug.
If this were really happening, then loop the input to output and listen. If you
input a 1 kHz tone, then you will get out a 500 kHz tone (and it will sound a bit
"edgy").
I think I suggested that you try this before. Do you not have a function generator
and speaker?
-Jeff
> I'll try to give another example: I performed a test with a 1kHz sine wave
> as an input. Samples of this sine were put into the frame and I checked the
> content of it. You can expect that there will be 8 samples in one period of
> the sine. There were 4. In the same time I watched the communication between
> AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It
> means that the half of these samples gone missing somewhere in the processor.
> If you still have any doubts, please check "audio" project in CCS v2.10
> examples for 6711 DSK. I use it without any changes. If you notice the same
> effect (or if everything is OK with this program), please let me know.
> Maybe something is wrong with my version.
> Alexandra
> Sorry to disappoint You, but the whole processing part contains only writing
> from input to output and I don't think that such an operation would be too
> much for 150MHz processor :) It is NOT the matter of slow processing.
Good to see that you are persistent. But not good to see that you're not using some
creative ways to debug.
If this were really happening, then loop the input to output and listen. If you
input a 1 kHz tone, then you will get out a 500 kHz tone (and it will sound a bit
"edgy").
I think I suggested that you try this before. Do you not have a function generator
and speaker?
-Jeff
> I'll try to give another example: I performed a test with a 1kHz sine wave
> as an input. Samples of this sine were put into the frame and I checked the
> content of it. You can expect that there will be 8 samples in one period of
> the sine. There were 4. In the same time I watched the communication between
> AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It
> means that the half of these samples gone missing somewhere in the processor.
> If you still have any doubts, please check "audio" project in CCS v2.10
> examples for 6711 DSK. I use it without any changes. If you notice the same
> effect (or if everything is OK with this program), please let me know.
> Maybe something is wrong with my version.
> Alexandra
Reply by ●July 29, 20082008-07-29
Alexandra-
Sorry, you would hear a 2 kHz tone on the output.
-Jeff
-------- Original Message --------
Subject: Re: [c6x] Re: Ticks in SWI period-again
Date: Tue, 29 Jul 2008 08:32:07 -0500
From: Jeff Brower
Organization: Signalogic, Inc
To: Alexandra Solita
CC: c...
Alexandra-
> Sorry to disappoint You, but the whole processing part contains only writing
> from input to output and I don't think that such an operation would be too
> much for 150MHz processor :) It is NOT the matter of slow processing.
Good to see that you are persistent. But not good to see that you're not using some
creative ways to debug.
If this were really happening, then loop the input to output and listen. If you
input a 1 kHz tone, then you will get out a 500 kHz tone (and it will sound a bit
"edgy").
I think I suggested that you try this before. Do you not have a function generator
and speaker?
-Jeff
> I'll try to give another example: I performed a test with a 1kHz sine wave
> as an input. Samples of this sine were put into the frame and I checked the
> content of it. You can expect that there will be 8 samples in one period of
> the sine. There were 4. In the same time I watched the communication between
> AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It
> means that the half of these samples gone missing somewhere in the processor.
> If you still have any doubts, please check "audio" project in CCS v2.10
> examples for 6711 DSK. I use it without any changes. If you notice the same
> effect (or if everything is OK with this program), please let me know.
> Maybe something is wrong with my version.
> Alexandra
Sorry, you would hear a 2 kHz tone on the output.
-Jeff
-------- Original Message --------
Subject: Re: [c6x] Re: Ticks in SWI period-again
Date: Tue, 29 Jul 2008 08:32:07 -0500
From: Jeff Brower
Organization: Signalogic, Inc
To: Alexandra Solita
CC: c...
Alexandra-
> Sorry to disappoint You, but the whole processing part contains only writing
> from input to output and I don't think that such an operation would be too
> much for 150MHz processor :) It is NOT the matter of slow processing.
Good to see that you are persistent. But not good to see that you're not using some
creative ways to debug.
If this were really happening, then loop the input to output and listen. If you
input a 1 kHz tone, then you will get out a 500 kHz tone (and it will sound a bit
"edgy").
I think I suggested that you try this before. Do you not have a function generator
and speaker?
-Jeff
> I'll try to give another example: I performed a test with a 1kHz sine wave
> as an input. Samples of this sine were put into the frame and I checked the
> content of it. You can expect that there will be 8 samples in one period of
> the sine. There were 4. In the same time I watched the communication between
> AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It
> means that the half of these samples gone missing somewhere in the processor.
> If you still have any doubts, please check "audio" project in CCS v2.10
> examples for 6711 DSK. I use it without any changes. If you notice the same
> effect (or if everything is OK with this program), please let me know.
> Maybe something is wrong with my version.
> Alexandra
Reply by ●July 29, 20082008-07-29
Alexandra,
On Tue, Jul 29, 2008 at 12:47 AM, wrote:
> Sorry to disappoint You, but the whole processing part contains only writing
> from input to output and I don't think that such an operation would be too
> much for 150MHz processor :) It is NOT the matter of slow processing.
> I'll try to give another example: I performed a test with a 1kHz sine wave
> as an input. Samples of this sine were put into the frame and I checked the
> content of it. You can expect that there will be 8 samples in one period of
> the sine. There were 4. In the same time I watched the communication between
> AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It
> means that the half of these samples gone missing somewhere in the
> processor.
Two things appear to be clear -
1. I do not know exactly what your code is doing, so I can only go by
problems from past experience.
2. Your code looks to you like it 'does what it is supposed to do' [at
least that is the way that i am when 'staring a problem in the face'
for a long period of time.
Looking at your task very simply, I see 2 parts - [1] a 'get'
[working, I think] and a 'put' [not working half the time].
Possible causes:
- Missing every other 'get' interrupt [not your problem]
- Get is reading shorts and put is writing ints [containing 2 shorts].
- Put pointer is being incremented every other time - 2 gets writing
to one location
- Some other 'mystery software problem'
How can you approach this??
1. Make a test copy of the project
2. Delete everything but the bare essentials to show the problem[you
have probably done this].
3. Add a global counter that is used to count codec reads.
4. Mask out the lower 4 bits of every codec read and replace them with
the lower four bits of the counter.
5. Check the output and verify that you are losing the even samples.
[or odd samples??]
6. Now that you have tagged your samples, you should be able to trace
them [by testing the 'failing lower bit pattern'] through your code.
7. If the problem is not yet clear, you could write the first 8 values
of the data variables and every pointer that is used in the process to
an array in memory.
Somewhere the problem will show up - and it will probably be something
simple [that is the way it usually works for me].
Good luck. Keep your focus and let us know how you progress.
mikedunn
> If you still have any doubts, please check "audio" project in CCS v2.10
> examples for 6711 DSK. I use it without any changes. If you notice the same
> effect (or if everything is OK with this program), please let me know. Maybe
> something is wrong with my version.
> Alexandra
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
On Tue, Jul 29, 2008 at 12:47 AM, wrote:
> Sorry to disappoint You, but the whole processing part contains only writing
> from input to output and I don't think that such an operation would be too
> much for 150MHz processor :) It is NOT the matter of slow processing.
> I'll try to give another example: I performed a test with a 1kHz sine wave
> as an input. Samples of this sine were put into the frame and I checked the
> content of it. You can expect that there will be 8 samples in one period of
> the sine. There were 4. In the same time I watched the communication between
> AD535 and DSP. Codec was sending non-zero samples with 8kHz frequency. It
> means that the half of these samples gone missing somewhere in the
> processor.
Two things appear to be clear -
1. I do not know exactly what your code is doing, so I can only go by
problems from past experience.
2. Your code looks to you like it 'does what it is supposed to do' [at
least that is the way that i am when 'staring a problem in the face'
for a long period of time.
Looking at your task very simply, I see 2 parts - [1] a 'get'
[working, I think] and a 'put' [not working half the time].
Possible causes:
- Missing every other 'get' interrupt [not your problem]
- Get is reading shorts and put is writing ints [containing 2 shorts].
- Put pointer is being incremented every other time - 2 gets writing
to one location
- Some other 'mystery software problem'
How can you approach this??
1. Make a test copy of the project
2. Delete everything but the bare essentials to show the problem[you
have probably done this].
3. Add a global counter that is used to count codec reads.
4. Mask out the lower 4 bits of every codec read and replace them with
the lower four bits of the counter.
5. Check the output and verify that you are losing the even samples.
[or odd samples??]
6. Now that you have tagged your samples, you should be able to trace
them [by testing the 'failing lower bit pattern'] through your code.
7. If the problem is not yet clear, you could write the first 8 values
of the data variables and every pointer that is used in the process to
an array in memory.
Somewhere the problem will show up - and it will probably be something
simple [that is the way it usually works for me].
Good luck. Keep your focus and let us know how you progress.
mikedunn
> If you still have any doubts, please check "audio" project in CCS v2.10
> examples for 6711 DSK. I use it without any changes. If you notice the same
> effect (or if everything is OK with this program), please let me know. Maybe
> something is wrong with my version.
> Alexandra
--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
