DRO DIY

@upanie
Nie jestem super ekspertem w kwestiach technicznych co do "komputerów". Ale coś tam liznąłem tematu i nie uważam żebym nie odróżniał mikrokontrolera od innych "wynalazków". Wszystko działa w podobny sposób więc upraszczam ponieważ to jest forum dla mechaników.

Odnośnie timerów, w systemie operacyjnym działa to inaczej. Priorytetem jest zawsze działanie OS a nie timery programów. Ale jeśli są potrzebne to istnieją owszem. Sprawdziłem, dla Cortex-A7 które siedzi w NanoPi NEO wygląda to tak:
http://infocenter.arm.com/help/index.js ... IGHII.html
O przerwaniach na linux:
http://students.mimuw.edu.pl/SO/LabLinu ... ndex2.html
O wydzielaniu 1 rdzenia na program sterujący:
http://stackoverflow.com/questions/9072 ... my-process
Nie wiem czego nie zrozumiałem z timerami według Ciebie. Ale biorąc pod uwagę jak rozległym tematem są przerwania pod linuxem, to wolę nie wnikać Tym bardziej że można stosować wielowątkowość programów.

Co do ARM to sie zgodzę że byłyby tutaj idealne. Ale to nie moja działka pomimo że mam programator od dawna. Jednak już na wstępie myślałem aby program był przenośny na Arduino z ARM.

Co do NanoPi NEO, jakiego systemu operacyjnego używałeś że dajesz takie wnioski?
Na Linux da sie wszystko, tylko trzeba się dogrzebać do informacji jak to zrobić.

Avalyah pisze:taktowanie oczywiście wciąż niższe[/URL]

Ale ilość bitów większa, poczytaj jak działa mikrokontroler Intel 8080 na przykładzie programów asemblerowych. To jest podstawowa tematyka na studiach i pozwala zrozumieć o co chodzi z tymi bitami.

Yogi_ pisze:

upanie pisze:Nie chce mi się już więcej pisać bo na pewno Cie nie przekonam. Na koniec dodam tylko, że program miałeś napisać w kilkadziesiąt minut

Na to akurat jest wzór czas podawany przez programistę należy pomnożyć przez dwa i przyjąć jednostkę bezpośrednio wyższą Jak często sam tak miałeś?

Jak dobry programista i dokumentacja, to wychodzi poślizg góra 20%. Na ogół w dół a nie w górę
Jednak jak masz zadanie na 60min a zadzwoni Ci telefon to już masz poślizg 25%
A ja w sumie to pisałem obsługę enkodera kilkadziesiat minut. Tylko na kombinacje z wyświetlaczem straciłem ze 4h. I nie chodziło wcale o wyświetlenie danych.
Temat rzeka, są o tym grube książki więc po co pisać kolejną.

upanie pisze:Coś takiego pokazuje jakim leszczem jest ten kto tak pisze.

A jesteśmy na spotkaniu projektowym, czy przy luźnej rozmowie o czymś robionym za darmo?
Kilkadziesiąt minut to minęło zanim wygrzebałem Arduino z szafy (nie mam miejsca w bloku), rozpakowałem wyświetlacz z paczki pocztowej i zebrałem resztę drobnicy.


@pukury
Tak to właśnie ma działać, tylko kasowanie luzów muszę jeszcze dodać. Zdecydowałem że wynik będzie miał zakres +/-999.9999mm.

@Yogi_
Może i nawpieniałem się z tym prostackim wyświetlaczem. Ale przynajmniej jest na tyle prosty że łatwo zrobić wiekszy odpowiednik samemu.
Największy wyświetlacz LED 7-segmentowy widziałem na przepompowni wody w centrum Warszawy. Pamięć zawodzi, ale był jakoś pomiędzy rozmiarem szklanki a puszki piwa

