DEV Community

Cover image for Letters from the "hell of configuration" - Part 1
Eckehard
Eckehard

Posted on

Letters from the "hell of configuration" - Part 1

I found myself several times getting lost in the "hell of configuration". Although there must be thousands inhabiting this hell, I always found myself alone with a problem, that was not my fault, and that I didn't even want to solve. But every time, it took me hours or days to get things running, that should be fairly simple.

What is the "hell of configuration"? Let me give an example...

In the old days, RS232 was one of the most used protocols for device communication. RS stands for Recommended Standard and was defined in the early 60´s by the US Electronic Industries Association (EIA). We should think from a standard, that this gives a clear definition of how to use it´s target, but if you ever tried to use RS232, you might know, this was not the case. The standard opened a new "hell of configuration" (and confusion). It is interesting to analyze the reasons. So, what´s up with RS232?

RS232 defines a serial communication protocol and wiring, and serial communication is still wideley used today. Even USB-connectors uses serial communication, most microcontrollers use serial communication as a "native language". This is how a serial communication works:

Serial wiring

Serial wiring is fairly simple. You need just three electric lines:

  • RX: receive
  • TX: talk (send)
  • Ground

If you just want to talk or to listen, you do not even need the second data line. So, pretty simple. Communication has a similar straightforwad approach. This is a timing diagram:

Timing

Communication is based on an 8-bit serial protocoll. We need to detect the start of a byte. In Idle state, the talker holds the line high, so the listener knows it is connected. The communication starts, if the line goes low. But RS232 is based on a predefined timing, and this is the point where you go down to hell: Unless you do not know the baud rate, you will not be able to establish any communication. The "baud rate" tells, how long a "bit" is. If you do not know the timing, you will not be able to derive this from the signal. You just need to know. And there are much more options that do not work...

Going down to hell

The standard Initially defined 7 possible rates

  • 2400 baud
  • 4800 baud
  • 9600 baud (most common)
  • 19200 baud
  • 57600 baud
  • 115200 baud

but there is no general limit to the timing. The Arduino-terminal defines 13 different speeds from 300 baud to 1M baud, Cool-Term knows 16 different values. If nobody tells you, you have 15 options to make it wrong!

And Baud rate is not the only possible pitfall. The protocol can have multiple variations:

  • the data word can have 5 - 9 bits
  • there can be parity bits that work like a checksum. But this comes in three flavours: odd, even or none
  • you can have a stop bit also in different length: 1, 1.5 or 2 bit
  • There can be additional data lines to indicate the status of a device. This is a typical - but not the only possible option:

Wiring RS232

As a rough estimation, there are 16 x 4 x 3 x 3 = 576 variants on the software side, with 575 options to do things wrong. Just one will give you a working communication - a needle in a haystack. Not mentioning the possible combinations on the wiring side.

Where does this "hell" come from? Possibly, there had been different companies working with serial devices these days, so the standard just describes all possible options. This is polite, but leaves the choice to the user - who does not necessarily know what the device does or needs.

We learned from this - but not all of us

Today, we still use serial communication. But people just plug in their USB and can expect, things will work. USB is made for "plug and play", which just means, the devices can care for their needs. They do not force the user to read tons of handbooks and documentation.

If you find an old serial device with RS232, you will for sure need to read the papers first (if you have them), being happy to get the communication to work in 2-3 hours. Without documentation - you possibly will not be able to run your device.

If you think, the old day´s are over - I can tell you, they are not. I find myself very often in a similar situation getting lost in the "hell of configuration", trying to get a simple things up and running. Ever tried to set up an apache server? Set up a firewall? Install typescript? Just read an outdated manual about a recent version, that is not supported anymore?

I will add some more examples on more recent tools.

So, see you next time. I love to see more examples of the "hell of configuration" in the responses.

Discussion (0)