Multiple PICs on usart network

[Demon]

Hi,

This is what my circuit looks like:




- 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:

' 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:

' 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:

' 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

[HenrikOlsson]

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.

[rmteo]

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.

[dhouston]

http://cool-emerald.com/?p=711

[MikeWinston]

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.

[Demon]

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

[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:

...
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

[dhouston]

The MAX3322E & MAX3323E are designed for this, as well, if using an RS232 transceiver.
http://www.maximintegrated.com/datas...ce=supplyFrame

[JoseJimenez]

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

[JoseJimenez]

this is my mail:
[email protected]

[Demon]

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

[sayzer]

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.

[Demon]

Can't comment on the diodes, but disabling USART also turns off receive. That's why I disabled only transmit.

[dhouston]

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

[JoseJimenez]

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.

[JoseJimenez]

here you have

[JoseJimenez]

[sayzer]

Post #8, "MAX3322E & MAX3323E are designed for this..."

Pretty much the same thing, but you need an extra I/O pin.

[Demon]

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

How fast a baud rate do you think this can handle?

[dhouston]

How fast a baud rate do you think this can handle?

I don't know. I seldom need more than 9600bps with embedded devices.

[Demon]

I needed 115200 at 48mhz, not sure diodes could handle it. Switching coms in software doesn't add hardware limitations.

[timmers]

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.

[prstein]

Hey Everybody,

Thanks for this thread, you saved me a truckload of frustration! The series diodes worked in my case.

All the Best,
Paul

[JoseJimenez]

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

[Wilton55]

Just another quick question, would using two MAX232 devices (one on each chip) and a common ground not also work?

[Demon]

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

[Demon]

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.

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:

...
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.

[tumbleweed]

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.

[HenrikOlsson]

Hi,
This....

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.

[Demon]

...
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

[tumbleweed]

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.

[HenrikOlsson]

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

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.

[richard]

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

[Demon]

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

[richard]

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

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

[HenrikOlsson]

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.

[ardhuru]

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?

[ardhuru]

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.

[ardhuru]

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!

[andymuller]

Hope somebody finds it useful!

Attachment 7684

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