RS 485 and microcontroller

[movie_freak]

Hi,


I want to interface RS 485 with a microcontroller, its ok with the hardware part, I am going to use a ISO3088 isolated 485 chip from TI. I'll connect one of my uart to its input from the controller which would be master...... now from its output i want to connect some slaves. I know that max slaves possible = 32 and would also depend on the communication cable length. I want help regarding the software side logic.

My requirement is Full duplex but it should be able to send data from master whenever needed and slave will only reply when master queries them.

I am thinking to implement in this way:
I'll make packets with header and payload(data). The header would contain information about the data like slave address, checksum, whether it is data to be accepted or it is a query command

I wanna know is this way of doing it is correct? or there is any better way?


Many Thanks,
Regards,
Surya

 

[bobcat1]

HI

you need to configure you network in star configuration - 1 master and many slaves

You don't need full duplex communication if the slave is only going to answer when master allow him to do so

Protocol is need needed in star configuration

All the best

Bobi

The microcontroller specialist

 

[planet69]

you can't do a full duplex with RS485.
those chips only allows 'one-way' traffic...something like a walkie-talkie.

 

[movie_freak]

I was actually looking for some kind of an approach or a way of doing this.. :idea:

 

[ftsolutions]

You CAN do full duplex in RS485 - one simply has to use the right driver chips that aren't hard-wired for 2-wire communication only. You need 4 wires, plus a shield(Recommended) to do full duplex RS-485. However, as you indicate that you are really only going to use it in half duplex mode (only 1 talking at a time) using just 2 wires instead of 4 makes sense, cost-wise.

You also don't need to make it a star - you could basically have a "bus" topology with this scheme as well.

Suggest you take a look at some published standards, like Profibus, CANOpen, etc. for example. There are docs on the net that give you a good idea how it works. Once you understand that, you can implement your own variety of a protocol, but at least you will learn why protocols do what they do and you can implement yours according to how fancy/complex you want to get.

 

[ChrisC]

I'll make packets with header and payload(data). The header would contain information about the data like slave address, checksum, whether it is data to be accepted or it is a query command

I wanna know is this way of doing it is correct? or there is any better way?

I don't know if there's a better way of doing it, but that's basically how we used to do it at the first company I worked for, where we were using RS485 to network HVAC controllers. We had individual RS485 networks of up to 127 slaves (we were using 1/4 load drivers), with network bridge devices allowing multiple networks to be hung off another network in a hierarchical setup - IIRC the largest installations had a few thousand slave nodes in all.

I can't now remember all the details of the in-house protocol we used (and even if I could, I suspect the company lawyers might take a dim view of me divulging too many details about it!), but essentially it worked as you describe. Each message consisted of a 15-byte header packet, which consisted of a 2 byte preamble sequence intended to allow the slaves to detect the start of a new packet, then the source and destination addresses (we needed to tell the slaves where the message was coming from, because in setups with multiple networks bridged together there could be multiple masters capable of taking to a particular slave), then the message type, data location (all our comms was based on reading from/writing to specific table locations within the device memory - table 4 was the device name, table 69 was the device RTC settings etc.), data length and finally an 8-bit CRC.

If the master was writing to the slave, then immediately following the header packet would be the corresponding data packet, which was simply the raw data to be written followed by a 16-bit CRC.

If the message was being sent to a specific slave (point-to-point), and the checksums had validated OK, then the slave was required to respond with either an ACK or a NAK header - an ACK told the master that the message had been received and acted on OK, a NAK told the master that the message had arrived OK but it was something the slave couldn't do (e.g. trying to set the RTC on a device which didn't have one...). If the master had requested data back from the slave, the slave would then transmit the data packet immediately following this ACK header.

We also had message types for group and globally addressed packets, which the slaves wouldn't respond to (the last thing you want is for multiple devices to try talking at the same time...) - the idea here was to minimise the number of messages the master had to send out to perform routine updates across a number of slaves (e.g. setting the time), where it wasn't critical that the master received confirmation that the update had been accepted.


