DSPRelated.com
Forums

ADSP-21065L to Coldfire

Started by Steve Holle September 2, 2003
Calculate the cost/benefit of having bus driver.
Could think of alternatively using just a serial
IF to talk to each DSP from host side.
It mostly depend on teh amount of data you
need to transfer. ADSP21161 has nice
paralell independet ports for that.
This chip makes many things much easier.

----- Original Message -----
From: "Mike Rosing" <>
To: "Steve Holle" <>
Cc: <>
Sent: Wednesday, September 03, 2003 8:03 PM
Subject: Re: [adsp] ADSP-21065L to Coldfire > On Wed, 3 Sep 2003, Steve Holle wrote:
>
> > Each 21065L will have it's own SRAM and each host port will be mapped
into
> > a separate memory mapped area in the Coldfire.
>
> But data bus is common (or how else does Coldfire talk to each 21065?).
> If every dsp has it's own address and data bus, and you use a tristate
> switch to connect the Coldfire to one dsp at a time, you'd have a very
> fast system since each dsp would only have to relinquish its bus when
> the Coldfire needs to get in.
>
> A very nice toy :-) Have fun with it!
>
> Patience, persistence, truth,
> Dr. mike >
> _____________________________________
> Note: If you do a simple "reply" with your email client, only the author
of this message will receive your answer. You need to do a "reply all" if
you want your answer to be distributed to the entire group.
>
> _____________________________________
> About this discussion group:
>
> To Join: Send an email to
>
> To Post: Send an email to
>
> To Leave: Send an email to
>
> Archives: http://groups.yahoo.com/group/adsp
>
> Other Groups: http://www.dsprelated.com/groups.php3 > ">http://docs.yahoo.com/info/terms/



I spoke too soon!!

After setting those two bits, I was able to transmit a single word
without getting the two extra words.

When I tried transmitting more data, I ran into another problem!! I
am using the SPI by core access, not DMA. I have a buffer with 5
words to transmit. I can write out the first two, but the next two
don't come out and the 5th causes a core hang, because I am writing
to a full FIFO. For some reason, the data stops coming out of the
SPITX. I haven't written to the SPICTL or anything. I don't
understand. ADI is looking at it, but I don't have much confidence
in them being able to help. They weren't the ones who helped with
the my first problem. Their suggestion, so far is to use DMA. I
would rather just have the thing work like it's supposed to.

If I clear those two bits, I can write as many words out as I want.
Of course, I have a problem writing out less than 3 words like
before! This is getting very frustrating. I have 6 devices on the
SPI, that I need to talk to. I am beginning to doubt that I will be
able to get any of this working!!!

Robert Allen,
Senior Software Engineer
Goodrich Sensor Systems

--- In , "rallen_prsch911" <rallen_prsch911@y...>
wrote:
> I have one of the 21161N EZ-KITs, and it has rev 1.2 chip on it,
and
> it was still acting up.
>
> Al Clark steered me to the documentation errata, that states both
> SPRINT and SPTINT bits need to be set for correct operation of the
> SPI hardware. After I enable the interrupts, things worked fine.
>
> Thanks for the input.
>
> Robert Allen
> Senior Software Engineer
> Goodrich Sensor Systems
>
> --- In , h h <hh_ca@y...> wrote:
> > I had a whole lot of SPI fun on the 21161N with the
> > 21161N configured as a slave. I was told by an AD
> > field support engineer that there were some problems
> > with their dsp revision 1.0(or 1.1?). The newer
> > revision 1.2 and above is supposed to solve those
> > issues. So if you are having problems with 21161 SPI,
> > check the hardware revision.
> >
> >
> >
> > __________________________________
> >




Just for everyone's information, I got the following response from
ADI. I know that the SPI bus is full duplex, but nowhere in the
documentation does it say that the SPIRX must be at least partially
empty before the SPITX will shift out data. I tried disabling the
MISO pin with the DMISO bit, but that didn't help any.

I should not have assumed that if the GM bit is clear, incoming data
that gets overwritten would be discarded and the SPI port would
basically ignore it.

"I have contacted the designers regarding your problem. I was told
that since
SPI in LCHH is intended to be full duplex, the SPICLK will stall on
transmit
buffer becoming empty OR on receive buffer becoming full. This is the
expected
behavior from the SPI. Dummy reads from the receive buffer will have
to be done
even if the received data is not of interest. Please insert a dummy
read of
receive buffer in the SPI transmit interrupt service routine in order
to avoid
the problem that you are facing. This will be mentioned clearly in
the next
version of the hardware reference manual. We apologize for the
inconvenience
caused."

I hope this will prevent someone else from running around so much on
this in the future.

Robert Allen
Senior Software Engineer
Goodrich Sensor Systems

--- In , h h <hh_ca@y...> wrote:
> I had a whole lot of SPI fun on the 21161N with the
> 21161N configured as a slave. I was told by an AD
> field support engineer that there were some problems
> with their dsp revision 1.0(or 1.1?). The newer
> revision 1.2 and above is supposed to solve those
> issues. So if you are having problems with 21161 SPI,
> check the hardware revision. >
> __________________________________
>