Hi N,Many PIC's have two serial ports, and it's always a good idea to choose one that does.
It's also very trivial to use a simple software serial port to output debugging data, and it just requires a single output pin - I add one on pretty well everything I build, and use a hardware serial port if there's a spare one (the PPI facility is very useful for moving peripherals to the pin you want).
You want to avoid 'blocking' in your routines, as you've probably got other things going on that need servicing, rather than sat waiting for something to happen. By using interrupts and flags your main routine can just loop round waiting for flags to appear.
I would also suggest writing routines that use the size of the data for transmission and reception, rather than having to hardcode FOR loops in the program.
That's one of the issues I alluded to in my last post.but I never got the DATA to be synchronised, and my tests seemed to suggest it was timing related,
Hi T,Another thing...
From looking at the code you don't appear to be using the SPI SS slave select pin. You should. As the master lowers/raises this pin around every byte transfer it re-syncs the bit counter. If you don't use it then if you get one clock glitch on the slave you will be out of sync forever.
This can occur right from startup as the master and slave setup their SPI hardware... without it you're at the mercy of which side powers up first and initializes its pins.
You can look at the TB3265 app note for some ideas, but even this glosses over many of the issues I've pointed out, simply stating things like "A slave must always be available and has to wait until the master pulls its SS channel low" without any hints as to how to go about doing that.
's2m(0) = "£" '£ [TOT 35 BYTES ]
's2m(1) = gps(7) 'Time
's2m(2) = gps(8) 'Time
's2m(3) = gps(9) 'Time
's2m(4) = gps(10) 'Time
's2m(5) = gps(11) 'Time
's2m(6) = gps(12) 'Time
's2m(7) = gps(14) 'Time
's2m(8) = gps(15) 'Time
's2m(9) = gps(19) 'Lat
's2m(10) = gps(20) 'Lat
's2m(11) = gps(21) 'Lat
's2m(12) = gps(22) 'Lat
's2m(13) = gps(24) 'Lat
's2m(14) = gps(25) 'Lat
's2m(15) = gps(26) 'Lat
's2m(16) = gps(27) 'Lat
's2m(17) = gps(27) 'Lat
's2m(18) = gps(28) 'Lat
's2m(19) = gps(30) 'N
's2m(20) = gps(32) 'Lon
's2m(21) = gps(33) 'Lon
's2m(22) = gps(34) 'Lon
's2m(23) = gps(35) 'Lon
's2m(24) = gps(36) 'Lon
's2m(25) = gps(38) 'Lon
's2m(26) = gps(39) 'Lon
's2m(27) = gps(40) 'Lon
's2m(28) = gps(41) 'Lon
's2m(29) = gps(42) 'Lon
's2m(30) = gps(44) 'W
's2m(31) = POSCNTL 'QEIDEGLB
's2m(32) = POSCNTH 'QEIDEGHB
's2m(33) = 12 'Bat volt
's2m(34) = 123 'Spare DATA
Hi T,Does the master CS output connect to the slave SPI SS in pin?
What is the slave SPI setup? I assume it doesn't enable this pin.
The BF flag does nothing to help with any of this, and having an interrupt line from the master doesn’t help any either.
Proc init_spi() 'PIC 18F4431
'4431
TRISC.6 = 1 '4431_CS=1
TRISD.3 = 1 'SCK from MASTER ******INPUT*****
TRISD.1 = 0 'MISO ****** OUTPUT *******
TRISD.2 = 1 'MOSI ****** INPUT *******
'MODE 0,0
SSPSTAT.SMP = 0 'Input data sampled at middle of data output time ** not about clock generation **
SSPSTAT.CKE = 0 '0 Output data changes on clock transition from active to idle ** AS ABOVE **
SSPSTAT.5 = 0 'I2C only
SSPSTAT.4 = 0 'I2C only
SSPSTAT.3 = 0 'I2C only
SSPSTAT.2 = 0 'I2C only
SSPSTAT.1 = 0 'I2C only
SSPCON = 0 'RESET THE CONTROL REGISTER **************************************ADDED
SSPCON.WCOL = 0 'Collision detect
SSPCON.SSPOV = 0 'Overflow
SSPCON.SSPEN = 1 'Configure SCK,SD0,SDI,/SS ** HAS TO BE 1. To reset or reconfigure SPI mode, clear the SSPEN bit,
'reinitialize the sspcon registers And Then set the SSPEN Bit from the datasheet !!!!!!!!!!!!!!!!
SSPCON.CKP = 0 '0 = Idle state for clock is a LOW level
SSPCON.SSPM3 = 0 '0100 = SPI SLAVE mode, clock = FOSC/64
SSPCON.SSPM2 = 1
SSPCON.SSPM1 = 0 'SLAVE MODE
SSPCON.SSPM0 = 0
End Proc
Hi J,"The MASTER does use a C/S-SS which can interrupt the SLAVE at any time, while other things are going on in the LOOP."
Is that true?
I thought the only thing that SS does, is to connect the slave to the SPI bus.
Without additional hardware it can't. And really what you need is for the slave to control the sync of transfers.How can the MASTER control the SYNC?
Hi T,Without additional hardware it can't. And really what you need is for the slave to control the sync of transfers.
The master has no idea when/if the slave can accept bytes... it will quite happily send data even if there's no slave there, and it'll send it at the speed it wants to. The slave has no buffering so if the master sends two bytes faster than the slave accepts them then data is lost and you're out of sync at the message level, and the master has no way of knowing this.
That's the problem with master-slave SPI. The master has complete control over the transfers, but it has no feedback mechanism. Basically you need a signal back to the master for the slave to say "I'm ready to accept data".
I don't know that there's a different between messages and arrays. To me, an array of data is a "message". That's not your problem.
Hi T,Looking back at some of those posts from 10 years ago on AAC vs your current code, it appears you've changed the SPI setup (it's no longer mode 0,0) and removed all the delays in the master routines. The SPI slave also changes from using hardware SS to not using SS in some of those posts, so it's hard to track what "used to work".
The delays in the master are important. They give the slave a chance to react, although you never know if it's "good enough" so they'll be unreliable and eventually fail at some point.
None of the methods you've shown so far are what I would call 'reliable'.The 'message' method used then was reliable,
Hi T,None of the methods you've shown so far are what I would call 'reliable'.
They may work for simple examples but they won't be when you add it to your app program code.
That's why I haven't bothered correcting the examples.
Strings and bytes and messages are all the same thing when it comes to transferring data.
No trying to be rude, but why would a WHILE/WEND do anything regarding the use of delays?
You're really out of your comfort zone here. I expect you'll still be working on this in another 10 years.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?