Serial and RS485 questions

[MrGlasspoole]

I ordered my first Teensy (3.2) and have some questions.

I found out what FIFO is (a build in buffer) but what does "High Res Baud" and "Fast Clock" mean?

Then what does "support for RS485 transmitter enable" exactly mean?
Normally i have 2 "MAX 488 CPA" - one on each side.
Does that mean i only need one on the non Teensy side?
But how do i connect A, B, Y, Z and do i need still need the 120ohm resistor between A&B and Y&Z?

 

[PaulStoffregen]

I found out what FIFO is (a build in buffer) but what does "High Res Baud" and "Fast Clock" mean?

Those are kinda like saying a car has turbo charging or more valves. Ultimately, they're features under the hood that improve performance, but you generally don't think about them while actually driving.

In a nutshell, these mean it can do higher speed baud rates more accurately than other serial ports without those special features. It's all handled automatically when you use Serial1.begin(baud), so you don't need to worry about those features. Well, not unless you want to write your own serial driver code. Teensyduino has very good serial code, so you almost certainly should just use it.

Then what does "support for RS485 transmitter enable" exactly mean?

Now there's a feature you do need to know about. Well, if you use half duplex with more than 2 devices transmitting at various times. (but see below, looks like this doesn't apply to you)

As documented on the serial page, you can use Serial1.transmitterEnable(pin) to have Serial1 automatically generate the control signal for your RS485 chip. Usually those chips have RE and DE pins which are normally connected together, so they receive or transmit (but never both at the same time), and you connect it to a pin on Teensy.

If you try using other non-Teensy boards, controlling the DE/RE pins is a challenge. The good news is this is built in, so all you have to do is call that function after Serial1.begin(baud) and it will automatically turn on the transmitter at the right times.

Normally i have 2 "MAX 488 CPA" - one on each side.
Does that mean i only need one on the non Teensy side?
But how do i connect A, B, Y, Z and do i need still need the 120ohm resistor between A&B and Y&Z?

You almost certainly need those chips on both sides.

That particular chip does not have the DE and RE pins. It looks like it's meant to only communicate with 1 other chip, using 4 wires in full duplex mode. Full duplex is very simple, but requires 4 wires instead of 2 and only allows 2 devices rather than many on the same line. Just connect Teensy's TX1 pin to the DI input on the MAX488, and Teensy RX1 pin to the RO output. Easy.

 

[MrGlasspoole]

Thanks for the explanation Paul.
I guess i will have a lot of questions if the Teensy is here and wired cause I'm not a coding god :-(

So the connection is the same as on my Arduinos with the RS485 ICs.
But you are wrong, aren't you? You can have many devices in full duplex but only the Master can talk to the Slaves and the Slaves to the Master. Slave to Slave is not possible with full duplex.

 

[PaulStoffregen]

But you are wrong, aren't you? You can have many devices in full duplex but only the Master can talk to the Slaves and the Slaves to the Master. Slave to Slave is not possible with full duplex.

Not with MAX488. It lacks the control pin to disable its transmitter. If even a single slave device uses the MAX488, it will always transmit, which prevents any other slave devices from transmitting.

 

[MrGlasspoole]

Ok, learned something new. I have just tested this with the MAX488 between two Arduinos. So for connecting more then 2 devices i need another MAX.
But what happens if two ore more devices turn on the transmitter at the same time?

 

[Epyon]

In RS485/488 topology, you can only have one master. He initiates communication to the slaves, and then only the slave that was spoken to by the master can transmit. Slaves can never initiate communication themselves.

 

[MrGlasspoole]

So this side is completely wrong?
https://orxor.wordpress.com/2013/03/18/mit-dem-arduino-den-rs485-bus-nutzen/

Sorry it's German but written there is:
1. In half duplex all participants can communicate with each other.
2. In full duplex slaves can't talk to each other. The master kann send to the slaves and the slaves can send to the master.

He initiates communication to the slaves, and then only the slave that was spoken to by the master can transmit. Slaves can never initiate communication themselves.

How would the master know there is data from a slave he should receive if he is the one who needs to initiate the communication?

 

[Epyon]

So this side is completely wrong?
https://orxor.wordpress.com/2013/03/18/mit-dem-arduino-den-rs485-bus-nutzen/

Sorry it's German but written there is:
1. In half duplex all participants can communicate with each other.
2. In full duplex slaves can't talk to each other. The master kann send to the slaves and the slaves can send to the master.

Kein Problem. In Belgien, wir sprechen Niederländisch, Französisch, Englisch und Deutsch .

What they mean is this: in half-duplex slaves can also act as master (although is unusually). All participants put their transceiver in listening mode (DE deasserted) when idle. The participant who initiates the communication (by asserting DE and transmitting something) acts as the (temporary) master. The addressed slave then responds and the bus returns to the idle state. The next participant to initiate communication is the new (temporary) master.

