Forums

RS485, multidrop protocol

Started by Ian McCrum MI5AFL November 14, 2004
T Marchini wrote:
> Ian McCrum MI5AFL wrote: > >>> Ian McCrum MI5AFL wrote: >> >> >>>> or trying to get TCP/IP sort of working, NFS or TFTP booting for >>>> example, I'd accept atrocious performance just for the convenience of >>>> it all. typically only a pair would be busy at once... >> >> >> >> Thanks again, Ian McCrum > > Here is a fun one, > Hack PPP and add an address field to it, along with a token passing > scheme and a master. > > Look at the older parallel port protocol for linux PLIP. > There could be some interesting reading along with methodology for > stuffing your serial protocol to work with the built in TCP/IP of linux. > T.
I brought up PLIP because it could give you a template of connecting your serial control protocol with internal TCP/IP transport. Using PPP(type) packeting allows for an easy way to create begin and end packet segments for easy packet synchronization. PPP is point to point, but if you ADD a leading address byte to the packet structure then you are all set. You obviously need to add a bunch of code here to make this work. I am just giving suggestions on where to start looking for pieces that can be used to transport data in the way you suggest. T
On Tue, 16 Nov 2004 12:48:20 +0100, the renowned "Meindert Sprang"
<mhsprang@NOcustomSPAMware.nl> wrote:

>"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message >news:cbqjp05rjfpvfe2hj369kskgp7laqjudvf@4ax.com... >> On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL >> <IJ.McCrum@ulster.ac.uk> wrote: >> >> >There may be implementations already done... was localtalk rs485? ( >> >old apple) or maybe versions of modbus, profibus or somesuch. I don't >> >know anything about modbus, profibus or localtalk, maybe someone here >> >can comment... >> >> Modbus is simple and may be appropriate. It comes in two flavors- RTU >> and ASCII. Google for more. > >Modbus-RTU is horrible, because it relies on inter-character timing for >frame delimiting.
That "feature" just requires low-level programming and may eat some system resources (a timer) if there is no buffering on the serial port. Other than that, it isn't difficult if you plan for it. Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Tauno Voipio wrote:

> The PPP framing is actually a special case of HDLC (ISO 3303)
Is that the correct ISO standard? I looked up ISO 3303 and found that it relates to "Rubber or plastic coated fabrics - determination of bursting strength". Nothing at all about HDLC protocols. Perhaps you really meant ISO/IEC 3309:193 "Information Technology - Telecommunications and information exchange between systems, High-level data link control (HDLC) procedures - Frame structures". -- ******************************************************************** Paul E. Bennett ....................<email://peb@a...> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:ij1kp0l7d9h3s6tldjt1ep7n55fc9gc7ff@4ax.com...
> That "feature" just requires low-level programming and may eat some > system resources (a timer) if there is no buffering on the serial > port. Other than that, it isn't difficult if you plan for it.
Try it on a UART with a FIFO..... Meindert
Anthony Marchini wrote:
> T Marchini wrote: > >> Ian McCrum MI5AFL wrote: > > Using PPP(type) packeting allows for an easy way to create begin and end > packet segments for easy packet synchronization. > PPP is point to point, but if you ADD a leading address byte to the > packet structure then you are all set. > You obviously need to add a bunch of code here to make this work. I am > just giving suggestions on where to start looking for pieces that can be > used to transport data in the way you suggest. >
The PPP framing is actually a special case of HDLC (ISO 3303) framing. There is an address byte: the first byte after the starting flag which is 0xff in PPP. If single byte addressing is enough for your network, just put the address in there. It may be worth while to think if the PPP link control protocols (IPCP & co) are really needed in a special network like this. The control protocol is needed if the IP addresses and other network parameters have to get distributed when the link is established. The main problem in a RS-485 network is the distributed control of the transmit enables to keep bus contention out. If the network is a logical star controlled by a single master station, the timing can be solely run by the master. -- Tauno Voipio (OH2UG) tauno voipio (at) iki fi
Spehro Pefhany wrote:
> On Tue, 16 Nov 2004 12:48:20 +0100, the renowned "Meindert Sprang" > <mhsprang@NOcustomSPAMware.nl> wrote: > > >>"Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message >>news:cbqjp05rjfpvfe2hj369kskgp7laqjudvf@4ax.com... >> >>>On Sun, 14 Nov 2004 20:46:59 +0000, the renowned Ian McCrum MI5AFL >>><IJ.McCrum@ulster.ac.uk> wrote: >>> >>> >>>>There may be implementations already done... was localtalk rs485? ( >>>>old apple) or maybe versions of modbus, profibus or somesuch. I don't >>>>know anything about modbus, profibus or localtalk, maybe someone here >>>>can comment... >>> >>>Modbus is simple and may be appropriate. It comes in two flavors- RTU >>>and ASCII. Google for more. >> >>Modbus-RTU is horrible, because it relies on inter-character timing for >>frame delimiting. > > > That "feature" just requires low-level programming and may eat some > system resources (a timer) if there is no buffering on the serial > port. Other than that, it isn't difficult if you plan for it.
The main problem is that hardware receive buffering cannot be used to prevent loss of frame timing gaps. You cannot measure the character timing from the FIFO output. Please forget Modbus/RTU - it seems to be designed for maximum difficulty to transport. The receive interrupt handler does not know the length of a frame unless is parses all of the commands and sub-options of the frame, and the parsing logic is different for a client (master) and server (slave). Modbus/TCP seems to be as broken, but in another way. Been there - done that (gotten bitten by a tunneling Modbus bridge). -- Tauno Voipio tauno voipio (at) iki fi
On 2004-11-16, Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote:

