Hi,
I have 2x PICs connected via SPI, and on each there is an SSPBUF STRING of 34 Characters.

When running they swap ok, but are slightly out of step. How to I SYNC them, please?

I'm sure I've done it before, but forgotten?
Camerart.

 

Hi,
I've realised that my question isn't clear!
I don't mean the SPI sync timing, I mean, when I read the first CHAR as received, it isn't the first CHAR that was sent, by the 'other' PIC.
I'm still not sure this is clear?
C

 

Hi,
I've realised that my question isn't clear!
I don't mean the SPI sync timing, I mean, when I read the first CHAR as received, it isn't the first CHAR that was sent, by the 'other' PIC.
I'm still not sure this is clear?
C

SPI is a simple shift register interface. When the master sends the first byte, the slave sends what was last latched into the register from the last transaction. That might be valid data from a previous data or it could be junk or a 'dummy' symbol. Normally you need to send a 'dummy' (all highs or all lows depending on the device being talked to) byte from the master to get the last (or first valid data of the current transaction) byte of valid slave data from the current SPI transaction.

 

SPI is a simple shift register interface. When the master sends the first byte, the slave sends what was last latched into the register from the last transaction. That might be valid data from a previous data or it could be junk or a 'dummy' symbol. Normally you need to send a 'dummy' (all highs or all lows depending on the device being talked to) byte from the master to get the last (or first valid data of the current transaction) byte of valid slave data from the current SPI transaction.

View attachment 295582

Hi N,
If for example MASTER has M1, M2, M3, M4 to send to SLAVE and SLAVE has S1, S2, S3, S4 to send to MASTER, at SLAVE-C/S, why don't they simply swap?
C.

 

Hi N,
If for example MASTER has M1, M2, M3, M4 to send to SLAVE and SLAVE has S1, S2, S3, S4 to send to MASTER, at SLAVE-C/S, why don't they simply swap?
C.

If S1 is already locked into the slave TX latch it will swap with M1 but typically (in the exchange data protocol) you need to tell the slave what to send or execute first, then it latches S1 to be transferred next.

 

If S1 is already locked into the slave TX latch it will swap with M1 but typically (in the exchange data protocol) you need to tell the slave what to send or execute first, then it latches S1 to be transferred next.

Hi N,
I found some CODE written for me in Oshonsoft BASIC.
https://forum.allaboutcircuits.com/...ommunication-and-settings.174701/post-1582383

M1, M2.... and S1, S2 ...... DATA are changing all of the time. Will this CODE work if [ msg1 = "ABCD" + cr + Lf ] is substituted by [ msg1 = "S1S2S3S4S5" + cr + Lf ]?
C

 

Most use a buffer for reception. Normally it's only the first sentence "out of sync" as one device will be ready before the other.
If you use a buffer and say wait for a control character that specifies the "END" , you can count back and grabb the correct sequence... Or wait for the "END" character, dump that incomplete or screwed up sentence, then start afresh.

I normally give the SPI slave plenty of time to get ready before I ask for data.

 

Most use a buffer for reception. Normally it's only the first sentence "out of sync" as one device will be ready before the other.
If you use a buffer and say wait for a control character that specifies the "END" , you can count back and grabb the correct sequence... Or wait for the "END" character, dump that incomplete or screwed up sentence, then start afresh.

I normally give the SPI slave plenty of time to get ready before I ask for data.

Hi I,
Ok, good!
In a similar way to other RX CODE I use, is it ok to look for the 1st CHAR, being £, then echange the next CHAR and rest of the STRING via SPI?
C

 

Most use a buffer for reception. Normally it's only the first sentence "out of sync" as one device will be ready before the other.
If you use a buffer and say wait for a control character that specifies the "END" , you can count back and grabb the correct sequence... Or wait for the "END" character, dump that incomplete or screwed up sentence, then start afresh.

I normally give the SPI slave plenty of time to get ready before I ask for data.

Hi I,
Ok, good!
In a similar way to other RX CODE I use, is it ok to look for the 1st CHAR, being £, then exchange the next CHAR and rest of the STRING via SPI?
C

 

You really only need to sync once. SPI is far more robust than you USART code. On most systems I make, I call the data rather than wait it's arrival. Pic 1 says "Send now" the other pic responds.. I hardly ever get sync errors this way.

 

You really only need to sync once. SPI is far more robust than you USART code. On most systems I make, I call the data rather than wait it's arrival. Pic 1 says "Send now" the other pic responds.. I hardly ever get sync errors this way.

