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.

Struktura programu avr - C

krdwx 02 Sty 2012 15:49 2138 11
  • #1 02 Sty 2012 15:49
    krdwx
    Poziom 7  

    Witam. Zaczynam programować w języku C dla uC. Mam pytanie odnośnie struktury kodu.
    Na przykład chcę napisać oprogramowanie dla termometru z prostym menu, który będzie wyświetlał na ekranie LCD aktualną temperaturę i zapalał diody w zależności od temperatury.
    Ja to rozumiem tak:
    - przerwanie timera0: aktualizuj temperaturę, wykonaj obliczenia, jeśli zajdzie potrzeba zapal/zgaś diodę
    - przerwanie timera1: aktualizuj ekran glowny
    - przerwanie int z przycisku: poruszaj się po menu
    - w pętli głównej nie rób nic ?

    I mam pytanie: to projektowanie jest poprawne? Proszę o rady i wskazówki

    0 11
  • #2 02 Sty 2012 16:00
    korneliusz
    Poziom 16  

    W pętli głównej obsługuj przycisk.
    Przynajmniej mnie zawsze uczono, żeby unikać obsługi mechanicznych przycisków przez przerwania, aczkolwiek Twoje rozwiązanie jak najbardziej będzie działać prawidłowo.

    0
  • #3 02 Sty 2012 16:26
    tadzik85
    Poziom 38  

    W pętli głównej masz robić wszystko. Przerwania mają ustawiać ci jedynie odpowiednie flagi.

    0
  • #4 02 Sty 2012 16:26
    mirekk36
    Poziom 42  

    Niestety to zdecydowanie złe podejście :( Z tego co piszesz już widać pierwszy poważny błąd, że chcesz zrobić wyświetlanie na LCD w przerwaniach.

    W zasadzie to większość z tych rzeczy można robić w pętli głównej a przerwaniami się tylko wspomagać aby wykonywać w tejże pętli różne funkcje w odpowiednim czasie.

    0
  • #5 02 Sty 2012 16:37
    tmf
    Moderator Mikrokontrolery Projektowanie

    IMHO podejście typu wszystko robić w pętli głównej, a w przerwaniach flagi, jak i podejście dokładnie odwrotne jest błędne. Jak we wszystkim trzeba znaleźć złoty środek.
    Twoje podejście z przerwaniami jest IMHO trochę skomplikowane - obsługa poszczególnych elementów jest długa, w dodatku wprowadzisz współbieżność programu, co dodatkowo utrudni jego napisanie. Tak naprawdę moim zdaniem w przerwaniu warto umieścić obsługę klawiszy i wskaźnik do wyświetlanego menu. Jeśli chcesz się pobawić to można umieścić obsługę 1-wire ( o ile z tego korzystasz i sprytnie zrobisz obsługę OW sprzętowo), jeśli korzystasz z czujnika analogowego (np. LM35) to odczyt w przerwaniu jest zupełnie na miejscu. Przy takim podejściu w pętli głównej masz ledwie odświeżanie ekranu (wtedy kiedy trzeba).

    0
  • #7 03 Sty 2012 09:05
    markosik20
    Poziom 33  

    Hmm, nie wiem dlaczego koledzy tak bardzo odradzacie obsługę LCD w przerwaniach.
    Ja to mam tak zrobione w wielu projektach. Przerwanie do obsługi LCD pojawia się co określony czas (czas potrzebny na zatrzaśnięcie danych do LCD), w przerwaniu "lecą" dane z bufora do LCD bez żadnych opóźnień. W pętli głównej wysłanie danych do LCD wiąże się z zapisem danych do bufora.

    0
  • #8 03 Sty 2012 09:20
    tmf
    Moderator Mikrokontrolery Projektowanie

    No to sam sobie odpowiedziałeś. Czy uważasz, że tworzenie takich buforów, zadbanie o odpowiedni dostęp do nich (coś w stylu mutexów) itd. to coś dla początkującego?
    W dodatku, uważam, że żeby coś komplikować to trzeba coś w zamian dostać. W sytuacji w której dostęp do LCD odbywa się tylko w jednym miejscu programu (nie jest dzielony pomiędzy konkurencyjnie wywoływane procedury, np. w pętli głównej i przerwaniach) jest to komplikacja nie mająca sensu.

    0
  • #9 03 Sty 2012 09:40
    mirekk36
    Poziom 42  

    markosik20 napisał:
    Hmm, nie wiem dlaczego koledzy tak bardzo odradzacie obsługę LCD w przerwaniach.
    Ja to mam tak zrobione w wielu projektach. Przerwanie do obsługi LCD pojawia się co określony czas (czas potrzebny na zatrzaśnięcie danych do LCD), w przerwaniu "lecą" dane z bufora do LCD bez żadnych opóźnień. W pętli głównej wysłanie danych do LCD wiąże się z zapisem danych do bufora.


    Widzisz, ja np robię często podobnie ale nie tak samo ;) .... tzn idea jest słuszna, żeby stworzyć sobie dodatkowe buforowanie w RAM dla LCD. I żeby wszystkie funkcje zamiast wyświetlać na LCD to żeby po prostu pisały do tego bufora (czy buforów bo można mieć ich kilka). W zamian za to np co 20-50ms cyklicznie wyrzucać cały bufor w najprostszy sposób na LCD. Gdzie w grę wchodzą tylko 4 rozkazy dla LCD - w uproszczeniu:

    1. Locate(0,0)
    2. LCD_STR( Linia1 )
    3. Locate(1,0)
    4. LCD_STR( Linia2 )

    Dzięki temu można uzyskać nawet płynne animacje i w ogóle w łatwy sposób mnóstwo efektów nie mówiąc już o możliwościach budowania fajnego MENU na LCD w najróżniejszy sposób i to jeszcze okraszonego animacjami na takim nawet alfanumerycznym LCD.

    Tylko u mnie jest taka różnica, że zamiast wyrzucać te bufory z RAM do LCD w przerwaniu - to także robię to w pętli głównej ale dokładnie co określony czas np 20ms a czas ten jest oparty właśnie o Timer sprzętowy. Owszem może się zdarzyć, że w związku z innymi zadaniami pętli głównej czas ten może raz wynieść 20ms a innym razem 21ms - ale co to za różnica ?

    Za to na pewno - w żadnym przerwaniu nie mam wyświetlania na LCD bo nawet przy sprawdzaniu BUSY_FLAG to jak dla mnie często zajmuje to i tak za dużo czasu i mogłoby zakłócać inne ważne procesy, które potrzebują znacznie większej i dokładniejszej rozdzielczości czasowej.

    ..... oczywiście, jak napisał tmf wyżej, nie ma co się dziwić, że wszyscy są przeciwko temu jeśli pytają o to początkujące osoby. Bo one najczęściej w takim przerwaniu nawet korzystają z takich rozkazów do LCD jak CLS czy HOME, co przy podłączonym pinie RW do GND (bez sprawdzania BF) - sam sobie zdajesz sprawę ile czasu to potrafi hmm musi zająć ?

    Poniżej przykład - filmik z działania na LCD i MENU zbudowanego w oparciu o tę metodę. A jest ona bardzo słuszna - bo przecież jako podstawę wykorzystują ją takie programy jak np "LCD Smartie" - a każdy wie jakie tam są fajne efekty robione - właśnie DOKŁADNIE tą metodą.

    https://www.elektroda.pl/rtvforum/topic1430008.html

    (filmik na dole pierwszego postu)

    0
  • #10 03 Sty 2012 13:12
    tmf
    Moderator Mikrokontrolery Projektowanie

    Jeśli idziemy tą drogą to poszedłbym ciut dalej - tak też zrozumiałem wypowiedź makrosika. Zamiast buforować dane całego wyświetlacza, buforujemy wysyłane komendy. Czyli np. wyświetl tekst. Procedura w przerwaniu je po prostu po kolei wysyła do LCD. Jeśli ilość uaktualnień LCD nie jest duża to takie podejście jest efektywniejsze - uaktualnienie nastąpi wyłącznie wtedy, kiedy coś na ekranie się zmieniło, w dodatku nie zmieniamy obszarów, które zmianie nie uległy. Ale tak, czy siak to nie jest zabawa dla nowicjuszy.

    0
  • #11 03 Sty 2012 17:56
    krdwx
    Poziom 7  

    Dziękuje wszystkim za pomoc.
    Mam jeszcze jedno pytanie: czy jest w atmedze16 opcja odczytywania czasu np od uruchomienia uC czy trzeba samemu podłączyć kwarc zegarkowy i odmierzać czas? Szukałem po dokumentacji, ale nie zalazłem.
    Potrzebuje tej funkcji np do odgrywania dźwięku przez x sekund.

    0