13
\$\begingroup\$

I am using an SPI peripheral in my application. The peripheral returns packets containing 15 data bits, plus an Even Parity bit for error detection.

Parity on an SPI peripheral

Therefore all zeros, and all ones both pass the parity check.

This means that my microcontroller cannot detect the most common type of error: the peripheral being disconnected! In this case, the received bits are all zero, which passes the parity check.

Presuming that it would have been just as easy for the manufacturer of the peripheral to implement Odd parity, my question is: Why would they have chosen to use even parity in this case? Is there some other advantage of Even Parity in this case to make up for the fact that it's unable to catch the most common type of error?

\$\endgroup\$
10
  • 6
    \$\begingroup\$ Please note that "parity", even or odd, is dinosaur technology, it should not be used in modern, professional systems. It has a probability less than 50% of catching single bit errors, and worse still for multi-bit errors. Just forget about using parity, using it was a moronic idea even back in the 1960s. If you need to validate an SPI data line, you should supervise the data on a lower layer, by using an input capture timer or similar. Also check SPI flags for buffer overrruns etc. \$\endgroup\$
    – Lundin
    Commented Jan 10, 2018 at 12:09
  • 40
    \$\begingroup\$ @Lundin "It has a probability less than 50% of catching single bit errors, and worse still for multi-bit errors." - If a single bit is wrong, the parity will be wrong. Simple parity has a 100% chance of catching single-bit errors, not "less than 50%". (similarly, it has 0% chance of catching 2-bit errors, and 100% again at catching 3-bit errors). \$\endgroup\$
    – marcelm
    Commented Jan 10, 2018 at 13:07
  • 7
    \$\begingroup\$ @Lundin - Please address your comments to the makers of AMS, who make these chips. \$\endgroup\$ Commented Jan 10, 2018 at 14:25
  • 26
    \$\begingroup\$ @Lundin If the parity bit flips, the parity check still fails. \$\endgroup\$
    – Adam Haun
    Commented Jan 10, 2018 at 15:16
  • 5
    \$\begingroup\$ @Lundin, you are right that a parity check can only detect 50% of the possible errors in a parity-protected block. However, it's far from a 'moronic' idea and the inventor made no stupid or wrong assumptions. It does indeed have a function and a value. You appear to have strong and definite, but I would say flawed, views on the subject. May I recommend that you post a question on this that can be discussed and debated. That would seem to be constructive, while throwing around insults clearly isn't. I look forward to reading your posted question and justifications. Thanks. \$\endgroup\$
    – TonyM
    Commented Jan 11, 2018 at 18:02

5 Answers 5

0
\$\begingroup\$

You are right to question this, I have the same criticism of even parity. With an odd number of data bits before addition of the parity bit, as in your example, and as is common, even parity allows all 0s and all 1s as valid transmitted words, which is useless in detecting a dead link or dead chip. The prior answer by Tony M is wrong in this regard. See the 7bit data example table here for proof:- https://en.wikipedia.org/wiki/Parity_bit

Odd parity however would insert an opposite state bit in the all 0s or all 1s case, thus proving that the link and chip are alive, and would be a far better choice in this case.

\$\endgroup\$
16
\$\begingroup\$

A single parity bit can only check for the presense of single or odd numbers of bits in errors so expecting it to detect when a peripheral is disconnected is probably expecting too much.

However, many systems will produce a continuous series of 1's when a peripheral is not present and this can be achieved with a simple pull-up resistor on the returning data line. If there was actual 8 bit data being returned by a connected peripheral then the parity bit would be zero for decimal 255 being transmitted. So even parity can detect when a peripheral is disconnected under these circumstances.

If odd parity were used, 8 high bits (decimal 255) would result in a high parity bit so rendering odd parity useless as a means of detecting loss of peripheral chip.

Horses for courses.

