Antystatyczny napisał(a):
Teraz rozumiesz, co mam na mysli, Mirku?
Antystatyczny --> ale zobacz co ja napisałem,
mirekk36 napisał(a):
Zdecydowanie dopuszczalny wszystko zależy oczywiście od projektu
Dlatego wcale nie masz bujnej wyobraźni bo takich projektów gdzie to będzie przeszkadzało są setki jak nie tysiące tak samo jak są setki/tysiące gdzie nie będzie przeszkadzało. Tylko o to mi chodziło ...
więc nie mogę się z tobą nie zgodzić. A i bez bujnej wyobraźni można podać jeszcze z 10000000 przypadków gdzie jest konieczne aby funkcje te nie były blokujące w ten sposób
Uwierz mi to nie jest tak - że ja byłem przekonany że nie ma przypadków w których to może stanowić problem. Proszę bardzo o wiele bardziej banalny przykład. Byle system, który coś tam robi - np wpuszcza pracowników na teren zakładu po wsunięciu karty
i rejestruje godziny wejścia/wyjścia
.... więc pracuje tam pewnie RTC na I2c (załóżmy) ... no i padła magistrala I2C - i co ? system ma paść i pracowników nie wpuścić albo wypuścić z tego powodu ?
toż zaraz zamieszki by powstały
A wprowadzenie timeout'u w tych procedurach na prawdę nie jest trudne to wręcz bułka z masłem i nawet bez użycia systemu przerwań ... To trzeba mieć na uwadze ... wtedy na prawdę przykłady mogą być jednak bułką z masłem dla każdego. Liczy się czasem najprostszy pomysł, który pokazuje drogę ... (OCZYWIŚCIE to jest droga na piechotę - a można też skorzystać z rozbudowanego systemu sprzętowych statusów TWI .... ale myślę, że najprostsza metoda da po prostu dużo do myślenia i inspirację jak do tego w ogóle podchodzić)
żeby nie być gołosłownym proszę bardzo - poniżej funkcja, która np blokuje nam program gdy mamy coś nie tak na magistrali sprzętowej (pokażę tylko jedną i jej przeróbkę - a na podobnej zasadzie można przerobić pozostałe, Ba! takie podejście programistyczne można stosować wszędzie - choć nie zawsze musi to być akurat dokładnie takie - staram się tylko naprowadzić na pewien typ myślenia), oto blogujący kod:
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
teraz zastanówmy się jaki jest nasz cel? Załóżmy że funkcja ma zasygnalizować w jakikolwiek sposób, że jest awaria. Można to zrobić na wiele sposobów, jednym z prostszych jest zwracanie rezultatu błędu, można ustawiać jakąś globalną flagę itp itd. My zrobimy to poprzez zwracanie błędu w rezultacie, dzięki czemu łatwo będzie sprawdzić to w nadrzędnej funkcji.
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
oczywiście tą wartość = 1000 dobieramy doświadczalnie albo uzależniamy jeszcze od prędkości I2C (nie ważne na razie). Dzięki czemu później wywołanie takiej funkcji gdzieś w nadrzędnej funkcji można już robić tak
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
jak mówię - jest to prosty albo nawet mega uproszczony przykład ale nie ma możliwości aby nie działał
i to skutecznie
REASUMUJĄC - Arek tu nie chodzi o znajdowanie przykładów gdzie to może być ISTOTNE a gdzie NIE - bo jak mówiłem jednych i drugich jest pełno.
Np budując zegarek - ot taki zegarek/budzik
... mi nie chciałoby się rozbudowywać tych funkcji po to tylko aby np dodać jakieś tam miganie diodą czy może wyświetlanie statusu na wyświetlaczu I2C error
Dlaczego ?
tu też jest kilka ważnych powodów hmm może praktycznych.
Po pierwsze dlatego, że napracuję się a prędzej urządzenie przeze mnie zbudowane zestarzeje się i NIKT NIGDY tego komunikatu nie zobaczy
to jest najbardziej smutne
Po drugie nawet jak nie ma obsługi błędów sprzętowych TWI (mówimy tu o tego typu projektach a nie w aucie z twojego przykładu) i takie urządzenie nie działa - zawiesza się to na prawdę uwierz mi - praktyka (którą sam jak mówisz nabyłeś niedawno) strasznie szybko podpowiada ci co jest uszkodzone .... sam zobacz jaką podpowiedź dałeś - że skoro się zawiesza odczyt to pewnie jest coś nie tak na magistrali I2C
.... widzisz jak to działa? (oczywiście że nie zawsze to musi być powód szczególnie gdy w urządzeniu pracuje więcej modułów i mogą generować one różne problemy - ale jednak uszkodzenie I2C bywają bardzo charakterystyczne w objawach. Np działa sobie cały TV a nie działa tylko regulacja głosu ... serwisant zwykle zaraz sprawdza czy nie padła komunikacja I2C z układem wzmacniacza czy potencjometra pracującego na I2C ... a jak na razie producenci telewizorów nie przygotowują tzw "komputerków" jak w samochodach gzie można się wpiąć i odczytać status błędu.
Po prostu robi to serwisant
No i po trzecie ... jak się ma byle oscyl pod ręką, byle analizator stanów logicznych to wystarczy dotknąć sondą do SCL czy SDA i sprawdzić czy coś tam "biega sobie" (bo podczas normalnej pracy wiemy że "biega") .... a jak widzimy, że jest głucho no to już znowu wiadomo że mamy sprzętową awarię I2C
A zatem - na prawdę wykrycie awarii sprzętowej I2C to można powiedzieć taki pryszcz (oczywiście jak już się nabrało troszkę praktyki) że szkoda gadać .... Niestety nie ma co się dziwić początkującym, że o tym nie wiedzą. Ba! oni mają problem w ogóle z namierzeniem problemu nawet mając własny kod źródłowy - a przecież jak widać wystarczy tu JEDNA DIODA LED, którą wg super prostej procedury wystarczy podłączyć po kolei:
1. do nogi RTC
2. do pinu procka i migać z przerwania
3. do pinu procka i próbować migać po odczycie I2C
to TYLKO tyle .... i mamy tak prosty sygnalizator 3 najczęściej spotykanych błędów że szok - nawet bez timeoutów i pokazywania komunikatów dla USERA że "I2C error"
bo czasem nie ma nawet na czym ich pokazać.
---------------------------
Arek - to aż tyle albo tylko tyle co chciałem tu dopowiedzieć i pokazać jak zwykle różne drogi
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