It was a relatively simple protocol to implement in code, which was important given that whilst the master devices were typically quite high powered, the slave devices generally had as little processing power as it was possible to get away with. Despite it's simplicity, it seemed to be pretty robust - it'd been in use for something like 5 years before I joined the company, and we were still using it heavily when I left 6 years later, with the only problems occurring due to bugs in the device firmware or hardware installation errors (running comms and power cables side by side was always a favourite trick of the installers, even though every single device came with specific instructions NOT to do this...).

As far as the implementation was concerned, the only things to watch out for were to make sure the master waited a sufficient length of time for the slave to respond - taking into account not only the speed at which the slave could reasonably be expected to start responding, but also the speed at which the network could be turned around (this shouldn't be an issue on a full duplex network, but on our half-duplex networks we had to insert a short delay to allow the drivers to settle after being switched from TX to RX or vice versa). We also had to consider what to do if a response wasn't received - balancing the number of retries against the need to maintain a decent level of message throughput on the other slave devices.


Anyway, personal trips down memory lane to one side, the point is that your basic idea sounds OK, and you just need to consider how robust and flexible you want your protocol to be - a lot of the stuff I've mentioned above, like network bridge support, group/global addressing etc, you probably don't need at this stage, if ever.

 

[planet69]

You CAN do full duplex in RS485 - one simply has to use the right driver chips that aren't hard-wired for 2-wire communication only. You need 4 wires, plus a shield(Recommended) to do full duplex RS-485. However, as you indicate that you are really only going to use it in half duplex mode (only 1 talking at a time) using just 2 wires instead of 4 makes sense, cost-wise.

yes you are right.
we just have to look beyond a 2-wire setup to develop a full-duplex in RS485

 

[er.vipulbagga]

have you succeded in doing rs 485 , if yes then can you pls send some circuit for it , i m also tring toimplement , and would be glad if you help

Warm regards ,

Vipul Bagga

R & D engineer

---------- Post added at 07:32 ---------- Previous post was at 07:28 ----------

can you please help me with circuit of rs 485

i have two rs 485 to 232 convertor and i want to check the loopback test , i tried two computer it works but when i connect pin 2 & 3 on one side of the
rs 232 data doe'nt comes back , i must be making some mistake , if can suggest something it would be a great help
pls reply on my mail if possible
er.vipulbagga@gmail.com
Warm regards ,

Vipul Bagga

R & D engineer

Mobile : +91-8826624066

---------- Post added at 07:37 ---------- Previous post was at 07:32 ----------

can you help me with circuit of micro controller interface with rs 485 i have rs 232 for now
,
i have 2 rs 232 to 485 converter how to test it loop back and they are working fine with 2 pc but , not when one side is connected to uc

 

[siongboon]

RS485 is for half duplex.
Use RS422 for full duplex. IC chip like MAX422 should be able to do the job.
Some reference regarding full duplex-ing RS485,
**broken link removed**

yes you are right.
we just have to look beyond a 2-wire setup to develop a full-duplex in RS485

 

[Arch Zone]

RS485 can be full duplex if use 4 wires. 2 wire for TX and 2 wire for RX of microcontroller's port. But it only works on peer-to-peer connection. If there are 32 slaves, there is no problem when master send data to all slaves. The problem will occur when a slave wants to send data (switch the slave's TX line to Low state), but the others still keep their TX line at High state.

 

[siongboon]

There should not be any problem if the output state is probably controlled by the slave.

RS485 can be full duplex if use 4 wires. 2 wire for TX and 2 wire for RX of microcontroller's port. But it only works on peer-to-peer connection. If there are 32 slaves, there is no problem when master send data to all slaves. The problem will occur when a slave wants to send data (switch the slave's TX line to Low state), but the others still keep their TX line at High state.