>>Modbus-RTU is horrible, because it relies on inter-character timing for >>frame delimiting. > > That "feature" just requires low-level programming and may eat some > system resources (a timer) if there is no buffering on the serial > port. Other than that, it isn't difficult if you plan for it.
"some" resources? It eats tons of resources. It makes it impossible to use the receive FIFO in a UART and thus requires an interrupt for every single byte. That makes it almost impossible to use at high baud rates. -- Grant Edwards grante Yow! BELA LUGOSI is my at co-pilot... visi.com
Paul E. Bennett wrote:
> Tauno Voipio wrote: > > >>The PPP framing is actually a special case of HDLC (ISO 3303) > > > Is that the correct ISO standard? I looked up ISO 3303 and found that it > relates to "Rubber or plastic coated fabrics - determination of bursting > strength". Nothing at all about HDLC protocols. Perhaps you really meant > ISO/IEC 3309:193 "Information Technology - Telecommunications and > information exchange between systems, High-level data link control (HDLC) > procedures - Frame structures". >
Yes - sorry for the slip. The text was at hand - and I copied wrong (blush!). -- Tauno Voipio tauno voipio (at) iki fi
Tauno Voipio wrote:

> Paul E. Bennett wrote: >> Tauno Voipio wrote: >> >> >>>The PPP framing is actually a special case of HDLC (ISO 3303) >> >> >> Is that the correct ISO standard? I looked up ISO 3303 and found that it >> relates to "Rubber or plastic coated fabrics - determination of bursting >> strength". Nothing at all about HDLC protocols. Perhaps you really meant >> ISO/IEC 3309:193 "Information Technology - Telecommunications and >> information exchange between systems, High-level data link control (HDLC) >> procedures - Frame structures". >> > > Yes - sorry for the slip. The text was at hand - and I > copied wrong (blush!).
It's OK, you are forgiven. I am sure many others would have identified the correct standard easily enough by googling for it. Generally you are below the 3% error rate for keyboard entry so no need to blush too redly. -- ******************************************************************** Paul E. Bennett ....................<email://peb@a...> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
On Tue, 16 Nov 2004 06:50:59 -0500, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

>Modbus is simple and may be appropriate. It comes in two flavors- RTU >and ASCII. Google for more.
Modbus master and Modbus point to point slave is trivial to implement, since you can rely on the message contents. However, implementing a Modbus multidrop slave is tricky, since you must adhere to the strict timing. The simplest environment to implement nearly perfect timing would be to use the QUICC co-processor found on the MC68360/MPC860/MPC2860 etc., but even in this case, the Tx message preamble would have to be set to 2 character times (instead of nominal 1.5 character times), the Tx trailer to 1 character time (nominal 1.5 character times) and the Rx end of frame interrupt at 3 character times (nominal 3.5 character times). Running Modbus multidrop slave at 115k2 or above with a general purpose hardware, you really need a timing accuracy and interrupt latency of 50 us or less, which the standard Linux kernel is definitely not going to offer. Paul