Hi I,
As it is now, there are BYTEs in the SLAVE and BYTEs in MASTER, both the same length. The MASTER_CS opens SLAVE, and starts the SPI clock. I think this is similar to what you are saying. I am puzzled why the 1st 2x exchange BYTEs aren't in sync

EDIT: It's possible that in my CODE there may be extra BYTEs being introduced somewhere. Checking!
C

 

You do know that SPI is a ring. when you send a byte, something is returned regardless, ergo the first received will be a dummy.
i
There cannot be any process until the first byte is received.

If you ask for the first byte , the SSPBUF in device 1 will have the garbage from powerup.
If you ask for the second byte, the SSPBUFF in device 1 will have the answer to the above and so on.

If you are just receiving you can ditch the first byte and start counting from the second.

 

You do know that SPI is a ring. when you send a byte, something is returned regardless, ergo the first received will be a dummy.
View attachment 295646i
There cannot be any process until the first byte is received.

If you ask for the first byte , the SSPBUF in device 1 will have the garbage from powerup.
If you ask for the second byte, the SSPBUFF in device 1 will have the answer to the above and so on.

If you are just receiving you can ditch the first byte and start counting from the second.

Hi I,
I know how SPI works, as your diagram, but I can't see why the first BYTE isn't the first, or perhaps one out, but there appear to be 10s out. I'm wondering if something is looping and moving the through the DATA, in between CS's?
I have a data analyser, so I may be able to track down the error?
C.

 

Hi I,
I know how SPI works, as your diagram, but I can't see why the first BYTE isn't the first, or perhaps one out, but there appear to be 10s out. I'm wondering if something is looping and moving the through the DATA, in between CS's?
I have a data analyser, so I may be able to track down the error?
C.

When external data buffers or FIFO's (the number of bits to send exceed one SPI transfer) are involved in SPI data transfers, the counts and start/stop sequences are important to know precisely or you will likely have problems. This usually means some sort of data packet protocol that uses the physical SPI transport to first send start of data information (packets). Don't trust raw, back to back transfers, on any data media.



Another thing is be be sure on what is triggering the SPI read. Most SPI controllers modules have separate interrupts/flags to notify when the shift register has completed, with a Tx flag, the transmit bit shift out and separate receive Rx flag to notify when a receive operation has completed the receive bits shift in.

A recent SPI device (IMU) had an slave interrupt it could notify the host the slave transfer buffer was ready and the first few bytes of that data transfer from the slave was in a packet header that gave the length of the total transfer so both sides could keep SYNC.

 

When external data buffers or FIFO's (the number of bits to send exceed one SPI transfer) are involved in SPI data transfers, the counts and start/stop sequences are important to know precisely or you will likely have problems. This usually means some sort of data packet protocol that uses the physical SPI transport to first send start of data information (packets). Don't trust raw, back to back transfers, on any data media.

View attachment 295661

Another thing is be be sure on what is triggering the SPI read. Most SPI controllers modules have separate interrupts/flags to notify when the shift register has completed, with a Tx flag, the transmit bit shift out and separate receive Rx flag to notify when a receive operation has completed the receive bits shift in.

A recent SPI device (IMU) had an slave interrupt it could notify the host the slave transfer buffer was ready and the first few bytes of that data transfer from the slave was in a packet header that gave the length of the total transfer so both sides could keep SYNC.

Hi N,
More difficult, than my skills I think.
I'll check to see if I have previous CODE sections.
C.

 

Hi N,
More difficult, than my skills I think.
I'll check to see if I have previous CODE sections.
C.

If you want to use SPI effectively then you need the skills. It's not difficult.

 

If you want to use SPI effectively then you need the skills. It's not difficult.

Hi N,
The project I've been working on for years has a number of skills, that I have improved on, but sadly my programming skills haven't improved much.
C

 

Hi,
A mate of mine has been writing the SPI CODE, but he's busy, so I'm having a go, I think it may be wise to wait till he's clear.
Thanks for all of the comments,
C

 

Hi N,
The project I've been working on for years has a number of skills, that I have improved on, but sadly my programming skills haven't improved much.
C

I have watched for several years. Your programming definitely has. I just wish you could move away from Oshonsoft as it's too limiting for your requirements now. Even Swordfish is more forgiving

 

Hi,
A mate of mine has been writing the SPI CODE, but he's busy, so I'm having a go, I think it may be wise to wait till he's clear.
Thanks for all of the comments,
C

You were involved with the SPI thread that Eric Nigel and I were chipping away with on the SPI LCD over at ETO..
All was written in Oshonsoft.

As per your "transfers" you are using a second pic as the slave, yes? how are you organizing the data on device 2?