RS485 With MAX3085 & PIC16F15356

[Backfire]

Hello all,
I've a question on RS485, which admittedly may be more hardware-focused at the moment, but I also want to ensure my PIC configuration is correct...

I have a Waveshare USB->RS485 driver that is generating the signals shown on the 'scope trace below, these are the signals as measured into a MAX3085 chip at the A & B chip pins, on a custom PCB.

This trace was also captured with a GND/0V signal bias on the B line (via a 715R resistor) and a +5V signal bias (again, via resistor) on the A line, also applied near the MAX3085 driver IC itself.

The trace was captured when including both the 120R termination resistor near the A/B output (currently only attempting data reception by the PIC) of the Waveshare module, and another termination resistor at the A/B pins of the MAX3085.



The yellow trace is the 'A' signal, and the blue trace 'B', using the MAX3085 nomenclature. The purple/pink trace is the oscilliscope math function of 'A-B'.

My current PIC configuration is as follows;
Driving the DE and (NOT)RE pins of the MAX3085 low, and my PIC is running other code without issue from the internal oscillator, @ 32MHz, with the RS485 serial port configured with the following parameters;

[Ttelmah]

First, your INT_RDA, wants:

[Backfire]

Hi Ttelmah,
thanks for your reply.

I can confirm that the devices all share a well-established common ground.

I have made the modifications to my ISR, but presently that never triggers, hence my suspicion I've a hardware issue currently.

Can I ask why you recommed that the (NOT)RE & DE pins are tied together? I can see this is a common implementation, but surely if the PIC can drive those pins to any state, or combination of states I should still have a valid reception?

As for a pull-up on RO, I've not seen one mentioned in the datasheet as being required... As this device is already soldered to a custom PCB, would the PIC's internal WPU likely to work, for testing at least?

Many thanks again for your advice.

[temtronic]

comment...
if you tie both -RE and DE together ,only ONE pic pin is needed to control BOTH receive and transmit of the RS485 device....otherwise you need 2 pins and we always run out of pins before the end of the project....

to make RS-485 bus 'bullet proof', you use 750r pullup, pull down AND the 125r bias resistor. While you 'may' get away with fewer resistors,sooner or later, depending on chips used, PCB layout, wiring, gremlins...you WILL have a 'problem'...... So spending 3 cents for 3 parts makes sense .

in the end, you want to design/build RELIABLE equipment,and no amount of costly and clever software will FIX faulty hardware.

[Backfire]

Hi temtronic,
I agree with you 100%, I have run out of pins on many projects, and the frustration is real!

That said, I don't believe my schematic is electrically incorrect, just maybe inefficient regarding the separated drives for (NOT)RE and DE.

As for the RS485 'side' of the circuit, on my target PCB I have the full biasing and termination network, and have terminated at the driver-end also.

Are you suggesting I need to add the biasing resistors at the point where the signal is introduced by the Waveshare module, as well as the termination resistor that is already present?

Many thanks for your input!

[Ttelmah]

The point is that chips vary. Some RS485 receivers will receive if RE is
low, whatever the state of DE. Problem is then that the device will receive
what is being sent. In your case if RE is high and DE low it goes into a
shutdown mode. Much safer to use just the two states. RE and DE both low,
which receives, and RE and DE both high for transmit. This saves a pin on
the PIC and avoids the possibility of receiving while transmitting, and of
going into the shutdown mode.

[Backfire]

Hi Ttelmah,
I completely understand, the two pins tied together is a more elegant solution, and inherently avoids some possible pitfalls.

But I have driven both (NOT)RE and DE low, am sending data into the MAX3085 as shown above, and I am still seeing no output from the RO pin of the MAX3085.

Is my configuration of the UART correct for RS485 reception?

Here's my current config;

[Ttelmah]

No.

This is a PPS chip. Look at the sticky at the head of the forum on how
to use the UART with this.

[Backfire]

Hi Ttelmah,
I have already attempted configuration as follows, including the below;

[Ttelmah]

The enable pin is done in software, not part of the UART hardware.
The PIN_SELECT and UART1 way is the correct configuration for your chip.

Unplug the MAX3085, and check the RX pin is high to the PIC. I must
admit I suspect you have something like a whisker preventing the line
going low.

[Backfire]

Hi Ttelmah,
thanks again for all your input thus far. Do you mean disconnecting the RS485 driving module? Sadly the MAX3085 in question is a SMD, so simply unplugging it is not an option. I have probed the voltage at the PIC pin 18 (UART1 default Rx) and seen ~0.15-0.2V.

Just for completeness, here's all the RS485-related code, as I'm running it at this moment;

In main.h I have the following configuration;

[temtronic]

curious...
is it just me or is there a lot of 'noise' on those lines in the 'scope' screen ?

also
i see bits=9, so how do you read the 9th incoming bit ?

[Backfire]

Hi temtronic,
my 'scope is truly a bottom of the line unit, to give some context, heres my scope as pulling from its own calibration output;



I work with what I have, ever-deaming of being able to afford an upgrade!

Both the PIC and the MAX3085 have local high-frequency decoupling (0.1uF) and small tank capacitors (10uF) though.

The example code in the CCS supplied rs485.c example file has 'bits=9', its reading through that file I was using as my starting point.

[gaugeguy]

Your code appears to be trying to echo a received byte, but you are probably not receiving properly formatted data, so nothing will be sent out.
Try just sending a known character at a periodic rate.

[Ttelmah]

There is another problem. You are specifying long_data, so you don't
receive an int8, you receive an int16....