Hello,
first to try my hand wanted to know if anyone has tried using the PIC18 SPI in VDM, that means that the Data Phase Length can have random value (any length from 1 Byte to N Bytes) according to the SCS control pin.
I think that can be done sequentially, taking care to act on the SCS according to the indicated timing. Someone has already tried it and can confirm if it works?
Read timing :
Write timing:
PIC18 SPI and VDM SPI mode
Moderators: David Barker, Jerry Messina
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: PIC18 SPI and VDM SPI mode
I've used it that way before... as long as the PIC18 is the master that would be no problem. You have to generate the SCS output by bit-banging a pin, so you have complete control over whether it gets asserted for each byte or each frame (VDM). There will be a short delay of a few clock cycles in between bytes since the MSSP can't generate back to back transmissions, but since it's a synchronous bus that shouldn't matter.
Remember to treat the SPI operation as what it is... a transfer of data. Whenever the master writes a byte it simultaneously reads one from the slave, and since the master controls the clock it must send a byte in order to read one.
If you're talking using the PIC18 as an SPI slave, then that's a different matter. The SSN signal is used to reset the bit counter to ensure the slave can resync with the master. Without it, a single extra glitch/transition on the SCLK line will put the slave permanently out of sync with the master.
Also, since there's no way for the master to know if the slave PIC is ready to accept new data, the master must use delays in between the bytes to allow the slave time to receive and process the incoming data. Slave SPI operation can be tricky at best, and usually only works if you have control over both ends. The times I've used it this way I've added an extra handshaking/status line between the two.
Remember to treat the SPI operation as what it is... a transfer of data. Whenever the master writes a byte it simultaneously reads one from the slave, and since the master controls the clock it must send a byte in order to read one.
If you're talking using the PIC18 as an SPI slave, then that's a different matter. The SSN signal is used to reset the bit counter to ensure the slave can resync with the master. Without it, a single extra glitch/transition on the SCLK line will put the slave permanently out of sync with the master.
Also, since there's no way for the master to know if the slave PIC is ready to accept new data, the master must use delays in between the bytes to allow the slave time to receive and process the incoming data. Slave SPI operation can be tricky at best, and usually only works if you have control over both ends. The times I've used it this way I've added an extra handshaking/status line between the two.
Re: PIC18 SPI and VDM SPI mode
Hello Jerry,
fortunately, the PIC is the master and the device is a "not PIC" slave.. PIC should just take care of managing this single SPI device on the bus. You confirm that there should be no problem since it is the same PIC to move the line SCS maintaining synchrony.
fortunately, the PIC is the master and the device is a "not PIC" slave.. PIC should just take care of managing this single SPI device on the bus. You confirm that there should be no problem since it is the same PIC to move the line SCS maintaining synchrony.