Nie wiem czy Wy też tak macie. Jak bym się nie starał pisać kod zwięźle, przejrzyście to w pewnym momencie dochodzę do sytuacji, że aż nieprzyjemnie mi gdy staram się analizować własny kod, szczególnie ze względu na zmienne globalne etc. Oczywiście używam AVR GCC.
Brakuje mi strasznie możliwości programowania obiektowego. Tu pytanie do Was, czy istnieje możliwość programowania obiektowego procesorów AVR. Czy istnieje możliwość nie deklarowania dziesiątek zmiennych globalnych, żeby w sposób efektywny wykorzystywać przerwania?
Jakie są alternatywne i dobre kompilatory do AVRów (Atmegi)? Niekoniecznie darmowe. Może lepiej od razu przenieść się na inny procesor? Zacząć uczyć się obsługi mikrokontrolerów z rdzeniem ARM? Jeśli tak to jak jakich STMa? AVR? etc...
zalezy co chcesz robic na tych procesorach. Jezeli dopiero co sie uczysz i Twoje zadania to miganie diodami LED, to proponuje zostac przy AVR, tym bardziej, że już coś zacząłes. AVRy mozna programowac w jezykach obiektowych, w C++ nawet i w Javie (tylko ze jej bootloader zajmuje jakies 7-8kB), ale jest to dość pamięcio- i szybkościo-żerne. Żeby nie używać TYLU zmiennych globalnych, cóż - pozostaje tylko praktyka czasem są one nieuniknione. Jeżeli chodzi o przerwania, to ich obslugi nie robi się w nich samych, tylko w pętli głównej, w przerwaniu jedynie wystawiając odpowiednią flagę, co także zwiększa pole działania zmiennym lokalnym
Oznacza to, że muszę mieć tablicę globalną z wynikami konwersji, oraz flagę, której z kolei używam do funkcji, która uśrednia mi wybraną liczbę wyników z tablicy ADC.
Do tego obsługa dwóch timerów i wiele innych funkcji czyni to niezbyt czytelnym. Tzn. patrzę na to bardzo krytycznie
Jeśli chcesz uśredniać wiele pomiarów to po co ci tablica z tymi pomiarami?
No chyba, że indywidualne pomiary, oprócz wartości średniej też są ci potrzebne...
Jeżeli chodzi o przerwania, to ich obslugi nie robi się w nich samych, tylko w pętli głównej, w przerwaniu jedynie wystawiając odpowiednią flagę, co także zwiększa pole działania zmiennym lokalnym
To jest przegięcie w drugą stronę niż większość.
W przerwaniu tylko ustawiać flagi?
To po co przerwania?
Przecież sprzęt sam flagi ustawia.
Chyba nie zrozumiałeś, o jakie flagi chodzi Często tak właśnie robię: mam kilka zmiennych globalnych, typu liczniki, stany itp. i w przerwaniu jedynie zmieniam ich wartość (np. zwiększam licznik po jeden) - a co z tego wynika, to już w pętli głównej. To dobra praktyka, ograniczająca czas wykonania przerwania - przecież licząc, powiedzmy, częstotliwość, wystarczy, że dokładnie zliczymy ilość impulsów, natomiast same obliczenia możemy przeprowadzać nawet tylko kilka razy na sekundę (albo i rzadziej).
Chyba nie zrozumiałeś, o jakie flagi chodzi Często tak właśnie robię: mam kilka zmiennych globalnych, typu liczniki, stany itp. i w przerwaniu jedynie zmieniam ich wartość (np. zwiększam licznik po jeden) - a co z tego wynika, to już w pętli głównej. To dobra praktyka, ograniczająca czas wykonania przerwania - przecież licząc, powiedzmy, częstotliwość, wystarczy, że dokładnie zliczymy ilość impulsów, natomiast same obliczenia możemy przeprowadzać nawet tylko kilka razy na sekundę (albo i rzadziej).
o to mi wlasnie chodzilo bo kolega albert mnie nie do konca chyba zrozumial, przeciez nikt nie wywarza otwartych drzwi sprawdzajac w przerwaniu czy wystapilo przerwanie
Trudno jest się z tobą zgodzić. Jak sama nazwa "przerwanie" wskazuje, jest to kod, który jest wykonywany niezależnie od kodu głównego, realizujący reakcję na jakieś zdarzenie. Zapewne w wielu przypadkach istnieje konieczność ścisłej relacji czasowej pomiędzy zdarzeniem a jego obsługą. A wtedy obsługa musi być w całości w przerwaniu. Np. obsługa enkodera - bez sensu jest w przerwaniu ustawiać flagi, które potem badamy w pętli głównej programu. Szczególnie w sytuacjach, w których ta pętla nie jest zbyt często wykonywana - np. długie podprocedury. Flagi mają sens tylko w określonych sytuacjach - znowu zgodnie z nazwą - wtedy kiedy chodzi tylko o zasygnalizowanie jakiegoś zdarzenia, a reakcja na nie może nastąpić lub nie w czasie bliżej nieokreślonym. Bądź też reakcją na zdarzenie jest jakaś trwała modyfikacja działania programu głównego, a nie obsługa zdarzenia wywołującego przerwanie.
Ty mi nie tłumacz, czym jest flaga w rozumieniu dosłownym. Próbuję Ci przekazać, że programiści tak mówią i tyle - i nie zmienisz tego, choćbyś się bardzo starał.
Jacy programiści? Ze szkolnej ławki? Publikacje, książki, noty katalogowe, nigdzie nie widziałem tam użycia terminu flaga dla licznika. To, że ktoś niedouczony myli pojęcia to nie powód, żeby przyjąć błędy za prawdę. Pokaż mi np. w MSDN Microsoftowym chociaż jeden przykład użycia terminu flaga dla określenia czegokolwiek innego niż naprawdę to znaczy.
Pozostawię tę wypowiedź bez komentarza.... tak samo w MSDN nie znajdziesz wielu innych określeń - które po prostu stanowią język potoczny danej grupy ludzi (tutaj: programistów). I nie, nie chodzi mi o kogoś "ze szkolnej ławki"... Zakończmy ten temat, zanim się pokłócimy. Postaraj jednak wyjrzeć poza świat akademicki. Ja też w tym świecie byłem, ale praktyka po prostu wiele zmienia. I nie chodzi wcale o mylenie pojęć - ale tego również nie doczytałeś. Skoro jednak nie potrafisz przyjąć wytłumaczenia, jak to jest w języku potocznym - EOT.
(ps. znasz skrót "EOT"?..... przecież w słowniku go nie ma...)
Jacy programiści? Ze szkolnej ławki? Publikacje, książki, noty katalogowe, nigdzie nie widziałem tam użycia terminu flaga dla licznika. To, że ktoś niedouczony myli pojęcia to nie powód, żeby przyjąć błędy za prawdę. Pokaż mi np. w MSDN Microsoftowym chociaż jeden przykład użycia terminu flaga dla określenia czegokolwiek innego niż naprawdę to znaczy.
.... aleś pan pojechał teraz ... sorki, ale zaczyna przypominać mi to przekomarzanie się na temat flag,.... kłótnie średniowieczne nad tym "ile diabłów mieści się na czubku szpilki" . Dajcie, żesz panowie spokój na temat prowadzenia wywodów naukowych i słowotwórczych, bo niedługo to kolejna osoba tu wpadnie i wykrzyczy, że to nie prawda co tu gadacie, gdyż flaga może być tylko narodowa
To czy ktoś sobie użyje całego bajtu czy nawet dwóch bajtów albo i nawet łańcucha znaków, który będzie coś sygnalizował w innej części programu - można na swój użytek nazwać flagą. To, że typowo mechanizm flag opiera się zwykle o pojedyncze bity sygnalizujące jakiś stan, wcale nie oznacza, że nie można w tym celu wykorzystać całego bajtu.
Poza tym łatwiej niedoświadczonemu jest wytłumaczyć mechanizm działania flag w taki właśnie prostszy sposób niż jeszcze tłumaczyć mu odrazu ew pozostałe zawiłości związane być może z definiowaneim struktur , unii itp.
Poza tym, z tymi "flagami" to jest tak zapewne jak z makrami, które najpierw wybijasz gościowi z głowy aby za chwilę mówić, że sam z nich chętnie korzystasz w C. To może tylko świadczyć o tym, że wiedzę teoretyczną ale i praktyczną masz - tyle że ciężko ci ją komuś przekazać składnie. Tak bym to ujął. Więc daj sobie spokój z niedouczonymi ze szkolnej ławki.
Cóż, dyskusję o flagach wywołałem ja nie tmf.
Zwróciłem uwagę, że "w przerwaniu jedynie wystawiając odpowiednią flagę"
jest niepoprawne, nie ze względu na czepianie się lecz ponieważ widziałem wiele programów, które naprawdę jedynie to robiły. A co do tego, że to absurd chyba wszyscy się zgadzamy. tmf podkreślił, że tak to formalnie wygląda. I ma rację, i nie zmieni tego żadne powoływanie się na język potoczny, ani mieszanie do tego struktur czy innego badziewia.
Ja zwróciłem uwagę na występujący błąd zbytniej minimalizacji przerwań w imię poprawności (bo mają być krótkie), tmf dorzucił kwestię czasu reakcji na zdarzenie.
Dwie wskazówki dla początkujących. W mojej ocenie przydatne.
A oponenci?
Co przekazaliście mniej doświadczonym programistom?
To czy ktoś sobie użyje całego bajtu czy nawet dwóch bajtów albo i nawet łańcucha znaków, który będzie coś sygnalizował w innej części programu - można na swój użytek nazwać flagą. To, że typowo mechanizm flag opiera się zwykle o pojedyncze bity sygnalizujące jakiś stan, wcale nie oznacza, że nie można w tym celu wykorzystać całego bajtu.
Może sobie nawet cały dysk zapełnić, nie zmienia to faktu, że flaga przechowuje wartość 1 lub 0, tak lub nie. Wrzucenie tego do całego bajtu nie zmienia prostego faktu, że ilość informacji ciągle wynosi 1 bit i w związku z tym jest to flaga.
mirekk36 napisał:
Poza tym, z tymi "flagami" to jest tak zapewne jak z makrami, które najpierw wybijasz gościowi z głowy aby za chwilę mówić, że sam z nich chętnie korzystasz w C. To może tylko świadczyć o tym, że wiedzę teoretyczną ale i praktyczną masz - tyle że ciężko ci ją komuś przekazać składnie. Tak bym to ujął. Więc daj sobie spokój z niedouczonymi ze szkolnej ławki.
Jak już mnie cytujesz to rób to dokładnie. Nie napisałem nigdzie, że chętnie korzystam, tylko często. A to nie to samo. Druga rzecz - gość któremu odpisywałem twierdzi, że czesto używa makr do zastępowania funkcji, podałem mu dwa przykłady prostych, jednolinijkowych makr, których wynik działania miał podać. W 100% podał błędny. Utwierdzanie kogoś takiego, że makra są super to jak danie 2 latkowi pistoletu.
A co do reszty to panowie nieźle mnie rozśmieszyliście pisząc o tych programistach. Jak rozumiem wg was programiści Microsoftu (którzy piszą MSDN) są teoretykami Życzę wam takich podstaw teoretycznych.
Kolego utak3r - znowu się mylisz. EOT jest w słowniku.
Może sobie nawet cały dysk zapełnić, nie zmienia to faktu, że flaga przechowuje wartość 1 lub 0, tak lub nie. Wrzucenie tego do całego bajtu nie zmienia prostego faktu, że ilość informacji ciągle wynosi 1 bit i w związku z tym jest to flaga.
No więc o co toczysz ten spór człowieku? Jak
tmf napisał:
...., podałem mu dwa przykłady prostych, jednolinijkowych makr, których wynik działania miał podać. W 100% podał błędny. Utwierdzanie kogoś takiego, że makra są super to jak danie 2 latkowi pistoletu.
hyhyhyhy "przykłady" dobre sobie, ktoś kto nigdy nie doczytał dokładnie na temat działania preprocesora, zawsze tak samo odpowie na te twoje "przykłady" - a autor wątku właśnie zaczyna od tyłu (stąd jego odpowiedź taka a nie inna) - ale fakt , ty z kolei tłumaczysz mu od tyłu. Twoje zachowanie jest mniej więcej takie jakbyś dziecku w 2 klasie szkoły podstawowej zadał pytanie jak się liczy całki i z lubością byś się cieszył, że dziecko tego nie wie...... za to ciebie duma rozpiera.
tmf napisał:
A co do reszty to panowie nieźle mnie rozśmieszyliście pisząc o tych programistach. Jak rozumiem wg was programiści Microsoftu (którzy piszą MSDN) są teoretykami Życzę wam takich podstaw teoretycznych.
No proszę, piszesz co najmniej tak jakbyś był jednym ze współautorów MSDN'u, jakbyś chodził z nimi na piwo - fakt to jest śmieszne - tm bardziej, że uwziąłeś się na flagi jakby ktoś tu wpierał że flaga to coś innego. Kto w tym temacie powiedział, że flaga to inny stan niż 0 albo 1 ??? ty coś sobie ubzdurałeś chyba i czepiłeś się tego.
utak3r napisał:
Chyba nie zrozumiałeś, o jakie flagi chodzi Często tak właśnie robię: mam kilka zmiennych globalnych, typu liczniki, stany itp. i w przerwaniu jedynie zmieniam ich wartość (np. zwiększam licznik po jeden) - a co z tego wynika, to już w pętli głównej. To dobra praktyka, ograniczająca czas wykonania przerwania - przecież licząc, powiedzmy, częstotliwość, wystarczy, że dokładnie zliczymy ilość impulsów, natomiast same obliczenia możemy przeprowadzać nawet tylko kilka razy na sekundę (albo i rzadziej).
czy z tego co kolega utak3r napisał można wywnioskować, że liczniki nazywa flagami??? napisał tylko tłumacząc autorowi , że podobnie na zasadzie mechanizmu działania flag w przerwaniach zmienia stany innych zmiennych, liczników itp - aby później w pętli głównej na to zareagować. Cóż w tym złego ???? za to nagle znajduje się dwóch obrońców FLAG, którzy czepiają się nie wiedzieć czego. Jeśli źle zrozumiałeś wypowiedź to dopytaj, podyskutuj a nie zarzucaj komuś farmazony o super programistach z MSDNu bo to trochę albo nawet bardzo - dziecinada.
tmf - no chyba masz dzisiaj gorszy dzień.
albertb napisał:
Cóż, dyskusję o flagach wywołałem ja nie tmf.
Zwróciłem uwagę, że "w przerwaniu jedynie wystawiając odpowiednią flagę"
jest niepoprawne, nie ze względu na czepianie się lecz ponieważ widziałem wiele programów, które naprawdę jedynie to robiły. A co do tego, że to absurd chyba wszyscy się zgadzamy. tmf podkreślił, że tak to formalnie wygląda. I ma rację, i nie zmieni tego żadne powoływanie się na język potoczny, ani mieszanie do tego struktur czy innego badziewia.
Ja zwróciłem uwagę na występujący błąd zbytniej minimalizacji przerwań w imię poprawności (bo mają być krótkie), tmf dorzucił kwestię czasu reakcji na zdarzenie.
Dwie wskazówki dla początkujących. W mojej ocenie przydatne.
A oponenci?
Co przekazaliście mniej doświadczonym programistom?
Albert
Mało programów w takim razie widziałeś w swoim życiu. Druga sprawa to, to, że jak ktoś tutaj poleca początkującym korzystanie z flag w celu minimalizacji obsługi przerwań - to zwykle w 99% chodzi o takich początkujących, którzy walą do przerwania wszystko łącznie np z wyświetlaniem na LCD .... Też im powiesz, żeby nie szli w taki minimalizm jak flagi w tak oczywistych przypadkach ???? Nikt nie mówi, że w przerwaniach mają być tylko flagi bo wiadomo, że to bzdura - chodzi o to, żeby w przerwaniach było jak najmniej operacji w sensie nie tyle nawet ilości kodu co krótkiego czasu jego wykonywania. To oczywiste. A że do tego jeszcze można albo i nie w zalezności od sytuacji zastosować flagi, liczniki i inne statusy to też oczywiste. Takie wytłumaczenie więcej da początkującemu niż wasze "zagadki" i spory o słowniki.
Co do samego sedna, to dopiero co w sąsiednim wątku omawialiśmy, co powinno znaleźć się w procedurze obsługi przerwań. Warto więc zajrzeć do innych wątków, zamiast pytać, co kto wniósł do dyskusji. A co do reszty, to ja już nie karmię Jak mawiają kandydatki na miss - "world peace!".
Wracając do meritum - Piotr_pp - jak byś napisał funkcję obsługi przerwania "z wykorzystaniem technik obiektowych"? Co byś tam uprościł i jak byś sobie poradził bez użycia globalnych obiektów?
Słuszna uwaga. Nawet w C++ podczas przerwania musiałbyś korzystać z obiektów statycznych, ew. można wykonać technikę dynamicznego rzutowania na właściwość obiektu - ale to już niebezpieczne zabawy i powinno się je wykonywać tylko wtedy, gdy już inaczej się nie da.
Słowem - dać by się dało, ale wcale nie spowodowało by to ani upiększenia kodu, ani tym bardziej jego uproszczenia...
...., podałem mu dwa przykłady prostych, jednolinijkowych makr, których wynik działania miał podać. W 100% podał błędny. Utwierdzanie kogoś takiego, że makra są super to jak danie 2 latkowi pistoletu.
hyhyhyhy "przykłady" dobre sobie, ktoś kto nigdy nie doczytał dokładnie na temat działania preprocesora, zawsze tak samo odpowie na te twoje "przykłady" - a autor wątku właśnie zaczyna od tyłu (stąd jego odpowiedź taka a nie inna) - ale fakt , ty z kolei tłumaczysz mu od tyłu. Twoje zachowanie jest mniej więcej takie jakbyś dziecku w 2 klasie szkoły podstawowej zadał pytanie jak się liczy całki i z lubością byś się cieszył, że dziecko tego nie wie...... za to ciebie duma rozpiera.
Oj, widzę, że prześladują cię urojenia. Wyraźnie napisałem mu, że powinien zabrać się za podstawy najpierw, ba, nawet dostał namiar na książkę. A skoro upierał się przy makrach to mu na prostym przykładzie pokazałem, że nie wszystko jest takie jakim się wydaje być.
mirekk36 napisał:
tmf napisał:
A co do reszty to panowie nieźle mnie rozśmieszyliście pisząc o tych programistach. Jak rozumiem wg was programiści Microsoftu (którzy piszą MSDN) są teoretykami Życzę wam takich podstaw teoretycznych.
No proszę, piszesz co najmniej tak jakbyś był jednym ze współautorów MSDN'u, jakbyś chodził z nimi na piwo - fakt to jest śmieszne - tm bardziej, że uwziąłeś
A jednak urojenia. Ale nie martw się, tu mogę ci posłużyć profesjonalną pomocą
mirekk36 napisał:
utak3r napisał:
Chyba nie zrozumiałeś, o jakie flagi chodzi Często tak właśnie robię: mam kilka zmiennych globalnych, typu liczniki, stany itp. i w przerwaniu jedynie zmieniam ich wartość (np. zwiększam licznik po jeden) - a co z tego wynika, to już w pętli głównej. To dobra praktyka, ograniczająca czas wykonania przerwania - przecież licząc, powiedzmy, częstotliwość, wystarczy, że dokładnie zliczymy ilość impulsów, natomiast same obliczenia możemy przeprowadzać nawet tylko kilka razy na sekundę (albo i rzadziej).
czy z tego co kolega utak3r napisał można wywnioskować, że liczniki nazywa flagami???
A jak inaczej można to zrozumieć "Chyba nie zrozumiałeś, o jakie flagi chodzi Często tak właśnie robię: mam kilka zmiennych globalnych, typu liczniki, stany itp." ?
Jeśli nie chciał nazwać te liczniki flagami to ok, nie ma dyskusji.
mirekk36 napisał:
Mało programów w takim razie widziałeś w swoim życiu. Druga sprawa to, to, że jak ktoś tutaj poleca początkującym korzystanie z flag w celu minimalizacji obsługi przerwań - to zwykle w 99% chodzi o takich początkujących, którzy walą do przerwania wszystko łącznie np z wyświetlaniem na LCD .... Też im powiesz, żeby nie szli w taki minimalizm jak flagi w tak oczywistych przypadkach ???? Nikt nie mówi, że w przerwaniach mają być tylko flagi bo wiadomo, że to bzdura - chodzi o to, żeby w przerwaniach było jak najmniej operacji w sensie nie tyle nawet ilości kodu co krótkiego czasu jego wykonywania. To oczywiste. A że do tego jeszcze można albo i nie w zalezności od sytuacji zastosować flagi, liczniki i inne statusy to też oczywiste. Takie wytłumaczenie więcej da początkującemu niż wasze "zagadki" i spory o słowniki.
Akurat w naukach ścisłych jasny język jest istotny, mylenie pojęć powoduje niemożność komunikacji. A co do flag - skoro robi flagi, które potem przez pooling sprawdza w pętli głównej programu, to po co mu przerwania? Przecież równie dobrze może bezpośrednio sprawdzać czy nie zaszło zdarzenie wywołujące przerwanie. Oczywiście nie zawsze jest to równoważne, ale skoro piszemy o początkujących...
Trochę stary i częściowo nieaktualny, ale warto przeczytać. Oczywiście funkcja obsługująca przerwanie najprościej jeśli by była statyczna, ale wcale taka nie musi być. Tylko wtedy potrzebny jest dispatcher. Użycie dispatchera w przypadku przerwań np. ADC, czy UART sens miałoby niewielki, ale już dla timera tak. Nawiasem mówiąc w jednym projekcie coś takiego wykorzystałem. Klasa działa na timerze. Np. chce co 100ms wywołać jakąś procedurę, dodaję ją do kolejki i zapominam o problemie. Dla jednej to oczywiście bez sensu, ale dla wielu...
A w przypadku UARTa można ładnie enkapsulować dane, np. program nic nie musi wiedzieć o buforowaniu, obsłudze itd. Wysyła coś na UART, klasa sobie to kolejkuje, w przerwaniach wysyła kolejne bajty. Aplikacja dostaje tylko potwierdzenie (jeśli chce), że cała paczka została wysłana. Zresztą jeśli ktoś jest zainteresowany to chętnie wrzucę tu swoje przykłady klas obsługujących przerwania w C++.
A co do flag - skoro robi flagi, które potem przez pooling sprawdza w pętli głównej programu, to po co mu przerwania?
Sens jest w rozdzielczości monitorowania. Program główny może mieć zbyt dużo zadań i np. jedna pętla może się wykonywać, powiedzmy, kilka ms. To prowadzi do tego, że monitorowanie zajścia zdarzenia staje się niemożliwe z tego poziomu - i po to właśnie przerwanie, którego jedynym czasami zadaniem jest właśnie odnotowanie faktu jego wywołania.
Wiem, że w pewnych przypadkach ma to sens, ale najogólniej taką samą funkcjonalność bez utraty "rozdzielczości" można uzyskać badając przez pooling flagę sprzętową związaną z przerwaniem, bez jakiejkolwiek procedury jego obsługi, ba nawet bez odblokowywania danego przerwania.