On Wed, 6 Nov 2013 00:23:42 -0800 (PST), pozzugno@gmail.com wrote:

>Il giorno mercoled� 6 novembre 2013 07:30:03 UTC+1, 
>robert...@yahoo.com ha scritto:
>> 
>> HDLC is both a transmission scheme (now pretty obsolete), and a
>> framing format, along with a bunch of standard link control commands.
>> In the latter sense HDLC lives in everything from PPP to LLC to the
>> control channels on SONET.
>
>What do you mean with "transmission scheme" and "framing format"?
>
>I think framing format is the mechanism to transport N octets in a frame,
>so with flags to signal the start/end of the frame and byte stuffing to
>avoid the flag inside the frame.
>The framing format of HDLC standard is similar to SLIP too.
>
>With "transmission scheme" I think you refer to the mechanism of 
>estalishing a connection (through U-frames) between the master and 
>a slave, giving reliability through flow-control (retransmissions 
>in case of errors, managing correctly frame duplication, and so on).
>The end-point (master or slave) sees the connection as a pipe: push
>bytes in the pipe to transmit and pop bytes from the pipe to receive.
>
>You say this "transmission scheme" is "pretty obsolete"... why?
>I think it's similar to TCP (flow-control by a window mechanism).
>What do you suggest as a "modern" alternative for "embedded networs"?
>
>
>> And HDLC over byte-oriented async connections is quite common (if less
>> so now that you see much less PPP over dial up).  If you're using a
>> PPPoE connection to your ISP, you're using HDLC framing, although over
>> an Ethernet style link.
>
>Anyway those examples are for point-to-point connection and not master-
>slaves networks.  I couldn't find any protocol that uses HDLC Normal 
>Response Mode in master/slave half-duplex networks.


HDLC defines a bit-synchronous (physical) transmission scheme using
NRZI coding and bit stuffing, intended for use on serial connections.
That's pretty obsolete (although it does pop up here and there).  On
top of that there's the frame format, with the frame delimiter, flag,
address, control, information and check fields, and how those are
used.  *That* part has been put on top of a bunch of
non-bit-synchronous/serial communications layers (like PPP, PPPoE,
SONET, 802.1 LLC...) and is commonly used.

Il giorno mercoled� 6 novembre 2013 07:30:03 UTC+1, 
robert...@yahoo.com ha scritto:
> 
> HDLC is both a transmission scheme (now pretty obsolete), and a
> framing format, along with a bunch of standard link control commands.
> In the latter sense HDLC lives in everything from PPP to LLC to the
> control channels on SONET.

What do you mean with "transmission scheme" and "framing format"?

I think framing format is the mechanism to transport N octets in a frame,
so with flags to signal the start/end of the frame and byte stuffing to
avoid the flag inside the frame.
The framing format of HDLC standard is similar to SLIP too.

With "transmission scheme" I think you refer to the mechanism of 
estalishing a connection (through U-frames) between the master and 
a slave, giving reliability through flow-control (retransmissions 
in case of errors, managing correctly frame duplication, and so on).
The end-point (master or slave) sees the connection as a pipe: push
bytes in the pipe to transmit and pop bytes from the pipe to receive.

You say this "transmission scheme" is "pretty obsolete"... why?
I think it's similar to TCP (flow-control by a window mechanism).
What do you suggest as a "modern" alternative for "embedded networs"?


> And HDLC over byte-oriented async connections is quite common (if less
> so now that you see much less PPP over dial up).  If you're using a
> PPPoE connection to your ISP, you're using HDLC framing, although over
> an Ethernet style link.

Anyway those examples are for point-to-point connection and not master-
slaves networks.  I couldn't find any protocol that uses HDLC Normal 
Response Mode in master/slave half-duplex networks.

On Tue, 05 Nov 2013 16:54:18 +0200, upsidedown@downunder.com wrote:

>On Tue, 5 Nov 2013 01:45:38 -0800 (PST), pozzugno@gmail.com wrote:
>
>>I was searching for a reliable and simple protocol for a 
>>multidrop master/slave RS485 network.
>>Reliable means it should work well if some errors occur,
>>so it should provide retransmissions and detection of
>>frame duplication.
>>
>>As soon as I read about HDLC in Normal Responde Mode, I 
>>loved it immediately.  It is exactly what I wanted.
>>
>>http://en.wikipedia.org/wiki/High-Level_Data_Link_Control
>
>These days, the main problem with HDLC is that it is a bit synchronous
>protocol and it is quite hard to find USART cards it at least with
>reasonable price. 
>
>The mainstream now is with character oriented protocols using UARTs in
>one way or an other and a huge number or devices and programs
>including PC diagnostics tools.
>
>If you want hardware arbitration, take a look at CAN bus, which can
>physically implemented RS-485 chips (actively driven in the dominant
>state, passive "fail safe" termination in the recessive state).
>
>IMHO SDLC/HDLC is quite outdated :-)


HDLC is both a transmission scheme (now pretty obsolete), and a
framing format, along with a bunch of standard link control commands.
In the latter sense HDLC lives in everything from PPP to LLC to the
control channels on SONET.

And HDLC over byte-oriented async connections is quite common (if less
so now that you see much less PPP over dial up).  If you're using a
PPPoE connection to your ISP, you're using HDLC framing, although over
an Ethernet style link.

On Tue, 05 Nov 2013 16:54:18 +0200, upsidedown@downunder.com wrote:

