Is it possible to perform a loopback test with the max485?

I have been able to successfully implement an atmega328p setup on a breadboard with a max232. I can upload code to the atmega as well as perform a loopback test. However, I am not able to do either when I switched the max232 out for the max485. Is it possible to do a loopback test with the max485 like I did with the max232 or am i misunderstanding how the max485 works?

My setup is I am using the following usb to rs232/rs485 converter:

http://www.ebay.com/itm/PC-USB-to-RS232-RS485-UART-TTL-Signal-Converter-New-/110823389067?ssPageName=ADME:L:OC:US:3160

I have vcc and ground from the converter going into pins 8 and 5 of the max485. I then have the A and B lines from the converter going into pins 7 and 6 of the max485. Finally I have pins 1 and 4 of the max485 connected together in an attempt to perform a loopback. Connecting the Rx and Tx pins together on the max232 is how I performed the loopback test, but when I do this with the max485 I get nothing back.

Interestingly, out of my converter using the rs232 outputs, if I connect the rx/tx together directly without using the max232 I get a positive loopback. But this doesn't happen with the rs485 A and B lines out of the converter. Does that mean the converter is possibly broken for the rs485 part? Or is the output from the A and B lines not in a readable format until it passes through a max485?

Are there any other steps I could perform to determine if my coverter is broken or if the max485 is fried?

-Sathi

The output from the A and B lines are not in a readable format until it passes through a max485. You need a 2nd one.

The A/B wires still represent 1 signal. You cannot short them together.
The A/B wires need to come back into a RS485 receiver to be seen as a single signal again.

It is not clear to me why you couldn't enable both the driver and the receiver simultaneously as long as DI and RO go to separate I/O pins on the Arduino. If you have connected /RE and DE together to make controlling the chip easier, you would have to separate them so that both the driver and the receiver were enabled. Also, you would need to make sure the bus was properly terminated. Mind you, I haven't tried this. This is kinda one of those things that may be against the law, but not against the laws of physics. :slight_smile:

My converter has a max485 in it, which is then hooked up to the max485 on my breadboard. So the output Rx/Tx pins from the max485 on the breadboard should be readable serial data right? I have it like this:

PC --> converter/max485 ---> max485/breadboard ---> output rx/tx connected to each other (pins 1 and 4).

So what can I do with the output from the max485 on the breadboard to test if it is working? I thoguht if I connected the output pins together it would loop back to the pc? I'm confused. Thanks for the help!

-Sathi

Sathi:
My converter has a max485 in it, which is then hooked up to the max485 on my breadboard. So the output Rx/Tx pins from the max485 on the breadboard should be readable serial data right? I have it like this:

PC --> converter/max485 ---> max485/breadboard ---> output rx/tx connected to each other (pins 1 and 4).

So what can I do with the output from the max485 on the breadboard to test if it is working? I thoguht if I connected the output pins together it would loop back to the pc? I'm confused. Thanks for the help!

-Sathi

You would have to separate pins 1 and 4 and connect them to separate pins on the MCU. You would also have to separate pins 2 and 3 so that you could enable both the driver and the receiver simultaneously, which you could do on your breadboard by just attaching pin 2 to ground and pin 3 to Vcc. Then make sure you have a suitable termination resistor, 120R, across pins 6 and 7.

On the software side, since you haven't posted your code we can't tell, you may have to do something different.

Sathi:
My converter has a max485 in it, which is then hooked up to the max485 on my breadboard. So the output Rx/Tx pins from the max485 on the breadboard should be readable serial data right? I have it like this:

PC --> converter/max485 ---> max485/breadboard ---> output rx/tx connected to each other (pins 1 and 4).

So what can I do with the output from the max485 on the breadboard to test if it is working? I thoguht if I connected the output pins together it would loop back to the pc? I'm confused. Thanks for the help!

-Sathi