How would the master know there is data from a slave he should receive if he is the one who needs to initiate the communication?

You as the application developer need to implement this logic. The convention is as follows:
- master initiates communication by sending a request to a slave and then returns to listening mode
- the next message on the bus is considered the reply of the slave
- if no reply is received within a certain time-out window, all participants considers the request to be lost (or the slave non-responsive)
- if required, another participant can now act as master

The reason why multiple masters on the same bus are discouraged is to avoid bus collisions. Take for instance two participants who want to initiate communication at the same time: this will lead to a disruption of communication. There are ways to avoid is, e.g. a random time to re-initiate transmission when a collision is detected. But having only one participant acting as the master, who polls slaves at regular intervals, is a less complex way. This is for example how the Modbus protocol over RS-485 works.

 

[PaulStoffregen]

You must avoid any 2 devices transmitting on the same wires simultaneously.

Three common ways exist to solve this problem. In order of how commonly they are used:

#1: 2-wire half duplex, master/slave protocol
#2: 4-wire full duplex, point-to-point communication (limited to only 2 devices)
#3: 4-wire full duplex, master/slave protocol

Those MAX488 chips are meant only for #2. Because the MAX488 can not disable its transmitter, it must not be used in #1 or #3.

Master/slave protocols work only because all the slave devices have unique assigned addresses, where only 1 slave device replies to the queries which clearly specify which device (if any) is to reply. The slave devices never transmit on their own initiative. They only reply to queries from the master. The master must also be carefully designed to send only 1 query at a time and allow enough time for the slave device to respond.

In theory #3 can offer slightly higher performance, because the master is able to begin sending the next query before a slave device completes transmitting. However, that is very risky design, because the slave device may continue transmitting longer than expected. #3 also allows no-reply messages to be transmitted by the master during the time a slave replied. In practice, #3 is rarely used, because the speed benefit is minimal and the extra work and risk of mistakes to connect twice as many wires usually is not worth the minimal improvement. Most system use #1 for more than 2 devices.

While these are the most commonly used, other approaches do exist. They are horrible and should be avoided. I personally wrote code for one of these systems (not my design... I was paid to make a device that worked on an already establish system). The usual alternative is a token passing protocol, rather than simple master/slave protocol. I'm not going to explain how these would work, other than to say they usually don't work well in practice. Almost everybody uses master/slave protocols.

 

[awardblvr]

So... What is a successfully implemented board with minimal requirements for 4 Teensys that must communicate status back and forth within a max of feet of each other? I would love to operate with only 3.3V, if possible. Not particularly high speed.

