2
\$\begingroup\$

I'm working on a code (written by other people) that uses a custom protocol to transmit data over RS485 in 8-bit packets.

For some reason, the protocol is built so that every 8 bits transmitted are actually 7 bits of data. This is because the MSB is always set high.

For instance, if I want to send 0x01, I need to send 0x81, and so on.

I don't really know why. The protocol uses a standard 16-bit CRC calculated over the whole series of packets.

Any idea?

\$\endgroup\$
8
  • 2
    \$\begingroup\$ It might help to know which protocol, but there are multiple reasons we could guess why it is so. Is the 7-bit data just ASCII text or generic 7-bit binary data? \$\endgroup\$
    – Justme
    Commented Apr 17, 2023 at 10:58
  • \$\begingroup\$ yup. Reasons could be many, from "that's been important for a completely different system, but is also present in this due to historical reasons", "the customer insisted we do it that way without giving a reason" (surprisingly common), "clock recovery", "start bit for a UART receiver", "existing microcontroller code expects 7 bits, the hardware expects 8, and we had to set the 8. bit to something", "can't remember, seemed like a good idea at the time"… \$\endgroup\$ Commented Apr 17, 2023 at 11:01
  • 5
    \$\begingroup\$ Compatibility with a legacy 7-bit protocol seems likely. If the MSB is transmitted last as is normally done with UARTs, it simply becomes an extra "stop" bit. \$\endgroup\$
    – Dave Tweed
    Commented Apr 17, 2023 at 11:10
  • \$\begingroup\$ Sometimes you see things like the "extra stop bit" suggested by Dave Tweed and also a seemingly-nonsensical CRC which includes the extra bits. Sometimes these two decisions are made at different times by different people for different reasons. Perhaps "old hardware compatibility" added the stop bit, and later someone added the CRC? \$\endgroup\$
    – jonathanjo
    Commented Apr 17, 2023 at 11:23
  • \$\begingroup\$ @Justme it's generic bit binary. It is used to trasmit values that are basically numbers \$\endgroup\$
    – NicoCaldo
    Commented Apr 17, 2023 at 11:26

2 Answers 2

0
\$\begingroup\$

I'm going to compile this answer from the comments made on your question.

(1) The fixed MSB could have been required by a different system and is present in yours due to legacy reasons.

(2) The customer insisted for no good reason (Seems to happen quiete often)

(3) MSB could be used for "Auto-Bauding"/"CLock-Recovery" on a byte basis

(4) A legacy FW could expect 7Bit Data (Common on older systems).

(5) Compatibility with legacy 7-Bit protocol

(6) Could be used as an "extra stop bit" in case MSB is send last

(7) Protocol could have been designed around a 7Bit UART hardware on older MCUs

(8) Could have been used to denote the end of a multi-byte number

Also, i want to include the following option.

(9) The FW on the controller could use a GPIO interrupt and a timer interrupt to implement a UART module in software. The 0x80 startbit could be used to determine timing on a byte basis and also provide a clean "rising edge" to trigger off in this case as a 1-0-1 Series would be present in all bytes. This requires the data MSB to be send as first bit after the startbit, which is uncommon at least.

\$\endgroup\$
5
  • \$\begingroup\$ All timing purposes you proposed are already fulfilled by the start and stop bits. \$\endgroup\$ Commented Apr 17, 2023 at 14:28
  • \$\begingroup\$ Wouldn't it be beneficial to always set the first bit in transmitted after the start bit to '1' as this would generate a fixed 1-0-1 series to determine the timing from? With the first bit beeing 'x' the is only a 1-0-X series. Assuming this, the first bit transmitted would be the data MSB which is rather uncommon though. \$\endgroup\$ Commented Apr 17, 2023 at 14:33
  • \$\begingroup\$ if you wanted to support baud rate auto-detection... but given that this is your own custom protocol now because of the extra bit, you don't need to auto-detect anything, you can just say what the baud rate is! and UART LSB is first \$\endgroup\$ Commented Apr 17, 2023 at 14:34
  • \$\begingroup\$ If your protocol does not include a range of possible baudrates to be detected on the fly, this is true. \$\endgroup\$ Commented Apr 17, 2023 at 14:35
  • 1
    \$\begingroup\$ If you want to auto-baud on the start bit, you need to set the LSB to "1", not the MSB. Most people hit the "Enter" key (0x0D) a few times, which serves this purpose just fine. \$\endgroup\$
    – Dave Tweed
    Commented Apr 17, 2023 at 23:33
0
\$\begingroup\$

It could be that the most significant bit as a special function, and while you only see bytes with that bit set, there could be cases where it is not set (or there used to be cases when it wasn't, and those no longer exist).

While not as extensive, this is for instance the case in I2C frames where the address byte as a bit which defines whether one is actually reading or writing.

Or it could be to make the difference between "old" and "new" protocols for instance. Or between "status" and "command" messages. Seems to be overkill if there's any sort of framing as a single bit for the whole message should be enough, but there may be historic reasons for this.

In some cases, it could mean that "there's more data" (all bytes would have that bit set but the last one).

In other protocols, that could be done to ensure that there are a few "1" bits even if you send lots of zeroes. Shouldn't be needed here because there's there are already start and stop bits, but it could be the result of re-using the same protocol as it was on a different underlying medium.

There are lots of possible reasons, but without more context it's difficult to guess what they could be.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.