Witam. Slecze nad projektem urzadzenia do zdalnego sterowania. Zastanawiam sie nad urzadzeniem odbiorczym. Odbiornik bedzie siedzial na okreciku, ktory bedzie plywal po wodzie. Sterowal nim bedzie procesorek 89c2051. I teraz problem. Zwazywszy, ze procesorek moze sie zawiesic, to stateczek nie bedzie reagowal na odebrane komunikaty, ktore eterem beda docieraly. Musze zrobic cos takiego, aby procesorka odwiesic. Poniewaz statek bedzie na otwartej wodzie, wiec nie moge do niego dotrzec. Ma ktos jakis pomysl, jak zrobic takiego "czuwajacego psa" dla tego procka w miare prosty sposob. Nie chcial bym stosowac specjalizowanych ukladow, ze wzgledu na niedostepnosc czesci. Chodzi mi o jakis prosty uklad na tranzystorach lub na jakis popularnych scalaczkach typu 555 lub 74121.
Sam sobie odpowiedziałeś. 555 nie nadaje się bo nie przedłuża impulsów.
Ale 74121 jak najbardziej. Ustalasz mu jakiś czas impulsu (RC) i podłączasz wyzwalanie pod nóżkę procesora. Wyjście pod reset. Procesor kiedy pracuje wysyła co jakiś czas (ale któtszy niż ustawiony na '121) impuls. Każdy taki impuls wydłuża czas generowania '121 i dzięki temu na wyjściu nie masz sygnału reset. Jeżeli procesor się zawiesi to impulsu nie poda, '121 skończy generować impuls, który wywoła reset.
Ważna zasada: nie umieszczać instrukcji generujących impulsów zerujących w przerwaniach.
Bo nawet jak program pójdzie w przysłowiowe maliny to przerwania mogą się wykonywać.
Obserwuję od pewnego czasu posty dot. ATmeli. Większość ukochała te Wathdogi. Ludziska przecież to ostateczność i porażka go używać. Od pewnego czasu "bawię" się prockami AT89C..51 i przeżyłem zwiechy itp...
Mogę powiedzieć jedno, prawidłowo napisany program działa bez zarzutu a jeśli masz podpięty rezystorem do masy reset i na zasilaniu 100nF procesora nie sposób zawiesić (próbowałem dziesiątki razy). Co innego jak zawiesza się bez powodu oznacza to że w programie jest (są) błędy "gramatyczne" (strukturalne). Moja rada w obsługach przerwań procedury ULTRAKRÓTKIE. Wszystko co można ładować do DO<->LOOP i podprogramów. Wtedy zapomnicie o "zwiechach".
Dzieki za odzew. A teraz po kolei. 74121 to moze byc rozwiazanie, ale... Zalozmy taka sytuacje. Nastapilo zawisniecie procka. Jeden z portow nie przedluza impulsu na 74121 i nastepuje podanie "1" na reset... i dalej jest ta "1" i procek czeka, az przestanie tam byc ta jedynka, aby w koncu mogl ruszyc od adresu $0. Ale on nie ruszy, bo caly czas jest ta cholerna "1" na nozce reset.
midas78:
Fajnie poradziles, ale rozwiazanie do dupy. Chyba, ze wsadzimy tam murzyna, ktory na chwile poda impuls na 74121.
john_t:
Zgadzam sie z toba, ze zwis procka nastepuje jak program napisany jest do bani. Jednak sa sytuacje, w ktorych bardziej oplacalne jest wsadzenie wathdoga. Program nie posiada bledow. Zwisy moga nastapic na skutek zachwiania napiecia zasilania. Calosc bedzie zasilana z akumulatorka, ktory w miare pracy zacznie obnizac napiecie. To moze spowodowac zachwianie gospodarki energetycznej w procku. Aby bylo jeszcze gorzej, to do tego samego zrodla zasilania beda przylaczone silniczki pradu stalego, ktore jak wiemy maja swoja indukcyjnosc. Sterowanie tymi silniczkami jest typu PWM co dodatkowo powoduje indukowanie sie chwilowych wysokich napiec. Te wszystkie iskrzenia i piki napiec chetnie powoduja wypadniecie procka. Trzymajac sie twojej koncepcji, musial bym dobudowac olbrzymia architekture filtrow i dodatkowo uwzgledniac przekroje sciezek, oraz oddzialywanie sciezek sasiednich na PCB. Mysle ze wystarczajaco przedstawilem argumenty, w ktorych nie mam zamiaru "wytaczac dziala na komara". Teoretycznie do zwisu nie powinno dojsc. Ale jesli dojdzie, to nie pozostanie nic innego, jak tylko poprosic zaprzyjazniona mewe lub innego ptaka wodnego o doholowanie stateczka do brzegu.
Może użyj TC1232. Dostępny np. w maritexie i w innych sklepach internetowych. Kosztuje ok 5zł i problem z głowy. Schemat podłączenia znajdziesz w karcie katalogowej. Możesz też poszukać w TME.
74121 to moze byc rozwiazanie, ale... Zalozmy taka sytuacje. Nastapilo zawisniecie procka. Jeden z portow nie przedluza impulsu na 74121 i nastepuje podanie "1" na reset... i dalej jest ta "1" i procek czeka, az przestanie tam byc ta jedynka, aby w koncu mogl ruszyc od adresu $0. Ale on nie ruszy, bo caly czas jest ta cholerna "1" na nozce reset.
Zgadzam sie z powyzszym rozumowaniem, jednak z dwoma zastrzezeniami: Po pierwsze uklad 121 nigdy nie byl i nie jest retrygowalny. Takim ukladem natomiast jest 74ls122 i 74ls123, a wiec raczej te uklady wchodza w rachube.
Co do sytuacji zawieszenia procka, to latwo zapobiec takiej sytuacji stosujac do retrygowania timera uklad rozniczkujacy, i niestraszne sa Ci juz stale jedynki po zawieszeniu procka. kostka 123 dobrze sie sprawdza w takich ukladach, ale jesli Twoj uklad ma chodzic na baterii, to moze lepiej jakis CMOS zastosowac ?
Pozdrawiam, yego.
0yego666#1313587
Jak to jest z tym zawieszeniem ?
Kiedyś zrobiłem układ sterownika z zegarem czasu rzeczywistego (zegar programowy) i po zastosowaniu zbyt długich procedur w przerwaniach procek po kilku minutach zawieszał się. Zaraz po zawieszeniu procesor podejmował pracę tzn. wykonywał DO<>LOOP ale wszystkie zmienne były wyzerowane, wszystkie piny (o ile pamiętam) ustawiał sobie na stan wysoki i nie wykonywał przerwań. Czy możecie potwierdzić że tak jest ?
Ja pisze w assemblerze, wiec dokladnie wiem co sie dzieje. Natomiast ty prawdopodonie piszesz w C lub basicu. Tu sytuacja jest nie do okreslona. Musisz debugerem zobaczyc kod assemblerowy. Samo zwisniecie zbyt dluga procedur moze spowodowac powiekszenie stosu, ktory zniczy zawartosc rejestrow specjalnych.
Piszę w Bascom'ie.
Nie chodzi mi o szczegóły zachowania się rejestrów ale o to czy zawsze po "zwisce" piny portów przyjmują stan wysoki (taki jak podczas uruchamiania procesora zaraz po autoresecie).
@john_t,
to jaki stan przyjma piny portow po zwisce nie jest okreslone w zadnych danych katalogowych. Ich stan zalezy od okolicznosci zawieszenia sie procka, czyli od stanu portow w chwili zawieszenia i od tego co sie tak naprawde zawiesilo. Najczesciej jest tak, ze procesor cos jednak wykonuje, ale nie wiadomo co , bo poszedl w maliny, tak wiec z czasem stany portow moga sie zmieniac.
Podsumowujac, nie ma szansy na jednoznaczne okreslenie a'priori tego co bedzie po zawieszeniu na portach. Z tego powodu watch-dog musi uwzgledniac rozne mozliwosci.
Pozdrawiam, yego
Tak jak kolega pisal. Dodam tylko, ze sam fakt zwisniecia procka, to jest tylko okreslenie dla ludzi. Dla procesora pojecie jak zwis nie istnieje. On tam cos robi, ale caly sek w tym, ze my nie wiemy co i nie mamy kontroli nad tym. To wlasnie nazywamy zwisem. Mam nadzieje, ze teraz wiesz, co tak naprawde kryje sie pod pojeciem zwisniecia procesora.
Chodzi mi o to że jeżeli już robimy "wathdog'a" to układ (zewnętrzny)musi rozpoznać kiedy jest stan zawieszenia i układ w konsekwencji ma wykonać reset. Najlepiej jakby był to sygnał z jednego pinu procka. Np. przebieg prostokątny to znaczy procek pracuje i układ resetu nic nie robi (utrzymuje stan niski na (1)), a gdy nie ma sygnału (jest stan wysoki lub niski) układ rozpoznaje to jako zawieszenie i generuje krótki sygnał resetu.
Wszystko pięknie ale to za piękne. Otórz tak jak pisałem wcześniej procesor zawiesił się a pętla DO<>LOOP działała nadal. Wyzerował tylko wszystkie zmiennne i nie wykonywał przerwań (ale czy zawsze tak jest) ?
Dlatego ponawiam pytanie: w jaki sposób (nie behavioralnie) tylko elektrycznie rozpoznać czy procek wisi ?
Urządzenie (stateczek czy coś) jest sterowane bezprzewodowo więc procek dostaje jakieś impulsy sterujące. Nasz watchdog mógłby działać wg następującej zasady: w drodze odbiornik kontroler wstawić najprostrzy przerzutnik np typu rs, który ustawi się po pierwszym leprzym impulsie z paczki impulsów informacyjnych. Przerzutnik będzie zerowany programowo przez procka (jakąś tam jedną nóżką). Jeśli przez oreślony czas (jakaś stała czasowa RC) przerzutnik nie będzie wyzerowany, to generuje krótki impuls resetu procka.
Jest to ogólna zasada, ale ten wspomniany impuls potwierdzenia z procka może nadejść w trakcie "zwisu", dlatego impuls musiałby nadejść w ściśle(no może nie przesadzajmy) określonym odcinku czasu (wyznaczonym przez brameczki).
Podsumowując: odbiornik nadaje paczki impulsów > przerzutnik jest ustawiany (czeka na potwierdzenie - zaczyna się odliczanie czasu RC) >procek dostaje informacje z odbiornika i tym samym odlicza czas po którym wyśle impuls potwerdzenia > jeśli impuls nadszedł po minimalnym czasie i przed maksymalnym czasem nadejścia, to wyzerowanie przerzutnika i brak generowania resetu inaczej reset (te odcinki czasu to nic innego jak zabawa brameczkami - razem najwyżej 2 układy z brameczkami).
Kiedy procek nie da impulsu potwierdzenia w tym określonym odcinku czasu to wiemy że jest zawieszony.
Dobierając dobre czasy - odpowiednie tolerancje - uzyskamy nienajgorszy system zabezpieczeń antyzawieszeniowych
Oczywiście proponuję choćby procka at90s2313, który ma zaimplementowanego watchdoga
