rs232 hardware question

[gjs_rsdi]

Hi

EUSART 18FX6K22 & 16F1847
Again, maybe I missed something in the data sheet so here is my question:
I would like to have rs232 communication between one master and a few slaves.
With the RX is simple as each one have a few addresses that according to the address will enable they TX and send they data accordingly and they are input.

In the data sheet is written that the stop bit is always 'H' (I know that from assembler) but I don't understand if the line remain 'H' until a start 'L' will be sent?
I am avoiding bus collision on the TX right now by using a mux. It is necessary?
Can just simply make the pin an input until it will have to send a message again?
Or just enough to disable the TX interrupt?
Hope someone can tell me what to do without using the mux.

Best wishes
Joe

[RF_Developer]

[gjs_rsdi]

Thank you for the answer RF_Developer

I am using the MAX chips for rs485 in some applications if I need distance in noisy environment.
In this case the controllers are close each other so I was thinking I can eliminate the mux.
I understand from your post that I can't.
Thanks again.

Best wishes
Joe

[temtronic]

As long as there's only one 'master', you shouldn't need the mux, it's all down to your 'protocol' you design.
Each 'slave' is assigned a unique address, either via DIP switch setings or burned into it's program. Until it receives a command from the master , it'll just listen on the RS485 bus.
It's the master that controls the bus. At an appropriate time, it sends out a 'command string' to say 'slave 4, status please'. Then slave 4 responds with the required data.
As to how fancy and secure your 'protocol' needs to be is up to you. Some folks don't worry about a checksum, especially if it's a short haul and small amount of data. Others require a 'tighter' level of control.

There's probably 1000s of examples of RS485 use, even CCS has examples in their 'examples' folder !

Jay

[gjs_rsdi]

Thank you for the answer Jay

My protocol is OK, check sum, etc' and I am using one master in the way you are writing.
As the controllers are close each other, it is more simple for me to use the mux, otherwise I will need rs485 chip for each controller.

Best wishes
Joe

[Ttelmah]

'A few' is a very open value.

This all depends on the capacitance of the lines, the speed you are driving the bus, and the environment in which it must work. Add then the complexity if you have several 'legs' to other devices of bus reflections. This is why RS485, is a terminated bus, and specifies maximum leg lengths etc..

Now you started by confusing things and talking about 'RS232'. From your description, you are not using RS232. RS232, is a signalling standard. Nothing to do with TTL or logic async serial (which is what a PIC generates). This signal only becomes 'RS232' when it is passed through an RS232 transceiver chip. I've 'sworn' in the past at why CCS calls the UART setup '#use rs232'. It's the simple thing that for 90% of users this logic standard will be fed to a RS232 transceiver. However the same standard can be used on lots of other busses, including RS485 etc..

Now, assuming you are not using 'RS232', then it is really pointless to be fiddling around with a multiplexer. From your description (limited), you are talking about a 'master', and a number of 'slave' devices, which only talk in response to the master?. These devices are close to the master?. Quite a bit depends on how electrically noisy the environment is likely to be?. Another question is how the connections are made?. There is a significant difference between a bus on a PCB, and a bus to devices that may be unplugged. Assuming your 'fanout' is small (how many 'slave' devices there are), the bus is relatively short, the noise is small, and that the data rate does not have to be high, (and that slave devices can never be present on the bus and turned off), then there is a very simple solution of just turning the transmit lines into 'open collector' lines.

Simply connect the master TX to the RX's on all the slave devices. Connect all the slave TX's together, and feed these all to the master RX. Have pull up resistors on both lines (perhaps something like 2K2R).
Then in all the devices select the option in the #USE RS232 'FLOAT_HIGH'. This means the compiler will 'tri state' the TX pins, after a transmission is complete, so provided your protocol is carefully designed (and you add some 'recovery options - so that for instance if a 'slave' does not see any bus activity for a while, it automatically resets itself). This can potentially work quite reasonably.
However 'caveat'. RS485 brings the big advantage of better noise immunity (differential bus), and of much better input protection. It's also designed to handle some common mode voltage differences between the boards, which a 'TTL bus' cannot to any significant extent. A RS485 transceiver has current limited outputs, slew rate limits to reduce bus reflections, inputs designed to survive significant voltages (devices like the LT1785, are rated to handle +/-60v, and up to 15Kv ESD). If the bus is going more than a very few inches, the cost of the RS486 transceivers, may well 'pay for itself' very quickly....

[RF_Developer]

Another idea - I2C was designed specifically for this purpose: to interconnect ICs on a board using as few connections as reasonably possible. It is not great with multiple boards as it has relatively little immunity against common-mode signals, i.e. voltage differences bewteen boards. However, if they share a common supply then I2C should be okay.

I2C is usually run with a single master and one or more slaves, but can also, with a fair bit of extra firmware work when using CCS to be fair, be run with multiple masters.

PICs have good I2C hardware internally and no additional hardware is required other than a pair of pull-up resistors. It uses no more interconnections than a full duplex TTL serial link, and less hardware than RS232 or RS485 as there are no interface ICs.

CCS has reasonable firmware support for I2C, though it is a little more complex to use than asynchronous serial (e.g. "RS232") and there are common gotchas, which are asked about often on this forum, which means there's plently of good advice on I2C here.

[gjs_rsdi]

Hi Ttelmah
Thank you for the reply and sorry if my posts were not enough clear.
I am using TTL and not rs232 chip, I used the terminology rs232 because in the CCS compiler as you said, they call the UART rs232.
I used extensively and successfully rs485 in noisy environment, up to 20 meters and 8 slaves, with twisted and shielded wires.
I am planing to have one master and 3 slaves on the same board, ground pour on both sides. The baud rate is 9600BPS.
I didn't know that the compiler have #USE RS232 'FLOAT_HIGH' directive.
If I was knowing that, I was just asking where to put the #USE RS232 'FLOAT_HIGH' in the program.
Can you tell me where to put the #USE RS232 'FLOAT_HIGH'?

Hi RF_Developer
Thank you for the reply.
I am planning to use I2C also.
I used I2C in the past with assembler, have no experience using I2C with CCS compiler.
I copy/paste to a file almost everything that Ttelmah, PCM Programmer and others wrote about I2C and I hope will go without big issues.
For longer distances and different VCC, I am intending to use the P82B96
The data sheet is very clear about how to use it.

Best wishes
Joe

[Ttelmah]

First remember you can have multiple I2C master ports. For what you describe on a single board, this is really the easiest way to go. Just setup a second port to talk to the other parts.

#USE RS232 is the standard setup you use to configure the RS232 port. You can just add the 'FLOAT_HIGH' to this as one of it's options. You then need pull-up resistors on the RS232 lines, and when the chips are not sending, the compiler will tri-state the TX line.

[temtronic]

One other possible method is to use a 'single wire', examples include Dallas' one wire chips, CCS has a code example (in FAQ section I think) and I've done true single wire for 25 years going 15 miles on solid copper.
In my case I had up to 32 slaves to each sub master, 16 sub master to the master. It's not fast (24 baud) but far more reliable than anything else out 'there'.

Jay

[gjs_rsdi]

Thank you for the reply Ttelmah.
Helpful like always

Thanks for the reply and advice Jay
I have just one master on both UART system and I2C so is more easy.
The maximum wire length will be 5 meters and one more wire is not an issue.
I will try to checkout the Dallas one wire thing.

Best wishes
Joe

[Ttelmah]

15m is a significant distance. Rather more than a 'board'...

Now several things apply:
1) Protect the lines. Don't rely on the internal protection diodes, add your own protection where lines come onto each board. Can be very simple (pair of diodes clamping the signal from going outside the power rails), perhaps with a series resistor or a small self resetting fuse. You will be amazed at how often this can 'save' your circuits.
2) Look at the nature of your wire. Remember there is always going to be interference. Now there are different solutions in different circumstances, but one method that can run quite well over short distances, is to have a multi strand wire inside a shield. Ground the shield _at one end only_. Then have pairs of the multi strand wire doing different jobs. So (for instance), one pair for the supply (if this is fed between the boards). Shielded network cable is cheap, readily available, and works well.
3) If you are distributing the supply, consider sending at a higher voltage. So a 12v supply fed to multiple boards, which is regulated locally to 5v, works well.
4) Consider terminating the lines where they enter the boards. If you look at burglar alarm signalling, they use a simple 4K7 pull up in each device. Works quite well, and for the small number of devices allowed on each line, doesn't overload the drivers.
4) Speed is your enemy!... A TTL signal sent at 300bps, can go a huge distance. Send the same signal to 19200bps, and it can easily become unreliable at quite short distances. Go to 115200bps, and after even a few feet you start to run into reflection problems, slew rate limitations because of the capacitance etc...

Have fun.

[temtronic]

As Mr. T points out, noise aka EMI, can play havoc, even with the simplest systems.
It's the stuff you don't think about..cell phones, PWM drills, welding machines, especially random events, so the more robust or bullet proof you can make your system, the more reliable.
re: speed vs distance. I know that with solid copper conductors you can easily go 15 miles at 24 baud and be 100% reliable ,providing you design for the odd, nearby lightning strike to occour.
Yes, 5m =+-16 feet, say other side of big room, isn't far but there could be a lot of EMI there. CFls and LED lights can be 'noisey'. yet another source we don't consider. I'd use RS-485 transceivers. projects always tend to grow, expand and it's nice to NOT to have to redesign more than 2-3 times !

Jay

[gjs_rsdi]

Thank you for the answer Ttelmah and Jay.

I made a redesign and I will have one master and two slaves on the board and the pull-up resistors. In this stage of prototyping the components are true hole.
I am intending to use this board for 4 projects so I made it with four headers and different IO boards for each project connect on the controller board on top with female headers.
The controller board will be digitally isolated from the system by digital isolators, this stage by optocouplers. Will have separate isolated VCC and GND.

Will implement as much as I can, the advice you and others had given me.

Best wishes
Joe

[temtronic]

Please be sure to read and re-read the optocoupler specs !! some ain't good at high speed... yeah, been 'bit' by that once or twice in the past....

Jay