Go Down

Topic: Arduino serial via MAX485 IC, additional bytes appear in communication (Read 518 times) previous topic - next topic

irieger

Hello,

I try to build a communication between multiple Arduinos and a Raspberry Pi. To try the general workings I started out to test Communication between two Arduino Mega (as due to their additional Serial ports I can use the Serial console to monitor data and use another serial for the communication).

To test the communication I wrote some simple test code which works fine when directly connecting the Serial Ports of both Megas, but when I then try to add MAX485 chips and do two way communication, I get bogus bytes in the serial bus. When I comment the return channel out everything transfers fine, when I have the code added to switch direction I get those additional output. Played with different delay times and baudrates without success.

The code and the resulting output can be found on https://github.com/irieger/arduino-rs485-test
Output of the master is showing the value of an unsigned integer I send with "> " as a prefix while returned unsigned ints are prefixed "< ". Both sides wait for two bytes available and the read them and send back in case of the slave.

I'm going to add a proper protocol with addresses and start/stop bytes but as long as the basics aren't working and data gets scrambled ...

What could the problem be here?
Is Serial.print/Serial.write blocking so I can expect data to be transmitted when command is executed or do I have to expect it to do work after?


Regards,
Ingmar

noiasca

pls show up a clear picture of your wiring to see how you have connected the 485. Pull/up Pull/Downs, the 120Ohm resistor, DE/RE

by the way, this tutorial for general Arduino-Arduino RS communication is a pretty good start

https://forum.arduino.cc/index.php?topic=396450.0
DE: Wie man Fragen postet:
1. was hat man (Sketch und Hardware)
2. was SOLL es machen
3. was macht es: IST (Fehlverhalten, Fehlermeldungen, Serial.Output ...)
4. Eine Frage stellen bzw. erklären was man erwartet

pylon

Quote
What could the problem be here?
I agree with noiasca that a wiring diagram is necessary to analyze the situation. I guess that you forgot to put the RO pin in a defined state. While RE is low the MAX485 will control that pin but if RE is high the pin is left floating by the driver chip. In this case the pin may show any noise the surrounding area provides. A simple pull-up resistor may help.

Quote
Is Serial.print/Serial.write blocking so I can expect data to be transmitted when command is executed or do I have to expect it to do work after?
The Serial object is doing it's work in a special interrupt, so the output you provide to print/write methods is just copied to an internal buffer and the method returns. If you want to block until all data is sent, use the flush() method.

irieger

pls show up a clear picture of your wiring to see how you have connected the 485. Pull/up Pull/Downs, the 120Ohm resistor, DE/RE
As the image attached to this post might not really show this clearly enough, the wiring is (for both the same):
Arduino Pin D10 <-> MAX485 Write enable+Read enable (as Read enable is an inverted input)
Arduino RX2  <->  MAX485 RO
Arduino TX2  <->  MAX485 DI
Arduino 5V    <-> MAX485 VCC
Arduino GND  <-> MAX485 GND

MAX485 A/B connected between both MAX485 chips, GND also connected just in case if I use different systems while testing and not have both on the same USB with shared ground.

Also 120 Ohm between A and B on both size (might be a 150 Ohm, have to check, think the tutorial I went with named a 150 Ohm resistor).


by the way, this tutorial for general Arduino-Arduino RS communication is a pretty good start

https://forum.arduino.cc/index.php?topic=396450.0
Nice tutorial but not so much new for me there.



I agree with noiasca that a wiring diagram is necessary to analyze the situation. I guess that you forgot to put the RO pin in a defined state. While RE is low the MAX485 will control that pin but if RE is high the pin is left floating by the driver chip. In this case the pin may show any noise the surrounding area provides. A simple pull-up resistor may help.
See above. RE and DE are connected together to digital pin 10.

The Serial object is doing it's work in a special interrupt, so the output you provide to print/write methods is just copied to an internal buffer and the method returns. If you want to block until all data is sent, use the flush() method.
Ok, thats news for me. Good to know. Seems checking https://www.arduino.cc/reference/en/language/functions/communication/serial/availableforwrite/ and only switching write bus of might be the way to go (or in this simple case use flush to block).
(By the way created a pull request for the above post as I think I found a type [read instead of write in the definition of the return value].)

EDIT: Btw. I'll try my code with an added flush command later on. Also I'm thinking about switching to the MAX491 chip using it to have one line for the master always sending and just have a shared return for all the slaves to send status reports.

pylon

Quote
See above. RE and DE are connected together to digital pin 10.
I wrote "RO" not RE. RO is floating if RE is HIGH, so while you're sending out some bytes you're receiving random data. As the floating pin is near the sending pin you might catch up a faulty version of your sent data. In any case you get readings you cannot interpret correctly.

Quote
Btw. I'll try my code with an added flush command later on. Also I'm thinking about switching to the MAX491 chip using it to have one line for the master always sending and just have a shared return for all the slaves to send status reports.
In that case you need the idle state fixation resistors for both pairs (pull-up/down for A and B), at least if don't let DE HIGH constantly.

irieger

I wrote "RO" not RE. RO is floating if RE is HIGH, so while you're sending out some bytes you're receiving random data. As the floating pin is near the sending pin you might catch up a faulty version of your sent data. In any case you get readings you cannot interpret correctly.
Oh sorry, mixed this up. I just put a 10 kOhm between between 5V and RO on both sides.


In that case you need the idle state fixation resistors for both pairs (pull-up/down for A and B), at least if don't let DE HIGH constantly.
I also put two 18 kOhm between GND and B as well as A and 5V (Didn't had the 20 kOhm as suggested in http://yourduino.com/sunshop//index.php?l=product_detail&p=323 which I just found earlier). Should Pull-Up/Down be done on all members of the Bus or should one end be sufficient? Would expect the latter?

(DE High all the time would only be true for the sending master when I switch to the MAX491, all slaves would share the return channel and answer the master if requested by their address on the shared bus variant. So there would be times without an active sender [most of the time actually])


Seems to work mostly, will have to add start and stop byte of course but besides that it seems to transmit correct packages. Data is mixed up but there seems to be some bytes recognized that where not sent (Receiving 6F00 when 006F was transmitted and 1-2 junks of zeros coming in)

Thanks for yout help. Will add check for start/stop byte and sending of those later and report back if there are any problems.

pylon

Quote
I also put two 18 kOhm between GND and B as well as A and 5V
I use 470Ω. I'm not sure if resistors that high work with longer cables as they probably won't get the wires to the correct level fast enough.

Quote
Should Pull-Up/Down be done on all members of the Bus or should one end be sufficient? Would expect the latter?
They must exist only once per bus.

Quote
DE High all the time would only be true for the sending master when I switch to the MAX491, all slaves would share the return channel and answer the master if requested by their address on the shared bus variant. So there would be times without an active sender [most of the time actually])
I have no experience with a full-duplex bus.

irieger

Thank you, just found some time this week to get back to my project. In the meantime I got a few MAX491 chips and now have a working full duplex network working well.

Thank you all for your tips and help.

Go Up