>On Tue, 5 Nov 2013 01:45:38 -0800 (PST), pozzugno@gmail.com wrote:
>
>>I was searching for a reliable and simple protocol for a 
>>multidrop master/slave RS485 network.
>>Reliable means it should work well if some errors occur,
>>so it should provide retransmissions and detection of
>>frame duplication.
>>
>>As soon as I read about HDLC in Normal Responde Mode, I 
>>loved it immediately.  It is exactly what I wanted.
>>
>>http://en.wikipedia.org/wiki/High-Level_Data_Link_Control
>
>These days, the main problem with HDLC is that it is a bit synchronous
>protocol and it is quite hard to find USART cards it at least with
>reasonable price. 
>
>The mainstream now is with character oriented protocols using UARTs in
>one way or an other and a huge number or devices and programs
>including PC diagnostics tools.
>
>If you want hardware arbitration, take a look at CAN bus, which can
>physically implemented RS-485 chips (actively driven in the dominant
>state, passive "fail safe" termination in the recessive state).
>
>IMHO SDLC/HDLC is quite outdated :-)
> 

Il giorno marted� 5 novembre 2013 15:54:18 UTC+1, upsid...@downunder.com ha scritto:
> 
> >I was searching for a reliable and simple protocol for a 
> >multidrop master/slave RS485 network.
> >Reliable means it should work well if some errors occur,
> >so it should provide retransmissions and detection of
> >frame duplication.
> > 
> >As soon as I read about HDLC in Normal Responde Mode, I 
> >loved it immediately.  It is exactly what I wanted.
> > 
> >http://en.wikipedia.org/wiki/High-Level_Data_Link_Control
> 
> These days, the main problem with HDLC is that it is a bit synchronous
> protocol and it is quite hard to find USART cards it at least with
> reasonable price. 
>
> The mainstream now is with character oriented protocols using UARTs in
> one way or an other and a huge number or devices and programs
> including PC diagnostics tools.

No, HDLC can be used through octet-based asynchronous links.
Of course, byte stuffing is used instead of bit stuffing, but it's a
standard feature.


> If you want hardware arbitration, take a look at CAN bus, which can
> physically implemented RS-485 chips (actively driven in the dominant
> state, passive "fail safe" termination in the recessive state).

IMHO, CAN isn't the final answer. It's a technology for exchange small
frames, but doesn't create a connection-oriented stream of byte
channel. For this you have to look at some higher level protocols,
like CANOpen.


> IMHO SDLC/HDLC is quite outdated :-)

Ok, they could be outdated, but I think they are better than simpler
request/response protocols that I usually implemented in the past in
simple RS485 networks.

On Tue, 5 Nov 2013 01:45:38 -0800 (PST), pozzugno@gmail.com wrote:

>I was searching for a reliable and simple protocol for a 
>multidrop master/slave RS485 network.
>Reliable means it should work well if some errors occur,
>so it should provide retransmissions and detection of
>frame duplication.
>
>As soon as I read about HDLC in Normal Responde Mode, I 
>loved it immediately.  It is exactly what I wanted.
>
>http://en.wikipedia.org/wiki/High-Level_Data_Link_Control

These days, the main problem with HDLC is that it is a bit synchronous
protocol and it is quite hard to find USART cards it at least with
reasonable price. 

The mainstream now is with character oriented protocols using UARTs in
one way or an other and a huge number or devices and programs
including PC diagnostics tools.

If you want hardware arbitration, take a look at CAN bus, which can
physically implemented RS-485 chips (actively driven in the dominant
state, passive "fail safe" termination in the recessive state).

IMHO SDLC/HDLC is quite outdated :-)
 

On Tuesday, November 5, 2013 4:45:38 AM UTC-5, pozz...@gmail.com wrote:
> I was searching for a reliable and simple protocol for a 
> multidrop master/slave RS485 network.
> ...
> Does someone suggest other good protocols with similar
> features?

See:
http://www.bitbus.org

Two decades ago we licensed a commercial implementation for
a few small micros, contact me if you need further info
for a commercial option...

Hope that helps,
Best Regards, Dave

I was searching for a reliable and simple protocol for a 
multidrop master/slave RS485 network.
Reliable means it should work well if some errors occur,
so it should provide retransmissions and detection of
frame duplication.

As soon as I read about HDLC in Normal Responde Mode, I 
loved it immediately.  It is exactly what I wanted.

http://en.wikipedia.org/wiki/High-Level_Data_Link_Control

IMHO this protocol has many good points:
- one node on the network (master) starts transmission
  and could give token to another node (slave);
- as soon as the slave finishes transmissione the token
  is passed back to the master;
- frame are marked with sequence numbers so the receiver
  could detect duplicated frames and transmitter could
  detect which frames weren't received by the receiver;
- flow control data can be inserted in data frames (I-frame)
  or separated in other frames (S-frame);
- the protocol implementation could be flexible: the
  transmitter can sends only one frame or many frames at 
  the same time and the receiver is free to ack only the 
  last frame received (if the previous ones were received
  correct);
- it should be simple to implement in microcontrollers
  with poor resources.

I tried to find some HDLC NRM implementations, but I didn't
find any.  I also tried to write my implementation, but
it isn't so simple for me.


Does someone want to share his HDLC NRM implementation or
point me to an implementation I didn't found?

Does someone suggest other good protocols with similar
features?