Żaden arm tutaj nie jest potrzebny, ani 32-bitowa architektura. Nie studiowałem też informatyki, więc niespecjalnie mnie interesuje to na razie, jak zajdzie taka potrzeba, to wtedy się zainteresuję. Chociaż na razie się nie spodziewam.

Sztuką jest napisać program, który działa sprawnie i optymalnie, a nie ukrywanie niedociągnięć mocą obliczeniową. To, o czym tutaj mówimy to jest przecież sprawa nieskomplikowana. Trzeba podpiąć enkodery pod przerwania, zliczać im impulsy i wyświetlać to na jakimś wyświetlaczu... gdzie tu filozofia? Pewnie na zwykłej atmedze taktowanej 2MHz by się to dało zrobić, a Wy tutaj piszecie o czterordzeniowych prockach i armach No chyba, że wynik ma być na wyświetlaczu full HD podpiętym przez hdmi, to wtedy atmega nie wystarczy.

Avalyah pisze:Nie studiowałem też informatyki

Ja też nie, miałem to na przedmiocie powiązanym z elektroniką a studiowałem automatykę.

Avalyah pisze: No chyba, że wynik ma być na wyświetlaczu full HD podpiętym przez hdmi, to wtedy atmega nie wystarczy.

To i NanoPi NEO nie wystarczy bo nie ma wyjścia na monitor

Avalyah pisze:A takie rozwiązanie? Chińskie, bo chińskie, ale chyba do setki beda miały dokładnośc?

To przelicytuję o ok 20$ W sumie do tokarki to nawet z VAT-em zaczyna być ciekawie. Setkę powinno trzymać .

Avalyah pisze:Trzeba podpiąć enkodery pod przerwania

Pisałem wcześniej, że UNO może mieć problem przerwania są dwa a wyjść z enkoderów 6. Chyba żeby podpiąć odczyt pod któryś timer.

No to mega, ona ma bodajże 6 właśnie. Klon za 50zł można kupić sobie.

Yogi_ pisze:

Avalyah pisze:Trzeba podpiąć enkodery pod przerwania

Pisałem wcześniej, że UNO może mieć problem przerwania są dwa a wyjść z enkoderów 6. Chyba żeby podpiąć odczyt pod któryś timer.

Obsługę zerowania możnaby zrobić bez przerwania. Ale przerwania to jest złoooooo. Przykładowo ja przeliczam odległość na kolejne cyfry wyświetlacza. I co jeśli w takim momencie nastąpi przerwanie zmieniające tą odległość?
To jest przykład którego nie warto analizować. Ale pokazuję go po to aby uświadomić że przerwania zaburzają procesy w programie. Trzeba dbać o kopiowanie zmiennych do zmiennych zastępczych. W dużych programach powoduje to trudne do wykrycia bugi.

Ogólnie programy na Arduino i mikrokontrolery to masakra. Brakuje pamięci na stosowanie wzorców projektowych i klas. A bez tego nie da się wydajnie programować.
Dlatego ja stoję murem za komputerami jednopłytkowymi. One nie mają takich problemów, a wręcz przeciwnie. Dostarczają tysiące gotowych narzędzi, chociażby matematycznych czy sieciowych.
Jak starczy czasu to kiedyś zrobię frezarkę CNC sterowaną przez internet. Na komputerze jednopłytkowym to właściwie żaden problem. Ale chodzi raczej o dorobienie podajnika materiału.

Już chciałem odpowiedzieć na Twoje pytania ale przeczytałem ostatni post i...
Nie zwalaj winy na sterowniki wyświetlaczy, mikrokontrolery czy inne rzeczy. Jest takie stare przysłowie: "Złej baletnicy przeszkadza rąbek u spódnicy".
I odczep się od tych komputerów jednopłytkowych bo nie wiesz z czym masz do czynienia.

strikexp pisze:Obsługę zerowania możnaby zrobić bez przerwania.

