From: Wolfgang Denk <wd@denx.de>
To: "Young-Han, Kim" <yhkim@da-san.com>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: MPC 8xx as SPI slave...
Date: Wed, 26 Mar 2003 08:03:17 +0100 [thread overview]
Message-ID: <20030326070322.93F25C58BA@atlas.denx.de> (raw)
In-Reply-To: Your message of "Wed, 26 Mar 2003 11:50:51 +0900." <000b01c2f342$8347d830$337ceccb@dasan.com>
In message <000b01c2f342$8347d830$337ceccb@dasan.com> you wrote:
>
> I will use the MPC 8xx as SPI slave, the SPI master is not MPC 8xx.
> Currently, using the SPI interrupt for RX/TX on MPC 8xx.
> The SPI write operation on SPI master is run very well.
> But, SPI read operation on SPI master is not so good.
> When SPI read operation on SPI master, the CPM of MPC 8xx
> report the SPI TX interrupt as TX done.
> But, the MPC 8xx SPI not transmit that data on SPI bus,
> just transmit old TX data.
> In second SPI read operation on SPI master, the MPC 8xx SPI
> transmit previous data of TX BD.
This could be a cache issue. Which source is your SPI driver based on?
> It means that the MPC 8xx SPI not transmit the data on time.
> I was checked with oscilloscope.
Does the 8xx transfer data at all? You know, SPI has a very, very low
priority onthe CPM, so it will be starved by any other I/O (like
ethernet and especially USB).
Motorola writes:
Note that the SPI is of lower priority internally than the
SCCs, thus, the SPI will be the first device to be "starved".
Snce it has no FIFO, it is especially sensitive to underruns.
The best way to prevent this is to use a buffer size of 1
"character" (of size programmed in the mode register).
...
The physical clocking speed of the SPI can be up to 12 MHz.
However, it only has a 16-bit holding register. Thus, the 12
Mbit/sec rate can only be sustained for 16 bits. If you need
to transmit more than 2-bytes of data at that clocking rate,
you must put the data into separate BDs and set the data
length to 2 and set the L bit in each BD. If you are using a
character length of 16-bits, the maximum clocking rate is 3.1
Mbit/sec. If you are using a character length of 8 bits, the
maximum is 500 Kbits/sec. Note that 500 Kbits/sec is the
maximum throughput when no other peripherals (SCCs, SMCs) are
being used. Load on those peripherals will further reduce the
maximum data rate through the SPI.
[This calculation is based on a 25 MHz clock.]
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
People seldom know what they want until you give them what they ask
for.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-03-26 7:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-26 2:50 MPC 8xx as SPI slave Young-Han, Kim
2003-03-26 7:03 ` Wolfgang Denk [this message]
2003-03-26 9:44 ` Young-Han, Kim
2003-03-26 11:02 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030326070322.93F25C58BA@atlas.denx.de \
--to=wd@denx.de \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=yhkim@da-san.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).