Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
TespolTespol
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Arduino nie nadąża sczytywać sygnałów z enkodera

30 Jul 2015 14:00 7191 33
  • Pupil
    Dzień dobry

    Od jakiegoś czasu próbuję podłączyć do Arduino leonardo, inkrementalny enkoder firmy Kubler (1024imp/obr).
    Problem tkwi w tym, że Arduino tak jakby nie nadąża ze sczytywaniem wartości z enkodera (gdy kręce enkoderem powoli wszystko jest ok, ale już przy szybkim obracaniu na ,,serial monitorze '' wyświetlają się błędne wskazania)

    Program sterujący pobrałem ze strony Arduino i wygląda on tak:

    Code: c
    Log in, to see the code


    Myślę, że problem tkwi w programie, a nie w Arduino, niestety moja wiedza na temat programowania jest marna.

    z góry dziękuję za pomoc.

    Poniżej załączam informacje ze strony producenta na temat enkodera:

    Arduino nie nadąża sczytywać sygnałów z enkodera
    Do you have a problem with Arduino? Ask question. Visit our forum Arduino.
  • TespolTespol
  • Helpful post
    Level 19  
    Zrób obsługę tego encodera w przerwaniu, a nie w pętli typu for(1).
    (Na stronie, z której masz ten kod jest przykład z przewaniem ang. interrupt).
    Polecam przeczytać całą tą stronę z arduino playground.

    Dla innych, chodzi o stronę.

    P.S. Moim zdaniem najprościej to napisać w gołym C, a nie w tym całym arduino (chociaż też powinno dać się zrobić).
  • Pupil
    Dziś próbowałem załadować prawie wszystkie programy z tej strony. Znalazłem jeden który w miarę mnie zadowala, jednak problem tkwi w tym, że ten program:

    - gubi się powyżej ok. 500 obr/min enkodera,
    - nie pokazuje wartości minusowych,
    - dochodzi do wartości ok 65000 na ,,serial monitor" i zeruje się

    wygląda on tak:

    Code: c
    Log in, to see the code


    Będę wdzięczny jak ktoś mi pomoże to rozwiązać i wytłumaczyć tak ,,na chłopski rozum":)
  • TespolTespol
  • Helpful post
    Level 19  
    klim-ass wrote:

    - gubi się powyżej ok. 500 obr/min enkodera,


    Jaką masz częstotliwość procka? Jak długo trwa obsługa tych przewań? Zwszłaszcza, ile czasu zajmuje ten "ditigalRead()"?

    klim-ass wrote:

    - nie pokazuje wartości minusowych,

    Code: c
    Log in, to see the code


    Popatrz na tą linijkę i zastanów się dlaczego.

    klim-ass wrote:

    - dochodzi do wartości ok 65000 na ,,serial monitor" i zeruje się


    Dochodzi pewnie do 2^16-1 i się zeruje, tak? To samo jak wyżej. (jakiego typu masz zmienną).
  • Pupil
    Dzięki za pomoc, faktycznie wystarczyło tylko zmienić typ zmienych.

    Maksymalna częstotliwość procka to 16Mhz, na resztę pytań nie umiem Ci odpowiedzieć.

    Jeszcze jedno. Dlaczego jak wykonuję jeden obrót enkoderem to wyświetla mi wartość na "serial monitor" równą 4096?
  • Level 28  
    klim-ass wrote:
    Dlaczego jak wykonuję jeden obrót enkoderem to wyświetla mi wartość na "serial monitor" równą 4096?

    Jeden pełny cykl zliczania (1 "impuls") enkodera składa się z 4 zboczy. Link
    Twój program zlicza każde zbocze osobno, co w efekcie daje 4-krotnie wyższą liczbę zliczonych impulsów.
    Jeśli chcesz zliczać tylko pełne cykle, powinieneś zmodyfikować program tak, by reagował tylko na jedno zbocze (to przy okazji powinno zwiększyć maksymalną częstotliwość zliczania) lub dzielić wynik przez 4.
  • Level 19  
    klim-ass wrote:
    Dzięki za pomoc, faktycznie wystarczyło tylko zmienić typ zmienych.


    Nie ma sprawy.

    klim-ass wrote:
    Maksymalna częstotliwość procka to 16Mhz


    Maksymalna ok, ale jaka jest w Twoim układzie?

    W innych pytaniach chodziło o to, że może po prostu nie da się mierzyć tego w ten sposób nawet jeżeli napisać by program w asemblerze.

    Pytanie do Ciebie. Tam w datasheecie jest napisane, że sygnał z tego encodera jest 160kHz. 500 obr/min to jest około połowa tej częstotliwości. Jeżeli mają do nas dotrzeć dwa impulsy, to daje nam 160 kHz. Może ten encoder nie daje już rady?
  • Level 28  
    miszcz310 wrote:
    500 obr/min to jest około połowa tej częstotliwości.

    A skąd taki wniosek?
    500obr/min=8,33obr/s
    8,33obr/s*1024imp/obr daje nam częstotliwość ok. 8,5kHz
    Poza tym 160kHz dotyczy jednego kanału, więc nie trzeba mnożyć przez 2.

    EDIT:
    miszcz310 wrote:
    W innych pytaniach chodziło o to, że może po prostu nie da się mierzyć tego w ten sposób nawet jeżeli napisać by program w asemblerze.

    Właśnie bardziej jednak dopatrywałbym się problemu ze zbyt długo trwającymi procedurami obsługi przerwań.

    Detekcja na jednym zboczu powinna nieco polepszyć sprawę, jeśli oczywiście rozdzielczość pomiaru będzie wystarczająca. Napisanie procedur obsługi przerwań w asm na pewno też przyspieszy sprawę, ale nie tylko to ma znaczenie. Ważne jest też to, jakie inne zadania jeszcze będzie wykonywał mikrokontroler (szczególnie chodzi tu o inne przerwania lub kod w pętli głównej krytyczny czasowo).

    Nie znamy założeń projektowych autora, więc trudno odpowiedzieć, czy da się je osiągnąć. Według moich szacunków, przy częstotliwości taktowania 16MHz, detekcji na jednym zboczu, procedurach napisanych w asemblerze i niezbyt wysokich oczekiwaniach dodatkowych co do pozostałych zadań wykonywanych przez mikrokontroler można osiągnąć prawidłowe zliczanie maksymalnie do ok. 4500obr/min. Jeśli to za mało, to pozostaje zmiana mikrokontrolera, najlepiej na taki, który ma sprzętowy dekoder kwadraturowy.
  • Level 19  
    Andrzej__S wrote:

    A skąd taki wniosek?
    500obr/min=8,33obr/s
    8,33obr/s*1024imp/obr daje nam częstotliwość ok. 8,5kHz
    Poza tym 160kHz dotyczy jednego kanału, więc nie trzeba mnożyć przez 2.


    Faktycznie. Pomyliłem się tylko 10 razy (:(). Masz rację. Trzeba sprawdzać co się robi jednak. Dzięki za poprawkę.
  • Moderator on vacation ...
    Andrzej__S wrote:
    Według moich szacunków, przy częstotliwości taktowania 16MHz, detekcji na jednym zboczu, procedurach napisanych w asemblerze i niezbyt wysokich oczekiwaniach dodatkowych co do pozostałych zadań wykonywanych przez mikrokontroler można osiągnąć prawidłowe zliczanie maksymalnie do ok. 4500obr/min.

    Liczba wprowadzająca w błąd, autora tematu więc nie należy jej brać za wiarygodną. Rozumiem oczywiście co napisałeś w zacytowanym fragmencie, ale uwarunkowania te są tak płynnie opisane, że nie można się na nich opierać szacując maksymalną częstotliwość zliczania impulsów w przypadku projektu autora niniejszego tematu.

    Dlatego warto do tematu podejść nieco inaczej by autor tematu zrozumiał jakie są możliwości w tym zakresie.
    Zakładając że odczyt enkodera jest realizowany za pomocą przerwań:
    - pusta funkcja przerwania zawiera 14 taktów zegara,
    - przyjmując, że na obsługę enkodera (dla obu zboczy) będzie potrzebne 10x tyle czasu daje nam to 140 taktów zegara, co przy 16MHz daje nam to:

    16MHz / 140 = 114kHz

    co należy rozumieć tak, że jeżeli ten mikrokontroler będzie zajmował się tylko i wyłącznie obsługą enkodera będzie poprawnie działał dla sygnałów do 114kHz.

    Dopiero teraz można oceniać, na ile pozostałe funkcjonalności realizowane przez mikrokontroler w danym projekcie zmniejszą tę częstotliwość.

    Zawsze też można wykorzystać jakiś malutki ATtiny i na nim zrobić tylko i wyłącznie obsługę enkodera(-ów) a komunikować się z nim np. za pomocą SPI lub I2C,

    I wcale nie trzeba tego pisać w asemblerze, ponieważ kod wygenerowany przez C będzie równie optymalny - pomijam biblioteki Arduino oczywiście.
  • Level 28  
    dondu wrote:
    Liczba wprowadzająca w błąd, autora tematu więc nie należy jej brać za wiarygodną.

    Dlaczego tak uważasz?
    dondu wrote:
    16MHz / 140 = 114kHz

    No to dołóżmy do tego 60 taktów, żeby działało cokolwiek innego, oprócz przerwań, choćby wyświetlanie na LCD. Nawet, jeśli to zrobisz na jakimś osobnym ATtiny, i będziesz dane wysyłał w przerwaniach, to mikrokontroler też potrzebuje na to nieco taktów.
    16MHz/200=80000Hz
    80000Hz/1024imp=ok.78obr/s
    78obr/s*60= ok. 4600obr/min

    Andrzej__S wrote:
    Według moich szacunków...

    Zaznaczyłem, że te 4500obr/min to wartość szacunkowa.
    Moim zdaniem jednak wcale nie wprowadza w błąd, bo zgodnie z obliczeniami jest to praktycznie górna granica obrotów.:)
  • Pupil
    Ogólnie enkoder będzie pracował w urządzeniu do wykonywania badań wizualnych wałów drążonych. Maksymalna prędkość enkodera z jaką będzie się obracał w tym urządzeniu to 600-700 obr/min.
  • Level 28  
    dondu wrote:
    Przeczytaj proszę jeszcze raz mój poprzedni post.

    Nie muszę. Przeczytałem go wystarczająco uważnie.
    Widocznie nie jestem wystarczająco inteligentny, żeby go zrozumieć.

    EDIT:
    dondu wrote:
    - przyjmując, że na obsługę enkodera (dla obu zboczy) będzie potrzebne 10x tyle czasu daje nam to 140 taktów zegara, co przy 16MHz daje nam to:

    Więc to też tylko szacunkowa wartość. Możesz mi wytłumaczyć, dlaczego Twoje szacowanie jest bardziej wiarygodne od mojego? Dlatego, że nie uwzględnia dodatkowej funkcjonalności (która przecież jakaś musi być, choćby po to, że by wydobyć jakoś dane o ilości impulsów z mikrokontrolera i którą siłą rzeczy doliczyć trzeba)? Ja tylko tę dodatkową funkcjonalność doliczyłem i przedstawiłem szacunkowy wynik w obr/min zamiast w kHz, bo uważałem, że taka informacja będzie bardziej istotna dla autora tematu.

    To, że nie przedstawiłem wyliczeń, nie oznacza, że wartość nie jest wiarygodna (co wydaje mi się udowodniłem w następnym poście, popraw mnie proszę, jeśli moje wyliczenia nie są prawidłowe). Może po prostu nie chciałem się nadmiernie rozpisywać. Jeśli autor chciałby wiedzieć, skąd ta wartość wynikła, zawsze może zapytać. Wartość ta miała służyć autorowi tylko do oceny, na ile jego oczekiwania odbiegają od maksymalnych możliwości mikrokontrolera.

    Nie chcę tu broń Boże nikomu ubliżyć, bo każdy kto teraz ma jakąś wiedzę, kiedyś też jej nie miał. Można też być specjalistą akurat nie w tej dziedzinie. Każdy kiedyś musi się nauczyć, więc to żadna ujma nie wiedzieć, ujmą może być raczej niechęć do zdobywania wiedzy. Niemniej autor korzysta z Arduino i gotowych kodów z internetu (jeśli dobrze zrozumiałem, kod który przedstawił nie jest jego autorstwa), pyta dlaczego mikrokontroler zlicza 4096 impulsów zamiast 1024 itp. Jak myślisz, co mu powie "maksymalna częstotliwość sygnału" albo w jaki sposób ma samodzielnie oszacować "na ile pozostałe funkcjonalności .. zmniejszą tę częstotliwość"?

    Ja uznałem, że z tymi tłumaczeniami należy jeszcze poczekać, bo jeśli autor oczekuje prawidłowego zliczania np. do 6000obr/min (wcześniej tego nie sprecyzował) albo chce dodatkowo uruchomić przerwania od dwóch timerów i USART oraz wykonywać obliczenia na liczbach zmiennoprzecinkowych, to trzeba zmienić albo enkoder (na taki z mniejszą ilością imp/obr) albo mikrokontroler. W przypadku innego mikrokontrolera (mam na myśli oczywiście mikrokontroler z innej rodziny) sposób realizacji zadania jak i obliczania maksymalnej prędkości obrotowej będą inne.

    @klim-ass
    klim-ass wrote:
    - gubi się powyżej ok. 500 obr/min enkodera,

    500obr/min / 60 = 8,3obr/s
    1 obrót to 1024 cykle * 4 zbocza = 4096 przerwań
    4096 przerwań/obrót * 8,3 obr/s = 34133 przerwań/s
    Zakładając, że taktujesz mikrokontroler częstotliwością 16MHz odstęp między przerwaniami wynosi:
    16000000/34133 = 468,75 taktów

    468 taktów dosyć sporo. Nawet mało wydajne procedury obsługi przerwań Arduino powinny teoretycznie dać radę.

    W jaki sposób weryfikujesz poprawność wskazań?
    Zastanawia mnie, jak nadąża ta transmisja danych. Czy konsola wyświetla Ci kolejne wartości licznika przy większych prędkościach???
    Wyświetlanie jest inicjowane po każdej zmianie wartości zmiennej encoderPos, czyli przy 500obr/min teoretycznie co ok. 468 taktów=29us przy F_CPU=16MHz (w praktyce prawdopodobnie po zakończeniu poprzedniej transmisji, czyli kiedy licznik zliczy już kilka/naście impulsów). Przy prędkości 9600b/s USART w 29us nie zdąży z transmisją 1 bitu. Nawet przy prędkości 115200b/s zdąży wysłać zaledwie 3 bity.

    Wygląda też na to, że w pętli głównej nie zapewniasz atomowego dostępu do wielobajtowej zmiennej volatile (encoderPos) inkrementownej w przerwaniu, więc wyświetlany wynik może być nieprawidłowy. Ryzyko nieprawidłowego wyniku jest tym większe, im wyższa częstotliwość przerwań (prędkość obrotowa).
  • Level 32  
    Jeśli dekodowanie w soft jest problemem może czas sięgnąć po hardware? Ile to pracy zrobić dekoder na kilku TTL ? Zero zgubionych impulsów...
  • Level 27  
    Sorki że nie czytam całego tematu ale widziałem że zaczeliście sie spierać o szybkość. A tak się składa że ostatnio robiłem test na Arduino UNO.
    Biorąc nawet zapas bezpieczeństwa. Wyszło mi że prosty program kontrolujący pozycję silnika enkoderem, jest w stanie obsłużyć minimum 100.000 impulsów na sekundę. Z tym że ja pisałem program w C i korzystałem z operacji bitowych, a enkoder był 3-kanałowy. Oczywiście wszystko w środowisku Arduino IDE i wgrane standardowo przez bootloader.
  • Level 19  
    Dobra mam pytanie do autora tematu. Jakby w tym programie zmienić to:

    Code: c
    Log in, to see the code



    na coś takiego:


    Code: c
    Log in, to see the code


    Tylko teraz tak. Nie wiem czy coś takiego łyknie ten arduino IDE. Nie wiem jakiego masz procka (dobra nie pamiętam). Musisz sprawdzić jaki port i jaki pin trzeba wstawić zamiast tego PIND (port D) i PD2 i PD3 (odpowiednio piny 2 i 3).
  • Moderator on vacation ...
    Andrzej__S wrote:
    Więc to też tylko szacunkowa wartość. Możesz mi wytłumaczyć, dlaczego Twoje szacowanie jest bardziej wiarygodne od mojego?

    Jasno napisałem dlaczego nie wolno podawać granicy w taki sposób jak to określiłeś, bo to Twoje szacunki i do Twojego projektu, a do projektu autora tego tematu mogą być kompletnie niewiarygodne i tylko do tego się odnoszę.

    To w jaki sposób ktoś zrealizuje odczyt enkodera i późniejszą obróbkę uzyskanych danych zależy od projektu. Dlatego też napisałem że:

    dondu wrote:
    Dlatego warto do tematu podejść nieco inaczej by autor tematu zrozumiał jakie są możliwości w tym zakresie.
    Zakładając że odczyt enkodera jest realizowany za pomocą przerwań:
    - pusta funkcja przerwania zawiera 14 taktów zegara,
    - przyjmując, że na obsługę enkodera (dla obu zboczy) będzie potrzebne 10x tyle czasu daje nam to 140 taktów zegara, co przy 16MHz daje nam to:

    16MHz / 140 = 114kHz

    co należy rozumieć tak, że jeżeli ten mikrokontroler będzie zajmował się tylko i wyłącznie obsługą enkodera będzie poprawnie działał dla sygnałów do 114kHz.

    Dopiero teraz można oceniać, na ile pozostałe funkcjonalności realizowane przez mikrokontroler w danym projekcie zmniejszą tę częstotliwość.


    Innymi słowy nie pisz proszę, że nie da się więcej niż 4500obr/min, bo to jest szkodliwa porada dla osoby pytającej.
  • Level 28  
    @dondu
    dondu wrote:
    ...bo to Twoje szacunki i do Twojego projektu...

    To jest nieprawda, jakobym te szacunki wziął "z kapelusza" lub z mojego projektu.

    Ogólnie myślę, że się czepiasz i próbujesz mnie (bezpodstawnie) zdyskredytować.
    Wartość szacunkowa (czy to moja, czy Twoja, bo Ty też szacowałeś) z natury swojej nie jest wiarygodna, bo to tylko wartość szacunkowa, i należy do niej podejść z dystansem. Myślę, że jednak nie wszyscy podchodzą do tego tak restrykcyjnie jak Ty. Ja wcale nie twierdziłem, że to jest sztywna granica.

    Uważam, że nie masz racji, jakoby wartość ta wprowadzała autora tematu w błąd (przy uwzględnieniu tego, co napisałem powyżej). Mogę się jednak mylić, dlatego pewnie lepiej będzie, jeśli na wszelki wypadek powstrzymam się od udzielania się na forum, żeby nie obniżać jego poziomu i nie wprowadzać w błąd innych.

    Pozdrawiam wszystkich (bez wyjątku) :)
  • Moderator on vacation ...
    Andrzej__S wrote:
    Ja wcale nie twierdziłem, że to jest sztywna granica.

    Właśnie dlatego że twierdziłeś że więcej się nie da:

    Andrzej__S wrote:
    Według moich szacunków, przy częstotliwości taktowania 16MHz, detekcji na jednym zboczu, procedurach napisanych w asemblerze i niezbyt wysokich oczekiwaniach dodatkowych co do pozostałych zadań wykonywanych przez mikrokontroler można osiągnąć prawidłowe zliczanie maksymalnie do ok. 4500obr/min. Jeśli to za mało, to pozostaje zmiana mikrokontrolera, najlepiej na taki, który ma sprzętowy dekoder kwadraturowy.

    musiałem to zdementować.


    Twoje szacunki są prawidłowe dla Twoich założeń i nic więcej, dlatego po raz kolejny napiszę, że wprowadzasz w błąd pytającego. Twoje założenia przewidują jakieś funkcjonalności, jakieś ograniczenia i jakieś potrzeby. Ja natomiast piszę o prawidłowym podejściu do szacowania możliwości obsługi enkodera.

    Przykład:

    Mikrokontroler nadzorujący silnik i enkoder dostał rozkaz włączenia silnika do prędkości odpowiadającej około 110 kHz impulsów z tego enkodera (czyli około 6445 rpm). PWM sterujący silnikiem realizuje na bazie timera, a odliczanie czasu dla obliczenia prędkości obrotowej realizuje na bazie drugiego timera.

    Wszelkie funkcjonalności dot. :
    - odbioru danych via SPI,
    - obliczenie aktualnej prędkości,
    - korekta PWM,
    są w pętli głównej, a w przerwaniu jedynie zliczanie impulsów w zmiennej LONG (4 bajty):

    Code: c
    Log in, to see the code


    Kod assemblera funkcji przerwania:

    Code: c
    Log in, to see the code


    Realizacja powyższej funkcji przerwania zajmuje (według symulatora) jedynie 54 takty zegara.

    Czy teraz już rozumiesz, że Twoje szacunki są prawidłowe, ale tylko i wyłącznie dla Twoich założeń i że można osiągnąć znacznie więcej niż 4500 rpm, o których pisałeś?

    Edit:
    Pomijam już fakt, że do zliczania impulsów enkodera można zastosować timer z wejściem zliczającym.
  • Level 28  
    To co napisałeś, to się zgadza ... przy Twoich założeniach, że sygnał z enkodera nie będzie zawierał zakłóceń, bo ten kod ich nie wychwyci.
  • Moderator on vacation ...
    Uff ... :)

    To jest enkoder optyczny więc zakłóceń innych niż elektromagnetyczne indukowanych w przewodach nie ma. Należy więc jedynie poprawnie zaprojektować schemat i PCB oraz ewentualnie prawidłowo traktować przewody ferrytami i filtrami.
  • Level 28  
    To wszystko są założenia. Jak widzisz zawsze trzeba coś założyć, żeby coś oszacować. Nie wiesz jakim długim przewodem autor tematu to połączył, czy jest ekranowany, jakie są w pobliżu niego źródła zakłóceń, czy zastosował te wszystkie rzeczy, o których piszesz...

    Zrobiła się z tego jałowa dyskusja. Myślę, że nie ma sensu tego ciągnąć, tym bardziej, że autor chyba stracił zainteresowanie tematem. Dlatego przyznaję Ci rację. Wprowadziłem autora w błąd. Więcej grzechów nie pamiętam i obiecuję poprawę.
  • Moderator on vacation ...
    Nie ma problemu, po prostu każde zadanie jest inne i w dodatku można je zrealizować na tysiące sposobów, stąd czasami projektant (także mi się to zdarza) czymś się zasugeruje i klops, aż przyjdzie ktoś z boku i wskaże błędy myślenia lub inną koncepcję. Tym razem byłem to ja, następnym razem będziesz Ty lub ktoś inny :)
  • Level 28  
    Ja po prostu mam taką zasadę (być może złą), że przy szacowaniu przyjmuję - może nie pesymistyczny - ale zwykle ten mniej optymistyczny scenariusz, bo to daje mi poczucie, że niezawodność rozwiązania będzie wyższa. Pewnie to asekuranctwo, ale z drugiej strony być może właśnie dlatego niezawodność moich projektów jest (przynajmniej w mojej ocenie :)) całkiem niezła.

    I nie zrozum mnie źle, nie sugeruję w ten sposób, że Twoje projekty są bardziej zawodne :)
  • Moderator on vacation ...
    Mnie tylko chodziło o zdementowanie sztywno postawionego przez Ciebie progu :)

    A co do tego, jak projektujemy - w jakiejś części projektów należy wszystkie parametry dobrać, obliczyć, sprawdzić i przetestować, ale są też takie projekty, które nie wymagają precyzji na najwyższym poziomie, a projektant świadomie decyduje się na kompromis. Inaczej bowiem zaprojektuję dozownik leku podawanego w czasie operacji, a inaczej dozownik pasty do lutowania :)
  • Level 28  
    @dondu
    Przepraszam za ten opóźniony zapłon, ale byłem ostatnio bardzo zajęty.
    Nie chciałem tego kontynuować, ale niestety coś jeszcze muszę powiedzieć.

    dondu wrote:
    Mnie tylko chodziło o zdementowanie sztywno postawionego przez Ciebie progu

    Jak już się na coś uprzesz, to...
    Andrzej__S wrote:
    Według moich szacunków, przy częstotliwości taktowania 16MHz, detekcji na jednym zboczu, procedurach napisanych w asemblerze i niezbyt wysokich oczekiwaniach dodatkowych co do pozostałych zadań wykonywanych przez mikrokontroler można osiągnąć prawidłowe zliczanie maksymalnie do ok. 4500obr/min.

    Czyli według Ciebie to jest sztywno postawiona granica?

    dondu wrote:
    ...a projektant świadomie decyduje się na kompromis.

    Tak, jednak granice tego kompromisu to sprawa indywidualna projektanta. Być może ja akurat przyjąłem węższe granice niż Ty i stąd wyniknęła ta zaniżona wartość szacunkowa?
    A dlaczego węższe granice? Zdarza się, że zleceniodawca zmieni "minimalnie" (jego zdaniem) założenia pod koniec wykonania projektu. Jak nie masz zapasu, to cały misterny plan może się posypać, bo dopisanie kilku linijek kodu może spowodować, że program przestaje działać. Albo okazuje się, że w rzeczywistości zakłócenia na obiekcie są wyższe, niż deklarowane przez zleceniodawcę, lub zmieniają się w trakcie użytkowania urządzenia i w ramach reklamacji trzeba dopisać ich programową eliminację. Jak nie masz zapasu...
    Jak napisałem to kwestia indywidualnego podejścia. Dlatego wyraźnie napisałem: "według moich szacunków"...

    Jeśli chodzi o wprowadzanie w błąd, to równie dobrze Twoja optymistyczna kalkulacja może być dla autora myląca, bo jeśli się okaże, że w jego przypadku pewne Twoje założenia nie są spełnione, a on założy, że można szybciej (tym bardziej, jeśli na biurku mu to będzie działało)...

    Poza tym liczy się także ton wypowiedzi. Dla mnie takie stwierdzenie (i to jeszcze napisane pogrubioną czcionką):
    dondu wrote:
    Liczba wprowadzająca w błąd, autora tematu więc nie należy jej brać za wiarygodną.

    brzmi tak samo jak:
    Quote:
    Nie słuchajcie go. On się nie zna i nie jest wiarygodny. Ja wiem lepiej i ja Wam powiem, jak się powinno do tego podejść.

    Moim zdaniem można inaczej, np. coś w stylu:
    Quote:
    Myślę, że pomyliłeś się w kalkulacji. Według moich szacunków można szybciej, ponieważ... Będzie to działać przy założeniu, że ....

    Trochę szacunku dla innych użytkowników forum i świadomości, że nie jesteś nieomylny.
    Rozumiem, pozycja na forum to rzecz nadrzędna. Ja jednak nie będę o nią walczył, bo poza satysfakcją nie odnoszę z udziału w forum jakichś znaczących korzyści (może czas zacząć jakoś korzystać ze zdobytych punktów, tylko nie bardzo wiem na co by je przeznaczyć).

    To nie była kwestia braku argumentów, że się "przyznałem do winy". Po prostu chciałem zakończyć tę dyskusję. Jak widać, niezbyt mi się to udało, ale tym razem to już koniec dyskusji, niezależnie czy i co odpowiesz.

    W każdym razie, jeśli chciałeś mnie zniechęcić do udzielania się na forum, to osiągnąłeś swój cel.
    Gratuluję. Tylko tak dalej :)

    Pozdrawiam.
    Andrzej
  • Moderator on vacation ...
    Odpowiadam z opóźnieniem, bo byłem poza forum przez ponad tydzień:

    ??? 8-O ... wydawało mi się, że doszliśmy już do porozumienia.

    Trudno zaakceptować Twój sposób argumentacji. Zaznaczyłem jasno co było moim celem - wykazanie, że Twój szacunek, iż nie da się więcej niż 4500 rpm jest tylko Twoim szacunkiem, i że wprowadzasz w ten sposób osoby początkujące w błąd, ponieważ w innym przypadku można osiągnąć znacznie więcej.

    Niestety nasza rola jest taka, by dementować tego typu posty jak Twój, bo w ten sposób rodzą się mity, które początkującym zapadają w pamięć. Na tym forum dbamy jednak o to, by dostawali oni rzetelną informację nawet wtedy, gdy jest ona niewygodna dla innych podpowiadających, czy też nas.

    A nieomylny także nie jestem o czym śmiało piszę na forum i blogu - patrz stopień 7: http://mikrokontrolery.blogspot.com/2011/04/pieklo-poczatkujacych.html
  • Level 28  
    Nie odpisywałem wcześniej, bo chciałem dotrzymać słowa, że zakończę tę niepotrzebną dyskusję, jednak nie potrafiłem się powstrzymać, za co wszystkich przepraszam.

    Szanowny Kolego dondu. :)

    Mi też trudno zaakceptować Twój sposób argumentacji.

    Po pierwsze:
    Posługujemy się tym samym cytatem, jednak to co Ty podkreśliłeś ("można osiągnąć prawidłowe zliczanie maksymalnie do") nie można interpretować w oderwaniu od tego, co ja podkreśliłem ("Według moich szacunków"), bo tylko całość oddaje sens mojej wypowiedzi. Według mnie podkreślone przeze mnie sformułowanie oznacza w domyśle: "jestem tylko człowiekiem, więc mogę się mylić, i to co podaję to tylko moja prywatna kalkulacja, której nie trzeba bezkrytycznie przyjąć". Dlatego uważam, że nie masz czego dementować, ponieważ ja (przynajmniej w moim odczuciu) nie podałem tego jako pewnik, tylko jako skalkulowaną przeze mnie wartość szacunkową.

    Po drugie:
    OK, mogłeś mnie źle zrozumieć (może nadal mnie źle rozumiesz), mogłeś obawiać się, że autor tematu i/lub inni użytkownicy mnie źle zrozumieją, może ja się nieprecyzyjnie wyraziłem, może pomyliłem się w obliczeniach, może przyjąłem złe założenia, może przesadziłem z zapasem na inne funkcjonalności... to nieistotne. Nie chodzi mi o to, że mnie poprawiłeś tylko o to, w jaki sposób to zrobiłeś (patrz mój poprzedni post).

    Po trzecie:
    dondu wrote:
    Niestety nasza rola jest taka, by dementować tego typu posty jak Twój, bo w ten sposób rodzą się mity, które początkującym zapadają w pamięć. Na tym forum dbamy jednak o to, by dostawali oni rzetelną informację nawet wtedy, gdy jest ona niewygodna dla innych podpowiadających, czy też nas
    Skoro tak, to pozwolę sobie tutaj przytoczyć cytat z innego wątku, dotyczący kodu wynikowego generowanego przez avr-gcc:
    Quote:
    Tak naprawdę akurat jest to przykład na głupotę kompilatora, bo niezależnie jakie rejestry w ISR są użyte, to prolog i epilog zachowuja, a następnie odtwarzają wszystkie rejestry MCU. W efekcie proste funkcje mają olbrzymi narzut.

    Ty też brałeś udział w tej dyskusji (nie uwierzę, że tego nie przeczytałeś) i nie zareagowałeś, choć próbowałem w delikatny sposób zwrócić na to uwagę i skłonić autora tych słów (lub któregoś z moderatorów) do sprostowania. A przecież nawet podany przez Ciebie w tym wątku przykład procedury obsługi przerwania (przedstawiłeś kod źródłowy C i wynikowy asm) przeczy tej teorii.
    Dlaczego nie zdementowałeś tej informacji :?:
  • Moderator on vacation ...
    Wszystkie moje posty są jedynie odpowiedziami na Twoje. Jeśli więc po moim pierwszym poście w kolejnym wyliczasz swoją wersję, ja na niego odpowiadam, itd. Gdybyś nie wyliczał, tylko sprawdził jaki jest faktyczny narzut czasowy funkcji przerwania, to temat zakończylibyśmy na moim pierwszym poście.

    Problem polega na tym, że Ty odbierasz moje posty jako atak na Ciebie, podczas gdy tak nie jest. Pisze je bardzo spokojny człowiek zawsze pozytywnie nastawiony do wszystkich uczestników forum. Zresztą sam tego doświadczyłeś: https://www.elektroda.pl/rtvforum/viewtopic.php?p=14735386#14735386

    Proszę więc to co piszę odbierać bardzo pozytywnie :)

    Jeżeli natomiast coś wytłuszczam to robię to po to, by czytający to teraz i w przyszłości zwrócili na to uwagę, bo często czytają "po łebkach" i później są problemy z interpretacją postów.

    Jeśli więc jeszcze raz przeczytasz mój pierwszy post zauważysz, że po prostu bardzo spokojnie wyjaśniłem problem.

    -------

    Andrzej__S wrote:
    Po trzecie:
    dondu wrote:
    Niestety nasza rola jest taka, by dementować tego typu posty jak Twój, bo w ten sposób rodzą się mity, które początkującym zapadają w pamięć. Na tym forum dbamy jednak o to, by dostawali oni rzetelną informację nawet wtedy, gdy jest ona niewygodna dla innych podpowiadających, czy też nas
    Skoro tak, to pozwolę sobie tutaj przytoczyć cytat z innego wątku, dotyczący kodu wynikowego generowanego przez avr-gcc:
    Quote:
    Tak naprawdę akurat jest to przykład na głupotę kompilatora, bo niezależnie jakie rejestry w ISR są użyte, to prolog i epilog zachowuja, a następnie odtwarzają wszystkie rejestry MCU. W efekcie proste funkcje mają olbrzymi narzut.

    Ty też brałeś udział w tej dyskusji (nie uwierzę, że tego nie przeczytałeś) i nie zareagowałeś, choć próbowałem w delikatny sposób zwrócić na to uwagę i skłonić autora tych słów (lub któregoś z moderatorów) do sprostowania. A przecież nawet podany przez Ciebie w tym wątku przykład procedury obsługi przerwania (przedstawiłeś kod źródłowy C i wynikowy asm) przeczy tej teorii.
    Dlaczego nie zdementowałeś tej informacji :?:

    Proponuję zadać Tomkowi w tamtym temacie to pytanie jeszcze raz, bo zadałeś je, a on widocznie przegapił i nie odpowiedział: https://www.elektroda.pl/rtvforum/viewtopic.php?p=14735359#14735359

    Tak jak pisałem, początkujący często coś przeczytają i zapamiętają, i ... wierzą w to i co gorsza później powielają tematy takie jak ten:


    Link

    Nota bene musiałem zareagować (wtedy jeszcze jako zwykły użytkownik), bo był także wątek w tej sprawie na forum :)


    -------

    A tak przy okazji uzupełnię, że pokazany przeze mnie wyżej kod i jego 54 cykle zegara dają teoretyczną możliwość uzyskania maksymalnie:

    16MHz / 54 = 296 296 przerwań/sekundę

    co dla tego enkodera oznacza maksymalnie: 296 296 / 1024 = 289 rps

    a to oznacza maksymalne obroty: 289 rps * 60 sekund = 17 340 rpm

    Sposób szacowania natomiast podałem w moim pierwszym poście:

    dondu wrote:
    Dopiero teraz można oceniać, na ile pozostałe funkcjonalności realizowane przez mikrokontroler w danym projekcie zmniejszą tę częstotliwość.


    Reasumując:
    Naprawdę nie gryziemy, tylko pomagamy :)
    Jeżeli poczułeś się urażony, to przepraszam :)