Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

AVR - buforowanie LCD, wielowątkowość... Przemyślenia

tehaceole 08 Mar 2012 10:01 4359 11
  • #1 08 Mar 2012 10:01
    tehaceole
    Poziom 28  

    Z zainteresowaniem przeczytałem "zajawkę" Kolegi Mirka odnośnie stosowania buforowania zapisu do LCD alfanumerycznego. Skąd wzięło się moje zainteresowanie?
    Już tłumaczę. Często zdarza się, że po dłuższej pracy urządzenia pod wpływem zakłóceń zewnętrznych na wyświetlaczu pokazują się "duszki", jakieś znaki w przypadkowym miejscu.
    Wyświetlacze zrealizowane na omawianym przez Mirka sterowniku charakteryzują się tym, że po wyświetleniu danego znaku jest on "zatrzaskiwany" na LCD aż do jego nadpisania innym znakiem.
    Stąd często zachodzi konieczność nadmiarowego używania spacji do nadpisywania miejsc, które wg założeń powinny pozostać puste na wyświetlaczu. Istnieje także inny sposób, który omówię później wraz z jego wadami. Zatem zacznijmy nasze rozważania:
    1)
    ustawiam kursor w interesującej mnie pozycji:

    Kod: C
    Zaloguj się, aby zobaczyć kod

    Wypisuję na wyświetlacz tekst:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    Tekst ma długość 9 znaków. I wszystko gra :) Mamy nasze powitanie na wyświetlaczu. Tylko co się stanie w przypadku pojawienia się "duszka" na pozycji np 13 ? Jeżeli tak się złoży, że w programie nie używam pozycji 9-16, to taki "duszek znikąd" będzie sobie siedzieć na wyświetlaczu tak długo, aż nie użyję komendy LCDcls();. Można ten problem wyeliminować stosując dopełnienie spacjami:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    Tylko czy takie podejście ma jakikolwiek sens jeżeli w programie używamy kilkudziesięciu komunikatów? Te "czyszczące duszki" spacje to niesamowite marnotrawienie pamięci mikrokontrolera :(
    2)
    Nieco inaczej sprawa wygląda, gdy w pętli głównej cały czas wyświetlam sobie jakiś napis:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    A przy użyciu np. timera programowego co 100 lub 200ms wywołuję funkcję LCDcls();
    Kod: C
    Zaloguj się, aby zobaczyć kod

    I wszystko niby gra :) Na ekranie nie ma już żadnych śmieci, co więcej: teraz można już dynamicznie zmieniać teksty na wyświetlaczu:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    spowoduje wyswietlenie tekstu "nowy" :) W poprzednim przypadku wyswietlony zostałby "nowyo LCD". No chyba, że wyświetlilibyśmy coś takiego:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    czyli nadpisalibyśmy wcześniejszy tekst spacjami.
    I niby już wszystko gra :) Ten sposób testowałem na wielu różnych wyświetlaczach i spisywał się znakomicie. Ma on jednak jedną istotną wadę:
    wszystko jest ok dopóki patrzymy na wyświetlacz "na wprost". Wystarczy, że zmieni się kąt patrzenia np na 60 stopni... I co? I wtedy widać już jak na dłoni, że wyświetlacz jest cyklicznie czyszczony :(
    I masz babo placek... Niby nic wielkiego, ale niektórym użytkownikom naszego urządzenia coś takiego może się nie spodobać. Pytanie: jak temu zaradzić? Tutaj właśnie odpowiedzią jest buforowanie danych do wyświetlenia w pamięci RAM mikrokontrolera i wyświetlanie dopiero tak przygotowanych danych :)
    3)
    Mirek przygotowuje zaawansowaną bibliotekę, która z punktu widzenia użytkownika będzie "przezroczysta". Oznacza to, że funkcjami wyświetlającymi informacje będziemy posługiwać się tak jak wcześniej robiliśmy to z funkcjami bezpośrednio zapisującymi do LCD. Subtelna różnica polega na tym, że zapis do LCD odbywać się będzie "w tle" - my cały czas operujemy tylko na pamięci RAM.
    Jak to wygląda w praktyce? Ano załóżmy, że na pozycji 1 linii pierwszej chcemy mieć na stałe wyświetlony jakiś komunikat. Zaś na pozycji np. 12 chcemy wyświetlać komunikat dynamiczny, mogący np. migać. Przy wykorzystaniu 2 poprzednich sposobów da się to osiągnąć, jednak będzie to:
    a) pamięciożerne (nadpisywanie spacjami)
    b) powodować może migotanie całego ekranu

    Sposób Mirka pozwala zrealizować takie "animacje" bez najmniejszego problemu :) W ramach ćwiczeń napisałem naprędce do bólu prosty i nieefektywny kod:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    Kod absolutnie nie jest zoptymalizowany ani zbytnio zabezpieczony przed przekroczeniem zakresu tablicy, miał jedynie pokazać ideę wyświetlania buforowanego.
    w głównej pętli programu na stałe wywoływane jest coś takiego:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    i teraz z użyciem timera programowego powoduję miganie tekstu:
    Kod: C
    Zaloguj się, aby zobaczyć kod

    Przy czym dalsza część komunikatów wyświetlanych na LCD nie ulega jakimkolwiek zmianom, przekłamaniom itp. Nie występuje także efekt "duszków" :)
    Rzecz jasna użyłem tutaj spacji do oczyszczania ekranu, jednak już we właściwej bibliotece obsługi będą do tego użyte pętle powodujące, że cała zawartość bufora różna od tej którą do niego zapisujemy będzie czyszczona. Podany powyżej przepis pozwolił mi na wspaniałe uzyskanie efektu migania fragmentu tekstu z jednoczesnym brakiem problemów z tekstem wyświetlanym "statycznie".


    IMHO sposób Mirka jest nie tyle co wart uwagi - jest on wręcz niezbędny w zaawansowanych aplikacjach. Należy tu jednak mieć na uwadze przesiadkę ze sposobu liniowego programowania na programowanie "pseudo wielowątkowe". Taki tryb programowania stosowany jest powszechnie we wszelkiej maści sterownikach PLC. Przykładem niech będzie funkcja opóźnionego załączenia: w programowaniu liniowym funkcja taka na dłuzszy czas zablokowałaby przetwarzanie reszty programu. W sterowniku PLC deklaruję gotowy blok takiej funkcji, inicjuję ją sygnałem wejściowym a reszta mnie nie interesuje. Program się przetwarza a po jakimś czasie otrzymuję na wyjściu bloku sygnał o zakończeniu odmierzania czasu. W mikrokontrolerze niestety musimy samodzielnie opracować tego typu funkcję (jak zresztą wszystkie inne funkcje działające "wątkowo"). Zatem potrzebna jest zmiana przyzwyczajeń programistycznych, niektórych nawyków. Przede wszystkim potrzebna jest permanentna zmiana podejścia do "ciała" programu. W efekcie możliwe są do uzyskania zarówno efekty prezentowane w książce Mirka (rozdział "wprowadzenie do systemów czasu rzeczywistego") jak i wiele innych, znacznie bardziej zaawansowanych.
    Mam nadzieję, że moje przydługie opracowanie będzie zachętą dla wielu malkontentów nazywających takie sposoby "przerostem formy nad treścią"... Takim przerostem jest propozycja zastosowania FreeRTOSa dla przysłowiowego "mrygania diodą": http://www.elektroda.pl/rtvforum/viewtopic.php?p=10634041#10634041 Opisywane w tej dyskusji zagadnienie jest tak banalnie proste do wykonania, że aż głupio tutaj nawet wspominać o RTOS :) Jednak wielu programistów przyzwyczajonych do programowania liniowego nie widzi niestety innego wyjścia z sytuacji...

    Konkludując: programowanie "wątkowe" jest znacznie trudniejsze od liniowego. Jednak warto po nie sięgnąć ze względu na korzyści jakie daje.

    Zdaję sobie sprawę, że ten temat może wywołać "burzę" wśród zwolenników i przeciwników takiego podejścia. Chciałbym jednak, aby dyskusja przerodziła się we wzajemną wymianę doświadczeń, zarówno tych pozytywnych jak i negatywnych. Sam na codzień zawodowo zajmuję się programowaniem sterowników przemysłowych w języku ST. Tam "multiwątkowość" to chleb powszedni. Jednak, jak się okazuje, przy odpowiednim podejściu do zagadnienia z naszych poczciwych 8-io bitowych AVRków też można "wycisnąć" znacznie więcej niż programując liniowo. Kwestia dobrego zrozumienia tematu :) Aktualnie cały czas uczę się języka C i mikrokontrolerów AVR, jednak jestem już na taki etapie (dodatkowo doświadczenia z pracy z systemami Real Time), że sam zauważam potencjał drzemiący w odpowiednim podejściu do programowania AVR.

    Zapraszam Kolegów do dyskusji :)

    PS: temat ten to w żadnym wypadku nie jest reklama Kolegi Mirekk36 ani firmy którą reprezentuje. Proszę zatem o darowanie sobie tekstów w stylu "promujesz kogoś" itp. Recenzję książek Koleków Mirekk36 i tmf można przeczytać tutaj.

  • #2 08 Mar 2012 10:46
    dondu
    Moderator Mikrokontrolery Projektowanie

    Sprawa jest oczywista:

    tehaceole napisał:
    Konkludując: programowanie "wątkowe" jest znacznie trudniejsze od liniowego. Jednak warto po nie sięgnąć ze względu na korzyści jakie daje.
    ...
    Zapraszam Kolegów do dyskusji :)

    Do dyskusji o czym? O wyższości programowania liniowego nad pseudowielowątkowym? To zależy od projektu jaki masz do zrobieni, czasu jaki możesz na to przeznaczyć i tego co Ci się bardziej opłaca ... miliony przypadków, każdy inny ... nieskończona liczba pomysłów na realizację = niekończąca się dyskusja, w której każdy ma swoje racje i swój KOMPROMIS :)

    ... co Mirek fajnie podsumował:

    Mirekk36 napisał:
    Oczywiście nie mówię tu o aplikacjach, które po prostu wyświetlają non stop na ekranie to samo np datę, godzinę i temperaturę, bo realizacja takiego celu jest tak banalna, że aż szkoda byłoby poświęcać czas na jej opisywanie.


    Sposób na wyświetlacz, to jak Mirek napisał:

    Mirekk36 napisał:
    Tylko proszę mnie źle nie zrozumieć, nie jest to żadne odkrycie!
    Takie sposoby są bowiem wykorzystywane już przez wielu programistów ...

    każdy bardziej rozgarnięty programista niekoniecznie czytający książki dot algorytmów, prędzej czy później sam wpada na taki pomysł i tysiące innych podobnych.

    Ale skoro chcesz porozmawiać to:

    Ja osobiście prawie każdy program realizuję z wykorzystaniem pseudowielowątkowości, maksymalnie wykorzystując sprzęt i usypiając mikrokontroler kiedy tylko "rozdam robotę" do maksymalnego możliwego w danym momencie trybu. Takie podejście daje mi ciągłą praktykę, przez co zbudowanie skomplikowanego programu jest bardzo proste. Ale oczywiście w pewnych przypadkach pisanie liniowe dałoby mi oszczędność czasu.

    Jak się tego szybko nauczyć?
    Zacząć budować urządzenia bateryjne, stosując możliwie najmniejszą pojemność baterii - to zmusza, do kombinowania na wszelkie sposoby, co zrobić by jak najszybciej uśpić mikrokontroler, a to oznacza, że pseudo wielowątkowość musisz stosować, bo nie masz alternatywy. Do tego jeszcze operowanie zmianami prędkości zegara w czasie pracy mikrokontrolera, główkowanie jak oszczędnie wykorzystać bebechy - a czas ucieka ... ale zysk jest :)

    I nagle okazuje się, że np. I²C trzeba robić na przerwaniach, a pulling czegokolwiek to technika zakazana ... tematy nie dla początkujących, ale warto.

    -------------------------------
    tehaceole napisał:
    PS: temat ten to w żadnym wypadku nie jest reklama Kolegi Mirekk36 ani firmy którą reprezentuje.
    Proszę zatem o darowanie sobie tekstów w stylu "promujesz kogoś" itp.

    Wskazywanie źródeł dobrych rozwiązań, nie spotka się z krytyką, przynajmniej z mojej strony :)

  • #3 08 Mar 2012 10:48
    Jado_one
    Poziom 22  

    Witam,

    Ja to nazywam programowaniem współbieżnym.
    Wymaga to jednak spojrzenia na sposób pisania programu "od odwrotnej strony", co nie jest takie łatwe na początku. (własciwie, to nawet wszystko buntuje się przeciw takiemu podejsciu do tematu)
    Pewne rzeczy dzieją się w pewnych miejscach programu niejako "samoistnie", a my "puszczamy w ruch" pewne fragmenty tych zasobów z zupełnie innego miejsca.
    Na przykład mamy pętlę programową odpowiadającą tylko za wyswietlanie, inna odpowiada za obsługę klawiatury, a jeszcze inna za operacje I2C.
    Pętle te "kręcą się" cały czas (bo są w pętli głównej umieszczone)

    Np. tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Wystąpienie zdarzenia np. w pętli obsługi klawiatury (naciśnięcie klawisza), powoduje ustawienie pewnych stanów i/lub flag, które powodują np. że w pętli wyświetlania wykona się operacja wysyłania danych na wyświetlacz LCD.
    Po wykonaniu tego zadania pętla wyswietlania wraca do swojego podstawowego stanu idle.

    Głównym celem takiego podejścia do programowania jest eliminacja martwych pętli oczekiwania (np. while) - nazywam to stanem "dynamicznego zatrzymania".

    Ceną za taką współbieżność jest jednak pewien narzut czasowy przeznaczony na sprawdzanie flag, zezwoleń, maszyn stanów itp.....
    Podobnie jak RTOS traci czas i zasoby na przełączanie kontekstów.

    Tak czy inaczej taki program jest trudniej całkowicie zawiesić - jakaś część zawsze się wykonuje, co można wykorzystać do "odwieszenia" czyli przywrócenia podstawowych stanów w pozostałych pętlach.

    Jednak minusem (zależy jak kto jeszcze na to patrzy - może czasem to plus) jest to, że w zasadzie nie można korzystać z gotowych bibliotek jakie można znaleźć w internecie. Można tylko wykorzystać fragmenty (może do analizy zasady działania) i użyć ich w swoim programie.
    (Ciekawe czy RTOS na to pozwala?)

  • #4 08 Mar 2012 11:08
    tehaceole
    Poziom 28  

    dondu - fajnie mnie podsumowałeś :) I muszę przyznać Ci rację. Co innego na stałe wyświetlać jakiś tekst czy np. godzinę. Jednak co innego, gdy LCD ma zostać użyty do jakichś zaawansowanych interakcji z użytkownikiem, jakichś dynamicznych pseudo animacji itp. Tu może nie tyle chodzi o temat wątkowości obsługi LCD co o buforowanie danych przed ich wyświetleniem.

    Jado_one - pokazałeś w tym fragmencie funkcji main kwintesencję "pseudowielowątkowości". W językach programowania PLC występuje coś takiego jak język SFC - czysta implementacja maszyny stanów operująca na akcjach i tranzycjach. W przypadku maszyn stanu, automatów sekwencyjnych na uk z jakich rozwiązań korzystasz? Instrukcja switch z parametrem określającym numer stanu? Ify? Warto ten temat pociągnąć, gdyż z pewnością będzie pomocny dla wielu początkujących :)

  • #5 08 Mar 2012 11:18
    Jado_one
    Poziom 22  

    Switch, case i zmienna określająca stan maszyny stanów, różnego rodzaju flagi pomocnicze wskazujące czy np. odbywa się jakaś operacja dostępu do zasobów, itp...
    Np. obsługa menus (czyli reakcji na naciśnięcie klawisza) wygląda tak: (fragment)

    Kod: c
    Zaloguj się, aby zobaczyć kod


    PS. Teraz muszę wyjść, więc przez kilka godzin dyskusja musi odbywać się beze mnie :-)
    Powodzenia!

  • #6 08 Mar 2012 11:41
    dondu
    Moderator Mikrokontrolery Projektowanie

    tehaceole napisał:
    dondu - fajnie mnie podsumowałeś :)

    tak na wszelki wypadek: Nie nie miałem żadnego negatywnego nastawienia :)
    w przeciwieństwie do kol Mirka:

    Mirekk36 napisał:
    .... tymczasem ja powiem jedno, zwykle to co niezrozumiałe to wywołuje czasem na takich forach skrajne emocje.
    A ci fachowcy z koziej łaski mało mieli do czynienia z takimi zagadnieniami.

    ... szkoda, bo artykuł choć bez przykładowych kodów, to jednak daje początkującym pojęcie, jak można z LCD działać o wiele sprawniej, ale niesmak pozostaje ... więcej szacunku dla innych kol. Mirku - ta sama treść, ale inne słowa - naprawdę warto.

    tehaceole napisał:
    Tu może nie tyle chodzi o temat wątkowości obsługi LCD co o buforowanie danych przed ich wyświetleniem.

    Twoja konkluzja dot. wątkowości, stąd o niej przede wszystkim pisałem, a co do techniki LCD - stosować, gdy się to opłaci i pamiętać o słowie kompromis.

  • #7 08 Mar 2012 12:23
    gaskoin
    Poziom 38  

    Heh jak zwykle mirku - wypowiedź wyrwana z kontekstu. Skoro ja jestem fachowcem z koziej łaski na podstawie tamtej wypowiedzi, to dla mnie ktoś kto jej nie zrozumiał jest po prostu kapuścianym głąbem :)

    Podpowiem - posty się czyta od góry do dołu. Wytłumaczę też swojego posta, dla tych, którzy mają z tym jak widzę problemy:

    Cytat:
    Skoro programy robią to samo, tylko dla innych wejść to możesz napisać tylko jedną funkcję dla której parametrem będzie np numer pompy. Wtedy program zajmie połowę z tego co masz teraz. Można się zainteresować FreeRTOSem żeby otrzymać multitasking, ale na potrzebę tylko dwóch pomp jest to zbędny wysiłek


    Pierwsze dwa zdania, które są pogrubione, są propozycją rozwiązania dla autora.
    Niepogrubione zdanie jest propozycją, którą warto się zainteresować, gdyby chciało się otrzymać multitasking, ale co mamy dalej w zdaniu ? Wyjaśnienie, że dla zadania autora jest to bez sensu.

    Ktoś mi wytłumaczy, gdzie zaproponowałem użycie RTOSa ? Bo ja tam tego nie widzę.

    Mirekk36 napisał:

    A ci fachowcy z koziej łaski mało mieli do czynienia z takimi zagadnieniami.


    To fakt mało mieli, bo niektórzy już wyświetlacze alfanumeryczne porzucili dawno temu i zajęli się czymś innymi niż miganie diodami i robieniem zegarków.

    Co do tego co napisałem wyżej, polecam dla Ciebie książkę AVR - buforowanie LCD, wielowątkowość... Przemyślenia

  • #8 08 Mar 2012 12:38
    mirekk36
    Poziom 42  

    gaskoin napisał:
    Heh jak zwykle mirku - wypowiedź wyrwana z kontekstu. Skoro ja jestem fachowcem z koziej łaski na podstawie tamtej wypowiedzi, to dla mnie ktoś kto jej nie zrozumiał jest po prostu kapuścianym głąbem :)


    Dziękuję, ja tylko zwrócę twoją uwagę, że moja wypowiedź o fachowcach z koziej łaski nie dotyczyła ciebie a całkiem innego tematu i już nie będę go przywoływał żeby nie jątrzyć na tym forum. (a jeśli poczułeś się dotknięty tą wypowiedzią to przepraszam, zapewniam jeszcze raz, że to nie do ciebie i nie w tym kontekście były te słowa, które wspaniały dondu wyrywa z kontekstu i jak zwykle szuka zaczepki tu na tym forum)

    Ten post który cytuję na swoim blogu ma tylko pokazać jedno - że na pytanie o poradę jak wykonywać niezależnie dwie funkcje pada w ogóle FreeRTOS ! bo temu nie zaprzeczysz - ale widać w nim przecież, że dopisałeś na końcu że w tym przypadku nawet nie będzie potrzebny.... Jednak dla kogoś początkującego kontekst wypowiedzi może sugerować iż na końcu zostanie mu tylko ten FreeRTOS, jeśli sobie nie poradzi.

    Dodano po 4 [minuty]:

    gaskoin napisał:

    To fakt mało mieli, bo niektórzy już wyświetlacze alfanumeryczne porzucili dawno temu i zajęli się czymś innymi niż miganie diodami i robieniem zegarków.


    No widzisz a ja cały czas dłubię zegarki i programy do migania diodami na 8-bitowcach, i nie mogę się niczym innym zająć ;) .... Jak widzisz ja nie jestem pewnie tak bystry i sprytny jak ty.... ale cóż nie każdy musi być taki sam.

    gaskoin napisał:
    Co do tego co napisałem wyżej, polecam dla Ciebie książkę .....


    Dziękuję bardzo, chętnie skorzystam ;) człowiek uczy się całe życie.

  • #9 08 Mar 2012 20:07
    Jado_one
    Poziom 22  

    Widzę, że koledzy rozmyli trochę wątek za sprawą wypowiedzi emocjonalnych, ale może spróbujmy wrócić do tematu....

    Tak naprawdę najważniejszą rzeczą podczas pisania programów - niezależnie czy będą napisane liniowo, wielowątkowo, czy z wykorzystaniem RTOS'u jest ich -planowanie.
    Trzeba wiedzieć (zastanowić się) co się chce osiągnąć, dokonać przeglądu swojej wiedzy, sposobów jakie mamy już przećwiczone, a co musimy wykonać pierwszy raz, itp.... Do tego dochodzi wybór mikrokontrolera ze względu na jego szybkość, zasoby sprzętowe, cenę, itd....

    Jeżeli mamy do przećwiczenia jakiś nowy temat, to koniecznie jest dokładne zapoznanie się z nim - czytamy reference manual, przeglądamy opisy w internecie, w książkach o mikroprocesorach - co tylko uda nam się znaleźć na ten temat.
    Poszukujemy w sieci opisów podobnych projektów z wykorzystaniem interesujących nas zasobów sprzętowych, czytamy wątki na Elektrodzie dotyczące tego tematu, itp, itd...
    Ściągamy z sieci wszelkie możliwe przykłady programów na interesujący nas temat i podglądamy jak inni poradzili sobie z interesującym nas problemem....itd...

    Tak zorganizowane przygotowanie do problemu zabiera może dużo czasu, ale jest to tylko pozorna strata, gdyż później, zaopatrzeni we wcześniej zdobytą wiedzę szybko radzimy sobie z rozpracowywaniem problemu i unikamy trudnych do wykrycia później błędów, idąc prostą ścieżką do celu.

    Nie należy się też zbytnio śpieszyć z podjęciem ostatecznej decyzji na temat wyboru konkretnej ścieżki postępowania, tylko dać sobie np. dzień czasu na "przetrawienie problemu" - w tym czasie mózg, mimo pozornego oddalenia do tematu, nadal działa i mamy szansę na "olśnienie" czyli odkrycie jeszcze lepszego, prostszego i genialnego pomysłu niż ten początkowy.
    Czasami zbyt przeciążony mózg "zamula się" i trzeba mu trochę oddechu aby odzyskać jasność myślenia i oceniania sytuacji.

    Postępując w ten sposób unikamy wielu nieprzyjemnych błędów, które choć może uczą w konsekwencji, to jednak działają bardzo zniechęcająco na początkującego programistę/konstruktora.

    Starajmy się zebrać i wykorzystać wszelkie możliwe atuty zanim przystąpimy do gry ;-)

  • #10 09 Mar 2012 07:33
    tehaceole
    Poziom 28  

    Doskonale powiedziane :) Najważniejsze jest PLANOWANIE. Jako przykład niefrasobliwości młodego programisty, który po przesiadce na AVR zachłysnął się możliwościami języka C bez pełnego jego zrozumienia umieszczam poniżej kod maszyny stanów realizującej komunikację sterownik - PC.

    Kod: C
    Zaloguj się, aby zobaczyć kod


    Kod ten poczyniłem już DAAAWNO temu... Nie pamiętam już czemu zdecydowałem się na dekodowanie transmisji w locie zamiast z wykorzystaniem powszechnie znanego mechanizmu buforowania. Jednak jak na dłoni widać, że pisząc program popełniłem MASĘ błędów zaczynając od umieszczenia tak olbrzymiej procedury w obsłudze przerwania, aż po wiele innych, mniejszych :)
    Kod co prawda działał, BA! nawet ok 120 warningow mu nie przeszkadzało :D:D:D W sieć spięte miałem 30 sterowników, które odpytywała moja aplikacja na PC. Tylko co z tego, że działało mi to na stole? :) Teoretycznie to to był właściwie jakiś cud, że to wogóle działało.

    Czemu to przytoczyłem? Ano temu, że wtedy nawet do łowy mi nie przyszło, że AVR można programować "wątkowo". Najdłuższe opóźnienie w moim liniowym programie sięgało 5 sekund !!!! :) Cóż, człowiek uczy się całe życie... Teraz ten sam program nie dość, że napisałbym znacznie zwięźlej, to jeszcze uniknąłbym masy błędów które wtedy popełniłem.
    Planowanie tu było... Program miał działać i DZIAŁAŁ zgodnie z założeniami. Jednak tu kłania się wypowiedź mojego poprzednika - pisząc program należy uwzględnić przede wszystkim swoje własne umiejętności.... :P

  • #12 09 Mar 2012 11:22
    Jado_one
    Poziom 22  

    tehaceole napisał:

    Czemu to przytoczyłem? Ano temu, że wtedy nawet do łowy mi nie przyszło, że AVR można programować "wątkowo". "


    Bo brak jest literatury stricte "mikrokontrolerowej" traktującej o tym temacie.

    Dotyczącej struktury programu, jak i zarządzania czasem w programie - co w systemach czasu rzeczywistego jakimi są sterowniki na mikrokontrolerach, jest rzeczą b. ważną.

    Co prawda ostatnio autorzy książek o mikrokontrolerach oprócz pisania o rejestrach, SPI, kompilacji, itp, zaczynają poświęcać trochę uwagi zarządzaniu czasem (jak kolega Mirek np.), ale na razie jest to tylko dodatek do głównego tematu książki.


    Jeśli chodzi o "duże książki" to jest np. taka książka pt: "Podstawy programowania współbieżnego i rozproszonego" - autor M. Ben-Ari, wydana przez WNT w 1996 roku. Dotyczy ona co prawda systemów PC'towych (lub większych?), ale sporo zasad i zaleceń jakie można tam wyczytać dobrze pasuje do systemów opartych na mikrokontrolerach.

    edit: Widzę, że ta książka jest wciąż do kupienia - nowe wydanie. Np. tutaj: http://www.naukowa.pl/Informatyka,22kt/Podsta...owania-wspolbieznego-i-rozproszonego,376794kc


    Są też ciekawe strony poświęcone programowaniu określanemu jako "event driven programming" np. tutaj: http://www.state-machine.com/index.php

    Myślę jednak, że są to tematy, które zaczynają interesować osobę programującą, dopiero po przekroczeniu jakiegoś progu wiedzy, doświadczenia, umiejętności czyli opanowaniu podstaw. Co nie znaczy, że nie należy zaczynać sygnalizować istnienia tego tematu już u podstaw :-)

 
Promocja -20%
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
tme