Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Kategoria: Akumulatorki / Baterie / Ładowarki
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Wykrywanie zmian stanu potru Atmega16 w BASCOM

slaweek_22 20 Wrz 2007 19:31
  • #1 20 Wrz 2007 19:31
    slaweek_22
    Poziom 16  

    Wutam!
    Mam pewien problem z realizacją programową wykrywania zmiany stanu na porcie mikrokontrolera Atmega16. Do programowania używam BASCOM_AVR.
    Program odpytuje port wejściowy czyjników w nieskonczonej pętli, po wykryciu zmiany któregoś z pinów portu ma uruchomic opowiedną procedurę. Poniżej fragment kodu. Problem jest w tym iż nie każda zmiana stanu jest wykrywana, wykrywane jest jakieś 80% zmian na tym porcie, skuteczność musi być w tym wypadku 100%, Czy w dobry sposób zrealizowałem sprawdzanei portu?Do badania pracy układu używam symulatora więc to też moze być powodem tego problemu. Czy jest moze jakiś lepszy sposób jego realizacji. Myślałem nad zrobieniem wykrywaczy zbocza opadającego i narastającego na każdym z wejść ale to zikszyłoby znacznie koszt budowy i skomplikowało układ. Proszę o przykład realizacjii programowej wykrywacza zmiany stanu jedego z wyprowadzen (wszystkie czujniki są podłączone pod jejen port mikrokontrolera)
    Z góry dziękuję za pomoc.


    ...
    Do


    Port1 = Pina
    Waitms 75
    Port2 = Pina




    If Port1 = Port2 Then
    Zmiana = 0
    Else
    Zmiana = 1
    End If

    ....

    loop

  • #2 20 Wrz 2007 19:38
    Mad Bekon
    Poziom 23  

    Code:
    Do
    

    If Port1 != Pina Then
    begin
    Port1 = Pina
    Zmiana = 1
    end

    endif

    loop

    skuteczność psuło Ci opóźnienie czasowe.
    Wyobraź sobie co się stanie, kiedy stan pinu zmieni się po wykonaniu polecenia Port2=Pina...

    Pewniejszym sposobem jest skorzystanie z przerwania wyzwalanego zmianą stanu.

  • #3 21 Wrz 2007 14:21
    Wodusek
    Poziom 10  

    Moim zdaniem program miałeś dobry zmniejsz tylko 75ms na 25 ms

    a błędy są w symulatorze... Powie tak kiedy przeprowadzam symulacje w programie BASCOM AVR w symulatorze on nie widzi mi wszystkich zmian na portach.. które w realnym układzie są dostrzegane... Symulator jest poprostu do kitu... i tyle :)

  • #4 22 Wrz 2007 13:08
    Mad Bekon
    Poziom 23  

    Ale po Co? W ten sposób i tak nie masz maksymalnej możliwej pewności wykrycia zmiany stanu, a w dodatku deklarujesz jedną zmienną nie wiadomo po co...

  • #5 22 Wrz 2007 14:08
    Wodusek
    Poziom 10  

    niech spróbuje;) tylko mówię że Bascom w symulatorze robi błędy i nie widzi zmian :)

    chodź uważam że Twój pomysł jest bardzo dobry ... :) ale jego tez był dobry:)

  • Pomocny post
    #6 22 Wrz 2007 14:23
    Mad Bekon
    Poziom 23  

    Owszem, pewnie po zmianie czasu działałoby lepiej.
    Ale wiesz, warto uczyć się na doświadczeniu innych. Mnie kiedyś ten sposób pokazał na elektrodzie, przekazuję go więc dalej.

  • #7 22 Wrz 2007 19:06
    slaweek_22
    Poziom 16  

    Witam! Przetestowałem sposób Mad Bekon'a i działa bardzo dobrze 100% skuteczność. Symuluję w Proteusie ISIS, dal sprawdzenia dałem licznik zmian więc o przypadku nie mogło być mowy. Próbowałem ze zmianą czasu już wczesniej przed napisaniem posta, ale zmiana nie dawała pełnej skuteczności. Dziękuje za poradę sposób Mad Bekon'a działa w 100%.

  • #8 24 Wrz 2007 10:14
    luap
    Poziom 11  

    Witam , ja zmianę stanu linii portu zrobiłem w ten sposób:
    X = pind.1
    waitms 20
    Y = pind.1
    Zmiana = X Xor Y
    gdy Zmiana = 1 ' wtedy występuje zmiana stanu
    To dziła zawsze 100% skuteczności

    pozdrawiam.

  • #9 24 Wrz 2007 11:25
    Mad Bekon
    Poziom 23  

    Zalew jam Cię, że impulsu np o długości 10ms może nie wykrywać w 100% skuteczności.
    A nawet jeśli się upierać już przy tym opóźnieniu, to czemu nie zrobić tak:

    Code:

    X = pind.1
    waitms 20
    Zmiana = X Xor pind.1

  • #10 26 Wrz 2007 11:31
    luap
    Poziom 11  

    Witam ponownie
    Mnie chodziło o idee , więc konkretne wartości opóźnienia to drugo planowa sprawa.
    Opóźnienie trzeba odpwiednio dobrać w zależności od spodziewanego czasu trwania zmiany, a zaproponowane uproszczenie zapisu oczywiście jest OK.