Your best shot would be to post your code...
Ioannis
Your best shot would be to post your code...
Ioannis
There is no much code to show here. I know device A is sending the right data because I can see it with a logical analyzer. I know device B, like 1 out of 5 times, is reading some bytes wrong because I can see these variables values in an LCD. That makes me think that it is a problem with the line. I'm still troubleshooting.
Code:'Code at device A, PIC18F4550 SendData: pause 5 SEROUT2 PORTB.7,32,[STR RFID_IN\7] goto SendData 'Code at device B, PIC16F19197 ClockInDataArray var byte[7] SERIN2 PORTE.1, 32, 5, BOARDSEARCHFAILED, [STR ClockInDataArray\7] hours_0 = ClockInDataArray[0] minutes_0 = ClockInDataArray[1] seconds_0 = ClockInDataArray[2] hours_1 = ClockInDataArray[3] minutes_1 = ClockInDataArray[4] seconds_1 = ClockInDataArray[5]
"No one is completely worthless. They can always serve as a bad example."
Anonymous
alone, until you provide at least a minimal, complete and verifiable example [MCVE]I'm still troubleshooting.
posting useless snippets is a good example of a worthless bad example
my guess for the nearest to the pot Calcutta is inadequate power supplies
Warning I'm not a teacher
You're only allowing device B 5ms between transfers to receive the data and display it.Code:'Code at device A, PIC18F4550 SendData: pause 5 SEROUT2 PORTB.7,32,[STR RFID_IN\7] goto SendData
If device B is not finished and sitting back at the SERIN2 statement before device A does another transmission it will fail.
Try increasing the 'pause 5' to 'pause 500' and see if things get better.
You might also have to break the single SEROUT2 statement into something a little slower, like sending the RFID_IN array data a byte at a time with a pause in between the bytes to allow device B time to receive, save it, and be ready for the next byte. As I mentioned before, you're using a software SERIN2 on device B which is VERY timing-dependent and prone to failure. A hardware UART is much better suited for this, especially for receiving data.
You could also be having issues with osc accuracy between the two... on each end send a 'U' (hex 55) and measure the bit timing. At 19200 baud each bit should be 520us +/-15us, give or take (about 3%).
My bet would be on one of the first two above.
Tumbleweed, I had very strong suspicions that the issues were in the communication lines. I changed the Baud rate from 19200 to 9600 and I haven't got anymore wrong data at the receiver. I remember from my EE school days that the higher the frequency, the more prone to line noise the data is. So, by lowering the Baud rate it worked. I was pulling my hair out for a few days. At first I thought that it was some kind of SERIN2/SEROUT2 software issue.
"No one is completely worthless. They can always serve as a bad example."
Anonymous
By lowering the baud rate you're now allowing device B (and SERIN2) twice the time to receive the bits and assemble the byte.
That's probably what's helping a lot more than any line noise issue.
A software UART has a lot of potential timing issues, especially when it comes to receiving.
As Richard noted, the problem could be in any other part of your code. So you are alone on this as we cannot guess what may be happening there.
However, the part you posted does not somehow checks for valid incoming message. For example you could on the sending device use a string of "hey" and then the data.
On the receiving device wait("hey") and then collect your data. In this case you will not receive data in the middle of the transmission.
Ioannis
Just to correct myself in #9...
At 19200 baud each bit should be 52us +/-1.5us, give or take (about 3%).
I was thinking byte times, not bit times.
Ioannis, yes I'm doing data validation checks all the time. The first byte of the array is always 174. If this condition is not met, then the reading is discarded.
"No one is completely worthless. They can always serve as a bad example."
Anonymous
Bookmarks