Hello everyone, I think that there may be some confusion about the SPI protocol. The master / slave relationship is fairly well described in the previous parts of this message. It is important that there is no particular "protocol" which governs how the master requests data from the slave. There must be some event that tells the master that the slave has valid data which is ready to be transmitted. This signal can be something like the slave asserting an I/O pin that is connected to an interrupt line of the master. The Master SPI could also just poll the slave every so often with the understanding that $00 is a null byte and just to treat it was a "no data available" indication. Another point, the 68332 (or QSPI really) has 4 PCS lines that can be used as peripheral chip selects. The state of these lines are controlled by the command RAM. This allows 4 SPI periperals to be connected together. (One CS line per peripheral.) In addition, the 4 PCS lines can be used to drive a 1 or 16 selector and then there can be 16 SPI peripherals. Anyway, this is just a little more information. Regards, Charlie -----Original Message----- From: jeffrey.tenney@... [mailto:jeffrey.tenney@...] Sent: Thursday, October 10, 2002 11:45 AM To: 68300@yahoogroups.com Subject: Re: [68300] QSPI - Can it do this? Robert, Your understanding of the master/slave relationship is correct. The master always generates the clock and the CS during any transaction. Transactions are full duplex, but usually the peripheral utilizes the SPI connection only half duplex. Like in your example, the transaction begins with two 8-bit transfers (or one 16-bit transfer if the peripheral is fast) where only MOSI is meaningful. The next N transfers use only MISO because you're just reading data from the peripheral. I've used some peripherals that employ true full-duplex communication. It got a little tricky at times. SPI peripherals (ie, slaves) have specs for the required wait time between sequential transfers while CS remains asserted. This wait time allows the peripheral to get ready for the next transfer, during which the peripheral may have to provide data. Good peripherals allow continuous transfers with no wait time; I guess they're just fast. The CPU32 programs the QSPI with the delay time (DTL in SPCR1) and other important factors. As for the master determining the end of the transfer, the software on the master must know what it is requesting and how many transfers' worth of data to expect. So the CPU32 *does* have to know how many bytes there are to be transferred. What's great about the QSPI is that you can simply set up the entire transaction (multiple SPI transfers) all at once. When it's done, you'll have your data waiting in the QSPI Rx area. Jeff "Robert Manktelow" <robert.manktelow@...> on 10/10/2002 08:57:28 AM Please respond to 68300@yahoogroups.com To: "Yahoo 68300 group" <68300@yahoogroups.com> cc: Subject: [68300] QSPI - Can it do this? Hello All This is a general question about SPI operation, and QSPI on the CPU32 in particular. The Set-up The CPU32 is SPI master and there is one slave. As I understand it the CPU32 is therefore responsible for generating both the SPI clock and the chip select for the slave throughout the transaction. The transaction sequence is the CPU asks for information from the slave, by sending two bytes to it, which define the request. Chip Select, SPI clock and the DO are toggled by the CPU32 to achieve this - so far all is well. The slave has to first decode the request and then respond by sending back a number of bytes, dependant on the request sent. My question is:- How is the slave's response data transferred into the CPU32? The problem I have is that the CPU32 does not know when the response data is likely to start or how many bytes there are to be transferred. Can the QSPI in the CPU32 be set up to do this - i.e. set/maintain the slave's chip active and drive the SPI clock during this "read" part of the transaction. Cheers - Robert Manktelow Telspec Europe Ltd, Rochester, ME1 3QU Phone +44 (0)1634 687 133 extension 2346 --------------------------------------------------- To unsubscribe from this group, send an email to: 68300-unsubscribe@yahoogroups.com To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu <http://www.motorola.com/mcu> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1706554205:HM/A=810373/R=0/*http://geocities.yahoo.com/ps/info?.refer=blrecs> <http://rd.yahoo.com/M=212804.2460941.3878106.2225242/D=egroupweb/S=1706554205:HM/A=810373/R=1/*http://geocities.yahoo.com/ps/info?.refer=blrecs> <http://us.adserver.yahoo.com/l?M=212804.2460941.3878106.2225242/D=egroupmail/S=:HM/A=810373/rand=347756883> --------------------------------------------------- To unsubscribe from this group, send an email to: 68300-unsubscribe@yahoogroups.com To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu <http://www.motorola.com/mcu> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . [Non-text portions of this message have been removed]
Message
RE: [68300] QSPI - Can it do this?
2002-10-10 by Melear Charles-rdph40