ATNEL tech-forum https://forum.atnel.pl/ |
|
Timery programowe, nierówna praca https://forum.atnel.pl/topic24214.html |
Strona 1 z 1 |
Autor: | Rnext [ 1 maja 2022, o 08:01 ] |
Tytuł: | Timery programowe, nierówna praca |
Przecieram od rana oczy, bo próbuję sobie ćwiczyć timery programowe na diodzie i głośniczku. Zredukowałem do testów kod do chyba najprostszej możliwej formy. Przerwanie CTC ustawione co 1000ms. język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
...i głośniczek kołacze jak chce, led mruga jak chce ale na pewno nie są to zadane interwały. Jak umieszczę zmianę stanów w kodzie przerwania to wszystko jest jak najbardziej OK. Czegoś tu nie widzę? |
Autor: | JarekB [ 1 maja 2022, o 08:25 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Czy timer_1000ms i timer_300ms są volatile ? To po pierwsze Po drugie badanie w pętli głównej czy zmienna w przerwaniu osiąga 0 jest ryzykowne. W czasie wykonania przerwania może się zdarzyć że zero stanie się jedynką i pętla główna nie zdąży zareagować Gdybyś w przerwaniu postawił jakąś flagę i w pętli głównej ją zerował to wtedy miałbyś pewność że zawsze zdążysz. |
Autor: | Rnext [ 1 maja 2022, o 08:32 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
JarekB napisał(a): Czy timer_1000ms i timer_300ms są volatile ? To po pierwsze Tak, tak, naturalnie. JarekB napisał(a): Po drugie badanie w pętli głównej czy zmienna w przerwaniu osiąga 0 jest ryzykowne. W czasie wykonania przerwania może się zdarzyć że zero stanie się jedynką i pętla główna nie zdąży zareagować Gdybyś w przerwaniu postawił jakąś flagę i w pętli głównej ją zerował to wtedy miałbyś pewność że zawsze zdążysz. Adaptacja niemal żywcem z bluebooka. Ale racja, dodam flagę. ------------------------ [ Dodano po: 7 minutach ] No i super - z flagą pomocniczą wszystko działa perfect. Dzięki! |
Autor: | mirekk36 [ 1 maja 2022, o 17:20 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Rnext napisał(a): No i super - z flagą pomocniczą wszystko działa perfect. Dzięki! To jest bardzo zły sposób na realizację timerów programowych poza tym pisałeś: Rnext napisał(a): Adaptacja niemal żywcem z bluebooka. to "niemal" to u ciebie całkiem inaczej i źle - stąd twoje problemy. Gdybyś jednak spróbował jak w Bluebooku to mógłbyś działać DOKŁADNIE i tak samo wygodnie jak w Bluebooku i to bez żadnych dodatkowych flag - bo te dodatkowe flagi twoje to po prostu będą tylko zawalizdrogą przy bardziej rozbudowanych programach. |
Autor: | Rnext [ 2 maja 2022, o 05:43 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
mirekk36 napisał(a): Rnext napisał(a): to "niemal" to u ciebie całkiem inaczej i źle - stąd twoje problemy. Gdybyś jednak spróbował jak w Bluebooku to mógłbyś działać DOKŁADNIE Sam bardzo chętnie pozbył bym się flag. Pierwotnie zrobiłem DOKŁADNIE jak w BB i też działało nierówno. Stąd kolejne kombinacje w kodzie. Tak wyglądała przepisana żywcem pętla główna: język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. A tak przepisałem obsługa przerwania: język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. Po samej LED pewnie bym się nie zorientował, bo na oko mrugała jak powinna, ale głośniczek daje możliwość łatwego wyłapania skoków "taktu". |
Autor: | ord [ 2 maja 2022, o 13:04 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Poczytaj sobie o współdzieleniu danych i atomowym dostępie. |
Autor: | Zealota [ 2 maja 2022, o 13:38 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
ord napisał(a): Poczytaj sobie o współdzieleniu danych i atomowym dostępie. Tylko co to ma do rzeczy w kontekście problemu? Przy miganiu diody czy też buzzera nie ma żadnego znaczenia czy ktoś się pomyli o "kilka taktów zegara" Timery z bluebooka były wielokrotnie sprawdzane i używane do zadań jak w temacie i stawiam orzechy przeciwko kokosom, że autor coś pokikciał. Jeśli ktoś się wykłada na timerach programowych to niech jeszcze się nie bierze za "atomowość". |
Autor: | SylwekK [ 2 maja 2022, o 13:56 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Cytuj: Tylko co to ma do rzeczy w kontekście problemu? Więcej niż Ci się wydaje. Przy przekazywaniu 16bitowych parametrów do przerwania dzieją się różne rzeczy. Doczytaj jak Cię o to proszą, wiedzą co mówią.... |
Autor: | Zealota [ 2 maja 2022, o 15:20 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
SylwekK napisał(a): Więcej niż Ci się wydaje. Nie w tym banalnym przykładzie. Jest dość czasu na odczyt i zapis i "składanie" rejestrów. Nie ma innych przerwań, nie ma konfliktu dostępu do rejestrów mikrokontrolera Natomiast na pewno autor źle przepisał kod z bluebooka i od poprawnego powinien był zacząć. |
Autor: | SylwekK [ 2 maja 2022, o 17:53 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Nie zgodzę się. Nawet w tym banalnym przykładzie gdy timer programowy będzie 16bitowy to zwykle miganie diodą nie będzie idealnie równe. Dawno temu to przerabiałem w równie prostym programie i pytałem po forach co jest nie tak, że nie działa jak powinno. |
Autor: | Rnext [ 3 maja 2022, o 16:09 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Zealota napisał(a): SylwekK napisał(a): Więcej niż Ci się wydaje. Nie w tym banalnym przykładzie. {...} Natomiast na pewno autor źle przepisał kod z bluebooka i od poprawnego powinien był zacząć. Nie no, bez przesady Przecież sam możesz sprawdzić (lub ktokolwiek). Przecież wkleiłem też ten pierwotny, przepisany kod. Tym bardziej że za wiele do przepisywania tu nie ma, zwłaszcza że na pierwszy rzut oka w kod z BB wiadomo o co w nim chodzi. ------------------------ [ Dodano po: 19 minutach ] ord napisał(a): Poczytaj sobie o współdzieleniu danych i atomowym dostępie. Dzięki! Do głowy mi nie przyszło, żeby zerknąć w generowany ASM. Wstępnie zerknąłem w temat dostępu atomowego. Zdaje się tu jest pies pogrzebany. |
Autor: | mtbchn [ 3 maja 2022, o 17:49 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Rnext napisał(a): Zealota napisał(a): SylwekK napisał(a): Więcej niż Ci się wydaje. Nie w tym banalnym przykładzie. {...} Natomiast na pewno autor źle przepisał kod z bluebooka i od poprawnego powinien był zacząć. Nie no, bez przesady Przecież sam możesz sprawdzić (lub ktokolwiek). Przecież wkleiłem też ten pierwotny, przepisany kod. Tym bardziej że za wiele do przepisywania tu nie ma, zwłaszcza że na pierwszy rzut oka w kod z BB wiadomo o co w nim chodzi. ------------------------ [ Dodano po: 19 minutach ] ord napisał(a): Poczytaj sobie o współdzieleniu danych i atomowym dostępie. Dzięki! Do głowy mi nie przyszło, żeby zerknąć w generowany ASM. Wstępnie zerknąłem w temat dostępu atomowego. Zdaje się tu jest pies pogrzebany. Możesz pokazać ciało swojej funkcji: hw_timer0_ctc_enable? |
Autor: | Rnext [ 4 maja 2022, o 11:12 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
mtbchn napisał(a): Możesz pokazać ciało swojej funkcji: hw_timer0_ctc_enable? Jasne. Nic szczególnego w niej nie ma a jak pisałem, umieszczenie przełączania w obsłudze przerwania chodzi idealnie. język c Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. |
Autor: | Zealota [ 4 maja 2022, o 12:08 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Rnext napisał(a): Nie no, bez przesady Przecież sam możesz sprawdzić (lub ktokolwiek). Sprawdziłem, masz rację - zwracam honor. Na "usprawiedliwienie" mam to, że pomyliłem chyba Bluebooka z Greenbookiem. Różnica polega na tym, że w późniejszych implementacjach Mirek w obsłudze timerów programowych, przy inkrementacji, używa specyfikatora "register", który prawdopodobnie daje odpowiednią ochronę kodu. Takiego rozwiązania użyłem w wielu projektach i nigdy nie było problemu z działaniem w odpowiednim czasie. Sprawdź proszę, czy ta drobna zmiana spowoduje poprawne działanie. |
Autor: | ord [ 4 maja 2022, o 16:21 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Słowo kluczowe "register" użyte w taki sposób nic nie daje. Kod będzie identyczny. Generalnie w nowoczesnych kompilatorach słowo jest ignorowane. W przypadku C++ jest to wręcz wymuszone przez standard. |
Autor: | SylwekK [ 4 maja 2022, o 16:26 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Dokładnie. Teoretycznie kod wykona się szybciej, ale zmienna dostarczana do przerwana i tak może być przecięta na pół w losowych momentach... |
Autor: | Zealota [ 4 maja 2022, o 19:00 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
SylwekK napisał(a): przecięta na pół w losowych momentach... W przykładzie z jednym przerwaniem i modyfikacją w pętli głównej kiedy ma nastąpić to "przecięcie na pół"? Modyfikacja zmiennej następuje tylko w przerwaniu oraz w pętli głównej. Jeśli mikrokontroler wchodzi w obsługę przerwania, to póki nie skończy obsługi - podziała na rejestrach - to nic mu nie przerwie działania na rejestrach. "Atomowość" przerwania nie jest potrzebna, bo pętla główna nie jest wstanie zaburzyć/przerwać działania żadnego przerwania. W AVR przerwanie może zostać jedynie "przecięte na pół" przez inne przerwanie, czyż nie? No to może podczas modyfikacji zmiennej w pętli głównej? Nie, bo przerwanie wykonuje się co milisekundy, a inkrementacja dwubajtowej w pętli głównej, wraz z sprawdzeniem warunku będzie trwała wielokrotnie dłużej. Mamy zatem sekwencję: 1. Wejście w przerwanie 2. Obliczenia 3. Wyjście z przerwania 4. Wejście do pętli głównej 5. Co kilkanaście taktów zegara jest sprawdzany warunek - mikrosekundy najwyżej Gdy tylko przerwanie zmieni wartość licznika na 0 - w tym przerwaniu PĘTLA nie zmieni rejestrów, to DOPIERO po wyjściu z przerwania pętla będzie mogła wpisać nową wartość. PONIEWAŻ przerwanie nastąpi dopiero za kolejne milisekundy JEST DOŚĆ czasu na modyfikację dwóch jednobajtowych rejestrów. 6. Pętla sprawdza warunek (licznik == 0) wpisuje nową wartość w ciągu maks. kilku mikrosekund 7. Wielokrotnie sprawdzany jest warunek (licznik==0). Były ms zanim po raz kolejny nastąpiło przerwanie, ale zmienna już została zmodyfikowana do wartości początkowej (licznik = 1000 /ms/ ) 8. Wejście w przerwanie - po ms 9. Obliczenia 10. Wyjście z przerwania itd Mikrokontroler działa sekwencyjnie. Dopiero zagnieżdżanie przerwań wymusza w odp. momencie atomowość. Bo jedno jak i drugie przerwanie może zostać "przerwane", pokićkać wspólne rejestry. Nie pojedyncze przerwanie i pętla główna. No chyba, że coś pominąłem, ale co? Jaki macie pomysł na wytłumaczenie? Nie zadowala mnie "bo ktoś powiedział', albo że "tak ma być", "atomowość rozwiązała problem" Taki kod działa u mnie bezbłędnie nawet jeśli jest kilka liczników i kilka diod czy inne proste zmiany portów. Greenbook'owe kody też działają, a mamy tam przecież dość skomplikowane projekty, a softtimery są wykorzystywane. |
Autor: | andrews [ 4 maja 2022, o 20:41 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Zealota napisał(a): Mikrokontroler działa sekwencyjnie. Dopiero zagnieżdżanie przerwań wymusza w odp. momencie atomowość. W Twoim przykładzie linia 17. (if( softTimer1 == 0 )) wygeneruje mniej więcej taki kod asm: język asm Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. Jak widać dwubajtowa zmienna softTimer1 jest umieszczona w RAM pod adresami 0x0100 (low) i 0x0101 (high). Przyjmijmy, że zmienna softTimer1=256, czyli adres 0x0100 = 0x00, a adres 0x0101 = 0x01.
Coś takiego będzie się dziać bez zagnieżdżania, a nawet bez innych przerwań. Oczywiście nie będzie tak w każdym obiegu timera. Prawdopodobieństwo "trafienia" przerwania w nieodpowiednim momencie może nie jest duże, ale prędzej czy później się przytrafi, w efekcie czego program może działać niestabilnie. |
Autor: | SylwekK [ 4 maja 2022, o 21:46 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Dokładnie! Gdybym nie miał takiej sytuacji to bym nie mówił. |
Autor: | Zealota [ 5 maja 2022, o 10:04 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
andrews napisał(a): Scenariusz może być taki: Świetnie opisałeś moment "rozrywania" zmiennej, natomiast wg mnie takie coś w tym przykładzie być może nastąpi raz, na początku, po starcie programu. Od momentu uruchomienia globalnego przerwań sei() do pierwszego wejścia w warunek if (softTimer1 == 0) {} przerwanie może zaburzyć ten warunek wpisując "randomowe" wartości do zmiennej, poprzez rozerwanie dwubajtowej wartości softTimer1. Natomiast po wyjściu z pierwszego przerwania następne będzie dopiero po milisekundach. Być może pierwszy "tik" będzie dłuższy albo krótszy od zadanego softTimer1, ale następnie dojdzie do zsychronizowania pętli głównej z licznikiem i przerwaniami, a późniejsze sekwencje będą już "po kolei" i zgodnie z założeniami dla TEGO przykładu Jak pisałem wyżej: 1. Obsługa przerwania bezwzględnie blokuje obsługę kodu pętli while. 2. Pętla while nie "wywłaszcza" przerwania 3. Nie ma nic innego co "wywłaszczy" przerwanie i rozerwie słowo na bajty Te trzy warunki zapewniają, że po "rozkręceniu" licznika przerwań program będzie pracował poprawnie. Dodatkowo modyfikacja zmiennej softTimer1 przez pętlę główną, będzie zawsze po kilkunastu mikrosekundach od wyjścia z przerwania i czasu starczy na poprawną obsługę zmiennej softTimer1. Wyjście z przerwania da zawsze stabilną wartość zmiennej softTimer1 Stabilność "danych" w pętli while zapewnia bardzo długi czas pomiędzy przerwaniami. Może źle to tłumaczę, może mi coś umyka, ale ten przykład musi działać poprawnie. Dziś jeszcze dokonam prób sprzętowych na większej liczbie zmiennych, może coś się wyjaśni. |
Autor: | mtbchn [ 5 maja 2022, o 11:29 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Zealota napisał(a): andrews napisał(a): Scenariusz może być taki: Świetnie opisałeś moment "rozrywania" zmiennej, natomiast wg mnie takie coś w tym przykładzie być może nastąpi raz, na początku, po starcie programu. Od momentu uruchomienia globalnego przerwań sei() do pierwszego wejścia w warunek if (softTimer1 == 0) {} przerwanie może zaburzyć ten warunek wpisując "randomowe" wartości do zmiennej, poprzez rozerwanie dwubajtowej wartości softTimer1. Natomiast po wyjściu z pierwszego przerwania następne będzie dopiero po milisekundach. Być może pierwszy "tik" będzie dłuższy albo krótszy od zadanego softTimer1, ale następnie dojdzie do zsychronizowania pętli głównej z licznikiem i przerwaniami, a późniejsze sekwencje będą już "po kolei" i zgodnie z założeniami dla TEGO przykładu Jak pisałem wyżej: 1. Obsługa przerwania bezwzględnie blokuje obsługę kodu pętli while. 2. Pętla while nie "wywłaszcza" przerwania 3. Nie ma nic innego co "wywłaszczy" przerwanie i rozerwie słowo na bajty Te trzy warunki zapewniają, że po "rozkręceniu" licznika przerwań program będzie pracował poprawnie. Dodatkowo modyfikacja zmiennej softTimer1 przez pętlę główną, będzie zawsze po kilkunastu mikrosekundach od wyjścia z przerwania i czasu starczy na poprawną obsługę zmiennej softTimer1. Wyjście z przerwania da zawsze stabilną wartość zmiennej softTimer1 Stabilność "danych" w pętli while zapewnia bardzo długi czas pomiędzy przerwaniami. Może źle to tłumaczę, może mi coś umyka, ale ten przykład musi działać poprawnie. Dziś jeszcze dokonam prób sprzętowych na większej liczbie zmiennych, może coś się wyjaśni. Daj znać jak będziesz już po testach. Proponuję pomiar programowych timerów na kilku kanałach analizatora stanów logicznych. Jeśli byś mógł, wrzuć screeny. A w międzyczasie, może Mirosław zabierze głos i wyjaśni powyższe wątpliwości. |
Autor: | andrews [ 5 maja 2022, o 12:48 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Niestety kolego Zealota nie masz racji. Patrzysz na program z punktu widzenia języka C, a tu (aby zrozumieć problem) niestety trzeba spojrzeć na asemblera, bo instrukcje języka C nie są wykonywane przez mikrokontroler "atomowo". Przykładowo instrukcja porównania softTimer1==0 wymaga najpierw załadowania obydwu bajtów zmiennej softTimer1 do rejestrów. Odbywa się to w dwóch taktach mikrokontrolera, między którymi może wystąpić przerwanie, które zmodyfikuje zawartość zmiennej. Spowoduje to, że w rejestrach R25:R24 zmienna zostanie złożona z młodszego bajtu zmiennej softTimer1 w RAM przed modyfikacją i starszego bajtu zmiennej softTimer1 w RAM po modyfikacji (w przerwaniu), czyli wartość zmiennej będzie nieprawidłowa. I to na tyle. Struktura programu w języku C jak i wywłaszczanie nie mają tu nic do rzeczy. istotny jest tylko ten fragment dwóch instrukcji asm, pomiędzy którymi może wystąpić przerwanie (które zmodyfikuje wartość kopiowanej akurat zmiennej). Właściwie jedynym sensownym rozwiązaniem tego problemu jest wyłączenie przerwań na czas kopiowania z RAM do rejestrów, czyli w asemblerze wyglądałoby to tak: język asm Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod. W C można użyć makra ATOMIC_BLOCK() lub instrukcji cli(); i sei(); |
Autor: | Rnext [ 6 maja 2022, o 06:14 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
Przerwanie miałem ustawione co 1ms. Po zmianie na 10ms efekt "cudów" zniknął. Dziękuję wszystkim za pomoc i przede wszystkim ciekawą dyskusję. |
Autor: | SylwekK [ 6 maja 2022, o 07:19 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
No piękny felieton Mirek Teraz to i mnie się rozjaśniło. Wg powyższego moje problemy z nierównym odliczaniem, są tak widoczne, bo stosuję zazwyczaj podstawę nie większą niż 1ms - dość często 100us, a bywało, że i 50us i mniej. Może to dziwić, ale bardzo mi pomaga takie poganianie przerwań. Często umieszczam tam algorytmy, które wymagają szybkiego odświeżania, a o pętlę główną się nie martwię, bo ZAWSZE jest w pełni przelotowa nawet z wyświetlaczem LCD, który jest buforowany i jego obsługa zajmuje jednorazowo kilka/naście us. Może jestem szalony, ale ja na tych prostych timerach zegary dokładnie odliczające czas zawsze robię Jak w takim razie sobie radzę z dłuższym odcinkami? Na dwa sposoby - dokładny i mniej dokładny (teoretycznie, bo w praktyce nie widzę różnicy). Dokładny to użycie dodatkowej zmiennej w przerwaniach jako dzielnik dziełu czemu z pętli głównej wysyłam do timera zmienną jednobajtową, a mniej dokładny - w przerwaniach jest jeden timer sterujący, a w pętli głównej pod tym timerem kolejne timery już z wykorzystaniem dowolnej zmiennej (nawet 32bitowej). Jak wspominałem pętla główna u mnie jest nieblokująca i zabieg ten w moich programach sprawdza się praktycznie zawsze. Polecam |
Autor: | mirekk36 [ 6 maja 2022, o 08:08 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
SylwekK napisał(a): bo stosuję zazwyczaj podstawę nie większą niż 1ms Ja to doskonale wiem, bo kiedyś pisaliśmy nawet o tym na tym forum i wcale nikt nie jest szalony skoro takich technik używa, po to jest procek, żeby go cisnąć na maxa gdy trzeba. Powiem tak mnóstwo ludzi tak korzysta z procka - tylko, że tego już się nie da nazwać typowymi prostymi timerkami programowymi. W takich wypadkach gdy już schodzisz nawet do 100us czy 50us to jest już odmierzanie czasu dla konkretnych i sam przyznasz b.krótkich zdarzeń bo przecież przy 50us nie powiesz, że pakujesz tam jakiś kod który potrzebuje na wykonanie więcej niż 50us - pewnie zajmuje on nawet mniej niż połowę tego czasu. I to jest normalne jak jedzenie bułek z masłem i serem w programowaniu ... tylko właśnie trzeba mieć już na prawdę dobre doświadczenie w pisaniu programów w sposób nieblokujący ... a wiem, że ty masz i to duże bo już Bascoma wyciskałeś na MAXA kiedyś (ja też zresztą zanim przesiadłem się na C). Dlatego też na końcu mówiłem, że każdy ma rację - tylko w nieco innych aspektach i nie dotyczących koniecznie akurat tego konkretnego przypadku u autora tego wątku. ------------------------ [ Dodano po: kilkunastu sekundach ] Rnext napisał(a): Przerwanie miałem ustawione co 1ms. Po zmianie na 10ms efekt "cudów" zniknął. Dziękuję wszystkim za pomoc i przede wszystkim ciekawą dyskusję. No i bardzo fajnie - cieszę się, że ruszyło - teraz na pewno w przyszłości łatwiej będzie ci korzystać z tych mechanizmów |
Autor: | Zealota [ 6 maja 2022, o 08:57 ] |
Tytuł: | Re: Timery programowe, nierówna praca |
SylwekK napisał(a): nie większą niż 1ms - dość często 100us, a bywało, że i 50us Tak też podejrzewałem, ze w tym wątku piszemy głównie o CZYM INNYM. Ja o softTimerach w rozumieniu bluebook, a Autor o czym innym Jakiś kod ma u siebie, do wątku wrzuca jakieś tylko swoje zmiany wyrwane z kontekstu, opisuje to kodem przepisanym "żywcem" z książki, a tak na prawdę to działa chaotycznie, nieprecyzyjnie przedstawia problem. To najgorszy ze sposobów szukania pomocy Jakie to charakterystyczne dla programistów, którzy już mają sporą wiedzę, ale brakuje pokory SylwekK to już w ogóle o czym innym. soft timer 100us - w ogóle bym tego nie nazwał soft timerem jak uczono nas w Bluebooku. Dziwię się tylko, że jeszcze takie coś "wchodzi" na forum Atnel, kiedy Mirek od chyba już 10 lat mówi jak działać. To takie ogólne obserwacje i one tyczą się wszelkim gremiów technicznych. Musiałem to wyrzuć z siebie, bo od połowy wątku już mnie to gryzło Nie miałem na myśli oczywiście nic złego tak pisząc, jedynie komentuję "rzeczywistość" Jeszcze apropos roboty Andrews, to faktycznie "wyprostował" mnie w tym sensie, że zupełnie pominąłem fakt możliwości "rozdarcia" warunku IF. Cały czas byłem skupiony na modyfikacji softTimer1 = 1000, która była zabezpieczona poprzez długi okres między przerwaniami. Natomiast zarzut o patrzeniu z perspektywy C nie był zasadny, bo pierwsze co zrobiłem przy analizie to spojrzenie do asemblera Tyle wyjaśnień. |
Strona 1 z 1 | Strefa czasowa: UTC + 1 |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |