Timeline for Why bother with even parity?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 27, 2020 at 0:31 | comment | added | Andy aka | Ha ha you funster. | |
| Dec 26, 2020 at 23:45 | comment | added | Rocketmagnet | @Andyaka - Not a problem at all. | |
| Dec 25, 2020 at 9:56 | comment | added | Andy aka | @Rocketmagnet yes I am. Anything wrong with that? | |
| Dec 24, 2020 at 22:44 | comment | added | Rocketmagnet | Why, are you fishing for a tick? | |
| Dec 18, 2020 at 15:23 | comment | added | Andy aka | @Rocketmagnet are we done with this question now? | |
| Jan 15, 2018 at 19:27 | comment | added | Rocketmagnet | @old_timer - I2C is too slow for my application. | |
| Jan 10, 2018 at 19:03 | comment | added | old_timer | switch to I2C if you want an ACK to see if the peripheral is there. | |
| Jan 10, 2018 at 19:02 | comment | added | old_timer | @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. | |
| Jan 10, 2018 at 18:59 | comment | added | old_timer | 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.. | |
| Jan 10, 2018 at 18:57 | comment | added | old_timer | 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... | |
| Jan 10, 2018 at 18:09 | history | edited | Andy aka | CC BY-SA 3.0 |
added 22 characters in body
|
| Jan 10, 2018 at 18:08 | comment | added | Andy aka | @Trevor_G oops yes. Amending in progress. | |
| Jan 10, 2018 at 14:41 | comment | added | Andy aka | @Rocketmagnet yes I agree, it would make more sense to make it odd parity. Perhaps we'll never know! | |
| Jan 10, 2018 at 14:39 | comment | added | Rocketmagnet | That's a good idea. But I still wish I knew why they chose even parity. | |
| Jan 10, 2018 at 14:36 | comment | added | Andy aka | 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. | |
| Jan 10, 2018 at 11:55 | comment | added | Andy aka | @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? | |
| Jan 10, 2018 at 11:34 | comment | added | Andy aka | 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. | |
| Jan 10, 2018 at 11:30 | comment | added | Rocketmagnet | 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. | |
| Jan 10, 2018 at 11:10 | history | answered | Andy aka | CC BY-SA 3.0 |