in article zoKdnQCPlt40w8zfRVn-iQ@rcn.net, Jerry Avins at jya@ieee.org wrote
on 04/04/2005 11:34:

> robert bristow-johnson wrote:
>> in article eJWdnfoJfaSMzMzfRVn-1g@rcn.net, Jerry Avins at jya@ieee.org wrote
>> on 04/04/2005 10:36:
>> 
>> 
>>>> well, they don't tell you about it when they do.  (i've had errors because
>>>> of fabrication or mask problems with both the 56K and the early SHArC.  it
>>>> can be very frustrating.)
>>>> 
>>> 
>>> Be precise, Robert. What you're claiming is that sometimes DSPs _make_
>>> errors. I stand resolute. :-)
>> 
>> 
>> that's funny, i was just making a reference to such a phrase...
> 
> I was parroting you.

i eventually picked that up (had to check posting times).  perhaps Jim might
be right if he says i'm a little slow.

> No mockery intended; just proof that I read you.

i didn't take it that way.

>> anyway, i am talking about version 0.6 silicon of the ADSP-21062 SHArC (in
>> 1996) that literally crashed when certain instructions were executed and
>> other problems that i can't remember (some of these bugs did get fixed by
>> 1.0 silicon).    sorta like that floating-point error that was discovered on
>> the Intel Pentiums sometime last decade, that embarrassed Intel so much that
>> the did a total recall of that particular chip.
>> 
>> i would call that a "chip making an error".
> 
> So would I, and I did. It is not a chip *giving* an error. Compilers and
> linkers give (i.e., report) errors.

i get it.  (sloooooowly)

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

robert bristow-johnson wrote:
> in article eJWdnfoJfaSMzMzfRVn-1g@rcn.net, Jerry Avins at jya@ieee.org wrote
> on 04/04/2005 10:36:
> 
> 
>>>well, they don't tell you about it when they do.  (i've had errors because
>>>of fabrication or mask problems with both the 56K and the early SHArC.  it
>>>can be very frustrating.)
>>>
>>
>>Be precise, Robert. What you're claiming is that sometimes DSPs _make_
>>errors. I stand resolute. :-)
> 
> 
> that's funny, i was just making a reference to such a phrase...

I was parroting you. No mockery intended; just proof that I read you.

> anyway, i am talking about version 0.6 silicon of the ADSP-21062 SHArC (in
> 1996) that literally crashed when certain instructions were executed and
> other problems that i can't remember (some of these bugs did get fixed by
> 1.0 silicon).    sorta like that floating-point error that was discovered on
> the Intel Pentiums sometime last decade, that embarrassed Intel so much that
> the did a total recall of that particular chip.
> 
> i would call that a "chip making an error".

So would I, and I did. It is not a chip *giving* an error. Compilers and 
linkers give (i.e., report) errors.

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

in article eJWdnfoJfaSMzMzfRVn-1g@rcn.net, Jerry Avins at jya@ieee.org wrote
on 04/04/2005 10:36:

>> well, they don't tell you about it when they do.  (i've had errors because
>> of fabrication or mask problems with both the 56K and the early SHArC.  it
>> can be very frustrating.)
>> 
> 
> Be precise, Robert. What you're claiming is that sometimes DSPs _make_
> errors. I stand resolute. :-)

that's funny, i was just making a reference to such a phrase...

anyway, i am talking about version 0.6 silicon of the ADSP-21062 SHArC (in
1996) that literally crashed when certain instructions were executed and
other problems that i can't remember (some of these bugs did get fixed by
1.0 silicon).    sorta like that floating-point error that was discovered on
the Intel Pentiums sometime last decade, that embarrassed Intel so much that
the did a total recall of that particular chip.

i would call that a "chip making an error".

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

robert bristow-johnson wrote:
> in article FcednXqevck6oc3fRVn-vQ@rcn.net, Jerry Avins at jya@ieee.org wrote
> on 04/03/2005 14:57:
> 
> 
>>Diux wrote:
>>
>>>Thank you mark for you answer. My problem is that I can't de FFT,
>>>because I am using a fixed point, and the DSP gives errors when I
>>>compile the algorithm.
>>
>>The problem is not with your processor, but with your code. DSPs don't
>>give errors.
> 
> 
> well, they don't tell you about it when they do.  (i've had errors because
> of fabrication or mask problems with both the 56K and the early SHArC.  it
> can be very frustrating.)
> 

Be precise, Robert. What you're claiming is that sometimes DSPs _make_ 
errors. I stand resolute. :-)

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

in article FcednXqevck6oc3fRVn-vQ@rcn.net, Jerry Avins at jya@ieee.org wrote
on 04/03/2005 14:57:

> Diux wrote:
>> Thank you mark for you answer. My problem is that I can't de FFT,
>> because I am using a fixed point, and the DSP gives errors when I
>> compile the algorithm.
> 
> The problem is not with your processor, but with your code. DSPs don't
> give errors.

well, they don't tell you about it when they do.  (i've had errors because
of fabrication or mask problems with both the 56K and the early SHArC.  it
can be very frustrating.)

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

Diux wrote:
> Thank you mark for you answer. My problem is that I can't de FFT,
> because I am using a fixed point, and the DSP gives errors when I
> compile the algorithm.
> 
> Thank you

The problem is not with your processor, but with your code. DSPs don't 
give errors.

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

Thank you mark for you answer. My problem is that I can't de FFT,
because I am using a fixed point, and the DSP gives errors when I
compile the algorithm.

Thank you

Diux wrote:
> Thanks for your fast answers. I dowloaded the algorithms sugessted in
> this page. But I want an example that how call it algorithm. Can you
> send me a short code in C about it. Thank you.

The README file in the .tar.gz/.zip archive has example code.  There are 
  other examples in the tools directory.

If you are struggling with your development environment, I cannot help 
you.  I am not familiar with the DSP chip you mentioned.

If you are struggling with the concept of the DFT itself, you need to 
refer to a decent textbook.  Hopefully, you can find a good one in your 
native language (Spanish?).

Cheers,
Mark

Thanks for your fast answers. I dowloaded the algorithms sugessted in
this page. But I want an example that how call it algorithm. Can you
send me a short code in C about it. Thank you.

Diux wrote:
> I'm working with a motorola's DSP56824. But I need a library or
> algorithm to calculate de FFT (256 points and 1 Dimension). The
> problem is that I'm working with codewarrior(to programm with C), but
> I tried to compile some algorithms but they doesn't compile. Someone
> knows a link for a free FFT algorithm por DSP. Than You

Have a look at

http://sourceforge.net/projects/kissfft