[Dspforum] bitrev_index

[Doug Wenstrand]

I think I'm answering your question, but if I misunderstood, please clarify:
You are generating the table using the code provided.  You are able to run
it on the DSP, and it works, but you are trying to follow the comment in
the DSP library programmers reference which says : "this should be generated
at compile time, not in the DSP"

That comment seems a little funny to me, because the function doesn't care
how that table got there, just that it is there.  In my opinion, the
description of that function shouldn't give you general programming advice
:) I suppose that the code for generating it will take up more space than
the table itself, so it seems wasteful to generate it on board; however you
can go right ahead.

Again --

Go ahead and just make the index table on the DSP if you like.  Of course,
_only make it once_, don't call it each time you call the bitrev function...
that would be wasteful of clock cycles, which is what we really care about
in this case

Now, if you wanted to export data in shorts, it is a little bit of a pain.
 I often use hex, which makes it easier to parse the data later.  Still,
like you point out, everything will come out in 32bit values, so you will
have to do some post processing


On Wed, Oct 14, 2009 at 11:22 AM, Kyungjin Lim <klim7 at jhu.edu> wrote:

> Hi
>
> I am having hard time to generate bitrev_index from C file provided.
> However, DSP seems to be all right. What is the best way to convert DSP
> memory of short to C-array? File->Dada->Save doesn't have the option for
> short. I tried several of them, and none of the option preserved the data
> type.
>
> Thank you.
>
> Regards,
>
> Kayjin Lim
>
> _______________________________________________
> Dspforum mailing list
> Dspforum at echelonembedded.com
> http://echelonembedded.com/mailman/listinfo/dspforum_echelonembedded.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://echelonembedded.com/pipermail/dspforum_echelonembedded.com/attachments/20091014/7113b279/attachment.html>