1. Home
  2. Embedded Programming
  3. HDLC Normal Responde Mode implementation

HDLC Normal Responde Mode implementation

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.

formatting link

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?

Reply to
pozzugno
Loading thread data ...

See:

formatting link

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

Reply to
Dave Nadler

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 :-)

Reply to
upsidedown

Il giorno martedì 5 novembre 2013 15:54:18 UTC+1, snipped-for-privacy@downunder.com ha scritto:

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.

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.

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.

Reply to
pozzugno

Reply to
Robert Wessel

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.

Reply to
Robert Wessel

Il giorno mercoledì 6 novembre 2013 07:30:03 UTC+1, snipped-for-privacy@yahoo.com ha scritto:

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"?

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.

Reply to
pozzugno

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.

Reply to
Robert Wessel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.