View Full Version : Rs485 Using Hserin/hserout
koossa
- 25th January 2008, 10:48
Good day
I have a simple setup with <b>2 x PIC 16F877</b> and want to do <b>RS485 Comms</b> using <b>2 x SN75176</b> chips.
The one PIC is the <b>Master</b> and the other the <b>Slave</b>.
For debug purposes I send messages to my <b>PC using RS232</b> from the Master.
<font color="#993300">Below is my code for the MASTER:</font>
<hr>
<code>
Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
RS232_DEBUG_PIN VAR PORTB.5 ' Debugging to PC
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 20h
define HSER_SPBRG 103
DEFINE HSER_CLOERR 1
RCIF VAR PIR1.5
TXIF VAR PIR1.4
ADCON1 = 7
TRISC = %10000000
Main:
HIGH LEDPIN ' Indicate PIC is running
HIGH DE_OR_RE ' Make ready for TX
PAUSE 100
HSEROUT ["S0"] ' Send "S0"
PAUSE 100
LOW LEDPIN
LOW DE_OR_RE ' Make ready for RX
PAUSE 100
SEROUT RS232_DEBUG_PIN,N2400,["WAITING FOR REPLY..", 13, 10] ' DEBUG TO PC
if RCIF then
hserin 100,Main,[WAIT ("R"),DATARECEIVED]
PAUSE 100
ENDIF
SEROUT RS232_DEBUG_PIN,N2400,["REC:",DATARECEIVED, 13, 10] ' DEBUG TO PC
PAUSE 100
GOTO Main
END
</code>
<hr>
<font color="#993300">Here is the code for the SLAVE:</font>
<hr>
Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 20h
define HSER_SPBRG 103
DEFINE HSER_CLOERR 1
RCIF VAR PIR1.5
TXIF VAR PIR1.4
ADCON1 = 7
TRISC = %10000000
Main:
HIGH LEDPIN ' Indicate PIC is running
LOW DE_OR_RE ' Make ready for RX
PAUSE 100
if RCIF then
hserin 100,Main,[WAIT ("S"),DATARECEIVED] ' Looking for "S0"
PAUSE 100
IF DATARECEIVED = "0" THEN
HIGH DE_OR_RE ' Make ready for RX
PAUSE 100
HSEROUT ["R1"] ' Send R1
ENDIF
endif
LOW LEDPIN
PAUSE 100
GOTO MAIN
END
<hr>
<font color="#993300">Please find attached my schematic!</font>
<hr>
MY QUESTION:
<hr>
<font color="#993300">
The first time I connected the Slave to the 5v power and then after about 5 seconds the Master I get the following on the PC Side:
</font>
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
</b>
<font color="#993300">
Then when I done it again I get the following:
</font>
<b>
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
</b>
<font color="#993300">
When I startup the Master first and then after a few seconds the Slave I get the following
</font>
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
<font color="#993300">
When I connect the Slave first, then the Master and then after a few seconds disconnect and connect the master again, it just keep on returning <b>"WAITING FOR REPLY.."</b>
</font>
<b>
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
<font color="#993300">
It is very unreliable, sometimes it is working and sometimes not.
Am I doing something stupid???
</font>
Thank you
Koossa
koossa
- 25th January 2008, 13:23
Could this happen when the 2 pics are on seperate power supplies?
skimask
- 25th January 2008, 14:09
Could this happen when the 2 pics are on seperate power supplies?
Might have something to do with all of those pauses you've got sprinkled in the code. If the pauses don't line up right (the moon, saturn, mars, etc), one part of the project, either the master or the slave, misses a reception at one time or another, and/or gets caught in the middle of one or the other...basically a sync'ing issue.
koossa
- 25th January 2008, 16:28
Hi Skimask
Must I remove all the pauses?
I am working on 2400 Baud and want to give enough time to transmit the data.
Thank you
Koossa
skimask
- 25th January 2008, 16:43
Hi Skimask
Must I remove all the pauses?
I am working on 2400 Baud and want to give enough time to transmit the data.
Thank you
Koossa
That's just it, you're giving it enough time to TX the data, but in the process of Pausing for 100ms afterwards, you might've missed 200-ish bits of serial data. The receive buffer is only 2 bytes deep (1 if you want be conservative). I'd say pause for 1 byte time, 4ms (2400 baud = .416ms/bit = 4.16ms/byte) instead of 100ms.
The SERIN and SEROUT commands won't let the program continue until they're finished transmitting or receiving.
HSERIN/HSEROUT, not sure about them, as I generally access the serial port registers directly rather than using the commands.
I would assume that they would act the same as SERIN and SEROUT for continuity purposes, but, I would hope that they would be 'non-blocking' commands (unless WAIT is used with HSERIN of course).
koossa
- 25th January 2008, 18:35
Don't know if I understand you correctly, but here is my new code
MASTER PIC
<HR>
<p> Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
RS232_DEBUG_PIN VAR PORTB.5 ' Debugging to PC
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 20h
define HSER_SPBRG 103
DEFINE HSER_CLOERR 1
RCIF VAR PIR1.5
TXIF VAR PIR1.4
ADCON1 = 7
TRISC = %10000000
Main:
HIGH LEDPIN ' Indicate PIC is running
HIGH DE_OR_RE ' Make ready for TX
PAUSE 4
HSEROUT ["S0"] ' Send "S0"
LOW LEDPIN
LOW DE_OR_RE ' Make ready for RX
PAUSE 4
SEROUT RS232_DEBUG_PIN,N2400,["WAITING FOR REPLY..", 13, 10] ' DEBUG TO PC
if RCIF then
hserin 100,Main,[WAIT ("R"),DATARECEIVED]
ENDIF
SEROUT RS232_DEBUG_PIN,N2400,["REC:",DATARECEIVED, 13, 10] 'DEBUG TO PC
GOTO Main
END</p>
<HR>
SLAVE PIC
<hr>
<p> Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 20h
define HSER_SPBRG 103
DEFINE HSER_CLOERR 1
RCIF VAR PIR1.5
TXIF VAR PIR1.4
ADCON1 = 7
TRISC = %10000000
Main:
HIGH LEDPIN ' Indicate PIC is running
LOW DE_OR_RE ' Make ready for RX
PAUSE 4
LOW LEDPIN
if RCIF then
hserin 100,Main,[WAIT ("S"),DATARECEIVED] ' Looking for "S0"
IF DATARECEIVED = "0" THEN
HIGH DE_OR_RE ' Make ready for RX
PAUSE 4
HSEROUT ["R1"] ' Send R1
ENDIF
endif
GOTO MAIN
END</p>
<hr>
As soon as I connect the Master pic to the power I get the following, does not matter if the Slave pic is running or not, it return the same data.
<b>
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
REC:˙
WAITING FOR REPLY..
</b>
Thank you
Koossa
skimask
- 25th January 2008, 19:12
I think you've got the idea...but one other thing I just thought about...
You're checking RCIF in the code. If you're checking RCIF, that means there's already a byte in the receive buffer. HSERIN probably waits for the next byte to come along (basically ignoring what's already in the buffer). If you're already WAITing for a specific character, then why also wait for a flag in hardware? Also, you can make use of the TIMEOUT in the SERIN/HSERIN to keep your code from getting stuck.
koossa
- 25th January 2008, 19:18
Thank you, I will remove the RCIF and see what happens.
There is a 100ms Timeout in my code.
Koossa
koossa
- 25th January 2008, 19:54
I now get the following on the PC Side, so I assume it does not receive the "R"
(<b>hserin 100,Main,[WAIT ("R"),DATARECEIVED]</b>) and reaches the Timeout of 100 milliseconds?
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
Any ideas?
Thank you
Koossa
mister_e
- 25th January 2008, 19:58
Yup that's it!
PS: careful with your DEFINEs. DEFINE HSER_CLOERR 1 have to be DEFINE HSER_CLROERR 1
koossa
- 25th January 2008, 20:21
Thank you very much Mister_e!
I have implement it
<hr>
Code of My Master PIC
<br>
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2296&stc=1&d=1201292332" border="1">
<hr>
Code of My Slave PIC
<br>
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2297&stc=1&d=1201292342" border="1">
But it still only returns:
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
mister_e
- 25th January 2008, 20:33
what's your expected baudrate? I feel 2400 bauds right?
so you should use...
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER_SPBRG 25 ' 2400 Baud @ 4MHz, 0.17%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
OR
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 103 ' 2400 Baud @ 4MHz, 0.17%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
Unless your current USART setting show 600 baud.. and i'm not sure how god/bad it may works with your current hardware.
I would tent to use Usart interrupt for that.. but you can still remove the TimeOut to see what happen. Your code work as design so far.
Still looking...
Darrel Taylor
- 25th January 2008, 20:52
Try adding "Fail-Safe" resistors to the RS-485 buss.
2.2k from A to VDD
2.2k from B to gnd
When both ends are in receive mode, the buss is left floating.
If you're going to have multiple slaves on long distance wires, you may also need 4 schottky diodes on each device.
<br>
koossa
- 26th January 2008, 13:33
Thank you very much Mister_e, I have changed it to the second option, but still receives the :
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
Darrel, the 2.2k from A to VDD and 2.2k from B to gnd, must I put them on the Master and all the Slaves?
I will have long distance cables and multiple slaves.
Where will I put the diodes?
Thank you
Koossa
Darrel Taylor
- 26th January 2008, 20:39
The resistors and diodes should be on each device.
I like the Schottky-Diode Termination method because it allows you the have a "Star" configuration on the 485 buss, and it uses less power than other methods.
Other types of termination require the devices to be in a line with a single termination at the farthest end. This is not always practical, and invariably the farthest end device gets disconnected somewhere along the way, and there goes your termination. Unless someone remembers to terminate the next farthest device. (never happens)
See figure 6 in this page for the diodes.
http://www.maxim-ic.com/appnotes.cfm/an_pk/1090
<br>
koossa
- 27th January 2008, 09:11
Darrel, thank you very much!!!
I have updated my Schematic, could you please confirm that I understand it correctly (see attachment)?
Koossa
Darrel Taylor
- 27th January 2008, 21:45
Yup!
That looks good.
<br>
koossa
- 29th January 2008, 10:05
I have updated everything now, but when I start it up it return the following, no matter if the Slave is running or not.
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
Could this be a wiring problem or maybe something wrong in my code?
Thx
Koossa
Darrel Taylor
- 29th January 2008, 20:41
You might try removing the handshaking part.
Have the slave continuously transmit to the master, and see if you're getting anything.
If not, then yeah, it could be a wiring problem.
Or, 10-20 other things.
<br>
Archangel
- 30th January 2008, 00:43
Hi Koossa,
Background Question:
How much distance between master and slave? I am thinking maybe baud rate is too high due to line capacitance, I just had that problem with an ethernet connection, couldn't use 100 had to tell computer to use 10mbs.
koossa
- 30th January 2008, 09:11
Joe, the distance between my Master and slave is only about 1.5 meters.
<hr>
Darrel
When I remove the handshacking it is working!!
<b>
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
WAITING FOR REPLY..
REC:1
</b>
Do I need to play arround with "pause"?
skimask
- 30th January 2008, 13:54
See Posts #2 & #5.
Failing that, post the program as it sits now...
koossa
- 30th January 2008, 17:31
Skimask
Thank you for your reply!
Whith the following code I only get..
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
SLAVE
<hr>
<CODE>
Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 24h
define HSER_SPBRG 103
DEFINE HSER_CLROERR 1
RCIF VAR PIR1.5
TXIF VAR PIR1.4
ADCON1 = 7
TRISC = %10000000
pause 200
HIGH LEDPIN
Main:
LOW DE_OR_RE ' Make ready for RX
PAUSE 4
hserin 100,Main,[WAIT ("S"),DATARECEIVED] ' Looking for "S0"
IF DATARECEIVED = "0" THEN
HIGH DE_OR_RE ' Make ready for RX
PAUSE 4
HSEROUT ["R1"] ' Send R1
ENDIF
GOTO MAIN
END
</CODE>
<hr>
MASTER
<hr>
<CODE>
Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
RS232_DEBUG_PIN VAR PORTB.5 ' Debugging to PC
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 24h
define HSER_SPBRG 103
DEFINE HSER_CLROERR 1
RCIF VAR PIR1.5
TXIF VAR PIR1.4
ADCON1 = 7
TRISC = %10000000
PAUSE 200
HIGH LEDPIN
Main:
HIGH DE_OR_RE ' Make ready for TX
PAUSE 4
HSEROUT ["S0"] ' Send "S0"
LOW DE_OR_RE ' Make ready for RX
PAUSE 4
SEROUT RS232_DEBUG_PIN,N2400,["WAITING FOR REPLY..", 13, 10] ' DEBUG TO PC
hserin 100,Main,[WAIT ("R"),DATARECEIVED]
SEROUT RS232_DEBUG_PIN,N2400,["REC:",DATARECEIVED, 13, 10] ' DEBUG TO PC
GOTO Main
END
</CODE>
<hr>
Any idea what I am doing wrong?
Thank you very much!!!!
Koossa
skimask
- 30th January 2008, 17:48
It takes at least 87.5ms for each of those SEROUT debug statements to execute at 2400 baud. My guess is that both sides are getting sync'd up into not receiving each others inputs and they both end up missing each others outputs.
How about getting rid of them and try to use LEDs to see if either program is getting what it should? Maybe use a couple of switches on one, and LEDs on the other, and get one PIC to follow the other PIC.
Failing that, how about this:
SLAVE
----------------------------------------------------------
Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 24h
define HSER_SPBRG 103
DEFINE HSER_CLROERR 1
RCIF VAR PIR1.5:TXIF VAR PIR1.4:ADCON1 = 7:TRISC = %10000000
pause 200:HIGH LEDPIN
Main:
hserin 10,MAIN,[WAIT ("S"),DATARECEIVED] ' Looking for "S0"
IF DATARECEIVED = "0" THEN
HSEROUT ["R1"] ' Send R1
else
hserout ["RZ"] ' Send something to signify SOMETHING received
ENDIF
GOTO MAIN
END
--------------------------------------------------------------------------------
MASTER
--------------------------------------------------------------------------------
Include "Modedefs.bas"
DEFINE OSC 4
DE_OR_RE VAR PORTC.5 ' DE and RE Pin of SN75176
RS232_DEBUG_PIN VAR PORTB.5 ' Debugging to PC
LEDPIN VAR PORTD.2 ' LED to confirm PIC is running
DATARECEIVED VAR BYTE
'======== HSEROUT, HSERIN SETTINGS ==========
DEFINE HSER_RCSTA 90h
define HSER_TXSTA 24h
define HSER_SPBRG 103
DEFINE HSER_CLROERR 1
RCIF VAR PIR1.5:TXIF VAR PIR1.4:ADCON1 = 7:TRISC = %10000000
PAUSE 200:HIGH LEDPIN
Main:
HSEROUT ["S0"] ' Send "S0"
SEROUT RS232_DEBUG_PIN,N2400,["WAITING FOR REPLY..", 13, 10] ' DEBUG TO PC
hserin 100,Main,[WAIT ("R"),DATARECEIVED]
SEROUT RS232_DEBUG_PIN,N2400,["REC:",DATARECEIVED, 13, 10] ' DEBUG TO PC
GOTO Main
END
koossa
- 30th January 2008, 19:45
Here is my updated code.
Still getting..
<b>
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
WAITING FOR REPLY..
</b>
Hope I am not missing something?
Slave
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2316&stc=1&d=1201722269">
Master
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2317&stc=1&d=1201722269">
skimask
- 30th January 2008, 19:56
You've got LEDs on both modules, Yes?
Well, use them!
Make them blink whenever they 'receive a message' or whatever.
Forget about a specific message format for now, just get the things to recognize data in general.
And again, lose the SEROUT debug messages, make the LEDs blink or something.
Unless of course your TX and RX lines are backwards or something...
sayzer
- 31st January 2008, 08:09
1. I would put a 1 second pause to Master at initial startup (no pause to slave)
2. I would also make a minor modification as below:
Instead of HSEROUT ["S0"] I would use HSEROUT ["XYZ","0"]
and then
instead of hserin 10,MAIN,[WAIT ("S"),DATARECEIVED] ' Looking for "S0"
I would use HSERIN 10,MAIN,[WAIT ("XYZ"),DATARECEIVED] ' Looking for "0"
------------------
Archangel
- 31st January 2008, 09:42
Where is the interrupt routine? I see if rcif in the early code and it is now missing,
look at this thread especially posts 8, 16.
http://www.picbasic.co.uk/forum/showthread.php?t=4972
Powered by vBulletin® Version 4.1.7 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.