RS232 is a true full-duplex electrical standard and is why on your multi-converter board you are able to run the loop back test successfully via having the RS-232 send and rec signals wired together. As the max485 converter chip is fundamentally designed to work as a 2 wire half duplex device requiring an active control signal input to enable and disable the driver and receiver portions of the chip at the proper time to send or receive data, it's difficult to create the full-duplex path needed. I suspect if you hardwired both the receiver and transmitter enabling signals to both be active at the same time the data would loop back from the TTL level signals. But if you have those two control signal wired together then you can't do that and under a single input control signal as they are active at opposite logic levels.

Lefty

difficult to create the full-duplex path needed

Difficult but not impossible. The way I see it, if you hooked it up as I described in my reply above, you could use SoftwareSerial, for example, to perform a test like the loopback test for RS232. Correct or not?

PapaG:

difficult to create the full-duplex path needed

Difficult but not impossible. The way I see it, if you hooked it up as I described in my reply above, you could use SoftwareSerial, for example, to perform a test like the loopback test for RS232. Correct or not?

You and I are saying the same thing. With proper manipulation of the enable signals to the max chip a loop-back path should be possible. The problem with RS-485 links and arduino is that both the hardware serial library and the software serial library have no built in function to control the enabling signals the max485 chip needs to correctly switch for transmit mode to receive mode, and that has to be controlled within the users sketch. And now that hardware serial library uilized fully buffered and interrupt driven transmit, it's hard to get the switch over timing correctly without 'chopping off' the transmit message before all the characters in a message have actually been sent out the hardware UART. Not sure if software serial would be as tricky to modify, but again something has to be added either method to handle send/receive switch over control.

Now if you implemented a two pair (4 wire) RS-485 link where you have two max485 chips at both ends that were all hardwired to be send and rec enabled full time, then full-duplex communications would be had without any extra logic control needed to manage the data direction control and the serial communications would be fully transparent to the arduino hardware and software serial libraries. But at the added cost of double the max485 chips required and of course another twisted pair wire link.

Lefty

You and I are saying the same thing.

Yes, I believe we are.

Sathi, since your circuit is on a breadboard I think you can test your RS485 communication like you did for RS232 but you'll have to change your circuit a little bit.

First, on the '328, select a TX and RX pin for use with SoftwareSerial. On the MAX485, connect pin 1(RO) to the '328 pin you selected for RX and connect Pin 4(DI) to the '328 pin you selected for TX. Second, again on the MAX485, connect pin 2(/RE) to GND and pin 3(DE) to Vcc, then connect a 120R resistor between pins 6 and 7.Finally, still on the MAX 485, connect pin 8 to Vcc and pin 5 to GND. Remove any connections to the MAX485 that were not mentioned.

Now, run a sketch like the one you tested your RS232 breadboard loopback with. If you used hardware serial routines in your RS232 sketch, replace those with calls to SoftwareSerial. You should expect results similar to your RS232 test if everything is working okay.

Fantastic, this was exactly the info I was looking for. You guys saved me allot of wire mashing. The duplex explanation makes perfect sense.

So that leads me to a question. Do you need full duplex capability in order to upload a sketch to the atmega? Or can you just send one way to the receiving 328s rx/tx pins and time the reset? I was getting the stk500_getsync() error when I tried with the max458. I know it isn't an issue with timing the reset because I had a very good success rate using with the max232 and uploading sketches. I hope to be able to upload a sketch through the max485 because my design will need them and it would be convenient to use it to update code on each node's atmega without adding a max232 to the design or popping the chips in and out for programming.

PapaG, I am going to give the test you suggested a try. Seems like a good way to see if the max485 I have is broken. I had not been using hardware or software serial in my previous tests for loopback, just typing some text into a hyperterminal on the serial port. If I am understanding this right I will first upload the software serial sketch to the atmega, and then I will wire this up and the PC should be able to read the serial prints that the atmega is reading in and then replying back with?

