13

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?

Rocketmagnet
  • 26,933
  • 17
  • 92
  • 177
  • 6
    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. – Lundin Jan 10 '18 at 12:09
  • 40
    @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). – marcelm Jan 10 '18 at 13:07
  • 7
    @Lundin - Please address your comments to the makers of AMS, who make these chips. – Rocketmagnet Jan 10 '18 at 14:25
  • 1
    I mean, assuming that the main goal of the device was to make a 14-bit widget, I'd guess that these are not a primary design focus. They could have just stuffed those two bits with 0's, and then they wouldn't have you complaining about tertiary features. – W5VO Jan 10 '18 at 15:13
  • @marcelm When calculating effectiveness of error detection mechanisms, you take the whole data package in account, not just the payload. _The single bit error can hit the parity bit as well as any other bit_!!! EMI is not kind enough to leave your checksum alone and just occur on the payload bits. This is why parity is a stupid invention - the person who invented it made the same fundamentally wrong assumption as you just did. – Lundin Jan 10 '18 at 15:15
  • 26
    @Lundin If the parity bit flips, the parity check still fails. – Adam Haun Jan 10 '18 at 15:16
  • It has a 50% probability of catching errors involving more than 1 bit assuming random/normal distribution of error length. But 100% of catching a single bit. This is still *mostly* useless in *most* situations. – tom r. Jan 11 '18 at 02:46
  • 4
    _This is still mostly useless in most situations._ ⁽ᶜᶦᵗᵃᵗᶦᵒᶰ ᶰᵉᵉᵈᵉᵈ⁾ – dasdingonesin Jan 11 '18 at 08:46
  • 2
    @Lundin _".. you take the whole data package in account, not just the payload."_ - I did. Consider a 7-bit payload with 1-bit even parity code. The resulting code word is 8 bits. Any code word with an even number of high bits is a valid code word. Any code word with an odd number of high bits is an invalid code word. So changing _any_ bit in a valid code word (0 to 1 or 1 to 0) will change the number of high bits from even to odd, resulting in an invalid code word. Regardless of which bit you change. For example: `0b1001010+1`. Even number of `1`s, so valid. Change _any_ bit, and parity fails. – marcelm Jan 11 '18 at 11:42
  • 5
    @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. – TonyM Jan 11 '18 at 18:02

5 Answers5

16

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.

Andy aka
  • 434,556
  • 28
  • 351
  • 777
  • 2
    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. – Rocketmagnet Jan 10 '18 at 11:30
  • If there are an odd number of data bits then it lends itself to an odd parity bit if you want to use parity as a means for detecting loss of connectivity. – Andy aka Jan 10 '18 at 11:34
  • 1
    @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? – Andy aka Jan 10 '18 at 11:55
  • 3
    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. – Andy aka Jan 10 '18 at 14:36
  • That's a good idea. But I still wish I knew why they chose even parity. – Rocketmagnet Jan 10 '18 at 14:39
  • @Rocketmagnet yes I agree, it would make more sense to make it odd parity. Perhaps we'll never know! – Andy aka Jan 10 '18 at 14:41
  • 1
    @Trevor_G oops yes. Amending in progress. – Andy aka Jan 10 '18 at 18:08
  • 1
    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... – old_timer Jan 10 '18 at 18:57
  • being 15 data bits for whatever reason they perhaps tossed in a parity bit as a freebie. better than no checks at all. that was probably the end of the design meeting, hey its a freebie why not.. – old_timer Jan 10 '18 at 18:59
  • @Rocketmagnet To say it another way, WHEN the system design is such that the data is heavily checked through logic, THEN you can begin to consider having the software not validate the data that comes back. Until then it is certainly softwares job to validate the data, independent of the interface/protocol. – old_timer Jan 10 '18 at 19:02
  • switch to I2C if you want an ACK to see if the peripheral is there. – old_timer Jan 10 '18 at 19:03
  • @old_timer - I2C is too slow for my application. – Rocketmagnet Jan 15 '18 at 19:27
  • @Rocketmagnet are we done with this question now? – Andy aka Dec 18 '20 at 15:23
  • Why, are you fishing for a tick? – Rocketmagnet Dec 24 '20 at 22:44
  • @Rocketmagnet yes I am. Anything wrong with that? – Andy aka Dec 25 '20 at 09:56
  • @Andyaka - Not a problem at all. – Rocketmagnet Dec 26 '20 at 23:45
  • Ha ha you funster. – Andy aka Dec 27 '20 at 00:31
5

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.

Stephan Samuel
  • 51
  • 2
  • 1
    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. – dave_thompson_085 Jan 11 '18 at 09:31
  • 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. – Rocketmagnet Oct 31 '18 at 14:55
4

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.

TonyM
  • 21,742
  • 4
  • 39
  • 62
  • 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. – Rocketmagnet Jan 10 '18 at 14:34
0

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.

dreamcatcher
  • 123
  • 3
0

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.

TopCat
  • 214
  • 1
  • 3