\$\endgroup\$
17
  • 2
    \$\begingroup\$ Silly me, I should have mentioned that this particular application has 15 data bits, and one parity bit. Corrected now. But I still think it's reasonable to expect a parity check to detect a completely disconnected peripheral. It's quite within its capability, and is actually the most useful check you can do. \$\endgroup\$ Commented Jan 10, 2018 at 11:30
  • 1
    \$\begingroup\$ @Rocketmagnet also, the table you have added to your question appears to be for the format of data that is sent to the peripheral - note the term "Has to be 0" for the 14th bit - maybe you should link to the device data sheet? \$\endgroup\$
    – Andy aka
    Commented Jan 10, 2018 at 11:55
  • 3
    \$\begingroup\$ The modified table shows bit 14 as the error flag and my advice is to use a pull-up on the serial return data to make the data all 1's when the device is disconnected because then decoded bit 14 will indicate a problem. \$\endgroup\$
    – Andy aka
    Commented Jan 10, 2018 at 14:36
  • 1
    \$\begingroup\$ @Trevor_G oops yes. Amending in progress. \$\endgroup\$
    – Andy aka
    Commented Jan 10, 2018 at 18:08
  • 1
    \$\begingroup\$ The proper expectation is the software that uses the spi controller should validate the data that comes back, if there is a risk. If you dont have control over one or the other sides, then you definitely need to do this in the higher level software. The only time you can let that go is if you control both sides of the spi design and make it meet your bit error requirements, which it sounds in this case that you cant. So your software should be checking for all zeros and all ones, not the job of the spi controller, nor parity which has limited usefulness... \$\endgroup\$
    – old_timer
    Commented Jan 10, 2018 at 18:57
5
\$\begingroup\$

Parity, or any block error detection, is intended to detect errors within a data transmission itself. Parity is not designed to detect whether or not data transmission is taking place.

Given a transmission line, there are several different kinds of concerns. The two which are relevant here are: 1) outright failure of the line itself, and, 2) block data errors within a particular transmission. Others less relevant are, for example, incorrect line voltages, protocol errors, or security errors. Parity helps with 2 but not 1. For a subsystem on either end of a transmission line to cope with 1 (outright failure of a connection), another protocol feature is required.

The error detection rate of a single parity bit is often higher than 50%. Exactly what that rate is depends on the heuristics of the data segment in the protocol. Say you have a packet, (MSB) 1011010111011110, and there is an single bit error in the last transmitted bit, the parity check would fail and correctly reject it packet. Similarly, if you had a data error in the first bit (the parity bit), the packet would be rejected.

Performing this check in hardware is extremely simple and requires no complicated processing. It is useful in applications with relatively low bit error rates to weed out things like clock skew or clock signals generated by processors running garbage-collected software stacks.

SPI is a physical link protocol that designed for short electrically connected lines where the single-bit error rate doesn't much depend on the loss of the line. If you're running something across a lossy line, you're going to need something way more robust than parity. This isn't really what SPI does.

To check whether a device is still connected, try something higher in the stack. By comparison, TCP/IP (IP, specifically) doesn't specify parity bits while many of the 802.x Ethernet specifications do. IP does, on the other hand, have a complicated, "are you there?" protocol. What are you running on top of SPI? The answer to data link management is probably there.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ 802.3 and .11 use CRC32; IP and TCP and (optionally) UDP use a 16-bit one's-complement sum, which due to the fact very few machines or even ALUs today are 1sC is mostly implemented by unsigned addition plus carry-around. \$\endgroup\$ Commented Jan 11, 2018 at 9:31
  • \$\begingroup\$ The point is that parity could easily detect outright failure of the line itself. If I get back all 1s or all 0s, that should be a failure. \$\endgroup\$ Commented Oct 31, 2018 at 14:55
4
\$\begingroup\$

There's no obvious benefit of even parity over odd. In communication and storage schemes, the parity polarity (odd or even) should be selected to trap the most likely or highest-occurring failure modes.

As you say, an unresponsive target or broken data receive wire may well result in a MISO line stuck high or low.

When communicating even numbers of bits, such as bytes over SPI, an odd parity bit would detect a fault in this all-1's or all-0's data but even parity wouldn't.

However, there's no such clear winner when communicating an odd numbers of bits, such as in your application with 15 bits over SPI. Even parity would detect a fault in the all-1's case but miss the all-0's case. Conversely, odd parity would detect a fault in the all-0's case but miss the all-1's case.

\$\endgroup\$
1
  • \$\begingroup\$ Actually, yes, there clearly is in this case. As I explained in the question, Odd parity would be able to detect: missing, faulty disconnected chips and cable failures, whereas Even parity can't. \$\endgroup\$ Commented Jan 10, 2018 at 14:34
0
\$\begingroup\$

There is little difference in benefit with even or odd parity. One can be converted to the other with a single invert gate. The main purpose of the parity bit is to check only the 15 bits in that value. It is not its purpose to do any other thing. That one or the other could detect a missing, faulty, or disconnected chip is not a consideration. You mention that being disconnected is the most common type of error in your case. It does not matter. The parity bit is not there to detect that type of error.

\$\endgroup\$
0

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.