In my case each "station" should be able to send a small packet to each of the OTHER two devices. (If I have to send one packet to each (one at a time), that's OK, but a "broadcast" packet would be nice also, though confirming reception would probably be a pain.)

I wonder what library would be best for this. Any suggestions appreciated.

 

[Epyon]

If you're saying that each station should send to the two other devices, the fourth device acts as a master? In that case you're probably best of with half-duplex RS-485 and have the master poll each slave and then forward the data to the other slaves. If not you could use full duplex RS-485 with some fairly simple collision prevention (e.g. don't send when the transmit line is busy), but you will have to implement a proper communication stack.

I'd go for the first option. You need another device, but the wiring and setup is less complex. Full duplex multi-client communication is not that simple.

 

[awardblvr]

Thanks... but I really don't want to have a dedicated master. I was hoping to utilize on some of Nick Gammon's work with RS485, or possibly HardwareSerialRS485. But, Nick Gammon's work seems to use Software serial, which is totally unnecessary with Teensy's 3 hw serial's. The question is whether anyone one has implemented either of these two methods on Teensy. The HW Serial looks like a MESS.. Looks like I would be spending all my time porting and debugging that instead of getting to the application I need to develop. UGGG.

I also wonder if anyone has determined which board can be used. I see a bunch of 5V RS485 boards for a a few bucks on ebay. I wonder how well they will interface with Teensy.

 

[Epyon]

I think you first need to read up about interfaces and protocols. The two links you provide are about the RS-485 interface. With this interface you can easily connect several devices to each other. However, that doesn't mean they will be able to talk to each other. To do that, you need a protocol. And the RS-485 interface always requires a protocol where you need a dedicated master, unless you a) only have two devices or b) you make up your own protocol.

Besides, the first link you give clearly talks about the need for a master device.

 

[awardblvr]

Read the third part of Gammon's post... He floats the mastership around on a round-robin basis after initial discovery.

Protocol wise, I will be sending some simple command / status messages between the three "stations". The receiver will know by it's ID whether to do something, or just ignore it based on the message contents. So if I can just get the Physical layer and the transport layer accomplished, the message generation and parsing part will be the satisfying part. Message structure will be the same, regardless of destination. Each will have a source ID, so, if needed an ack can be sent back.

Pretty simple stuff (two touch LCD screens for Projector control from either side of a room) and some lighting control. Each LCD screen will be updated if the other touched. One station @ the projector also has an interface to lighting. One LCD station also has a serial interface to and HDMI switch.)

Thanks

Any advice appreciated.

 

[Epyon]

That's some sort of ring token implementation then. That could work with full-duplex or even half-duplex RS-485, but I don't know of any implementation of this. It's less complex and more reliable to use a master/slave arrangement. Even in your case: the lighting control can act as the master and poll/update each LCD continuously, so all devices know each other status.

 

[PaulStoffregen]

Any advice appreciated.

Almost everyone uses master-slave protocols for more than 2 devices on RS485. Other ways are possible, like token passing, but they involve a lot of complexity.

 

[awardblvr]

OK OK... I get it... I appreciate the clarity. I'll just poll each salve and re-send the message to the other slave.

THANKS.

Now what are some modules that have worked with Teensy 3.x for this purpose?
And does anyone have a recommendation for the easiest library compatible with Teensy that can accomplish this?

 

[defragster]

Question: Aren't the receive lines common? Once the master addresses a slave - won't the subsequent transmit be apparent to everyone on line at the same baud rate?

<edit>: suppose I missed it by half... The slaves all transmit to the master receive and the master does the reverse.

 

[BradleyC]

As documented on the serial page, you can use Serial1.transmitterEnable(pin) to have Serial1 automatically generate the control signal for your RS485 chip.

I will soon be posting a support question with code and data regarding my application of teensy 3.2 in a 9-node RS485 half-duplex application. But I have been reading all of the forum postings returned from a search of "Serial1 RS485" and ran across this mention of the transmitterEnable() method. One early article mentioned it as undocumented, but here we see a reference to documentation 'on the serial page'. (I searched for this "serial page" and never found the reference so I'm posting this quick question.)

QUESTION: Where is the serial page?

I was planning on using digital IO pin 9 to reverse the transceiver direction using software, but it sounds like there is a possibility that I can use this built-in pin (if it's not already used in my application). So I want to know more about this software AND hardware (I.e. which pin(s) work with the Serial1.transmitterEnable() method?)

One other quick question: Because of the existing system into which I'm deploying the teensy based upgrade, MAX483 transceivers are used. Do you see any problem with using the same chip with my Teensy 3.2 RS485 connected devices? (I'm not a HW guy -- so the electrical details are not second nature to me)

 

[BradleyC]

I will soon be posting a support question with code and data regarding my application of teensy 3.2 in a 9-node RS485 half-duplex application. But I have been reading all of the forum postings returned from a search of "Serial1 RS485" and ran across this mention of the transmitterEnable() method. One early article mentioned it as undocumented, but here we see a reference to documentation 'on the serial page'. (I searched for this "serial page" and never found the reference so I'm posting this quick question.)

QUESTION: Where is the serial page?

I was planning on using digital IO pin 9 to reverse the transceiver direction using software, but it sounds like there is a possibility that I can use this built-in pin (if it's not already used in my application). So I want to know more about this software AND hardware (I.e. which pin(s) work with the Serial1.transmitterEnable() method?)

One other quick question: Because of the existing system into which I'm deploying the teensy based upgrade, MAX483 transceivers are used. Do you see any problem with using the same chip with my Teensy 3.2 RS485 connected devices? (I'm not a HW guy -- so the electrical details are not second nature to me)

I found my own answer to the QUESTION: It's here: https://www.pjrc.com/teensy/td_uart.html - and the way it is documented, ANY digital pin can be used by this function. If not any pin, then please let me know.


I'm still curious about the use of MAX483.

 

[PaulStoffregen]

QUESTION: Where is the serial page?

This page:

https://www.pjrc.com/teensy/td_uart.html

So I want to know more about this software AND hardware (I.e. which pin(s) work with the Serial1.transmitterEnable() method?)

Any digital pin can be used. It's implemented by software in the interrupt routines, so you're not limited to a specific pin.

Same with RTS, any digital pin. But CTS is hardware, so only on certain pins.

MAX483 transceivers are used. Do you see any problem with using the same chip with my Teensy 3.2 RS485 connected devices?

I have personally used MAX483. Works great and has the very nice (for normal baud rates) slew rate limiting. The slew rate limiting reduces high frequency noise and lessens the need for good impedance termination on long lines. But if you're doing high speed baud rates or transmitting addressable LED data, you'd need the faster chips.