hej.
schemat jest schemat - jest w paczce zip.
w sumie jaki jest cel w " narobieniu " się i uzyskaniu tego samego - tylko na lcd ?
no chyba że chodzi ambicję - co ja nie zrobię ?
pzd.
DRO DIY
-
251mz
- Moderator
-
Lider FORUM (min. 2000)
- Posty w temacie: 5
- Posty: 4478
- Rejestracja: 27 sie 2004, 21:59
- Lokalizacja: Polska
ALU to arytmetyczno logina jednostka...strikexp pisze:Tym językiem wywołujemy konkretne instrukcje ALU czy coś w ten deseń. Sam nie wnikałem aż tak głęboko, bo to mało przydatna wiedza w praktyce.
Kolega wie na pewno o czym pisze?
Bardziej przydatna niż Ci się wydajestrikexp pisze:Sam nie wnikałem aż tak głęboko, bo to mało przydatna wiedza w praktyce.
-
strikexp
- Lider FORUM (min. 2000)
- Posty w temacie: 105
- Posty: 4690
- Rejestracja: 31 mar 2017, 19:47
- Lokalizacja: Warszawa
A proszę bardzo, z tym że nie starałem się go dopracować. Po prostu zerknąłem że działa zgodnie z założeniami, i zabieram się za czytanie o centrowaniu konika na tokarce 
Zauważyłem że dałem za mało zer przy przeliczaniu na cyfry wyświetlacza. Dodałem ale nie sprawdzałem czy prawidłowo.
@251mz
Już nie pamiętałem schematu wewnetrznego mikrokontrolera. A co to ALU to dobrze wiem co to jest.
Zauważyłem że dałem za mało zer przy przeliczaniu na cyfry wyświetlacza. Dodałem ale nie sprawdzałem czy prawidłowo.
@251mz
Już nie pamiętałem schematu wewnetrznego mikrokontrolera. A co to ALU to dobrze wiem co to jest.
- Załączniki
-
- DRO.rar
- kod
- (1.35 KiB) Pobrany 96 razy
-
Avalyah
- Lider FORUM (min. 2000)
- Posty w temacie: 22
- Posty: 2437
- Rejestracja: 29 lis 2015, 00:38
- Lokalizacja: Bielsko-Biała
No i tyle było gadania dla takiego prościutkiego kodu. Moja uwaga jest taka, że niepotrzebnie stosujesz 4-bajtowe inty do oznaczenia np. pinów mikrokontrolera.
Zazwyczaj stosuje się uint8_t do jednobajtowych wartości, zawsze to trochę mniej zajętej pamięci. Nie ma to znaczenia w tym przypadku, ale w bardziej rozbudowanych programach już jak najbardziej.
Zazwyczaj stosuje się uint8_t do jednobajtowych wartości, zawsze to trochę mniej zajętej pamięci. Nie ma to znaczenia w tym przypadku, ale w bardziej rozbudowanych programach już jak najbardziej.
-
strikexp
- Lider FORUM (min. 2000)
- Posty w temacie: 105
- Posty: 4690
- Rejestracja: 31 mar 2017, 19:47
- Lokalizacja: Warszawa
I to odpowiedź dlaczego tak zrobiłem.Avalyah pisze:Nie ma to znaczenia w tym przypadku
Na co dzień pracuję z automatycznym typowaniem i bazami danych. To powoduje trochę zboczenia z typami, na ogół rozróżniam co najwyżej bool i integer. A prawdziwe problemy pamięciowe to są dopiero przy nieregularnych string i blob.
Nie ma sensu bawić sie w szukanie problemów których nie ma. Ja jak mam dobry okres to potrafię dziennie wypracować 1-2k dla zleceniodawcy (korporacji). A to wymaga takiego właśnie podejścia i trzymania deadline.
-
strikexp
- Lider FORUM (min. 2000)
- Posty w temacie: 105
- Posty: 4690
- Rejestracja: 31 mar 2017, 19:47
- Lokalizacja: Warszawa
Zaczynałem od C++ i jeszcze 7 lat temu nie miałem problemu z typami danych. Ale po pewnym czasie programowania z automatycznym typowaniem po prostu się przestawiłem. Programowanie bez typów uwalnia od problemów technicznych i pozwala się skupić wyłącznie na problemach funkcjonalnych. Szybsze programowanie = lepsza kasa.
W mikrokontrolera tak się nie da bo zasoby są bardzo ograniczone. Ale uwierz mi, żeby zapchać pamięć w Arduino UNO to trzeba się postarać. Mi się to udało używając pamięci RAM jako dysku i dodatkowo korzystając z kilku bibliotek oraz modułu Ethernet. To jedyny przypadek gdzie miałem problem, znacznie łatwiej zajechać "procesor". Do profesjonalnych enkoderów Arduino UNO jest naprawdę słabym dodatkiem.
W mikrokontrolera tak się nie da bo zasoby są bardzo ograniczone. Ale uwierz mi, żeby zapchać pamięć w Arduino UNO to trzeba się postarać. Mi się to udało używając pamięci RAM jako dysku i dodatkowo korzystając z kilku bibliotek oraz modułu Ethernet. To jedyny przypadek gdzie miałem problem, znacznie łatwiej zajechać "procesor". Do profesjonalnych enkoderów Arduino UNO jest naprawdę słabym dodatkiem.
-
Avalyah
- Lider FORUM (min. 2000)
- Posty w temacie: 22
- Posty: 2437
- Rejestracja: 29 lis 2015, 00:38
- Lokalizacja: Bielsko-Biała
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.
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.
-
strikexp
- Lider FORUM (min. 2000)
- Posty w temacie: 105
- Posty: 4690
- Rejestracja: 31 mar 2017, 19:47
- Lokalizacja: Warszawa
A masz pewność że przekopiowanie typu long nie zostanie zaburzone przerwaniem? Z tego co mi sie przypomina z wykładów, to w Intel 8080 urywa kod w dowolnym momencie. Tutaj akurat ciężko znależć taki problem. Ale jak przerwanie zmodyfikuje akurat odczytywaną zmienną to przynajmniej jeden bajt zostanie doklejony.
Na takich błędach można rozwalić np tokarkę CNC zadając jej parametr który nigdy nie miałby prawa wystapić (np wjazd noża na uchwyt). W dodatku przerwania mają priorytety, nie pamietam jak dokładnie działały w ATmega328. Ale prawdopodobnie przerwanie nr 0 nie może być przerwane przez przerwanie nr 1. A już na odwrót jest to możliwe ze względu na priorytet.
Przyjąłem założenie aby program działał możliwie małymi kroczkami (stąd zmienna timer kluczująca IF-a). Wystarczy pokręcić z pewną prędkością śrubą i ma sie pewność że na 20% mniejszych obrotach błąd na pewno nie wystąpi.
Jakoś nie uważam żeby ATmega328 było dobrym pomysłem do odtwarzania muzyki. Ale tutaj sie sprawdza to co próbuję udowodnić, łatwo napisać taka funkcjonalność dzięki gotowym bibliotekom. Nawet pomimo tego że są strasznie niewydajne.
Na takich błędach można rozwalić np tokarkę CNC zadając jej parametr który nigdy nie miałby prawa wystapić (np wjazd noża na uchwyt). W dodatku przerwania mają priorytety, nie pamietam jak dokładnie działały w ATmega328. Ale prawdopodobnie przerwanie nr 0 nie może być przerwane przez przerwanie nr 1. A już na odwrót jest to możliwe ze względu na priorytet.
Przyjąłem założenie aby program działał możliwie małymi kroczkami (stąd zmienna timer kluczująca IF-a). Wystarczy pokręcić z pewną prędkością śrubą i ma sie pewność że na 20% mniejszych obrotach błąd na pewno nie wystąpi.
Jakoś nie uważam żeby ATmega328 było dobrym pomysłem do odtwarzania muzyki. Ale tutaj sie sprawdza to co próbuję udowodnić, łatwo napisać taka funkcjonalność dzięki gotowym bibliotekom. Nawet pomimo tego że są strasznie niewydajne.