Thanks again guys, this has been a tremendous help.

-Sathi

"Do you need full duplex capability in order to upload a sketch to the atmega? "
Yes.

Do you need full duplex capability in order to upload a sketch to the atmega?

I don't know how you'd get get around it without modifying the bootloader. You can consider updating your code through ICSP instead. That way you will have more versatility with serial communication.

PapaG, I am going to give the test you suggested a try. Seems like a good way to see if the max485 I have is broken. I had not been using hardware or software serial in my previous tests for loopback, just typing some text into a hyperterminal on the serial port. If I am understanding this right I will first upload the software serial sketch to the atmega, and then I will wire this up and the PC should be able to read the serial prints that the atmega is reading in and then replying back with?

Are you talking about the MAX485 on the ebay converter or one on your breadboard?

If we are talking about a breadboard one, the scheme I am suggesting would have you use your USB to TTL converter to send debug commands to your PC terminal or to the serial monitor in the Arduino IDE. In your test sketch, using SoftwareSerial, you would transmit a character through the MAX485 and receive it back. You would compare the transmitted to received characters to make sure the RS485 circuit worked, reporting the success or failure through the hardware serial port to the PC.

I was talking about the breadboard one. This sounds like it is going to do exactly what I need. Once I can do a basic sanity check on the hardware I think it will be pretty straight forward for me. I don't need the atmega to do anything complicated, just receive instructions from its master over rs485, and then tell its local tlc5940 to turn on/off its LEDs. I could probably just proof that part on the breadboard, use the max232 to upload the finalized code to the rest of the atmega slaves, and be done with it. Then all the real programming will be done with a single master and be easy to deal with.

I'll report back with the results of the test. Much appreciate the help.

-Sathi

use the max232 to upload the finalized code to the rest of the atmega slaves,

If you mean to upload sketch code from the arduino IDE to the remote slaves via your link, how do plan to handle the DTR auto-reset function that kicks off the bootloader code at the correct time to sync up with the IDE and AVRDUDE for uploads?

Lefty

No, what I mean to do is develop the recieving code for all the slaves locally on the breadboard, and once that is complete I will upload that code to all the needed slave atmegas locally off the breadboard with the max232, and then I will put them into their final node circuit. I really just need for slaves to listen to the master say something like "Slave #6, turn on LEDs 4,7,12, and 14. Turn off 6", and perform that action. I believe that should be relatively little code for the slave. Once that is working I doubt I will need to update them much. I imagine most of my time will be spent on the master side programming the light sequencing it will direct the slaves to perform. I hope that makes sense and there is no major flaw in my plan :slight_smile:

-Sathi

Sathi:
No, what I mean to do is develop the recieving code for all the slaves locally on the breadboard, and once that is complete I will upload that code to all the needed slave atmegas locally off the breadboard with the max232, and then I will put them into their final node circuit. I really just need for slaves to listen to the master say something like "Slave #6, turn on LEDs 4,7,12, and 14. Turn off 6", and perform that action. I believe that should be relatively little code for the slave. Once that is working I doubt I will need to update them much. I imagine most of my time will be spent on the master side programming the light sequencing it will direct the slaves to perform. I hope that makes sense and there is no major flaw in my plan :slight_smile:

-Sathi

That sounds like a very workable plan. It gets a little more complex in master and slave code if you want the slave to send feedback information to the master as to if it got the message OK or perhaps you want the master to be able to ask a specific slave what outputs do you presently have on? Typically RS-485 links will implement a robust software protocol to use to communicate back and forth with the slaves and it might include error detection check sum or CRC bytes to every 'message'.

Good luck on your project.

Lefty

Typically RS-485 links will implement a robust software protocol to use to communicate back and forth with the slaves and it might include error detection check sum or CRC bytes to every 'message'.

A good example of such a protocol from Nick Gammon: Gammon Forum : Electronics : Microprocessors : RS485 communications