Can an SPI slave start a transmission in full-duplex mode?STM32 SPI not working as I expect it should based on online readingSerial Peripheral InterfaceSPI slave unreliable on PIC18LF2550Full duplex SPI Master using DMA - STM32F105STM32F2xx: Data from SPI Slave to MasterWhat is holding the SS pin high in SPI master mode on AVRs?STM32F411 SPI slave enters debug infinite loopSPI daisy chain read receive from slaveSPI clock source - master or slaveSPI internals _ missing MISO clock during read operationSPI: Receiving bytes from slave
How to query data in backups?
Is there a way to create a report for the failed entries while calling REST API
Double blind peer review when paper cites author's GitHub repo for code
Atari ST DRAM timing puzzle
Can an SPI slave start a transmission in full-duplex mode?
Why couldn't soldiers sight their own weapons without officers' orders?
Arrange a list in ascending order by deleting list elements
Did WWII Japanese soldiers engage in cannibalism of their enemies?
What is the idiomatic way of saying “he is ticklish under armpits”?
English - Acceptable use of parentheses in an author's name
Do other countries guarantee freedoms that the United States does not have?
Does the United States guarantee any unique freedoms?
What are good ways to improve as a writer other than writing courses?
Why are physicists so interested in irreps if in their non-block-diagonal form they mix all components of a vector?
How do we avoid CI-driven development...?
How does The Fools Guild make its money?
Look mom! I made my own (Base 10) numeral system!
Can I call myself an assistant professor without a PhD
Is there a loss of quality when converting RGB to HEX?
Is it really ~648.69 km/s delta-v to "land" on the surface of the Sun?
Team goes to lunch frequently, I do intermittent fasting but still want to socialize
Best gun to modify into a monsterhunter weapon?
What happen if I gain the control of aura that enchants an opponent's creature? Would the aura stay attached?
Plausibility of Ice Eaters in the Arctic
Can an SPI slave start a transmission in full-duplex mode?
STM32 SPI not working as I expect it should based on online readingSerial Peripheral InterfaceSPI slave unreliable on PIC18LF2550Full duplex SPI Master using DMA - STM32F105STM32F2xx: Data from SPI Slave to MasterWhat is holding the SS pin high in SPI master mode on AVRs?STM32F411 SPI slave enters debug infinite loopSPI daisy chain read receive from slaveSPI clock source - master or slaveSPI internals _ missing MISO clock during read operationSPI: Receiving bytes from slave
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
As far as I know, SPI transmission for an SPI slave works like below:
- Master selects a slave using SS pin
- Master and slave send data to each other simultaneously
- Master starts clock and data transmission at the same time (there is no clock before write operation)
- Master stops transmission any time it wants (by stopping write operation and clock generation), even if slave has more data to send.
Is there any SPI slave configuration which allows slave to transmit data without permission of master?
I'm just thinking out loud. Assume that there is only one slave and a continuous clock is provided by master etc.
Even if assumed statement is true, don't master and slave lose byte synchronization (i.e. receives bit stream) since there is no start-stop bits for SPI?
I'm asking such a question because I've read the following section from this document.
2.2 SPI Example
The attached SPI example illustrates the use of the USART in
synchronous mode. USART1 is configured as slave, whereas USART2 is
master. The following transactions take place:
- Data transmission from master to slave.
- Data transmission from slave to master.
- Data transmission from master to slave and from slave to master simultaneously.
The document gives SPI example but realizes the example using USART devices. And I get that a USART slave can start a transmission without permission of master.
I couldn't find the source code that is referenced by the document.
microcontroller spi uart serial
New contributor
$endgroup$
add a comment |
$begingroup$
As far as I know, SPI transmission for an SPI slave works like below:
- Master selects a slave using SS pin
- Master and slave send data to each other simultaneously
- Master starts clock and data transmission at the same time (there is no clock before write operation)
- Master stops transmission any time it wants (by stopping write operation and clock generation), even if slave has more data to send.
Is there any SPI slave configuration which allows slave to transmit data without permission of master?
I'm just thinking out loud. Assume that there is only one slave and a continuous clock is provided by master etc.
Even if assumed statement is true, don't master and slave lose byte synchronization (i.e. receives bit stream) since there is no start-stop bits for SPI?
I'm asking such a question because I've read the following section from this document.
2.2 SPI Example
The attached SPI example illustrates the use of the USART in
synchronous mode. USART1 is configured as slave, whereas USART2 is
master. The following transactions take place:
- Data transmission from master to slave.
- Data transmission from slave to master.
- Data transmission from master to slave and from slave to master simultaneously.
The document gives SPI example but realizes the example using USART devices. And I get that a USART slave can start a transmission without permission of master.
I couldn't find the source code that is referenced by the document.
microcontroller spi uart serial
New contributor
$endgroup$
4
$begingroup$
The slave, by definition, cannot initiate a transaction (it may be able to interrupt the master to get a transaction started though).
$endgroup$
– Peter Smith
9 hours ago
4
$begingroup$
Unidirectional data transfer in traditional SPI is just someone ignoring the state of the line going in the other direction. Writes, reads, and bidirectional transfers aren't really any different. In fact for example many SPI peripherals will clock out a status word during the first word, before they even know what is being requested, since it costs next to nothing to do so and allows a quick status polling.
$endgroup$
– Chris Stratton
8 hours ago
add a comment |
$begingroup$
As far as I know, SPI transmission for an SPI slave works like below:
- Master selects a slave using SS pin
- Master and slave send data to each other simultaneously
- Master starts clock and data transmission at the same time (there is no clock before write operation)
- Master stops transmission any time it wants (by stopping write operation and clock generation), even if slave has more data to send.
Is there any SPI slave configuration which allows slave to transmit data without permission of master?
I'm just thinking out loud. Assume that there is only one slave and a continuous clock is provided by master etc.
Even if assumed statement is true, don't master and slave lose byte synchronization (i.e. receives bit stream) since there is no start-stop bits for SPI?
I'm asking such a question because I've read the following section from this document.
2.2 SPI Example
The attached SPI example illustrates the use of the USART in
synchronous mode. USART1 is configured as slave, whereas USART2 is
master. The following transactions take place:
- Data transmission from master to slave.
- Data transmission from slave to master.
- Data transmission from master to slave and from slave to master simultaneously.
The document gives SPI example but realizes the example using USART devices. And I get that a USART slave can start a transmission without permission of master.
I couldn't find the source code that is referenced by the document.
microcontroller spi uart serial
New contributor
$endgroup$
As far as I know, SPI transmission for an SPI slave works like below:
- Master selects a slave using SS pin
- Master and slave send data to each other simultaneously
- Master starts clock and data transmission at the same time (there is no clock before write operation)
- Master stops transmission any time it wants (by stopping write operation and clock generation), even if slave has more data to send.
Is there any SPI slave configuration which allows slave to transmit data without permission of master?
I'm just thinking out loud. Assume that there is only one slave and a continuous clock is provided by master etc.
Even if assumed statement is true, don't master and slave lose byte synchronization (i.e. receives bit stream) since there is no start-stop bits for SPI?
I'm asking such a question because I've read the following section from this document.
2.2 SPI Example
The attached SPI example illustrates the use of the USART in
synchronous mode. USART1 is configured as slave, whereas USART2 is
master. The following transactions take place:
- Data transmission from master to slave.
- Data transmission from slave to master.
- Data transmission from master to slave and from slave to master simultaneously.
The document gives SPI example but realizes the example using USART devices. And I get that a USART slave can start a transmission without permission of master.
I couldn't find the source code that is referenced by the document.
microcontroller spi uart serial
microcontroller spi uart serial
New contributor
New contributor
edited 8 hours ago
bitsmack
13.3k7 gold badges38 silver badges82 bronze badges
13.3k7 gold badges38 silver badges82 bronze badges
New contributor
asked 9 hours ago
JeJoRicJeJoRic
183 bronze badges
183 bronze badges
New contributor
New contributor
4
$begingroup$
The slave, by definition, cannot initiate a transaction (it may be able to interrupt the master to get a transaction started though).
$endgroup$
– Peter Smith
9 hours ago
4
$begingroup$
Unidirectional data transfer in traditional SPI is just someone ignoring the state of the line going in the other direction. Writes, reads, and bidirectional transfers aren't really any different. In fact for example many SPI peripherals will clock out a status word during the first word, before they even know what is being requested, since it costs next to nothing to do so and allows a quick status polling.
$endgroup$
– Chris Stratton
8 hours ago
add a comment |
4
$begingroup$
The slave, by definition, cannot initiate a transaction (it may be able to interrupt the master to get a transaction started though).
$endgroup$
– Peter Smith
9 hours ago
4
$begingroup$
Unidirectional data transfer in traditional SPI is just someone ignoring the state of the line going in the other direction. Writes, reads, and bidirectional transfers aren't really any different. In fact for example many SPI peripherals will clock out a status word during the first word, before they even know what is being requested, since it costs next to nothing to do so and allows a quick status polling.
$endgroup$
– Chris Stratton
8 hours ago
4
4
$begingroup$
The slave, by definition, cannot initiate a transaction (it may be able to interrupt the master to get a transaction started though).
$endgroup$
– Peter Smith
9 hours ago
$begingroup$
The slave, by definition, cannot initiate a transaction (it may be able to interrupt the master to get a transaction started though).
$endgroup$
– Peter Smith
9 hours ago
4
4
$begingroup$
Unidirectional data transfer in traditional SPI is just someone ignoring the state of the line going in the other direction. Writes, reads, and bidirectional transfers aren't really any different. In fact for example many SPI peripherals will clock out a status word during the first word, before they even know what is being requested, since it costs next to nothing to do so and allows a quick status polling.
$endgroup$
– Chris Stratton
8 hours ago
$begingroup$
Unidirectional data transfer in traditional SPI is just someone ignoring the state of the line going in the other direction. Writes, reads, and bidirectional transfers aren't really any different. In fact for example many SPI peripherals will clock out a status word during the first word, before they even know what is being requested, since it costs next to nothing to do so and allows a quick status polling.
$endgroup$
– Chris Stratton
8 hours ago
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
No, with SPI, all communications are driven by the master device. You are correct that the master cannot simply provide a continuous clock; there would be no way to detect the byte boundaries.
A slave device will often have a separate output pin to signal to the master that it has data available. This pin is connected to an input on a microcontroller and is often used as an interrupt.
Then, the device can assert the pin, causing the microcontroller to spin up the SPI bus.
For more detailed information, please read on :) This is a slightly-modified version of an explanation found here:
The slave device can only communicate when it is provided a clock from the master. This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.
When you send an SPI command from the master, two transmissions actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.
But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.
Then you need to provide an additional eight clocks to allow the slave to return the actual value. In many code implementations, this is done by sending a "dummy byte" to the slave.
Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.
That describes the general case. There can be additional complexities. For example, some slave ICs will actually output some sort of status byte at the same time they are receiving a command from the master. So, in this case, the master shouldn't discard the first received byte.
$endgroup$
1
$begingroup$
"the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately.
$endgroup$
– Aaron
4 hours ago
$begingroup$
@Aaron Good to know! People keep getting more and more clever :-)
$endgroup$
– bitsmack
1 hour ago
add a comment |
$begingroup$
No, master is the one that arbitrates the chipselects and drives the clock. A slave will always only listen to clock and chipselect. Data transfer can be full duplex still. There are some implementations where the clock can be continuous, but it does not matter much as the chipselect is used to synchronize the byte boundaries anyway. But then there are multimaster systems, so basically you can have some mechanism for the devices to decide who is slave and master. Or just include a separate "interrupt" wire for the slave to signal the master that it has a data packet for the master.
$endgroup$
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("schematics", function ()
StackExchange.schematics.init();
);
, "cicuitlab");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "135"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
JeJoRic is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f452278%2fcan-an-spi-slave-start-a-transmission-in-full-duplex-mode%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
No, with SPI, all communications are driven by the master device. You are correct that the master cannot simply provide a continuous clock; there would be no way to detect the byte boundaries.
A slave device will often have a separate output pin to signal to the master that it has data available. This pin is connected to an input on a microcontroller and is often used as an interrupt.
Then, the device can assert the pin, causing the microcontroller to spin up the SPI bus.
For more detailed information, please read on :) This is a slightly-modified version of an explanation found here:
The slave device can only communicate when it is provided a clock from the master. This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.
When you send an SPI command from the master, two transmissions actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.
But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.
Then you need to provide an additional eight clocks to allow the slave to return the actual value. In many code implementations, this is done by sending a "dummy byte" to the slave.
Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.
That describes the general case. There can be additional complexities. For example, some slave ICs will actually output some sort of status byte at the same time they are receiving a command from the master. So, in this case, the master shouldn't discard the first received byte.
$endgroup$
1
$begingroup$
"the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately.
$endgroup$
– Aaron
4 hours ago
$begingroup$
@Aaron Good to know! People keep getting more and more clever :-)
$endgroup$
– bitsmack
1 hour ago
add a comment |
$begingroup$
No, with SPI, all communications are driven by the master device. You are correct that the master cannot simply provide a continuous clock; there would be no way to detect the byte boundaries.
A slave device will often have a separate output pin to signal to the master that it has data available. This pin is connected to an input on a microcontroller and is often used as an interrupt.
Then, the device can assert the pin, causing the microcontroller to spin up the SPI bus.
For more detailed information, please read on :) This is a slightly-modified version of an explanation found here:
The slave device can only communicate when it is provided a clock from the master. This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.
When you send an SPI command from the master, two transmissions actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.
But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.
Then you need to provide an additional eight clocks to allow the slave to return the actual value. In many code implementations, this is done by sending a "dummy byte" to the slave.
Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.
That describes the general case. There can be additional complexities. For example, some slave ICs will actually output some sort of status byte at the same time they are receiving a command from the master. So, in this case, the master shouldn't discard the first received byte.
$endgroup$
1
$begingroup$
"the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately.
$endgroup$
– Aaron
4 hours ago
$begingroup$
@Aaron Good to know! People keep getting more and more clever :-)
$endgroup$
– bitsmack
1 hour ago
add a comment |
$begingroup$
No, with SPI, all communications are driven by the master device. You are correct that the master cannot simply provide a continuous clock; there would be no way to detect the byte boundaries.
A slave device will often have a separate output pin to signal to the master that it has data available. This pin is connected to an input on a microcontroller and is often used as an interrupt.
Then, the device can assert the pin, causing the microcontroller to spin up the SPI bus.
For more detailed information, please read on :) This is a slightly-modified version of an explanation found here:
The slave device can only communicate when it is provided a clock from the master. This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.
When you send an SPI command from the master, two transmissions actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.
But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.
Then you need to provide an additional eight clocks to allow the slave to return the actual value. In many code implementations, this is done by sending a "dummy byte" to the slave.
Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.
That describes the general case. There can be additional complexities. For example, some slave ICs will actually output some sort of status byte at the same time they are receiving a command from the master. So, in this case, the master shouldn't discard the first received byte.
$endgroup$
No, with SPI, all communications are driven by the master device. You are correct that the master cannot simply provide a continuous clock; there would be no way to detect the byte boundaries.
A slave device will often have a separate output pin to signal to the master that it has data available. This pin is connected to an input on a microcontroller and is often used as an interrupt.
Then, the device can assert the pin, causing the microcontroller to spin up the SPI bus.
For more detailed information, please read on :) This is a slightly-modified version of an explanation found here:
The slave device can only communicate when it is provided a clock from the master. This complicates reading from the slave, because you have to cause the master to provide enough clock cycles for the slave to respond.
When you send an SPI command from the master, two transmissions actually happen during the same eight clock pulses. The first is that your byte is clocked out of the MOSI line. But, at the same time, data is being clocked in to the microcontroller via the MISO line.
But since the slave doesn't get the full command until the end of these transactions, it doesn't present any data to the bus. This results in a received value of 0x00 or 0xFF.
Then you need to provide an additional eight clocks to allow the slave to return the actual value. In many code implementations, this is done by sending a "dummy byte" to the slave.
Note that, in the first transmission, the master ignores whatever arrives from the slave. In the second transmission, the slave ignores whatever is sent by the master.
That describes the general case. There can be additional complexities. For example, some slave ICs will actually output some sort of status byte at the same time they are receiving a command from the master. So, in this case, the master shouldn't discard the first received byte.
edited 7 hours ago
answered 9 hours ago
bitsmackbitsmack
13.3k7 gold badges38 silver badges82 bronze badges
13.3k7 gold badges38 silver badges82 bronze badges
1
$begingroup$
"the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately.
$endgroup$
– Aaron
4 hours ago
$begingroup$
@Aaron Good to know! People keep getting more and more clever :-)
$endgroup$
– bitsmack
1 hour ago
add a comment |
1
$begingroup$
"the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately.
$endgroup$
– Aaron
4 hours ago
$begingroup$
@Aaron Good to know! People keep getting more and more clever :-)
$endgroup$
– bitsmack
1 hour ago
1
1
$begingroup$
"the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately.
$endgroup$
– Aaron
4 hours ago
$begingroup$
"the master cannot simply provide a continuous clock" Actually I've seen a device not too long ago that does exactly that. It was a weird little beast. I don't recall the P/N unfortunately.
$endgroup$
– Aaron
4 hours ago
$begingroup$
@Aaron Good to know! People keep getting more and more clever :-)
$endgroup$
– bitsmack
1 hour ago
$begingroup$
@Aaron Good to know! People keep getting more and more clever :-)
$endgroup$
– bitsmack
1 hour ago
add a comment |
$begingroup$
No, master is the one that arbitrates the chipselects and drives the clock. A slave will always only listen to clock and chipselect. Data transfer can be full duplex still. There are some implementations where the clock can be continuous, but it does not matter much as the chipselect is used to synchronize the byte boundaries anyway. But then there are multimaster systems, so basically you can have some mechanism for the devices to decide who is slave and master. Or just include a separate "interrupt" wire for the slave to signal the master that it has a data packet for the master.
$endgroup$
add a comment |
$begingroup$
No, master is the one that arbitrates the chipselects and drives the clock. A slave will always only listen to clock and chipselect. Data transfer can be full duplex still. There are some implementations where the clock can be continuous, but it does not matter much as the chipselect is used to synchronize the byte boundaries anyway. But then there are multimaster systems, so basically you can have some mechanism for the devices to decide who is slave and master. Or just include a separate "interrupt" wire for the slave to signal the master that it has a data packet for the master.
$endgroup$
add a comment |
$begingroup$
No, master is the one that arbitrates the chipselects and drives the clock. A slave will always only listen to clock and chipselect. Data transfer can be full duplex still. There are some implementations where the clock can be continuous, but it does not matter much as the chipselect is used to synchronize the byte boundaries anyway. But then there are multimaster systems, so basically you can have some mechanism for the devices to decide who is slave and master. Or just include a separate "interrupt" wire for the slave to signal the master that it has a data packet for the master.
$endgroup$
No, master is the one that arbitrates the chipselects and drives the clock. A slave will always only listen to clock and chipselect. Data transfer can be full duplex still. There are some implementations where the clock can be continuous, but it does not matter much as the chipselect is used to synchronize the byte boundaries anyway. But then there are multimaster systems, so basically you can have some mechanism for the devices to decide who is slave and master. Or just include a separate "interrupt" wire for the slave to signal the master that it has a data packet for the master.
answered 8 hours ago
JustmeJustme
5,9612 gold badges6 silver badges17 bronze badges
5,9612 gold badges6 silver badges17 bronze badges
add a comment |
add a comment |
JeJoRic is a new contributor. Be nice, and check out our Code of Conduct.
JeJoRic is a new contributor. Be nice, and check out our Code of Conduct.
JeJoRic is a new contributor. Be nice, and check out our Code of Conduct.
JeJoRic is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f452278%2fcan-an-spi-slave-start-a-transmission-in-full-duplex-mode%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
$begingroup$
The slave, by definition, cannot initiate a transaction (it may be able to interrupt the master to get a transaction started though).
$endgroup$
– Peter Smith
9 hours ago
4
$begingroup$
Unidirectional data transfer in traditional SPI is just someone ignoring the state of the line going in the other direction. Writes, reads, and bidirectional transfers aren't really any different. In fact for example many SPI peripherals will clock out a status word during the first word, before they even know what is being requested, since it costs next to nothing to do so and allows a quick status polling.
$endgroup$
– Chris Stratton
8 hours ago