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.

CMSIS stm32f103 obsługi drgań styków w przerwaniu

pioter996 17 Maj 2018 09:15 954 49
  • #31 17 Maj 2018 09:15
    nowyARM
    Poziom 27  

    Freddie Chopin napisał:
    Oczywiście że jest skuteczne. Tajemniczy "impuls zakłócający" chyba nie pochodzi z kosmosu, tylko z faktu, że jednak ktoś ten przycisk nacisnął, wiec jeśli zostanie to zinterpretowane jako naciśnięcie, to doskonale - właśnie o to chodzi.

    A jeśli zakłócenie zaindukowało się w przewodzie? Przechodzi w pobliżu urządzenia, podłączonego długimi przewodami, człowiek z komórką i zostanie to zinterpretowane jako awaryjne zatrzymanie linii produkcyjnej? Włączył sie silnik dużej mocy? Przykłady można mnożyć.

    Dodano po 2 [minuty]:

    powrotnik napisał:
    chociaż przy okazji przyznaje że dopiero zaczyna z ARM-ami).

    A co ma wspólnego znajomość lub nie drgania styków z konkretnym uC? Czy Z-80, czy ARM zasady sa te same.

    powrotnik napisał:
    wie wszystko na każdy temat

    Krócej omnibus (nie mylić z środkiem transportu).

  • #32 17 Maj 2018 09:29
    BlueDraco
    Specjalista - Mikrokontrolery

    Było wcześniej - są dwa przypadki - przycisk niezakłócany (tylko drgający) i zakłócany, Pierwszy - 2 linie kodu, drugi - 6..7 (z eleganckim switch trochę więcej, ale czytelniej).

  • #33 17 Maj 2018 09:36
    nowyARM
    Poziom 27  

    BlueDraco napisał:
    Było wcześniej - są dwa przypadki - przycisk niezakłócany (tylko drgający) i zakłócany

    Było w #5. W #26 nie ma nic na zakłócania lub nie.
    Jeśli nawet wydaje się, że przycisk nie jest zakłócany, należy brac taki przypadek pod uwagę. W większości wypadków używane jest wewnętrzne podciąganie. Włączenie odkurzacza może spowodować zakłócenia. No chyba, ze przycisk jest podciągnięty rezystorem wymuszającym przepływ dużego prądu, np 10 ohm.

  • #34 17 Maj 2018 10:49
    3171327
    Użytkownik usunął konto  
  • #35 17 Maj 2018 12:43
    pioter996
    Poziom 3  

    Dzięki za wszelkie sugestie i dużą dawkę doświadczenia. W przerwaniu sprawdzam 2 ostatnie stany jeśli są takie same zakładam że przycisk został wciśnięty , wszystko funkcjonuje jak powinno. W przyszłości planuje wykorzystać rozwiązanie zaproponowane przez Pana BlueDraco z analizą 3 ostatnich stanów.
    Jeszcze raz dzięki wielkie za pomoc.

  • #36 17 Maj 2018 13:09
    nowyARM
    Poziom 27  

    pioter996 napisał:
    W przerwaniu sprawdzam 2 ostatnie stany jeśli są takie same zakładam że przycisk został wciśnięty

    W czasach "bez procesorowych", były układy scalone eliminujące drżenia styków. Dla jednego syku był to szeregowo-równoległy rejestr przesuwny, 8-wejściowa bramka NAND, 8-wejściowa OR i przerzutnik RS. Gdy na wszystkich wyjściach rejestru były jedynki, bramka NAND ustawiała przerzutnik RS, gdy na wszystkich wyjścia były zera, bramka OR kasowała przerzutnik. Kiedy zaimplementowałem taką funkcjonalność w jednym z projektów. Do obsługi klawiatury to przerost formy nad treścią ale do odczytu stanu czujnika gdzie zależy na szybkości i pewności odczytu sposób z 4 czy 8 odczytami jest dobry (np obsługa enkodera).

  • #37 17 Maj 2018 18:06
    krisRaba
    Poziom 25  

    pioter996 napisał:
    Jakieś małe opóźnienie i kolejny raz sprawdzenie stanu

    No przecież po to
    pioter996 napisał:
    Ustawilem przerwanie co 30ms.

    To jest właśnie opóźnienie, którego potrzebujesz :) W kolejnych wywołaniach tego przerwania sprawdzasz sobie stan poprzedni i porównujesz z bieżącym. Jeśli są takie same, to uwzględniasz zmianę.

    Dodano po 8 [minuty]:

    Ewentualnie spróbuj podejścia z filtrami wejść timerów - bardzo przydatny "ficzer". Jeśli oczywiście ten przycisk masz podpięty do pinu "tajmerowego"
    Poszukaj w RM czegoś takiego jak IC1F / IC2F / IC3F itp. Zależnie od tego do którego TIMx_CHy masz podłączony przycisk.
    W te pola wpisujesz sobie "moc" filtracji, tj. przez ile taktów zegara sygnał musi być zgodny, by został uznany za zmianę stanu. Potem od input capture możesz sobie generować przerwanie itp.
    Dodatkowo możesz, jeśli chcesz mierzyć okres między dwoma zboczami opadającymi, przy wystąpieniu pierwszego resetować timer (Slave mode: Reset mode, czy jakoś tak), przy wystąpieniu drugiego masz zliczoną liczbę taktów zegara w CCR1 i licznik ponownie się resetuje...
    Coś mi się kojarzy, że nie wszystkie wejścia timera mogą służyć jako trigger w Reset mode, więc jak wybierzesz coś innego niż TIMx_CH1, to możliwe że będzie trzeba robić jakieś obejścia XORem itp. Więc żeby nie utrudniać sobie życia najlepiej wybrać CH1, który na bank zadziała z tym trybem.

    Nie wiem czy jasno to napisałem, w razie czego mogę doprecyzować, jeśli czegoś nie rozumiesz.

  • #38 17 Maj 2018 19:18
    BlueDraco
    Specjalista - Mikrokontrolery

    pioter996 napisał:
    Dzięki za wszelkie sugestie i dużą dawkę doświadczenia. W przerwaniu sprawdzam 2 ostatnie stany jeśli są takie same zakładam że przycisk został wciśnięty , wszystko funkcjonuje jak powinno. W przyszłości planuje wykorzystać rozwiązanie zaproponowane przez Pana BlueDraco z analizą 3 ostatnich stanów.
    Jeszcze raz dzięki wielkie za pomoc.


    Chyba jednak nie rozumiesz. żeby stwierdzić, że przycisk jest wciśnięty, nie potrzebujesz żadnych przerwań ani odliczania czasu. Przerwanie timer służy do wykrycia, że nastąpiło naciśnięcie - był zwolniony, a jest wciśnięty. Stwierdzasz to wtedy, kiedy w poprzednim przerwaniu był zwolniony, a teraz jest wciśnięty. Sprawdzenie, czy poprzednio był wciśnięty i teraz jest wciśnięty ma taki sam sens, jak pojedyncze sprawdzenie, czy teraz jest wciśnięty.

  • #39 17 Maj 2018 19:39
    krisRaba
    Poziom 25  

    BlueDraco napisał:
    Stwierdzasz to wtedy, kiedy w poprzednim przerwaniu był zwolniony, a teraz jest wciśnięty.

    No właśnie nie do końca ;-) Masz cały czas 1, sprawdzasz, że za pierwszym razem jest 1, po 30ms masz 0... i nie wiesz czy to zakłócenia, czy zmiana stanu. Dopiero gdy po kolejnych 30ms stwierdzisz ponownie 0 przyjmujesz, że stan się faktycznie zmienił.

    Dodano po 2 [minuty]:

    Tak naprawdę masz gdzieś zapisane info, że np. dotąd była 1, a po dwukrotnym wykryciu 0 stwierdzasz, że możesz przepisać nowy stan do swojej odfiltrowanej zmiennej.

  • #40 17 Maj 2018 19:40
    BlueDraco
    Specjalista - Mikrokontrolery

    Jeśli wrócisz do postu #5 i przejrzysz cały wątek ,to zobaczysz, że mowa głównie o wersji bez zakłóceń elektrycznych )tylko drgania styków) - wtedy wystarczy znać 2 stany. Przy zakłóceniach - 3.

  • #42 17 Maj 2018 21:51
    BlueDraco
    Specjalista - Mikrokontrolery

    Zawsze czytamy IDR - w każdej wersji kodu. Czy ktoś pisał o filtracji w tym rozwiązaniu? Tu tylko ignorujemy drgania. "Filtracja", a raczej eliminacja zakłóceń elektrycznych jest przy trzech próbkach.

  • #44 17 Maj 2018 23:07
    BlueDraco
    Specjalista - Mikrokontrolery

    Nic o żadnej pętli nie było. W 95% małych urządzeń (przyciski na płytce uC lub tuż obok) nie ma zakłóceń i nie może ich być.

  • #45 17 Maj 2018 23:15
    nowyARM
    Poziom 27  

    BlueDraco napisał:
    nie ma zakłóceń i nie może ich być.

    ESD też nie będzie?

  • #46 17 Maj 2018 23:56
    BlueDraco
    Specjalista - Mikrokontrolery

    Wewnątrz obudowy?

  • #47 18 Maj 2018 07:15
    krisRaba
    Poziom 25  

    BlueDraco napisał:
    W 95% małych urządzeń (przyciski na płytce uC lub tuż obok) nie ma zakłóceń i nie może ich być.

    Generalnie nie mam dostępu do takich statystyk, więc wierzę na słowo, że aż 95% urządzeń się łapie do wspomnianej przez Ciebie grupy ;-)
    Moje doświadczenie jest inne, ale projektuję urządzenia na granicy przemysłu lub innych zastosowań profesjonalnych.. czyli w grupie pozostałych 5%, gdzie zwieszenie czy fałszywe zadziałanie, to nie tylko facepalm ;-)
    Jeżeli różnica między lepiej a dobrze, to pojedyncze linijki kodu, to dla mnie nie ma uzasadnienia, by robić to słabiej. Ale jeśli ktoś uważa inaczej, to nie mam z tym problemu i droga wolna :-)

  • #48 18 Maj 2018 07:41
    nowyARM
    Poziom 27  

    BlueDraco napisał:
    Wewnątrz obudowy?

    To jak z kondensatorami blokującymi (odsprzęgającymi), w 99% przypadków nie sa potrzebne, dlaczego więc używa sie ich gdzie tylko się da? Dmuchanie na zimne?

    Dodano po 1 [minuty]:

    Moje zdanie podziela niewielka grupa w postaci jednej osoby:
    krisRaba napisał:
    Jeżeli różnica między lepiej a dobrze, to pojedyncze linijki kodu, to dla mnie nie ma uzasadnienia, by robić to słabiej.

    Ale mam nadzieję, że będzie ich więcej.


    W urządzeniu dostępny miałem sygnał cyfrowy (CoinAcceptor) doprowadzony długimi przewodami (ok 1 m). W chwili zadziałania Hoppera na przewodzie z CoinAcceptora miałem krótka szpilkę. W innym przypadku, lampki w klawiaturze multipleksowanej generowały szpilki na przewodach od klawiszy.
    Kolejny przypadek ESD. Dotknięcie ramki wyświetlacza LCD często kończyło sie fałszywymi odczytami klawiatury a nawet zawieszeniem programu.

  • #49 18 Maj 2018 08:44
    BlueDraco
    Specjalista - Mikrokontrolery

    Zgoda, tylko czy w którymś z opisywanych przypadków miałeś do czynienia z całym urządzeniem w jednej, niewielkiej obudowie i przyciskami na płytce uC?
    Ja używam obu technik obsługi przycisków, o których pisałem wyżej. W większości urządzeń pierwszej. W tych, gdzie przyciski są na dłuższych niż 15 cm przewodach lub środowisko jest zakłócone (silniki, przekaźniki) - tej drugiej. Gdybym w urządzeniu zaobserwował jakiekolwiek efekty związane z ESD, zmieniłbym algorytm na drugi, z eliminacją zakłóceń - to tylko dodatkowych 6 linijek w switch() plus 6 żeby był switch() zamiast if(). if() zajmuje 2 linijki i załatwia 95% przypadków. Tu nie chodzi o oszczędność pamięci uC czy klawiatury, tylko oczu programisty przy czytaniu kodu.

  • #50 18 Maj 2018 09:26
    nowyARM
    Poziom 27  

    BlueDraco napisał:
    Zgoda, tylko czy w którymś z opisywanych przypadków miałeś do czynienia z całym urządzeniem w jednej, niewielkiej obudowie i przyciskami na płytce uC?

    Tak. Małe urządzenie w obudowie ok 150x50x150mm. Problemem była ramka LCD. Połączenie jest z masą (na LCD są stosowne zworki) zmniejszyło problem ale nie zlikwidowało. Dodanie osobnego uziemienia (w zasadzie uziemienie było za pośrednictwem komputera przez kabel USB) jeszcze bardziej zmniejszyło problem ale nadal go nie wyeliminowało. Trzeba było zrobić porządną obsługę klawiatury.

    Dodano po 1 [minuty]:

    BlueDraco napisał:
    Tu nie chodzi o oszczędność pamięci uC czy klawiatury, tylko oczu programisty przy czytaniu kodu.

    define można zrobić