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

Odbiornik IR wiesza procesor.

JarekPrzybyl 23 Gru 2013 20:23 1065 8
  • #1 23 Gru 2013 20:23
    JarekPrzybyl
    Poziom 15  

    Taki mi się problem pojawił:

    Hardware: Atmega 8, do niej podpięty TSOP1736, w standardowym prostym układzie jak z datasheeta: linia danych wprost do procka, zasilanie przez opornik 100R do +5V i podparte kondensatorem 22uF. Sam TSOP wyciągnięty poza układ na ok. 3m przewodzie ekranowanym (jakiś tani przewód audio).

    Software: obsługa odbiornika IR w przerwaniu, zrobiona w Bascomie na wzór powielanego w nieskończoność także tu na tym forum przykładu z książki M. Wiązani. Nie podaję póki co nic więcej, bo to nie ma sensu, procedura odbioru IR jest żywcem z Wiązani wzięta.

    I sprawa ma się tak: generalnie całość działa niezawodnie i bez zarzutu, jednak już trzy razy zdarzyło się, że przy intensywnym korzystaniu z innego pilota (nawet nie RC5) pozostającego w polu widzenia odbiornika, procesor się wieszał. Porty są ustawiane w jakieś absurdalne z punktu widzenia napisanego softu stany i tak sobie całość wisi, nie reagując na żadne impulsy zewnętrzne, w tym i na kolejne przerwania od IR, pomaga jedynie reset zasilania.

    Moje pytania:
    1) czy to jest znany problem? Ktoś z czymś podobnym walczył?
    2) czy jest możliwe, że w jakichś sytuacjach bascomowa procedura GetRC5 odbierając coś, co nie jest RC5 wiesza procesor?
    3) jak właściwie działa watchdog? Może dałoby się go tutaj użyć jako workaround?

    0 8
  • #2 23 Gru 2013 20:50
    tmf
    Moderator Mikrokontrolery Projektowanie

    Zacznę od końca:
    ad 3. WD nie służy do naprawiania błędów w sofcie. A działa on tak, że jeśli nie będziesz psa okresowo kopał to zresetuje ci procek.
    ad 2. Niewykluczone, że gotowa funkcja, jeśli natrafi na coś co nie potrafi zinterpretować to się wiesza. Taki urok zamkniętego kodu, że jak coś nie działa to jesteś w...

    0
  • #3 24 Gru 2013 08:48
    JarekPrzybyl
    Poziom 15  

    to w taki razie watchdog mi dupę ratuje, bo program działa w dużej pętli i okresowe kopanie kundla nie jest problemem.

    Analizując ten swój kod trafiłem na jeszcze jedną możliwość. Jest jedno miejsce, w którym w pewnej dość wydumanej, ale teoretycznie możliwej okoliczności jest możliwe wywołanie przerwania (tego obsługującego odczyt IR) w trakcie obsługi tegoż przerwania z poprzedniego wywołania. Powiedz mi, jak procesor reaguje na taką obsługę zagnieżdżonego przerwania? Może to jest przyczyna mojego problemu?

    0
  • #4 24 Gru 2013 09:21
    tmf
    Moderator Mikrokontrolery Projektowanie
  • #5 24 Gru 2013 10:08
    JarekPrzybyl
    Poziom 15  

    Ok... w takim razie nie mam innych pomysłów, co w programie mogłoby powodować ten problem. Program jest rozległy, ale jednocześnie jest to po prostu długachny ciąg warunków, bez szczególnie dużych rozgałęzień, w nim nigdzie nie ma żadnej możliwości na "zamrożenie" urządzenia, a przynajmniej ja takiej możliwości nie widzę (tak, wiem, to "ja" może być zasadniczym problemem :) ).

    Dwa ostatnie pytania w takim razie:
    1) czy od strony hardware'u praktykuje się jakieś dodatkowe odkłócanie linii prowadzącej do odbiornika IR? Jakiś mały (!!!) kondensator do masy, czy coś takiego?

    2) odnośnie watchdoga jeszcze - poczytałem, mniej więcej wiem już o co chodzi, jedno jednak jest dla mnie niejasne: gdzieś na elektrodzie pojawiła się informacja, że niektóre procedury języka (akurat też o bascom chodziło) same w sobie mają zaimplementowane kasowanie watchdoga. Niestety bascomowy help o tym nie wspomina, a jest to dla mnie dość istotne, zwłaszcza w odniesieniu do procedury "wait" i "waitms". Przykładowo, czy poniższy programik ma szansę działać?

    Code:
    config watchdog=1024
    
    start watchdog
    do
       cośtamcośtam
       wait 2
       reset watchdog
    loop


    watchdog powinien być resetowany co mniej niż sekundę. Pauza wait 2 wyklucza taką możliwość. Jeśli ona watchdoga resetuje sama, będzie ok, jeśli nie - nie będzie, pętelkę trzeba będzie zmodyfikować.

    0
  • #6 24 Gru 2013 11:11
    tmf
    Moderator Mikrokontrolery Projektowanie

    ad 1. Nie nie, praktykuje się z prostej przyczyny - na wyjściu odbiornika po prostu mogą być śmieci i program dekodera musi być na nie odporny.
    ad 2. Nie wiem, sprawdź sam - wstaw te instrukcje i zobacz czy wstawiają kod instrukcji asemblera WDR.
    BTW, może czas porzucić Bascoma na rzecz języka, ktorego się używa (C/C++)?

    0
  • #7 24 Gru 2013 11:26
    JarekPrzybyl
    Poziom 15  

    Wiesz... próbowałem, ale nie leży mi jakoś :)
    Ja jestem wychowany na Pascalu i Bascom jest dla mnie naturalnym językiem, który bez problemu ogarniam, z C mi jakoś nie idzie :)

    0
  • #8 24 Gru 2013 11:36
    tmf
    Moderator Mikrokontrolery Projektowanie

    No cóż, to walcz dzielnie w osamotnieniu rozwiązując problemy nieznane w innych językach :)

    0
  • #9 28 Gru 2013 16:34
    ryku5
    Poziom 10  

    Witam,
    Byłem w identycznej sytuacji. Pomogła zmiana kompilatora na 1.11.8.1. W wersji 2.0.7.5 komenda getrc5 zawieszała program.
    Pozdrawiam

    0
  Szukaj w 5mln produktów