RS-485 or shared serial lines

Questions on UARTs, and serial communication
Post Reply
basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

RS-485 or shared serial lines

Post by basicchip »

>from the help line
>I've seen almost nothing on the forum about RS485.
>It would be much to my advantage on an upcoming project if I could do a multi-drop RS485 network.
>It must be fully interrupt-driven, with any higher-level protocol being managed transparently, so that all I must do is examine i/o buffers from time-to-time to discern the states of the various processors on the net.
>I will have five SuperPros in a 'symbiotic' array, where each one's activities are dependent upon the states of the other four.
>I already did this with RS232 in another machine, but it requires a 'central communications processor' to handle all the dispatches. It would be 'handier' to have all the boards chatting freely among themselves, to be moving only binary status words, instead of text messages or blocks of encoded data, and having each processor containing a local table of all the other processors' states, at any given time.
>I did a lot of syncronous communications coding in decades past... but it has been decades, so any code samples of NXP17xx RS485 multi-drop would be helpful.

What it sounds like you want is a multidrop masterless network. While this can be done, it is probably not worth the time to debug. You would have to handle collision detect and backoff if you go multi-master, or come up with some token passing scheme, and then handle error conditions. Now I'm not saying it is impossible, as UART1 supports RS-485 with a transmit enable pin, which you could use by setting the appropriate control bits AFTER you set the BAUD in BASIC, as after that the firmware only accesses status, interrupt and data registers.

I recently had to do a data gathering with 4 CPUs (in this case LPC1549s) talking serially to a PC (via USB). As this was a one of a kind design, I opted for simplicity. All CPUs listen to the RXD line from the PC, but only one transmits on the TXD line at a time (they tri-state the pin when they are not selected). I used a special character to turn on one of the 4 listeners, and each could ignore the character when buried in a message if that was needed. Yes, quick and dirty and KISS. In my case the connections were short so error recovery not a big deal. So unless you want to spend a lot of time debugging, I'd suggest a master-slave arrangement with a SuperPRO managing the communication. If the cable are long RS-485 is a good way to go to nearly eliminate noise and errors, and go full-duplex (separate RX and TX pairs), and have everyone listen to the master, but only enable transmit when selected by the master.



basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: RS-485 or shared serial lines

Post by basicchip »

Other options, would be use an existing multi-drop protocol. Ethernet would be overkill, but CANbus might fit the bill. Both you get hardware support from the LPC175x, only requiring external transceivers.

We haven't gotten to it yet, but one of the custom designs we have been working on has had CAN on the wish list for a while, but so far it is still on the list, but we have implemented MODBUS over both RS-232 and isolated RS-485 and Ethernet.

AMDlloydsp
Posts: 99
Joined: Mon Apr 15, 2013 3:51 pm
Location: NE Central FL

Re: RS-485 or shared serial lines

Post by AMDlloydsp »

That's essentially how I did it last time, except the "PC" was another SuperPro, driving a serial touchscreen LED as a diskey, and communicating to the others via RS232.

Because there aren't enough UARTs to actually _do_ that with four other boards (<G> NXP's problem, not yours), I set up two of the other ones in the 'network' as receive-and-forward machines, all interrupt-driven. Any message not destined for them got forwarded in/out two UART ports to/from another board. I used the same scheme of using a 'board ID' in the message block to trigger a response. Latency, even at a bogglingly-slow 9600baud was not a problem (because the data blocks were tiny), and at that speed, noise-induced transmission errors over 20' or so are almost non-existent (checksumming is enough; no complex CRC algorithm). Of course, I buffered and terminated everything per RS232 (full-swing, no +-5V stuff).

So, the central control SuperPro had three UARTs active (plus the USB port). One to talk to the LED, and two to send messages in/out to the other four boards.
Each of the two at the head of the line from the control received and forwarded any message blocks (both ways) that were not intended for them. If I'd had only three remote boards to communicate with, I'd have considered using UART1, and abandoning the USB port except for debugging and software loading.

It worked fine, and it WAS simple to do; truly KISS. I know, though, that I will some day need a multi-master, 'negotiating' bus, and I'm not equipped with the knowledge to put together a whole protocol stack for Ethernet. So I guess RS232 is it, until the CAN bus primitives are in the ROM, or there's a library to drive it.

Thanks, Bruce. At least you confirmed my prior experience. And it works... that's a plus!

Lloyd

basicchip
Posts: 1090
Joined: Fri Oct 19, 2012 2:39 am
Location: Weeki Watchee, FL
Contact:

Re: RS-485 or shared serial lines

Post by basicchip »

I guess you are listening to possible traffic from any of the 4 or more SuperPROs simultaneously.

I can't speak for your application, but would a polled version work? The master sends out "give me your data # 1" type messages, which could be ignored by the slave if it busy or it could send data if ready. And messages could be formatted as "#1 sends back blah"

Obviously the messages would be shorter. For instance I used w,x,y, and z characters as "give me your data #x"

That way you would only need 1 UART, with tri-stated shared line for slave back to master.

AMDlloydsp
Posts: 99
Joined: Mon Apr 15, 2013 3:51 pm
Location: NE Central FL

Re: RS-485 or shared serial lines

Post by AMDlloydsp »

Yes, I could have used a passive one way, active the other transmit line on each of the four slaves, and that would have been enough... wouldn't have even needed to tri-state the thing. (although, if one started to chatter, it breaks that design). In most stuff I build, that probably would be plenty. But except for the extra MAX3232 boards, it was just software... <G>

Lloyd

Post Reply