Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Reset ATmega przez RS232 / RTS lub CTS

20 Lip 2010 23:01 2778 10
  • Poziom 17  
    Witam czy jest moliwość resetu uC (ATmega) przez port RS232 na linii CTS lub RTS?

    Jeśli tak to jak to podłączyć?
    Darmowe szkolenie: Ethernet w przemyśle dziś i jutro. Zarejestruj się za darmo.
  • Pomocny post
    Poziom 42  
    Jeśli masz konwersję na TTL np przez MAX232 to możesz wprost podłączyć a jeśli nie to przez kondensator 100nF (linie DTR i RTS)
  • Poziom 17  
    Mam MAX'a 232, znasz się może na Delphi, chodzi mi o to że jak podać sygnał na chwilę by zresetować układ.

    Jeśli chodzi o ogólne programowanie Delphi a uC przez RS232 to nie mam problemu, lecz nie weim jak pojedynczi ustawiać linię CTS i RTS.

    Aha jak podłącze to nie będzie układ cały czas resetowany?
  • Poziom 27  
    Nie byłoby pewniej dokonywać resetu poprzez programową obsługę ? Ustawiasz sobie określony ciąg odebranych danych które definiujesz jako reset w momencie kiedy avr to obierze skacze pod adres $0000 i masz reset.
  • Poziom 42  
    rpal napisał:
    Nie byłoby pewniej dokonywać resetu poprzez programową obsługę ? Ustawiasz sobie określony ciąg odebranych danych które definiujesz jako reset...


    Tak, zdecydowanie lepsze jest takie rozwiązanie tzn programowe niż za pomocą linii RTS lub CTS. Dlaczego? ano dlatego, że jak np włączysz terminal albo inny program, który korzysta zwykle z tych linii to masz serię niekontrolowanych resetów :(


    rpal napisał:
    .... w momencie kiedy avr to obierze skacze pod adres $0000 i masz reset.


    ... ale już rozwiązanie poprzez skok pod adres $0000 już nie jest najlepszy zdecydowanie lepiej zrobić sobie wtedy reset za pomocą watchdoga, np:

    Code:
    cli();
    
    wdt_enable(1);
    while(1);


    to zapewni zawsze w pełni poprawny i PEŁNY reset w przeciwieństwie do skoku pod zerowy adres.
  • Poziom 27  
    Na czym będzie polegać ta różnica ? Jedyną widze w tym że pamięć SRAM może mieć jakieś pozostałości z poprzednio wykonanego "zadania" . Z drugiej strony w programie powinna mieć inicjowane wartość dla zmiennych a nie założenie że jest tam "nic". Osobiście nie widzę różnicy ale kłócić się nie zamierzam - gorąco :)
  • Poziom 38  
    no własnie zmienne są chyba inicjowane od nowa ?
  • Poziom 28  
    Dobra praktyka programistyczna jest wyzerowanie pamieci na poczatku programu. Swego czasu spedzilem chyba ze dwa dni walczac z bledem ktorego nie bylo. Okazalo sie ze fabryczny bootloader korzysta z ktorys tam rejestrow. Ja tez z nich korzystalem. Efekt taki ze pierwszy raz po zaprogramowaniu program zawsze szedl w krzaki. Zrobilem sobie dwa makra ClearMemory i ClearRegisters i problem zniknal.
    Roznica pomiedzy skokiem pod adres $0000 a reset przez watchdoga jest i to spora. Watchdog sprzetowo linie RESET na jakis czas aktywuje. Wtedy wewnetrznie wszystkie rejestry opisane w dokumentacji przyjmuja swoj stan poczatkowy. Przy skoku pod adres $0000 ciagle dzialaja przerwania, sa poustawiane rozne rejestry wczesniej zainicjalizowane wiec moga ciagle dzialac timery, przerwania zewnetrzne, UARTy i tak dalej...
  • Poziom 42  
    Dexter77 napisał:

    Roznica pomiedzy skokiem pod adres $0000 a reset przez watchdoga jest i to spora. Watchdog sprzetowo linie RESET na jakis czas aktywuje. Wtedy wewnetrznie wszystkie rejestry opisane w dokumentacji przyjmuja swoj stan poczatkowy. Przy skoku pod adres $0000 ciagle dzialaja przerwania, sa poustawiane rozne rejestry wczesniej zainicjalizowane wiec moga ciagle dzialac timery, przerwania zewnetrzne, UARTy i tak dalej...


    Dobrze mówisz. A szczególnie, że przy starcie programu zwykle się nie pisze cli();

    Zatem po skoku pod adres $0000 działające timery czy inne przerwania mogą już troszkę namieszać.

    Też się nie będę kłócił że jest to najlepszy sposób, jednak jak wspomina wyżej kolega czasem po zwykłym skoku pod adres $0000 można się naciąć i szukać buga w swoim programie niepotrzebnie. Podczas gdy reset przez watchdoga wszystko załatwi profesjonalnie i po cichu ;)
  • Poziom 28  
    mirekk36 napisał:

    A szczególnie, że przy starcie programu zwykle się nie pisze cli();


    Nawet gdyby pisac cli na poczatku programu to tez niczego to nie zalatwia. Mozna np. wyobrazic sobie ze w trakcie trwania skoku lub juz nawet po nim trwajaca transmisja na UARCIe wpisala do buforu odbiornika dana i ustawila flage ze jest cos do odczytu. Owszem przerwanie sie nie zglosi, ale zaraz po nowej inicjalizacji UARTu i wlaczeniu przerwan natychmiast bedzie chcialo sie wykonac. Jezeli w komunikacji z innym urzadzeniem korzystamy z jakiejs ustalonej ramki danych to taka przypadkowa dana moze wszystko rozwalic. Program musi wtedy byc wyposazony w mechanizmy odzyskania synchronizacji, bez tego poprostu sie wykrzaczy...