AW: ADSP-21061 (SHARC) programming issue
Started by ●January 30, 2006
-----Ursprgliche Nachricht-----
Von: Yipeng Tang
Gesendet am: Freitag, 27. Januar 2006 18:10
An: ADSP@ADSP...
Betreff: [adsp] ADSP-21061 (SHARC) programming issue
Hi DSP guru,
I am programming for ADSP21061. The code was developed by other developer
who left long time ago. I am trying to understand his code, but I don't
have experience on DSP at all. The DSP is used as a slave that is
listening to the command sent from the master Micro controller. These
interface signals include IRQ0, dsp_data[31:0] SPR0I, etc. According to what I understand, IRQ0 is used to tell DSP to be ready to
receive input data (dsp_data[31:0]). If IRQ0 is 1, then get_command( )
will kick off.
Same as SPR0I. If SPR01 is '1', then isr_handler( ) will kick off.
That is what I understand from the following code. ========================================================================
========
Main ( )
{
...
...
interrupt(SIG_IRQ0, get_command);
interrupt(SIG_SPR0I, isr_handler);
...
...
} get_command(int sig_num)
{
uint32 dsp_command;
dsp_command = dm_port.idata;
switch (dsp_command)
{
case 0x10000000:
set_flag(SET_FLAG0, SET_FLAG);
break;
case 0x20000000:
set_flag(SET_FLAG1, SET_FLAG);
break;
case 0x30000000:
get_input(SAMPLES+MORE_SAMPLES);
break;
case 0x40000000:
get_input(SAMPLES+MORE_SAMPLES);
break;
}
}
void isr_handler(int sig_num)
{
if (calc_freq)
auto_freq_meas();
else
distn_meas();
}
Since get_command ( ) is going to use dm_port data as a command. I assume
the data on dm_port is dsp_data[31:0]. Does that mean dsp_data[31:0]
should be available before IRQ0 becomes '1'? If dsp_data[31:0] come later
then IRQ0, will these data not be latched into DSP?
No, this is not required. dm_port.idata is evaluated in the beginning of
the interrupt service routine. This interrupt service routine is activated
by the processor, but the execution of this routine depends on different
issues: global interrupt enable register - other interrupts actually being
processed, when IRQ0 occurs.
Therefore you cannot be sure that get_command() will be processed
immediately when IRQ0 occurs.
For dm_port.idata this means, that its contents are evaluated at a certain
time later (and you cannot rely on a fixed value for the delay!) According to what the master Micro-controller said, Micro-controller won't
give the dsp_data[31:0] until RD and MS<1> signals from DSP is pulled down.
Where is the DSP code to pull RD, MS<1> or WR up and down?
That depends. Without making assumptions about the signal lines, it's not
easy to tell. There are RD/WR flags which are required to control external
memory chips.
Since memory transfers are usually processed by the internal DMA chip of
the DSP, it will certainly be responsible for the line control.
However, RD and WR might be "self-made" general-purpose lines which have to
be set/cleared by explicit DSP code.
Check the pins on the DSP, to which these signals are connected, find them
in the hardware description/manual of the DSP, then you can find out, what
they really do.
What I guess is, that these lines are used to synchronize bus accesses so
that DSP and micro can write on this bus without conflicts.
And I guess, that there's some additional code describing how the DMA
processor captures data from dsp_data and providing it in a latched memory
location dm_port.idata.
In this case, you could possibly rely on the contents being present at the
time of the interrupt's servicing. You'll have to find out...
Is set_flag ( ) system function?
Take it as a system function or library call. In your case, I'd always
check the code behind such a function. This isn't difficult, since you
could just step through this portion of code in the debugger or simulator
and watch in the disassembly window of the IDDE, what happens while
executing this procedure.
Although it seems trivial, it might give you more insight, and help to
avoid errors because you misunderstand anything.
(Be aware, that there are certain circumstances, where the compiler and
linker might be happy with your code, though it wouldn't work, since such a
library call has no code behind - compiling with different optimizer
levels, enabling/disabling certain compiler pragmas / defines differently
in different modules, might do awkward things.
Especially, if you try to revive outaged or unknown code modules, be aware
of every evil thing which is imaginable, and even worse...! )
Bernhard I attached a diagram in this email for your reference.
Thank you.
Yipeng ----
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.
Ueber das Internet versandte E-Mails koennen leicht unter fremden Namen
erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um
Verstaendnis, dass wir zu Ihrem und unserem Schutz die rechtliche
Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen
ausschliessen.
This E-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this E-mail in
error, please notify the sender immediately and destroy this E-mail. Any
unauthorized copying, disclosure or distribution of the material in this
E-mail is strictly forbidden.
E-mails via Internet can easily be prepared or manipulated by third
persons. For this reason we trust you will understand that, for your own
and our protection, we rule out the legal validity of the foregoing
statements and comments.
