InzSpawalnik pisze:Poczytajcie panowie (...)

Do kogo mówisz, że mówisz w liczbie mnogiej?

strikexp pisze: Wychodzę przyciskiem MENU to od razu wskakuję spowrotem. Wychodzę przyciskiem ZERO to mi sie zeruje to co ustawiłem. Pozostaje chyba wyjść przyciskiem NEXT po przeleceniu wszystkich cyfr.

Zrób tak, że przycisk wymaga minimum np. 1 sekundy, żeby ponownie zarejestrował naciśnięcie. Możesz to zrobić funkcją "przechodnią" (żeby nie stosować żadnego okropnego delaya, czego w zasadzie nie możesz zrobić, bo pętli głównej nie możesz opóźniać) i skorzystać z funkcji millis() i porównywać czas w każdym wywołaniu. Taka funkcja oczywiście w pętli loop.

upanie pisze: Cholera jasna jakie to proste. Że też tyle lat się męczyłem a wystarczy czytać datasheet-a.

Chyba się zgodzisz, że warto od niego zacząć?

strikexp pisze: To dowodzi że do zabawy w elektronikę potrzebny jest multimetr

Do zabawy w elektronikę wystarczy czytać datasheeta (zapamiętać to słowo).

Są arduinowe przykłady zrealizowane na kilka sposobów (oczywiście wszystkie z przerwaniami). Możecie je sobie wypróbować. Nawet na jednej osi, żeby zobaczyć, czy działa.

Powinien, bo taki botlandowy enkoder używałem właśnie z nimi.

Jak to to samo? I jak to przerwań się w tym wypadku nie używa?

Nie chcę się tutaj kłócić, bo nie pracuję profesjonalnie, gdzie nie wątpię stmy są wykorzystywane częściej, niż xmegi.

Dla mnie dużo łatwiej było się przerzucić z atmeg na atxmegi, niż na stmy, które są 32 bitowe i programuje się je inaczej. 32MHz taktowanie, system DMA i eventów (chyba w stmach takiego nie ma?), wszystkie interfejsy komunikacji, które są potrzebne i to jest według mnie ogromny skok jakościowy.

Więc co najwyżej określiłbym to tak:

atmega <<<<<<< atxmega <<< stm

tzn xmegom bliżej pod względem możliwości do armów, niż do atmeg. A różnica w cenie w zastosowaniach jednostkowych albo małych serii, gdzie koszt procesora nie stanowi dużej części kosztu całego urządzenia nie jest aż tak bolesna. U chińskich przyjaciół za 7-8zł (z vat i cłem) można kupić całkiem porządną atxmega32a4u-au z full speed usb i wszystkimi możliwymi bajerami dostępnymi w tej serii.

AVR to nie tylko arduino. A pod względem peryferiów xmegi niespecjalnie ustępują stmom, ich cena również nie jest powalająca.

strikexp pisze:Jakoś nie uważam żeby ATmega328 było dobrym pomysłem do odtwarzania muzyki

Można zrobić to nawet na 8-nóżkowym attiny, który czyta dane z karty uSD i cały układ można zmieścić na płytce wielkości właśnie takiego gniazda. I to tylko z drobną pomocą assemblera. A taki potężny komputer jak atmega328 nie ma z tym już żadnego problemu, nawet przy 44kHz i próbkach 16 bitowych.

Nie wiem, czemu się tych przerwań tak boisz, ale jak chcesz mikrokontrolery programować, to będziesz musiał się do nich przekonać. Jeśli nie mylę terminów (a wolno mi, bo się nigdzie za programistę nie podaję ) to teraz robisz polling portów, żeby odczytywać stany na enkoderze i przez to wykorzystujesz do tego 100% zajętości mikrokontrolera. Jakbyś chciał rozszerzyć jakkolwiek działanie - np dodać przycisk zerujący, to byś musiał prawdopodobnie zmienić podejście.

Przy czym ja wcale nie mówię, że ten program jest zły (nie testowałem), tylko zwracam uwagę na kilka faktów, które rzuciły mi się w oczy.

Mógłbyś mi wskazać jeszcze linijki kodu, w których przerwanie mogłoby "zaburzyć kopiowanie typu long"? Bo nie do końca rozumiem, czego się obawiasz.

Widzę, że nie wykorzystałeś tutaj przerwań. Skąd masz pewność, że odczytasz w takiej sytuacji wszystkie impulsy z enkoderów?

A co do tej pamięci, to akurat UNO ma jej mało i łatwo ją zapełnić. Tu biblioteka, tam biblioteka i masz pełny flash. A jak się zachce np. odtwarzać muzykę i do tego wykorzystasz bufor 2x512b to nagle się okaże, że razem z serialem i innymi duperelami jest za mało wolnego RAMu.


EDIT: Sprostuję może, bo na UNO i tak braknie tych przerwań, ale na MEGA już nie.