Hi
SPI & USART are same. If you made any usart communication program.
You should follow that proceeder.
I'm sorry but SPI and USART are most certainly NOT the same. SPI uses the MSSP peripheral which is quite different to the USART peripheral. Also the means of communication are different as are the hardware level protocols.
Referring back to the original question in the referred to thread (which is really a request to understand how SPI exchanges work) I suggest that you do a search for "SPI" as there are very many descriptions of the SPI process.
Basically SPI is a synchronous exchange of values between a master and a slave device. The master device generates not only the data pulses (often referred to as MOSI - Master Our Slave In) but also the clock pulses. On the defined clock edge (leading or trailing - this is one of the design decisions you need to make) the slave will present its own data bit (often called MISO - Master In Slave out) and clock in the bit from the master. The master will do the same (present the bit from the value it is sending and receive the bit from the slave).
A master is able to communicate with several slave devices (one at a time) as the slave device has a 'slave select' line that the master must set just before it starts the clock and data pulses, and then resets when the exchange has completed.
Therefore you need to know if you are writing code for the master or the slave device.
For the master, the sequence is typically:
- set the slave select line
- write the value to send to the peripheral's buffer
- wait until the exchange has completed
- reset the slave select line
- read the received value from the peripheral's buffer
Depending on the device, you should check that the peripheral is ready to begin the next exchange.
For the salve, things are a little different because you are normally not in control of when the exchange occurs. This has several implications. Firstly, the slave will exchange whatever value is in its buffer when the master initiates the exchange. If you have not set a value then the value that is sent may not be defined. Also, slaves often use interrupts so that the whole MCU is not 'stuck' waiting for the exchange to complete. However, if you do block, then the process is typically:
- set the value you want to exchange
- wait until the exchange is complete
- read the value that has been received
For many devices, a key step is that the slave must read the received value before the master initiates the next exchange or you will get a 'buffer overflow'. When this occurs, some devices will simply 'freeze' until the error is corrected - however the master cannot tell this has occurred and so will continue attempting to exchange values and therefore values will be lost by the slave and/or received values misinterpreted by the master.
You might see code examples where there is a SPI 'read' and a SPI 'write' function. AS you can see from the above, SPI is an exchange process and so all you really need is a single function that takes a parameter of the value you want to send and a return value of the value you have received. If you simply want to 'send' a value then you can ignore the returned value form the function (but it is very important that the function has read the received value to stop overflows). If you want to 'read' a value, then you still need to 'send' something and so you can send a dummy value (0x00 is often used but you can also define your own).
Susan