Code: Select all
assign MOSI[1] = MOSI[0], SCLK[1] = SCLK[0];
assign MOSI[2] = MOSI[0], SCLK[2] = SCLK[0];Am I right in saying that MOSI and SCLK signals are all shorted together? What's the purpose of this? (I'm a relative novice with SPI)
Why are the SPI MISO and SCLK signals shorted together?
Why are the SPI MISO and SCLK signals shorted together?
I'm curious about the following lines in the RISC5Top Source code. (I hope it's okay to post this little snippet of source)
Am I right in saying that MOSI and SCLK signals are all shorted together? What's the purpose of this? (I'm a relative novice with SPI)
Am I right in saying that MOSI and SCLK signals are all shorted together? What's the purpose of this? (I'm a relative novice with SPI)
-
cfbsoftware
- Site Admin
- Posts: 517
- Joined: Fri Dec 31, 2010 12:30 pm
- Contact:
Re: Why are the SPI MISO and SCLK signals shorted together?
My understanding is that only one SPI device on the RISC5 system is active at any time. In section 17.2.3. The SPI interface for the SD-card (disk) and the Net of the book Project Oberon - The Design of an Operating System, a Compiler, and a Computer. it states:
However, the SS (Slave Select) connection is separate for each SPI device. A device is enabled when SS for that device goes low.Here, however, no use is made of SPI's ring topology. Instead, One master interface is serving both the disk and the net.
Re: Why are the SPI MISO and SCLK signals shorted together?
I think we should differentiate between the SPI device itself, and SPI-connected devices, for lack of a better term. The SPI device is implemented in the FPGA, the SPI-connected devices are, well, connected to this SPI device. The SD card is an SPI-connected device, as is the RTC if installed.
Using this distinction and terminology, out of the box, Embedded Project Oberon (EPO) has one SPI device, and provides three CS (chip select, or SS, slave select) lines. Any GPIO pin could be used to provide more CS signals if needed. The three default CS lines are a convenience feature to make coding simpler (see the SPI module, and the spiCtrl register in the FPGA hardware). Of the three CS lines {0..2}, the SD card uses CS = 0, the RTC by default uses CS = 1. Note that the CS bit for the SD card is hard coded in several places of the Oberon system code, it's better to leave this alone.
The general concept and design of SPI is that all signal lines, ie. MOSI, MISO, and SCLK, are common for all SPI-connected devices, only the CS signals are separate and distinct for each connected device, exactly as implemented in EPO. That we get MOSI[0] and MOSI[1] etc. as separate physical outputs is also a convenience feature to make connections easier. We also could just use one MOSI line for all connected devices and actually wire the signals together in hardware off the board (as long as we stay within electrical limits of the FPGA's ports). Of course, the CS lines must be physically separate, and only one is supposed to be active at any time.
So even if EPO has three explicit MOSI, MISO, SCLK and CS lines, it's possible to connect four SPI-connected devices. Just connect two external devices to the same MOSI, MISO and SCLK lines, and use a GPIO signal as CS line for the fourth device (again, make sure the thusly connected devices stay within the electrical limits of the FPGA ports).
Each connected device is supposed to "listen" all the time, but is only allowed to "reply" if its CS line is selected (pulled low). That is, all connected devices receive all MOSI information, but ignore it unless their CS input is active, and may send data via MISO if, and only if, their CS is active. The MISO line is pulled high in hardware, and the connected devices use an open-collector output, so that they don't interfere when another connected device uses MISO to send data.
On my Arty board I have three SPI devices, each with its own MOSI, MISO, and SCLK lines, and each with its own and distinct set of CS lines for the connected devices, and of course each with separate IO addresses for control and data. This allows me to experiment with SPI devices while being sure that I don't interfere with the SD card in case I make a mistake, either in hardware/wiring or software, as I, alas, am wont to do. Interfering with the SD card can result in the system not even loading, which is hard to debug. I recently finally installed the RTC as described elsewhere in this forum, but until I was sure everything worked, I used a separate SPI device, and only then connected it to the same SPI device as the SD card, freeing the other SPI device. Of my three SPI devices two are unbuffered, one is buffered.
PS: the above applies to the situation with the RISC5 processor being the master.
Using this distinction and terminology, out of the box, Embedded Project Oberon (EPO) has one SPI device, and provides three CS (chip select, or SS, slave select) lines. Any GPIO pin could be used to provide more CS signals if needed. The three default CS lines are a convenience feature to make coding simpler (see the SPI module, and the spiCtrl register in the FPGA hardware). Of the three CS lines {0..2}, the SD card uses CS = 0, the RTC by default uses CS = 1. Note that the CS bit for the SD card is hard coded in several places of the Oberon system code, it's better to leave this alone.
The general concept and design of SPI is that all signal lines, ie. MOSI, MISO, and SCLK, are common for all SPI-connected devices, only the CS signals are separate and distinct for each connected device, exactly as implemented in EPO. That we get MOSI[0] and MOSI[1] etc. as separate physical outputs is also a convenience feature to make connections easier. We also could just use one MOSI line for all connected devices and actually wire the signals together in hardware off the board (as long as we stay within electrical limits of the FPGA's ports). Of course, the CS lines must be physically separate, and only one is supposed to be active at any time.
So even if EPO has three explicit MOSI, MISO, SCLK and CS lines, it's possible to connect four SPI-connected devices. Just connect two external devices to the same MOSI, MISO and SCLK lines, and use a GPIO signal as CS line for the fourth device (again, make sure the thusly connected devices stay within the electrical limits of the FPGA ports).
Each connected device is supposed to "listen" all the time, but is only allowed to "reply" if its CS line is selected (pulled low). That is, all connected devices receive all MOSI information, but ignore it unless their CS input is active, and may send data via MISO if, and only if, their CS is active. The MISO line is pulled high in hardware, and the connected devices use an open-collector output, so that they don't interfere when another connected device uses MISO to send data.
On my Arty board I have three SPI devices, each with its own MOSI, MISO, and SCLK lines, and each with its own and distinct set of CS lines for the connected devices, and of course each with separate IO addresses for control and data. This allows me to experiment with SPI devices while being sure that I don't interfere with the SD card in case I make a mistake, either in hardware/wiring or software, as I, alas, am wont to do. Interfering with the SD card can result in the system not even loading, which is hard to debug. I recently finally installed the RTC as described elsewhere in this forum, but until I was sure everything worked, I used a separate SPI device, and only then connected it to the same SPI device as the SD card, freeing the other SPI device. Of my three SPI devices two are unbuffered, one is buffered.
PS: the above applies to the situation with the RISC5 processor being the master.