eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaBurza i kłopoty w MCU...Re: Burza i kłopoty w MCU...
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!news.task.gda.pl!not-for-mail
    From: sundayman <s...@p...onet.pl>
    Newsgroups: pl.misc.elektronika
    Subject: Re: Burza i kłopoty w MCU...
    Date: Tue, 04 Jun 2013 22:30:30 +0200
    Organization: CI TASK http://www.task.gda.pl/
    Lines: 48
    Message-ID: <kolj34$cgs$1@news.task.gda.pl>
    References: <koilv9$p9s$1@news.task.gda.pl> <kok4ed$f7o$1@somewhere.invalid>
    <kok5ou$4o5$1@news.icpnet.pl> <kok7tk$4da$1@mx1.internetia.pl>
    <kol071$tf2$1@news.task.gda.pl> <kolgrt$85f$1@mx1.internetia.pl>
    NNTP-Posting-Host: terminal-1-178.retsat1.com.pl
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    X-Trace: news.task.gda.pl 1370378148 12828 195.13.38.178 (4 Jun 2013 20:35:48 GMT)
    X-Complaints-To: a...@n...task.gda.pl
    NNTP-Posting-Date: Tue, 4 Jun 2013 20:35:48 +0000 (UTC)
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509
    Thunderbird/17.0.6
    In-Reply-To: <kolgrt$85f$1@mx1.internetia.pl>
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:648011
    [ ukryj nagłówki ]


    > To nie pomoże.
    > Pokaż lepiej fragment pętli, gdzie odczytujesz stan klawiszy i gdzie masz
    > kasowanie tej zmiennej od klawiszy.
    > Raczej wydaje mi się, że przeskoczył rejestr i ma taką wartość,
    > na którą program nie jest przygotowany i ciągle reaguje.
    > Np.
    > 1) odczyt klawiszy BIT1 i BIT2
    > 2) sprawdzasz czy są naciśnięte po kolei BIT1=0, BIT2=0 itp.
    > 3) Jeśli jest różne od FF zakładamy, że są 2 wciśnięte równocześnie.
    > 4) Tak>włączasz silnik
    > 5) kasujesz BITY1 i 2
    > 6) zapętlasz do 1, a program ciągle uznaje, że ma wciśnięte klawisze.

    > Nie wiem, czy czujesz co mam na myśli, ale jakoś tak mi to wygląda.
    > Burza ustała, a program uważa, że ma ciągle wciśnięte klawisze, bo może
    > wpływ na warunek mają inne, nieużywane bity.

    Rozumiem oczywiście, ale jest jak piszę.
    W pętli głównej , gdzie są sprawdzane klawisze, po prostu kolejno
    testowane są linie wejściowe. I zależnie od ich stanu wykonywany jest
    wskok w określoną procedurę.
    Więc naciśnięcie więcej niż jednego klawisza powoduje wejście kolejno
    w procedurą X(klawisz x), potem Y(klawisz y) itp.

    Nie były stosowane żadne pośrednie zmienne. Po prostu reakcja na
    fizyczny stan linii. Poza tym, jak wspomniałem program działa na kilku
    urządzeniach przez dłuższy już czas, i nie było z tym problemu.

    Tak, że na pewno nie było to problem od strony programu. Dlatego też
    , zanim o 6 rano w łóżku wpadłem na rozwiązanie, to przez ileś godzin
    gapiłem się w monitor i myślałem "to niemożliwe, to niemożliwe..." :)

    Wiem, że to bardzo chyba rzadki przypadek. No, ale skoro taki jest fakt,
    to trzeba się z nim pogodzić :)

    Teraz wprowadzam modyfikacje w programie, polegające na tym, że
    1) klawisz musi być puszczony przez ponowną aktywacją
    2) normalnie klawiatura jest "zablokowana", jedynie jeden przycisk
    uaktywnia możliwość wpisania hasła , które odblokowuje klawiaturę.
    3) wykrycie naciśnięcia więcej niż 1 przycisku wywołuje błąd (zapis w
    pamięci zdarzeń, potem autoreset, po 3 takich autoresetach trwałe
    wyłączenie).
    4) oczywiście zewnętrzne rezystory podciągające.
    5) powłoka z EMI-35 połączona z masą zasilania

    I myślę, że powinno być ok. Dopóki nie wydarzy się coś innego :)

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: