Gdyby w tym był problem - głównym sposobem znalezienia hazardu jest analiza wszystkich zmiennych używanych (tutaj) w przerwaniach.
Każda która jest zapisywana z przerwania i z kodu głównego, nie wiadomo co "zwycięży".
Dodatkowo każda operacja "odczyt i zapis" (zależnie od rozwinięcia nawet operator ++) może dać efekt nieokreślony (jeśli z drugiej flanki będzie ustawiona). Sekwencyjne porównanie i działanie na takiej zmiennej to niemal pewny błąd.
Dodatkowo każdy zmienna większa niż "naturalny dla platformy integer" nie musi / nie będzie obsługiwana jednym rozkazem maszynowym, przerwanie może "wejść między wódkę i zakąski" (inkrement na większych ingerach.
Ile jest
Zaloguj się, aby zobaczyć kod
w obecności szalejących przerwań?
Lekarstwem mocnym, ale to jak z każdym mocnym lekarstwem różnie bywa, jest wyłączenie i przywrócenie przerwań.
Nie robiłem na A2560, czuję że możliwości jest więcej niż na najstarszych, koledzy może podpowiedzą.
Lekarstwem precyzyjnym jest właściwy projekt.
Aha, źródła wiedzy. Rozmawiałem z wieloma programistami, jest jakoś naturalnie oczekiwana "gwarancja podczas współbieżności", obrazowo (z pewną luką) język Java ma na to słowo "synchronized".
A słowo volatile NIE MA takiego znaczenia, ono znaczy tylko "proszę nie składuj tej zmiennej podczas optymalizacji do rejestrów", jest to owszem pomocne (konieczne) do przerwań ale nie wystarczające. Jak widzę duży urodzaj vilatile mam pomarańczowe światełko, tak po prostu mam, nie pytaj dlaczego.
Błędy od hazardów są losowe, czary mary itd... Każda zmienna globalna tu występująca jest "podejrzana".
Zaloguj się, aby zobaczyć kod