-
1 Attachment(s)
Multiple PICs on usart network
Hi,
This is what my circuit looks like:
Attachment 6709
- The 18F4550 sends 1 byte to the slaves on Master TX line.
- Both slaves receive the byte properly.
- 1st slave replies successfully with same byte on Master RX line.
Problem: communication is blocked if 2nd slave is added on Master RX line.
Note: 2nd slave does not reply to master yet, extra address byte will be added later so each slave will reply only when spoken to.
Master:
Code:
' 184550 external oscillator 20MHz
' 4K7 pull-up on RX
@ __CONFIG _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L
@ __CONFIG _CONFIG1H, _FOSC_HSPLL_HS_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
@ __CONFIG _CONFIG2L, _PWRT_OFF_2L & _BOR_ON_2L & _BORV_1_2L & _VREGEN_ON_2L
@ __CONFIG _CONFIG2H, _WDT_OFF_2H
@ __CONFIG _CONFIG3H, _CCP2MX_OFF_3H & _PBADEN_OFF_3H & _LPT1OSC_OFF_3H & _MCLRE_ON_3H
@ __CONFIG _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _ICPRT_OFF_4L & _XINST_OFF_4L & _DEBUG_OFF_4L
DEFINE OSC 48
ADCON1 = %00001111
INTCON2 = %10000000
TRISA = %00000000
TRISB = %00000000
TRISC = %11000000
TRISD = %00000000
TRISE = %00000000
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 25 ' 115200 Baud @ 48MHz, 0,16%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator
DEFINE LCD_DREG PORTD ' Set LCD data port
DEFINE LCD_DBIT 0 ' Set starting data bit
DEFINE LCD_BITS 8 ' Set LCD bus size
DEFINE LCD_LINES 2 ' Set number of lines on LCD
DEFINE LCD_RSREG PORTC ' Set LCD register select port
DEFINE LCD_RSBIT 1 ' Set LCD register select bit
DEFINE LCD_EREG PORTC ' Set LCD enable port
DEFINE LCD_EBIT 0 ' Set LCD enable bit
define LCD_COMMANDUS 1500 ' Set command delay time in microseconds
DEFINE LCD_DATAUS 50 ' Set data delay time in microseconds
DataIn VAR byte
DataOut VAR byte
low PORTC.2
Start:
Pause 2000
Main:
DataOut = PortC.2
LCDOUT $FE,$80,"This is the data out: ", dec1 DataOut
hserout [dec1 DataOut]
hSERIN [dec1 DataIn]
LCDOUT $FE,$C0,"This is the data in: ", dec1 DataIn
pause 1000
toggle PortC.2
GOTO Main
end
1st slave:
Code:
' 18F44K22 internal oscillator 64MHz
' 4K7 pull-up on RX
@ __CONFIG _CONFIG1H, _FOSC_INTIO67_1H & _PLLCFG_ON_1H & _PRICLKEN_OFF_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
@ __CONFIG _CONFIG2L, _PWRTEN_ON_2L & _BOREN_SBORDIS_2L & _BORV_285_2L
@ __CONFIG _CONFIG2H, _WDTEN_OFF_2H
@ __CONFIG _CONFIG3H, _PBADEN_OFF_3H & _HFOFST_OFF_3H & _MCLRE_EXTMCLR_3H
@ __CONFIG _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _XINST_OFF_4L & _DEBUG_OFF_4L
DEFINE OSC 64
OSCCON = %01110000
OSCCON2 = %10000000
OSCTUNE = %11000000
INTCON2 = %10000000
ANSELA = 0
ANSELB = 0
ANSELC = 0
ANSELD = 0
ANSELE = 0
TRISA = %00001111 ' Set port A pins 0-3 to input, others output
TRISB = %00000000 ' Set port B pins to output
TRISC = %11111111 ' Set port C pins to input
TRISD = %00111111 ' Set port D pins 0-5 to input, others output
TRISE = %00000000 ' Set port E pins to output
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 138 ' 115200 Baud @ 64MHz, -0,08%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator
INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ; PBP Re-entry for external interrupt
INCLUDE "Elapsed_INT-18.bas" ; Elapsed Timer Routines
ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RX1_INT, _ReceiveInterrupt, PBP, no
endm
INT_CREATE ; Creates the interrupt processor
ENDASM
DataIn VAR byte
DataOut VAR byte
RS232Flag VAR byte
goto Start
ReceiveInterrupt:
hSERIN [dec1 DataIn]
RS232Flag = 1
@ INT_RETURN
Start:
Pause 1500
@ INT_ENABLE RX1_INT
mainloop:
if RS232Flag = 1 then
RS232Flag = 0
PortA.4 = DataIn
DataOut = DataIn
hserout [dec1 DataOut]
endif
Goto mainloop
end
2nd slave:
Code:
' 18F26K22 internal oscillator 64MHz
' 4K7 pull-up on RX
@ __CONFIG _CONFIG1H, _FOSC_INTIO67_1H & _PLLCFG_ON_1H & _PRICLKEN_OFF_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
@ __CONFIG _CONFIG2L, _PWRTEN_ON_2L & _BOREN_SBORDIS_2L & _BORV_285_2L
@ __CONFIG _CONFIG2H, _WDTEN_OFF_2H
@ __CONFIG _CONFIG3H, _PBADEN_OFF_3H & _HFOFST_OFF_3H & _MCLRE_EXTMCLR_3H
@ __CONFIG _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _XINST_OFF_4L & _DEBUG_OFF_4L
DEFINE OSC 64
OSCCON = %01110000
OSCCON2 = %10000000
OSCTUNE = %11000000
INTCON2 = %10000000
ANSELA = 0 ' Digital I/O
ANSELB = 0
ANSELC = 0
TRISA = %00111111 ' Set port A pins 0-5 to input
TRISB = %00000000 ' Set port B pins to output
TRISC = %11000000 ' Set port C pins 6-7 to input, others output
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 138 ' 115200 Baud @ 64MHz, -0,08%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator
INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ; PBP Re-entry for external interrupt
INCLUDE "Elapsed_INT-18.bas" ; Elapsed Timer Routines
ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler RX1_INT, _ReceiveInterrupt, PBP, no
endm
INT_CREATE ; Creates the interrupt processor
ENDASM
DataIn VAR byte
RS232Flag VAR byte
RS232Flag = 0
goto Start ' Jump over sub-routines
ReceiveInterrupt: ' [USART RX - interrupt handler]
hSERIN 50,No232,[dec1 DataIn]
RS232Flag = 1
No232:
@ INT_RETURN
Start:
Pause 1500
@ INT_ENABLE RX1_INT ; Enable USART Receive interrupts
mainloop:
if RS232Flag = 1 then
RS232Flag = 0
PortA.7 = DataIn
endif
Goto mainloop
end
This has been driving me nuts for several days. I've trimmed my programs down to this bare essential and I still can't see what I'm doing wrong.
Everything works beautifully as long as I don't add that 2nd slave on the reply line.
Robert
-
Re: Multiple PICs on usart network
Hi Robert,
I think the two TX-pins are fighting each other. When neither are trying to send they are both idle at high (or low, I can't remember). Then all of a sudden one is trying to send a bit pulling the pin low (or high) which effectively shorts the output thru the other slaves TX-pin. It doesn't matter that the second slave isn't actually sending anything yet, its TX-line is still pulled to the idle state of the line so when the other slave is trying to send its output gets shorted.
What you could try is to "isolate" each slave from the masters RX-line with a 1k resistor. I'd probably remove the pullup on the masters RX-line as well otherwise it'll act as a voltage divider when the slave pulls the line low thru its "isolating resistor".
/Henrik.
-
Re: Multiple PICs on usart network
RS-485
RS-485, is a standard defining the electrical characteristics of drivers and receivers for use in balanced digital multipoint systems. The standard is published by the Telecommunications Industry Association/Electronic Industries Alliance (TIA/EIA). Digital communications networks implementing the EIA-485 standard can be used effectively over long distances and in electrically noisy environments. Multiple receivers may be connected to such a network in a linear, multi-drop configuration. These characteristics make such networks useful in industrial environments and similar applications.
-
Re: Multiple PICs on usart network
-
Re: Multiple PICs on usart network
why not use open mode. in the manual under serout2 command says:
Bit 15 selects whether the data pin is always driven (bit 15 = 0), or is open in one of
the states (bit 15 = 1). The open mode can be used to chain several devices
together on the same serial bus.
of course this is no good if you still want to use the hardware uart.
-
Re: Multiple PICs on usart network
Thank you.
Your replies sent me on search for "rs232 multidrop" and that gave important note.
"One Master PIC can talk to multiple slaves, but only 1 slave can connect back to Master RX."
I had missed that fact if it was mentionned in the PBP manual, or anywhere else.
I've since switched to an alternate solution.
Thanks!
Robert
:)
-
Re: Multiple PICs on usart network
This post is for the next guy that tries to do this. A few things I learned:
- you can put a basic MAX232 on the TX and RX lines and "watch" what is being sent around your network.
- 4K7 pull-up resistors are good for master and slave RX pins (supposedly only necessary in case PIC is disconnected).
- a structured approach to communication helps, ie: a PIC address, a command, data and checksum.
- slaves then look at the PIC address and decide if it applies to them, a "calling all slaves" address is also useful.
- a local command can help support various processing.
- data can be as big as you need it.
- and checksum can be as simple as addition of every byte sent, a word variable has more room.
- RS232 is great for Master to multiple Slaves, as long as only 1 slave replies back UNLESS:
Code:
...
TXSTA.5 = 1 ' Enable USART TX function
HSEROUT (slave sends reply only when spoken to by master)
TXSTA.5 = 0 ' Disable USART TX function
...
There's more than one way to skin a cat, but this was by far the easiest to have more than 1 slave on the MASTER RX line. There may still be an issue with this solution, but I have 6 slaves sharing a master RX line right now and they're all purring nicely.
Thanks to all that helped me work through this (don't even want to count how many days it took to get this working).
Robert
:)
-
Re: Multiple PICs on usart network
The MAX3322E & MAX3323E are designed for this, as well, if using an RS232 transceiver.
http://www.maximintegrated.com/datas...ce=supplyFrame
-
Re: Multiple PICs on usart network
Hi,
I am assembling this circuit. 1 Week ago i am suffering of the same situation that you have.
I am conecting 5 PIC 16F690, 1 as master (Tx conected to 4 Rx) and 4 slaves (all tx in parallel with other slaves...)
If I only conected 2 pics (P2P) all works fine, but adding 1 more, the Tx from 1 slave to master is corrupted.
I have the solution, can you reply what did you do to solve?
/jose p
-
Re: Multiple PICs on usart network
this is my mail:
[email protected]
-
Re: Multiple PICs on usart network
Quote:
Originally Posted by
JoseJimenez
Hi,
...can you reply what did you do to solve?
I have only 1 slave enable the TX line at one time:
http://www.picbasic.co.uk/forum/show...809#post116809
Robert
-
Re: Multiple PICs on usart network
1. Two Schottky diodes on TX lines could be one solution. This way, one TX line does not effect the other.
or if not using diodes,
2. After each Transmit, you may disable USART and make TX pin input pin. When you need to send again, make TX pin an output pin and enable USART, then transmit.
If one TX line is an input pin, it will not effect the network during the transmission of other TX line.
These two are only suggestions and are not tested.
:)
-
Re: Multiple PICs on usart network
Can't comment on the diodes, but disabling USART also turns off receive. That's why I disabled only transmit.
-
Re: Multiple PICs on usart network
The URL I referenced in post #4 shows diodes in TX lines. There's no coding required. Schottky diodes would be best.
http://cool-emerald.com/?p=711
-
Re: Multiple PICs on usart network
Mr Demon,
I definitely solve this.
You will need a couple of transistor per each Tx output and 3 resistor.
As you said, if you disable the usart, also Rx line will be disable.
If you use diodes, you will need a conversor as MAX 232...
Problem with diodos, is due to signal keep positive if Tx is idle. Plus this, Impedance for Tx and Rx line are so sensitive.
If want to communicate several PIC without using interfacing, you can do it using the schematic that I will post next.
/jose p.
-
1 Attachment(s)
Re: Multiple PICs on usart network
-
Re: Multiple PICs on usart network
-
Re: Multiple PICs on usart network
Post #8, "MAX3322E & MAX3323E are designed for this..."
Pretty much the same thing, but you need an extra I/O pin.
-
Re: Multiple PICs on usart network
Quote:
Originally Posted by
dhouston
How fast a baud rate do you think this can handle?
-
Re: Multiple PICs on usart network
Quote:
Originally Posted by
Demon
How fast a baud rate do you think this can handle?
I don't know. I seldom need more than 9600bps with embedded devices.
-
Re: Multiple PICs on usart network
I needed 115200 at 48mhz, not sure diodes could handle it. Switching coms in software doesn't add hardware limitations.
-
1 Attachment(s)
Re: Multiple PICs on usart network
Attached is a pdf schematic similar to Jose P's posting, but halving the number of transistors per channel.
Also need to add a TX BUSY bus to prevent collision. (Hold to ground when transmitting, tristate when idle).
A similar circuit ran fine at 115200 baud.
Almost any signal diode in series to the TX pins (cathode to the TX pin) with a bus pull up resistor on the anode could also work fine.
Tim.
-
Re: Multiple PICs on usart network
Hey Everybody,
Thanks for this thread, you saved me a truckload of frustration! The series diodes worked in my case.
All the Best,
Paul
-
Re: Multiple PICs on usart network
Look guys,
My schematic use 2 transistor and 3 Rs per tx line. You dont need any other ic as converter or similar.
I am mounting 4 PIC forming a network, 1 master and 13 slaves. Tx from master will be conected to all Rx of slaves, then all Tx from slaves will be conected to master Rx.
Anyway, looks like demon have resolve this...
/jose p
-
Re: Multiple PICs on usart network
Just another quick question, would using two MAX232 devices (one on each chip) and a common ground not also work?
-
Re: Multiple PICs on usart network
Quote:
Originally Posted by
Wilton55
Just another quick question, would using two MAX232 devices (one on each chip) and a common ground not also work?
Sorry for the delayed reply to Wilton.
Yes, a MAX232 chip on each PIC will work. It will also improve reliability over long distances (can't remember if this was from a Microchip datasheet of Maxim application note).
Robert
-
Re: Multiple PICs on usart network
Nope, not my video. That's Jose's and he uses transistors. I preferred a software solution, no extra parts involved.
All Slaves keep their TX line disabled until they are spoken to by the Master and have to send back a reply.
Quote:
Originally Posted by
Demon
This post is for the next guy that tries to do this. A few things I learned:
- you can put a basic MAX232 on the TX and RX lines and "watch" what is being sent around your network.
- 4K7 pull-up resistors are good for master and slave RX pins (supposedly only necessary in case PIC is disconnected).
- a structured approach to communication helps, ie: a PIC address, a command, data and checksum.
- slaves then look at the PIC address and decide if it applies to them, a "calling all slaves" address is also useful.
- a local command can help support various processing.
- data can be as big as you need it.
- and checksum can be as simple as addition of every byte sent, a word variable has more room.
- RS232 is great for Master to multiple Slaves, as long as only 1 slave replies back UNLESS:
Code:
...
TXSTA.5 = 1 ' Enable USART TX function
HSEROUT (slave sends reply only when spoken to by master)
TXSTA.5 = 0 ' Disable USART TX function
...
There's more than one way to skin a cat, but this was by far the easiest to have more than 1 slave on the MASTER RX line. There may still be an issue with this solution, but I have 6 slaves sharing a master RX line right now and they're all purring nicely.
...
The only addition I would add to my list is using a MAX232 on each PICs for stability when using very long cables. It's not known at this point how "long" a network has to be for USART to become "less reliable".
My project will communicate underground between the house, garage and shed (at least 100' end to end). I plan on using MAX232 chips; it's not like they are expensive.
Robert
EDIT: The existing "fried" commercial alarm system has a MAX232, so it's a known solution.
-
Re: Multiple PICs on usart network
You can't have multiple MAX232's sharing TX and RX lines... the TX signals will conflict.
Even one output to multiple inputs can easily exceed the device specs since each input has about 5K ohm input resistor.
-
Re: Multiple PICs on usart network
Hi,
This....
Code:
TXSTA.5 = 1 ' Enable USART TX function
HSEROUT (slave sends reply only when spoken to by master)
TXSTA.5 = 0 ' Disable USART TX function
...is also a bad idea.
The HSEROUT will load TXREG with the last byte to be sent, then the program continues. If the next line turns off the transmitter the last byte won't be sent properly.
Poll TXIF to determine when you can turn off the transmitter.
If this is for anything more than messing around, use RS485 or something designed for the purpose.
/Henrik.
-
Re: Multiple PICs on usart network
Quote:
Originally Posted by
HenrikOlsson
...
The HSEROUT will load TXREG with the last byte to be sent, then the program continues. If the next line turns off the transmitter the last byte won't be sent properly.
...
Weird, nothing unusual came up when I was doing my tests back then; no bytes lost, no data loss. I'm going to have to test this with a higher volume of data transfer and add the polling of TXIF as you suggest.
I just read a RS485 app note and my head hurts.
http://www.analog.com/static/importe...tes/AN-960.pdf
Robert
-
Re: Multiple PICs on usart network
TXIF only means that you can load the TXREG.
You need to poll TRMT to know when the byte has been shifted out of the TSR (Transmit Shift Register) and you can disable the output. TRMT gets set halfway into the STOP bit.
-
Re: Multiple PICs on usart network
Robert,
I've done quite a bit of work with half duplex RS485 where you have a pin telling the tranceiver chip if it should operate in TX or RX mode.
If I do
Code:
TxRx = Tx ' Switch tranceiver to TX mode
HSEROUT["Test",10,13] ' Send data
TxRx = Rx 'Sitch tranceiver to RX mode
The last byte (13) will not go thru properly because the tranceiver chip is switched from Tx to Rx mode in the middle of it. I'm pretty sure you'll get the same thing when disabling the USART. It's possible though that a low oscillator frequency in combination with high baudrate "masks" the problem.
Tumbleweed,
TRMT is the correct bit, thanks for pointing that out!
/Henrik.
-
Re: Multiple PICs on usart network
they might get away with it because the last chr is 13 , so that means the last 4 bit and the stop bit all leave the tx line high anyway
-
Re: Multiple PICs on usart network
It was 64MHz at 115,200 with a checksum that always balanced.
I can't explain it but it worked. But I'm going to do intensive testing soonday and report back here.
Robert
-
Re: Multiple PICs on usart network
for a half duplex scheme to work the slave must not talk unless asked to by the master .
in this spi example the slave loops constantly looking for a change in the rotary coder position.
when a change is detected the new position is calculated and the "mint pin" is set to 0, this signals the master that the slave has something to say. the slave now waits
at some stage the master clocks the data out of the slave , when done it generates a sspif interrupt which terminates the slaves waiting , rinse repeat
the half duplex (simplex) principle remains the same no mater what the transmission medium/method is, for a multi master scheme its no less complex a solution than Ethernet or any other collision sensing multiple access network and not for the faint hearted
Quote:
pos var byte
old_pos var byte
mint var portc.0
tmp var byte
DEFINE OSC 20
adcon1=6
trisc=%11011110
option_reg.7=0
mint=1
SSPSTAT.6=1
sspcon.5=1
sspcon.4=0
sspcon.2=1
pir1.3=0
PIE1.3=1
INTCON=$c0
gosub getp
old_pos=pos
pause 2000
MAIN ; loop here till re moves
gosub getp
if (pos != old_pos )&& (mint) then ; if we have a new move and we are not waiting then
old_pos=pos
sspbuf=pos; ; prep the data to send
mint=0; ;set the pin low to signal master
endif
GOTO MAIN
GETP:
tmp= (porta&$f)|((portb&$f)<<4)
Lookdown tmp,[$7F,$3F,$3E,$3A,$38,$B8,$98,$18,$08,$48,$49,$4D,$4 F,$0F,$2F,$AF,$BF,$9F,$1F,$1D,$1C,$5C,$4C,$0C,$04, $24,$A4,$A6,$A7,$87,$97,$D7,$DF],Pos
return
spo: ; the master has read the data locks released
mint=1;
pir1.3=0
@ INT_RETURN
-
Re: Multiple PICs on usart network
Andy,
Just like Richard says the key is to make sure that the slaves never ever starts to speak without being spoken to. If you have one master and multiple slaves you need to come up with a scheme where the master interrogates the slaves, one by one, and the slaves only speak when asked to speak.
Most of my experience with this type of thing comes from writing code for MODBUS. With MODBUS there's one master and one or more slaves (or servers as they're sometimes called). The master sends out messages on the bus containing a slave adress, a command and some data like "Slave 2, give me the value of your register number 5 and a checksum). All the slaves gets the message, verifies the chcksum and then determines if the message was for them or not. Only the slave with the adress matching that of the message is allowes to speak and must do so within a certain amount of time or a timeout error occurs. A slave can never start talking unless asked to by the master.
There are of course other alternatives, like each slave has a "slave select line". The master asserts the slave select line of one slave at the time and the slave sends whatever it needs to send.
If you need to have multimaster capabillity then perhaps CAN is an alternative.
/Henrik.
-
Re: Multiple PICs on usart network
http://www.sampson-jeff.com/article/.../int.htm#async
Please scroll down to figure 3b;
Looks interesting; Tx, Rx, and perhaps power too, all on 1 line.
Comments, folks?
-
Re: Multiple PICs on usart network
Also, from the forum, http://www.picbasic.co.uk/forum/showthread.php?t=4292
Bob talks of a separate line for flow control, but that could be avoided by querying each slave, I guess.
-
1 Attachment(s)
Re: Multiple PICs on usart network
Recently, I too needed to connect a couple of nodes to a common controller. I wanted a bus on which I could go on adding slaves "in parallel".
Also, half duplex was acceptable in my application. This is the outcome: works like a charm along a 20 meter cable run at 9600 baud. I'm sure will run much longer at slower speeds..
And, comms happen over a single line, so you also save a pin on the pic.
Hope somebody finds it useful!
Attachment 7684
-
Re: Multiple PICs on usart network
Quote:
Originally Posted by
ardhuru
Hello Ardhuru
It is a wonderful idea. I have not already thought about it.
Great work!
Would you please share some routine (source code) about your work?
Andy