MAX485 signal mystery

[earckens]

EDIT: I am not sure this was posted in the correct subcategory?

A simple circuit with a MAX485 (attachement 1) works perfectly when used in a breadboard setup. However, as soon as the test is transferred to a fabricated pcb this circuit does not work.

1. The RS485 link receives valid data which is correctly parsed in the breadboard dcircuit. The RX line receives data (see attachment 3: scope printout), the DE line is properly pulsed when TX wants to send its reply. The master acknowledges receipt.

2. However, when using the PCB design (attachment 2), RX is still properly received at slave controller level (stil same image as attachment 3) but DE does not respond: level stays low, ie no intention to transmit.

Same software, same controller.
When reverting back to the breadboard setup all functions as should be.

When in breadboard modus I connected DE from the breadboard setup to the PCB (with a MAX485 soldered in place, under power: all still ok (to make sure there are no PCB issues with the DE line).

When removing the soldered MAX485 from the pcb for testing: it functions well, all ok.

I am "end of line" after two days of testing; any help would be very greatly appreciated!

/* http://www.utrainia.com/65-arduinocmri-and-rs485
/* Arduino CMRI and RS485
*/

#include <Auto485.h>
#include <CMRI.h>

#define CMRI_ADDR 0

#define    DE_PIN 2
#define   LED_PIN 13

Auto485 bus(DE_PIN); // Arduino pin 2 -> MAX485 DE and RE pins
CMRI cmri(CMRI_ADDR, 24, 48, bus); // defaults to a SMINI with address 0. SMINI = 24 inputs, 48 outputs

void setup() {
  pinMode(LED_PIN, OUTPUT);
  bus.begin(19200);
}

void loop() {
  // 1: main processing node of cmri library
  cmri.process();
 
  // 2: update output. Reads bit 0 of T packet and sets the LED to this
  digitalWrite(LED_PIN, cmri.get_bit(0));
 
  // 3: update input. Flips a bit back and forth every second
  cmri.set_bit(0, (millis() / 1000) % 2 == 0);
}

 

[FvM]

Is there a way to correct this in software? The controller I use (AtMega328 in "pro mini" version) does not have a UART chip, TX and RX are directly read by the controller.

ATmega has no provision to invert UART polarity. Swapping A and B lines is the only option.

 

[KlausST]

Hi,

Afaik the AVR has no programmable UART polarity, thus it always expects idle HIGH and is synchronized by a LOW START bit.

Klaus

 

[earckens]

I was thinking of a software solution: if at idle RX is not high then polarity of incoming bits must be inverted. Something like that?
The fact there is no hardware UART means that software parses what is incoming; so if the expected idle "high" state is not there, then inverse whatever follows..?

 

[KlausST]

Hi,

I was thinking of a software solution: if at idle RX is not high then polarity of incoming bits must be inverted. Something like that?

Wrong thinking ... (at least when you want to use the AVR internal UART hardware.)

You say "incoming bits" ... but "bits come in" triggered by a falling edge = start_bit.
You are free to use software_UART.

By why not simply swap the bus wires at the connector?

Klaus

 

[earckens]

That is the point: when using a controller based board without UART then RX and TX are handled by a software serial part in its program.

"..why not simply swapping bus wires..": if polarity can be handled by software, why bother?

But I guess I have to post this in a software specific forum.
Erik

 

[FvM]

A 19200 Baud software UART is possible on ATmega but consumes a considerable share of the available processing power. Time critical tasks may be affected. Look for Arduino SoftwareSerial library, it has a inverse_logic option included. https://www.arduino.cc/en/Reference/softwareSerial

 

[earckens]

...

Arduino SoftwareSerial library, it has a inverse_logic option included. https://www.arduino.cc/en/Reference/softwareSerial

Interesting, I was not aware the inversing logic is available in that library. Thanks!
Erik