Po co zawracać sobie głowę nawet parzystością?

Używam urządzenia peryferyjnego SPI w mojej aplikacji. Urządzenie peryferyjne zwraca pakiety zawierające 15 bitów danych plus bit parzystości parzystej do wykrywania błędów.

Dlatego wszystkie zera i wszystkie z nich przechodzą kontrolę parzystości.

Oznacza to, że mój mikrokontroler nie może wykryć najczęstszego rodzaju błędu: odłączenie urządzenia peryferyjnego! W tym przypadku wszystkie odebrane bity są zerowe, co przechodzi kontrolę parzystości.

Zakładając, że producent urządzeń peryferyjnych równie łatwo wdrożyłby nieparzystą parzystość, moje pytanie brzmi: dlaczego w tym przypadku zdecydowaliby się zastosować parzystą parzystość ? Czy w tym przypadku jest jeszcze inna zaleta funkcji Even Parity w celu zrekompensowania faktu, że nie jest w stanie wychwycić najczęstszego rodzaju błędu?

Pojedynczy bit parzystości może sprawdzić obecność pojedynczej lub nieparzystej liczby bitów w błędach, więc oczekiwanie, że wykryje, kiedy urządzenie peryferyjne jest odłączone, prawdopodobnie oczekuje zbyt wiele.

Jednak wiele systemów generuje ciągłą serię 1, gdy urządzenie peryferyjne nie jest obecne i można to osiągnąć za pomocą prostego rezystora podciągającego na powracającej linii danych. Jeśli przez podłączone urządzenie peryferyjne zwracane są 8-bitowe dane, wówczas bit parzystości wynosiłby zero dla przesyłanego dziesiętnego 255. Tak więc nawet parzystość może wykryć, kiedy urządzenie peryferyjne zostanie odłączone w tych okolicznościach.

Gdyby użyto nieparzystej parzystości, 8 bitów wysokich (255 po przecinku) spowodowałoby bit o wysokiej parzystości, przez co nieparzysta parzystość byłaby bezużyteczna jako sposób na wykrycie utraty układu peryferyjnego.

Konie na kursy.

Wykrywanie błędów parzystości lub dowolnego bloku ma na celu wykrycie błędów w samej transmisji danych. Parzystość nie jest przeznaczona do wykrywania, czy ma miejsce transmisja danych.

W przypadku linii przesyłowej istnieje kilka różnych rodzajów problemów. Dwa, które są tutaj istotne, to: 1) całkowita awaria samej linii oraz 2) blokowanie błędów danych w ramach danej transmisji. Inne mniej istotne to na przykład nieprawidłowe napięcie linii, błędy protokołu lub błędy bezpieczeństwa. Parzystość pomaga przy 2, ale nie 1. Aby podsystem na obu końcach linii przesyłowej poradził sobie z 1 (całkowita awaria połączenia), wymagana jest inna funkcja protokołu.

Częstotliwość wykrywania błędów pojedynczego bitu parzystości jest często wyższa niż 50%. Dokładnie, jaka jest ta szybkość, zależy od heurystyki segmentu danych w protokole. Załóżmy, że masz pakiet (MSB) 1011010111011110, aw ostatnim przesyłanym bicie występuje błąd pojedynczego bitu, kontrola parzystości zakończy się niepowodzeniem i poprawnie go odrzuci. Podobnie, jeśli wystąpił błąd danych w pierwszym bicie (bit parzystości), pakiet zostałby odrzucony.

Przeprowadzenie tej kontroli sprzętu jest niezwykle proste i nie wymaga skomplikowanego przetwarzania. Przydaje się w aplikacjach o relatywnie niskich bitowych poziomach błędów, aby wyeliminować takie rzeczy, jak przekrzywienie zegara lub sygnały zegarowe generowane przez procesory uruchamiające stosy śmieci.

SPI jest fizycznym protokołem łącza zaprojektowanym dla krótkich linii połączonych elektrycznie, w których jednobitowy współczynnik błędów nie zależy w dużej mierze od utraty linii. Jeśli prowadzisz coś wzdłuż linii stratnej, będziesz potrzebować czegoś znacznie bardziej niezawodnego niż parzystość. To nie jest tak naprawdę SPI.

Aby sprawdzić, czy urządzenie jest nadal podłączone, spróbuj czegoś wyżej na stosie. Dla porównania protokół TCP / IP (w szczególności IP) nie określa bitów parzystości, podczas gdy wiele specyfikacji Ethernet 802.x tak. Z drugiej strony własność intelektualna ma skomplikowane pytanie „jesteś tam?” protokół. Co działasz na bazie SPI? Prawdopodobnie istnieje odpowiedź na zarządzanie łączem danych.

Nie ma oczywistej przewagi parzystości nad nieparzystą. W schematach komunikacji i przechowywania należy wybrać polaryzację parzystości (nieparzystą lub parzystą), aby uwięzić najbardziej prawdopodobne lub najczęściej występujące tryby awarii.

Jak mówisz, niereagujący cel lub przerwany przewód odbierający dane mogą spowodować, że linia MISO utknie wysoko lub nisko.

Podczas przesyłania parzystej liczby bitów, takich jak bajty przez SPI, nieparzysty bit parzystości wykryłby błąd w danych tego all-1 lub all-0, ale nawet parzystość nie.

Jednak nie ma tak wyraźnego zwycięzcy w komunikowaniu nieparzystej liczby bitów, na przykład w twojej aplikacji z 15 bitami przez SPI. Nawet parzystość wykrywa błąd w przypadku all-1, ale pomija przypadek all-0. I odwrotnie, nieparzysta parzystość wykryłaby błąd w przypadku all-0, ale pominie przypadek all-1.

Niewielka różnica w korzyściach z parzystą lub nieparzystą parzystością. Jedno można przekształcić w drugie za pomocą pojedynczej bramy odwróconej. Głównym celem bitu parzystości jest sprawdzenie tylko 15 bitów tej wartości. Nie jest celem innych rzeczy. To, że jedno lub drugie może wykryć brakujący, wadliwy lub odłączony układ, nie jest brane pod uwagę. Wspominasz, że rozłączenie jest najczęstszym rodzajem błędu w twoim przypadku. Nie ważne. Bit parzystości nie służy do wykrywania tego rodzaju błędu.

Masz rację, kwestionując to, mam taką samą krytykę nawet równości. Przy nieparzystej liczbie bitów danych przed dodaniem bitu parzystości, jak w twoim przykładzie, i jak zwykle, parzystość zezwala wszystkim zerom i wszystkim jedynkom na prawidłowe przesyłane słowa, co jest bezużyteczne w wykrywaniu martwego łącza lub martwego układu. Wcześniejsza odpowiedź Tony'ego M. jest w tym względzie błędna. Aby zobaczyć dowód, zobacz tabelę przykładowych danych 7-bitowych: - https://en.wikipedia.org/wiki/Parity_bit

Dziwna parzystość wstawiłaby jednak bit stanu przeciwnego w przypadku wszystkich zer lub wszystkich zer, dowodząc w ten sposób, że połączenie i układ są aktywne, i w tym przypadku byłby znacznie lepszym wyborem.