A co ma piernik do wiatraka? Zerowanie wyświetlacza ma się nijak do odczytu stanu enkoderów. Kup Ty sobie choćby te 24-ro impulsowe enkodery z allegro i zobacz o co kaman. Enkoder ma dwa wyjścia i żadne nie służy do zerowania czegokolwiek. Poczytaj o kodzie Gray'a choć ten to akurat da się ogarnąć timerem lub albo poszukaj albo sam napisz procedury obsługi sygnałów wyzwalających na obu zboczach. Wymaga to przerwań niestety.

strikexp pisze:Ale przerwania to jest złoooooo. Przykładowo ja przeliczam odległość na kolejne cyfry wyświetlacza. I co jeśli w takim momencie nastąpi przerwanie zmieniające tą odległość?

Zacznie przeliczać raz jeszcze, co innego miałoby się dziać. Wg Ciebie impulsy lecą w eter bo przeliczasz coś?

Przerwania to jest podstawa i jak dla mnie jedna z największych zalet... A do tego, żeby Ci się cuda nie działy deklarujesz zmienne używane w przerwaniach i pętli głównej jako volatile. Zresztą to Twoje kalkulowanie odległości to powinno być kilka operacji, z jaką częstotliwością Ty się spodziewasz tych impulsów po korbce kręconej ręką, żeby przerywanie kalkulacji (potencjalne) dawało jakiekolwiek efekty widoczne na wyświetlaczu?

A co do tego, że bez klas nie da się wydajnie projektować... Taa, bo język C to wcale nie istnieje i nie jest stosowany powszechnie w programowaniu mikrokontrolerów.

Teorii o frezarkach sterowanych komputerkami nie będę komentował, bo po co, inni już powiedzieli wsyzstko, co trzeba. Spróbuj to rzeczywiście zrobić, to przestaniesz pisać herezje na forum

Czekam niecierpliwie na weekend, bo jak rozumiem wtedy to wszystko masz w planach zrobić. Mam nadzieję, że się swoimi rozwiązaniami tutaj podzielisz.

Yogi_ pisze:Kup Ty sobie choćby te 24-ro impulsowe enkodery z allegro

Mam i wiem jak działa. Zerowanie dotyczyło wykrycia naciśniecia przycisku bez użycia przerwania.

Avalyah pisze:z jaką częstotliwością Ty się spodziewasz tych impulsów po korbce kręconej ręką, żeby przerywanie kalkulacji (potencjalne) dawało jakiekolwiek efekty widoczne na wyświetlaczu?

To był taki przykład przerwanie procesu. Czy programując mikrokontrolery nie doszliście do takiego pojęcia jak proces ( nie, nie chodzi o te z Linuxa)?
To są problemy programów wielozadaniowych, wielowątkowych i ogólnie programów serwerowych z których korzysta więcej niż jeden klient jednocześnie.
Może tego nie pojmujecie bo mikrokontrolery są jednowątkowe i rzadko działaja jak serwery.
W dużych programach jak np aplikacje internetowe. Stosuje się bardzo skomplikowane struktury aby temu zaradzić. Więc radzę ostrożnie z teoriami że C to jest taki wspaniały język, ponieważ ktoś doświadczony może was wyśmiać. Owszem jest to szybki język, dla prostych programów. Ale w bardziej wymagających zastosowaniach wyparty niemal całkowicie przez obiektowe C++.
Obecnie to nawet odchodzi się od programowania w czystych językach. Wszystko przenosi się na frameworki. Jedynie w mikrokontrolerach to nie przechodzi, ponieważ tam nie ma tyle zasobów sprzętowych.

Avalyah pisze: Teorii o frezarkach sterowanych komputerkami nie będę komentował

Nie chodziło mi o sterowanie frezarką komputerem. Ale o zdalne jej uruchamianie przez sieć i wgrywanie projektu. Dla mnie to istotne bo nie opłaca mi sie jechać do warsztatu.