I got a basic question considering SPI coding... how can the master display what is received from the slave once the data is sent... so i know if the spi is working well on both sides,
and do i need to set the clock on both sides ? or just on the arduino uno (master) is enough?
You send the clock from the master. While the clock is ticking the master sends out data to the slave. At the same time the master reads data from the slave.
If you see the clock as a square wave, typically the master sets the data output pin to the right bit on the rising edge of the square wave, and reads the state of the data input pin on the falling edge of the square wave.
If you want to read data after sending data you will have to send some dummy data from the master so the slave can send its data at the same time.
majenko:
You send the clock from the master. While the clock is ticking the master sends out data to the slave. At the same time the master reads data from the slave.
ok then as far a i understand . a clock from the slave isnt important, the only step is to set it from the master.
If you want to read data after sending data you will have to send some dummy data from the master so the slave can send its data at the same time.
can you elaborate more on the dummy data, it'll be good if u give me a rough example...
Not only is a clock from the slave "not important", but it is impossible. A slave does not, can not, nor ever will generate a clock. The moment it generares a clock it becomes a master.
"dummy data" can be absolutely anything. Commonly 0x00 or 0xFF are used (0 or 255) as the data out line is then held at one fixed level which can reduce crosstalk.
For example, if you have a system where you send a command byte from the master to the slave, then the master needs to wait for acknowledgement from the slave, you might do something like this:
unsigned char response;
SPI.transfer(0x48); // Send the command byte 0x4
while ((response = SPI.transfer(0x00)) == 0); // Wait for an SPI transferred byte to not equal 0, and store it in response
// Now you can do something with response
A slave receiving clocks will be receiving data. It should be arranged such that the data it receives between the command byte and sending the response should be ignored.
Note also that the slave does not "send" the response back, but it places it in a buffer ready to be "collected" by the master. Only when the master sends a byte to the slave can the response be read back from that buffer.
majenko:
Not only is a clock from the slave "not important", but it is impossible. A slave does not, can not, nor ever will generate a clock. The moment it generares a clock it becomes a master.
"dummy data" can be absolutely anything. Commonly 0x00 or 0xFF are used (0 or 255) as the data out line is then held at one fixed level which can reduce crosstalk.
For example, if you have a system where you send a command byte from the master to the slave, then the master needs to wait for acknowledgement from the slave, you might do something like this:
unsigned char response;
SPI.transfer(0x48); // Send the command byte 0x4
while ((response = SPI.transfer(0x00)) == 0); // Wait for an SPI transferred byte to not equal 0, and store it in response
// Now you can do something with response
A slave receiving clocks will be receiving data. It should be arranged such that the data it receives between the command byte and sending the response should be ignored.
Note also that the slave does not "send" the response back, but it places it in a buffer ready to be "collected" by the master. Only when the master sends a byte to the slave can the response be read back from that buffer.
What is even more fun is what the slave is. If the slave is another Arduino, it has it's own clock and can do things on it's own, but relies on the master SPI device for the SPI communication. But with some SD cards that I've used they didn't seem to have their own internal oscillator. So I would need to feed it extra nothings just to give it clock cycles to prepare for the next incoming command. (Boy did that take some creative troubleshooting to figure out as some SD cards needed those extra cycles and some didn't... For the insanely curious here is the stackoverflow thread that I started to try to figure this out... embedded - Initializing SD card in SPI issues - Stack Overflow)
majenko:
"dummy data" can be absolutely anything. Commonly 0x00 or 0xFF are used (0 or 255) as the data out line is then held at one fixed level which can reduce crosstalk.
For example, if you have a system where you send a command byte from the master to the slave, then the master needs to wait for acknowledgement from the slave, you might do something like this:
unsigned char response;
SPI.transfer(0x48); // Send the command byte 0x4
while ((response = SPI.transfer(0x00)) == 0); // Wait for an SPI transferred byte to not equal 0, and store it in response
// Now you can do something with response
A slave receiving clocks will be receiving data. It should be arranged such that the data it receives between the command byte and sending the response should be ignored.
Note also that the slave does not "send" the response back, but it places it in a buffer ready to be "collected" by the master. Only when the master sends a byte to the slave can the response be read back from that buffer.
What i understood from the code is the following , please correct me if am wrong (please bare with me :
while the SPI. is transferring 0x48 then confirm with the unsigned char "response" (any number from 0 to 255) to be printed on screen. is that right ?
another thing,,,what i got mixed feeling about is the response variable... it looks like its generated by the code , its like
if step A then print B .
in other words, the response variable merely shows that the data is sent , but not received by the master.. am i right ?
however, i did put the code in setup() and it gave me on screen "1" even without using digitalWrite(ss,HIGH/LOW);
and gave me 0 when i put the code between digitalWrite(ss,HIGH/LOW);
why not same result ??