logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Pierwsze starcie z mikrokontrolerami (dozwolone linki Allegro, eBay, itp)

Ślepiec 31 Gru 2004 18:09 554568 2015
Najlepsze odpowiedzi

Jakie elementy, oprogramowanie i sposób programowania są potrzebne, żeby zacząć pracę z mikrokontrolerami?

Do startu potrzebujesz mikrokontrolera z pamięcią Flash, programatora, kompilatora/środowiska na PC, dokumentacji układu oraz prostego zestawu testowego z LED-ami i przyciskami; na początek polecano AVR-y Atmela, a znając C najlepiej pisać właśnie w C i wgrywać gotowy plik HEX przez ISP lub prosty programator typu STK200/300 [#1101096][#1101109][#1835895] Program powstaje na komputerze, kompiluje się do postaci binarnej/HEX, a programator zapisuje go do pamięci programu mikrokontrolera, często bez wylutowywania układu [#1101109][#1101096] Jako pierwszy krok warto kupić gotowy zestaw uruchomieniowy albo płytkę testową z AVR, bo pozwala uniknąć błędów własnej konstrukcji i szybciej zacząć eksperymenty [#1101149][#2824895]
Wygenerowane przez model językowy.
  • #1621 13074316
    tplewa
    Poziom 39  
    Posty: 6727
    Pomógł: 222
    Ocena: 988
    tronics napisał:
    @tplewa - czy ja wiem, np. LPC111x też nie są aż takimi strasznymi procesorami, oferują większą wydajność w typowych algorytmach i mają większą prędkość rdzenia niż nawet xmegi (które nota bene też otrzymały mnóstwo dodatkowych rejestrów w porównaniu z mega avr).


    Wiesz mi bardziej chodzi o przejscie z Arduino na C/C++ i ARMy... ja najpierw proponowal bym pocwiczyc pisanie samemu w C na jakims 8 bitowcu (bez wsparcia dodatkowych bibliotek)...

    Arduino jak Bascom sporo ulatwia, ale troche zatraca sie wiedze o dzialaniu mikrokontrolera... Pisze sie co prawda w C, ale nie potrzeba wiedzy o rejestrach itp. ot ma sie proste instrukcje pinMode, digitalWrite itp.


    Ja jak przechodzilem z 8/16 bitowcow na ARM-y to niestety musialem przebrnac i tak dosc bolesna droge przez dokumentacje (nie zawsze jasna)... Natomiast pisalem na rozne procki w ASM i C wiec jakas tam praktyke mialem. Pakowanie sie od razu w ARMy moze po prostu szybko zniechecic... Nie mowie ze to zly wybor... ale jak ma sie Arduino to mozna pobawic sie i na tej platformie pocwiczyc... Jak sie ogarnie dobrze AVRy to mozna pchac sie w ARMy
  • #1622 13074508
    piotrva
    VIP Zasłużony dla elektroda
    Posty: 6409
    Pomógł: 625
    Ocena: 734
    Popieram @tplewa - ogrom możliwości ARM może wiele osób przytłoczyć, poza tym AVR'y mają dużo czytelniejszą dokumentację.
  • #1623 13074669
    tmf
    VIP Zasłużony dla elektroda
    Posty: 14318
    Pomógł: 2090
    Ocena: 2203
    klami85 napisał:
    Czy ktoś kto przesiadł się z Arduino UNO na STM32 może mi krótko opisać z autopsji jak wyglądała taka przesiadka?

    Pytam bo brakuje mi mocy i portów w UNO i zastanawiam się czy brać tym razem DUE, czy iść w STM32.

    Na plus DUE jest banalne środowisko arduino IDE w pełni wystarczające do moich potrzeb, no i już je znam. Na minus cena.
    Z kolei STM32 np. discovery są tańsze. Tylko nie wiem jak wygląda w praktyce przestawienie się na nowe środowisko. Znam tylko C i to w stopniu średnim.


    Koledzy już ci wytłumaczyli jak wygląda przesiadka. Ja dodam jeszcze jedno - framework Arduino wprowadza tak koszmarne narzuty, że śmiało mogę zaryzykować stwierdzenie, że nie brakuje ci mocy, tylko ją marnujesz korzystając z frameworku Arduino. Zanim coś zmienisz (procesor), wywal cały Arduinowy kod i napisz to co chcesz w C. Zresztą i tak musisz zacząć od nauki C/C++ i podstaw mikrokontrolerów, bo nie ma Arduino na ARM - dlatego uważam, że pomimo licznych zalet, Arduino to taka sama ślepa uliczka jak Bascom.
  • #1624 13074683
    klami85
    Poziom 10  
    Posty: 19
    tplewa napisał:
    Niestety ale przesiadka z Arduino na jakikolwiek mikrokontroler bedzie bolesna... a STM32 czy jakikolwiek ARM jeszcze bardziej bolesna (to sa bardzo rozbudowane procesory o duzej licznie rejestrow itd.). Niestety rezygnujac z Arduino trzeba dosc mocno poznac mikrokontroler...


    tplewa napisał:

    Wiesz mi bardziej chodzi o przejscie z Arduino na C/C++ i ARMy... ja najpierw proponowal bym pocwiczyc pisanie samemu w C na jakims 8 bitowcu (bez wsparcia dodatkowych bibliotek)...

    Arduino jak Bascom sporo ulatwia, ale troche zatraca sie wiedze o dzialaniu mikrokontrolera... Pisze sie co prawda w C, ale nie potrzeba wiedzy o rejestrach itp. ot ma sie proste instrukcje pinMode, digitalWrite itp.


    tronics napisał:
    Jeśli koledze rzeczywiście brakuje mocy to ARMy mogą być rozwiązaniem - ale tylko jeśli RZECZYWIŚCIE brakuje mocy, a nie efektywności jej wykorzystania.


    Na arduino bardzo mi pomagają biblioteki i gotowe instrukcje zamiast operowania na rejestrach.
    Gdybym miał pisać program opierając się na rejestrach procesora to w zasadzie uczyłbym się od zera.
    Oczywiście jestem świadomy, że odwołując się bezpośrednio do rejestrów całość działa zdecydowanie szybciej, ale dla mnie jest to inny poziom świadomości. :|
    Jestem inżynierem, ale nie elektronikiem i nie programistą.

    Chcę wykorzystać kontroler do sterowania prostą obrabiarką (3 silniki krokowe + wyświetlacz + klawiatura + krańcówki obsługiwane przez przerwania).
    Teraz śmiga to sobie przez MACH3, a chcę zrobić tak, żeby gotowy plik PLT był przesyłany do mikrokontrolera i już bez uczestnictwa komputera całość była sterowana przez kontroler.
    Oczywiście jest to poziom hobby, a nie profesjonalny.

    Niestety arduino uno nie posiada jednostki zmiennoprzecinkowej i w związku z tym obliczanie ścieżki, jak i rampy dla silników krokowych jest strasznie powolne.
    Całość wprawdzie działa, ale bardzo wolno.

    Rozumiem, że przesiadając się na arduino DUE zachowuje prostotę programowania jak dotychczas, a zyskuje znacznie szybszy procesor.
    No i w już przygotowanym programie nie musiałbym dużo zmieniać.

    A jak wygląda pisanie programów pod STM32?
    Są dostępne jakieś darmowe biblioteki upraszczające całość do poziomu tego co jest w adruino IDE? Jestem świadomy, że jest to pójście na łatwiznę, i nie jest to optymalnie wykorzystanie możliwości procesora. Ale coś za coś.


    EDIT:
    tmf napisał:

    Koledzy już ci wytłumaczyli jak wygląda przesiadka. Ja dodam jeszcze jedno - framework Arduino wprowadza tak koszmarne narzuty, że śmiało mogę zaryzykować stwierdzenie, że nie brakuje ci mocy, tylko ją marnujesz korzystając z frameworku Arduino. Zanim coś zmienisz (procesor), wywal cały Arduinowy kod i napisz to co chcesz w C. Zresztą i tak musisz zacząć od nauki C/C++ i podstaw mikrokontrolerów, bo nie ma Arduino na ARM - dlatego uważam, że pomimo licznych zalet, Arduino to taka sama ślepa uliczka jak Bascom.


    C/C++ znam na poziomie wystarczającym do moich potrzeb, ale odwoływanie się bezpośrednio do rejestrów procesora to jak już pisałem inny poziom świadomości.

    Arduino DUE wg. wszelkich mi znanych źródeł jest na ARM - KLIK, a programuje się przez arduino IDE.
    W sumie nie uważam, że to ślepa uliczka. Od czegoś trzeba zacząć i do pewnych zastosowań jest to najprostsze rozwiązanie.
  • #1625 13074765
    tplewa
    Poziom 39  
    Posty: 6727
    Pomógł: 222
    Ocena: 988
    To jak nie masz checi na nauke (nie lubie tlumaczen ze ktos cos tam, a nie cos tam ;) ) to zostaje ci tylko arduino DUE... o innych ARM-ach mozesz zapomniec i tyle...

    Na STM32 jest co prawda biblioteka (standard peripheral library), ale ona nie jest na takim poziomie jak Arduino i tak trzeba sporo wiecej wiedziec... inna sprawa to to ze jest ona kiepska, dokumentacji praktycznie brak i jak cos nie dziala (dosc czesto) to jest za zwyczaj masakra w dojsciu co jest problemem...

    Do tego wymieniony ARM nie ma FPU, a jak chcesz korzystac z FPU czy innych wyspecjalizowanych instrukcji, DMA itd. to czeka cie pisanie w C... Po prostu nie ma szans napisac taki framework by optymalnie wykorzystac wszystkie bloki jakie masz w tych procesorach.

    IMHO pchasz sie z motyka na slonce z wymienionym projektem jak nie chcesz pisac w C... i ma miec to funkcjonalnosc MACH-a oraz dzialac z rozdadna predkoscia...


    Jesli chodzi o STM32 to mozesz jeszcze uzyc ChibiOS/RT ktory ma warstwe HAL... ale wlasnie ale... jak cos chce sie przyzwoicie zrobic to okazuje sie ze nie da rady ot przyklad z wlasnego doswiadczenia:

    https://www.elektroda.pl/rtvforum/topic2475236.html#11819365

    ot nie szlo zrealizowac czegos co w C to kilkanascie linijek kodu... wlasnie przez niezbyt uniwersalna warstwe HAL...
  • #1626 13075134
    alagner
    Poziom 26  
    Posty: 768
    Pomógł: 85
    Ocena: 29
    Są jeszcze RTOS z warstwą HAL (abstrakcji sprzętu), typu ChibisOS/RT, ale to dla nowicjusza to jeszcze większa motyka ;) Aczkolwiek jak się w to człowiek wgryzie to jest to bardzo wygodne rozwiązanie.
  • #1627 13075427
    klami85
    Poziom 10  
    Posty: 19
    tplewa napisał:

    IMHO pchasz sie z motyka na slonce z wymienionym projektem jak nie chcesz pisac w C... i ma miec to funkcjonalnosc MACH-a oraz dzialac z rozdadna predkoscia...


    Nieprecyzyjnie się wyraziłem. To nie ma być zamiennik dla macha bo wówczas to rzeczywiście porwałbym się z motyką na słońce.
    Ma to być coś w stylu RAMPS, które z powodzeniem działa na Arduino MEGA. Tylko, że w moim przypadku nie używam małego shielda tylko normalnego sterownika CNC.
    Wszystko by mi działało na arduino, tylko, że z racji większych szybkości atmega już nie nadąża przeliczać i generować impulsów STEP z rozsądnymi prędkościami (potrzebuje nawet do 32000 impulsów/s dla każdego z silników bo mam sterownie z mikrokrokiem 16) i stąd mój pierwszy post.

    Potrzebuje mocniejszy procesor i nie wiem tylko w którą stronę iść, żeby zrobić i się nie narobić.
  • #1628 13075510
    piotrva
    VIP Zasłużony dla elektroda
    Posty: 6409
    Pomógł: 625
    Ocena: 734
    Potrzebujesz lepszego algorytmu, a nie procesora.
    Piszesz o obliczeniach zmiennoprzecinkowych - zastanów się czy nie można ich zastąpić stałoprzecinkowymi lub nawet całkowitoliczbowymi - zyskasz potężny przyrost wydajności.
    Dalej to co pisali przedmówcy - największy narzut to także samo Arduino - niestety szybko nie równa się prosto - jeśli chcesz coś podziałać to na prawdę zajmij się przewertowaniem dokumentacji procesora stosowanego w Arduino i zastąp instrukcje biblioteczne operacjami na rejestrach.
  • #1629 13076629
    tplewa
    Poziom 39  
    Posty: 6727
    Pomógł: 222
    Ocena: 988
    @klami85

    To ja jednak radze zrezygnowac z ARMow... posiedz troche nad AVRami aby je lepiej opanowac (nie jest to takie trudne i lepiej wykorzystasz czas), potem przesiasc sie na XMega i bedzie znacznie latwiej. Zwlaszcza ze jest troche literatury ktora pozwoli szybko ogarnac temat...

    Pchanie sie dalej w Arduino to IMHO marnowanie czasu i pieniedzy. Nawet biorac tego ARMa znowu wyjdzie ze masz jakies ograniczenia ktore trudno bedzie ominac jak ktos nie napisze jakiejs biblioteki... no i wrocisz do punktu wyjscia...

    Do tego nie potrzeba byc tutaj elektronikiem czy programista, mam kumple po gastronomii i hotelarstwie ktory nauczyl sie C na AVRach i calkiem niezle sobie radzi... wszystko to kwestia checi :)
  • #1630 13078424
    Konto nie istnieje
    Poziom 1  
  • #1631 13078935
    klami85
    Poziom 10  
    Posty: 19
    Dzięki za porady. Spróbuje w takim razie zgłębić temat rejestrów.
    Z książek przeczytałem jedynie anglojęzyczną Arduino programing - Brian Evans.
    Tam jest wszystko robione z wykorzystaniem biblioteki arduino. Jest chyba jeden przykład pokazujący jakby wyglądał ten sam kod bez użycia tej biblioteki czyli wersja AVR. Dla mnie wyglądało to jak jakaś chińszczyzna.

    Co do przejścia na liczby całkowite to dla mojego algorytmu nie jest to możliwe, gdyż dla każdego kroku muszę obliczać pierwiastek kwadratowy. :cry:
    Znalazłem coś takiego Generate stepper-motor speed profiles in real time. Wyprowadzono tutaj ładny wzór aproksymujący funkcję którą używam. Odpada dzięki temu pierwiastkowanie, więc powinno być dużo szybciej.
    Dodatkowo na CNC forum, ktoś miał podobny problem i powstał z tego spory temat przez który muszę teraz przebrnąć.
    Dodam, że zajrzałem na ostatnią stronę wspomnianego tematu, a tam link do arduino DUE oraz innych arduino kompatybilnych płytek z ARMem, więc jednak coś jest na rzeczy jeżeli chodzi o możliwości obliczeniowe tej atmegi w UNO.
  • #1632 13079153
    leonow32
    Poziom 30  
    Posty: 2027
    Pomógł: 37
    Ocena: 1232
    Jak Ty sterujesz tymi silnikami krokowymi, że potrzebujesz tyle pierwiastków liczyć? Nawet jeśli to rzeczywiście potrzebne, to może poszukaj jakiejś sprytniejszej metody
    http://pl.wikipedia.org/wiki/Metody_obliczania_pierwiastka_kwadratowego
    albo na innych stronach

    Kiedyś zrobiłem taki trik by liczyć pierwiastki bez liczb zmiennoprzecinkowych. Liczbę przemnożyłem przez 1000, potem wyliczyłem pierwiastek ze standardowej biblioteki math.h i w wyniku dostajesz liczbę z precyzją do 2 miejsc po przecinku, tyle że bez przecinka ;)

    Możesz też spróbować tablicę wyników. Zdecydowanie to przyspieszy obliczenia, jako że odczytujesz gotowy wynik albo co najwyżej interpolujesz. Jedyny haczyk jest taki, im dokładniejsza tablica tym więcej pamięci zajmie. Niegłupie może być zastosowania pamięci równoległej jako tablicy wyników - na magistralę adresową podajesz liczbę do spierwiastkowania, a z magistrali danych odczytujesz wynik.
  • #1633 13079270
    tplewa
    Poziom 39  
    Posty: 6727
    Pomógł: 222
    Ocena: 988
    Generalnie trzeba troche liczyc :) ale z innej beczki to ja i tak proponowal bym to zrobic na dsPIC
    Kiedys troche sie bawilem z takim tematem do frezarki, z tym ze takie pseudo serwa tzn. krokowy + enkoder +33FJ128MC + IRS2186 + IRF630... uzyskiwalo sie na prawde super dynamike... Ale projekt na razie lezy z powodu braku mozliwosci wykonania solidnej ramy do frezarki (a przynajmniej na razie nie znalazlem kto to zrobi mi z wyrzazaniem itd. w Warszawie za jakies rozsadne pieniadze)... Moze kiedys jak bede mial wiecej zbednej kasy to wroce do projektu :)
  • #1634 13079410
    klami85
    Poziom 10  
    Posty: 19
    Z ciekawych z mojego punktu widzenia płytek znalazłem na CNCforum jeszcze linki do takich:
    1) OLIMEXINO-STM32 - Program pisze się w MAPLE
    2) ZPUino - Program pisze się w zmodyfikowanym Arduino IDE

    Dobre porównanie szybkości tych układów dla banalnego programu: klik
    Biorąc po uwagę śmieszną cenę kilkudziesięciu złociszy stwierdzam, że będę miał nową zabawkę na święta.

    leonow32 napisał:
    Jak Ty sterujesz tymi silnikami krokowymi, że potrzebujesz tyle pierwiastków liczyć?

    Co do liczenia pierwiastków to przy obliczaniu rampy - przyśpieszenia/hamowania jest to chyba najdokładniejsza metoda i najprostszy wzór. Dlatego od tego zacząłem.
    Jest to w linku z mojego poprzedniego posta. Odpowiedź na Twoje pytanie kończy się przy równaniu nr 8.
  • #1635 13079480
    tmf
    VIP Zasłużony dla elektroda
    Posty: 14318
    Pomógł: 2090
    Ocena: 2203
    Brniesz w ślepą uliczkę, mimo, że wszyscy ci o tym piszą. Problemem nie jest procesor, jego wymiana na szybszy, co najwyżej opóźni moment w którym uświadomisz sobie problem. Masz do kitu algorytm, sugerujesz się teoretycznymi wzorami, które... są tylko teorią, niestosowaną w praktycznych implementacjach. Zapewniam cie, że nawet do najbardziej wymyślnego sterowania silnikami żadne pierwiastki i obliczenia zmiennopozycyjne nie są potrzebne.
    Czyli na teraz masz do ogarnięcia dwie sprawy:
    - poprawę algorytmu,
    - naukę C i obsługi peryferii procesora.
    Możesz sobie wmawiać, że kupno ARMa rozwiąże problem, ale to tylko pobożne życzenia. Pierwszy problem na jaki się natkniesz to zapewne przeniesienie bibliotek. I na tym utkniesz na amen.
    Z drugiej strony i ARM i XMEGA posiadają podsystemy peryferyjne umożliwiające sprzętową kontrolę silników - każdy, nawet najgorzej napisany program korzystający z tych sprzętowych ułatwień, będzie dziesiątki razy szybszy niż emulacja softwarowa i setki razy szybszy niż niedostosowana biblioteka z Arduino. Przed koniecznością nauki nie uciekniesz...
  • #1636 13079617
    tplewa
    Poziom 39  
    Posty: 6727
    Pomógł: 222
    Ocena: 988
    Kolega tmf dobrze to podsumowal, a na CNC forum nie patrz bo jest tam niewiel osob ktore sa w stanei zrobic sensowne sterowanie... a ci co potrafia sprzedaja komercyjnie swoje produkty... Wiec albo robisz sam solidnie, albo lepiej kupic gotowca... Cos za cos... bo na Arduino dobrze tego nie zrobisz...

    Jak uzyjesz procka z serii MoterControl to wywalisz sterowniki i zrobisz ladne sterowanie silnikow z procka, z tym ze tutaj potrzebujesz robic pomiar pradu i miec jakis sprzetowy Fault... bo rozumiem ze obecnie moduly sterujace krokowcami uzywasz jakies gotowe i potrzebujesz sterowac jedynie STEP/DIR/ENABLE... Jak zrobisz to solidnie to za jakis czas bedziesz mogl dodac enkodery i miec krokowce popierniczajace niemal jak serwa i calosc za o wiele mniejsza kase... Choc budowa solidnej CNC to i tak nie mala kasa wiec tutaj nie ma co robic bubla w postaci elektroniki na Arduino...
  • #1637 13079719
    klami85
    Poziom 10  
    Posty: 19
    tmf napisał:
    Masz do kitu algorytm, sugerujesz się teoretycznymi wzorami, które... są tylko teorią, niestosowaną w praktycznych implementacjach.


    A skąd brać wiedzę jak to robią w praktyce?
    Jakaś szybsza ścieżka niż metoda prób i błędów i wymyślania koła od nowa?

    Już postanowiłem, że pójdę w stronę rejestrów, więc to nie jest ślepa uliczka.

    Plan jest taki:
    1) Na tą chwilę zostaje na arduino IDE.
    2) Wymieniam powoli w miarę zdobywania doświadczenia instrukcje realizowane przez bibliotekę arduino na te realizowane na rejestrach.
    To chyba dobre podejście?

    Czy jeżeli zamiast arduino IDE będę używał maple, a zamiast rejestrów atmegi będę się wdrażał w rejestry ARM to już zły plan?
  • #1638 13079798
    tplewa
    Poziom 39  
    Posty: 6727
    Pomógł: 222
    Ocena: 988
    O ARM-ach zapomnij przynajmniej na razie... jak poznasz AVR-y to bedzie ci latwiej jak mowilem isc w strone XMEGA...

    IDE Bym zmienil... generalnie polecam ksiazki jakie tmf ma w podpisie... bedzie milo i przyjemnie. Kumel o ktorym wspomnialem uczyl sie z tej pierwszej...

    Jak bedziesz mial problem z kodem to na pewno ktos pomoze w dziale AVR-ow, wiec tez zaleta...
  • #1639 13079843
    leonow32
    Poziom 30  
    Posty: 2027
    Pomógł: 37
    Ocena: 1232
    klami85 napisał:
    leonow32 napisał:
    Jak Ty sterujesz tymi silnikami krokowymi, że potrzebujesz tyle pierwiastków liczyć?

    Co do liczenia pierwiastków to przy obliczaniu rampy - przyśpieszenia/hamowania jest to chyba najdokładniejsza metoda i najprostszy wzór. Dlatego od tego zacząłem.
    Jest to w linku z mojego poprzedniego posta. Odpowiedź na Twoje pytanie kończy się przy równaniu nr 8.

    Ten wzór jest do d... Kiedyś budowałem ploter z interpreterem HPGL na ATmega128 i pierwiastkowanie było mi potrzebne wyłącznie do rysowania kółek z równania okręgu. Do normalnej jazdy po prostej z prędkością stałą lub zmienną - żadne pierwiastkowanie nie jest potrzebne! Procesor tak naprawdę przez większość czasu nic nie robił, tylko odliczał czas do wykonania kroku silników.

    W poprzedniej pracy mieliśmy bardzo zabytkową maszynkę do nakładania elementów SMD, która miała możliwość regulacji prędkości i przyspieszeń w czterech osiach, a w środku siedział procesor... Z80 :) :) :) jakoś dali radę to zaprojektować bez Arduino i mega wypasionych procesorów.
  • #1640 13079887
    klami85
    Poziom 10  
    Posty: 19
    leonow32 napisał:

    Do normalnej jazdy po prostej z prędkością stałą lub zmienną - żadne pierwiastkowanie nie jest potrzebne! Procesor tak naprawdę przez większość czasu nic nie robił, tylko odliczał czas do wykonania kroku silników.


    Przy stałej prędkości nie jest potrzebne, przy skokowej zmianie prędkości też nie jest potrzebne.
    A kiedy jest potrzebne? Do łagodnego przyśpieszania i hamowania.

    Pomyśl co by się stało, gdybyś wyhamował samochodem od 100km/h do 0km/h w ciągu 0,01s. Czyli skokowa zmiana prędkości.
    Oczywiście to jest sytuacja przerysowana, ale ważąca kilkanaście kg część maszyny też nie zatrzyma się od razu w miejscu bez konsekwencji. :!:

    PS. Zmieniłem kilka linijek w kodzie i popierdziela aż miło. Przynajmniej na sucho.
    Jutro sprawdzę na maszynie.
  • #1642 13080395
    tmf
    VIP Zasłużony dla elektroda
    Posty: 14318
    Pomógł: 2090
    Ocena: 2203
    leonow32 napisał:
    klami85 napisał:
    leonow32 napisał:
    Jak Ty sterujesz tymi silnikami krokowymi, że potrzebujesz tyle pierwiastków liczyć?

    Co do liczenia pierwiastków to przy obliczaniu rampy - przyśpieszenia/hamowania jest to chyba najdokładniejsza metoda i najprostszy wzór. Dlatego od tego zacząłem.
    Jest to w linku z mojego poprzedniego posta. Odpowiedź na Twoje pytanie kończy się przy równaniu nr 8.

    Ten wzór jest do d... Kiedyś budowałem ploter z interpreterem HPGL na ATmega128 i pierwiastkowanie było mi potrzebne wyłącznie do rysowania kółek z równania okręgu.


    Do okręgów pierwiastkowanie też nie jest potrzebne - patrz algorytm Bresenhama. Istnieją jego jeszcze szybsze modyfikacje. Poza oczywistą zaletą jaką jest szybkość, jest on wygodny w implementacji bo daje ci po prostu liczbę kroków X i Y.

    Dodano po 7 [minuty]:

    klami85 napisał:
    tmf napisał:
    Masz do kitu algorytm, sugerujesz się teoretycznymi wzorami, które... są tylko teorią, niestosowaną w praktycznych implementacjach.


    A skąd brać wiedzę jak to robią w praktyce?
    Jakaś szybsza ścieżka niż metoda prób i błędów i wymyślania koła od nowa?

    Już postanowiłem, że pójdę w stronę rejestrów, więc to nie jest ślepa uliczka.

    Plan jest taki:
    1) Na tą chwilę zostaje na arduino IDE.
    2) Wymieniam powoli w miarę zdobywania doświadczenia instrukcje realizowane przez bibliotekę arduino na te realizowane na rejestrach.
    To chyba dobre podejście?

    Czy jeżeli zamiast arduino IDE będę używał maple, a zamiast rejestrów atmegi będę się wdrażał w rejestry ARM to już zły plan?


    No cóż, niestety programowanie to w dużej mierze wymyślanie koła od nowa. Jak widzisz wiedza ma swoją cenę, osoby, które ją posiadły raczej ją sprzedają (np. w postaci gotowych modułów), a nie dają.
    IMHO metoda stopniowej podmiany kodu jest błędna - trzeba siąść i napisać to od nowa - filozofia Arduino nijak ma się do szybkości i wykorzystania możliwości oferowanych przez sprzęt. Taka podmiana instrukcji coś da, ale efekt końcowy będzie niezadowalający.
    Zacznij przede wszystkim od teorii sterowania silnikami - kilka razy google kierowało mnie na CNC forum i generalizując układy elektryczne sterowników, które tam pokazują to elektronika sprzed 20-30 lat, a rozwiązania softwarowe to poziom przedszkola (uogólniam, nie chcę nikogo obrazić, bo dobre rozwiązania i przykłady też się zdarzają). Poczytaj noty katalogowe sterowników silników wiodących producentów i ich noty aplikacyjne - jest tam mega ilość przydatnych i praktycznych informacji. Dowiesz się jak robić akcelerację i decelerację w praktyce a nie w teorii. I Atmel i producenci ARMów mają świetne noty aplikacyjne wraz z gotowymi przykładowymi kodami w C. Nic tylko się wgryzać w długie zimowe wieczory.

    Dodano po 7 [minuty]:

    klami85 napisał:
    leonow32 napisał:

    Do normalnej jazdy po prostej z prędkością stałą lub zmienną - żadne pierwiastkowanie nie jest potrzebne! Procesor tak naprawdę przez większość czasu nic nie robił, tylko odliczał czas do wykonania kroku silników.


    Przy stałej prędkości nie jest potrzebne, przy skokowej zmianie prędkości też nie jest potrzebne.
    A kiedy jest potrzebne? Do łagodnego przyśpieszania i hamowania.

    Pomyśl co by się stało, gdybyś wyhamował samochodem od 100km/h do 0km/h w ciągu 0,01s. Czyli skokowa zmiana prędkości.
    Oczywiście to jest sytuacja przerysowana, ale ważąca kilkanaście kg część maszyny też nie zatrzyma się od razu w miejscu bez konsekwencji. :!:

    PS. Zmieniłem kilka linijek w kodzie i popierdziela aż miło. Przynajmniej na sucho.
    Jutro sprawdzę na maszynie.


    Krzywe akceleracji i deceleracji najprościej stabelaryzować. Jeśli np. sterujesz krokowcem to kolejne kroki komutacji można wrzucić do tabeli a szybkość ich wykonywania regulować timerem, dla którego kolejne odstępy też są w tabeli. Jeśli masz w miarę nowoczesny procek (XMEGA, część ARM), to masz np. coś co się nazywa pattern generator. Wtedy robisz tak:
    - tabele komutacji, tabele akceleracji/deceleracji
    - timer generujący zdarzenia (czas kolejnych kroków komutacji),
    - zdarzenia sterują DMA, który wrzuca gotowe kroki do pattern generator.
    - do tego łączysz to z układem wykrywania fault condition, lub z ADC, którego zdarzenie (przekroczenie progu prądu) generuje np. przejście do kolejnego kroku komutacji, lub zmianę sterowania dzięki czemu uzyskasz pracę mikrokrokową.
    Współczesne procki mają na tyle rozwinięte peryferia, że złożone schematy sterowania można zrobić praktycznie całkowicie sprzętowo. Potrzebna do tego moc obliczeniowa jest praktycznie żadna.
  • #1643 13091227
    Krzychu.B.
    Poziom 11  
    Posty: 23
    Ocena: 3
    Mam jeszcze jedno pytanko odnośnie AVRów a konkretnie ATMGEA 8. Otóż chcę zbudować sobie przetwornik sygnału analogowego na cyfrowy, i tu mam problem:
    Wiem, ze ATMEGA 8 ma wewnętrzny zegar, który umożliwia np. odczekanie zadanego czasu dzięki funkcji _delay_ms(wartosc), a czy jest możliwość obliczenia czasu pomiędzy np. dwoma impulsami otrzymanymi przez kontroler na wejściu? Np. w pętli nieskończonej:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Z tego co wygooglowałem to rozumiem, że muszę kombinować z przerwaniami. A da się to zrobić jakoś inaczej?
  • #1645 13092596
    leonow32
    Poziom 30  
    Posty: 2027
    Pomógł: 37
    Ocena: 1232
    Krzychu.B. napisał:
    Mam jeszcze jedno pytanko odnośnie AVRów a konkretnie ATMGEA 8. Otóż chcę zbudować sobie przetwornik sygnału analogowego na cyfrowy, i tu mam problem:

    Porzuć tego przestarzałego dinozaura sprzed 12 lat i wypróbuj nowe XMEGA, np ATxmega16A4U albo ATxmega32E5 - oba mają wbudowany przetwornik cyfrowo-analogowy. Wpisujesz do niego wartość napięcia jaka ma się pojawić i to od razu działa :) bez cudowania z PWM albo drabinkami R-2R
  • #1646 13110369
    mobiline
    Poziom 11  
    Posty: 31
    No dobra Miśki. Ostatnio rozkminiam taki temat. XMEGA czy ARM ? Załóżmy, że oba podkręcone na PLL do 150MHz. Jak wielka jest przepaść między nimi ? ARM wiadomo 32bity, lepsza ( jak bardzo ) wydajność. Czemu pytam . Kiedyś kilkanaście lat temu pisałem na '51 , potem do teraz na AVR, ale chcę iśc o poziom wyżej . Czy jest sens sie pchać a ARMy ? Czy XMEGI wystarczą na moje potrzeby ? Jakaś drobna grafika na TFT + dotyk , raczej wolnozmienna , do tego moduł Ethernetowy plus troche zapasu na resztę programu. Pytam bo łatwiej będzie mi wejść w XMEGI niż ucząc się od nowa czegoś nowego. Za wszelkie wskazówki , podziękował :)
    pozdrawiam
  • #1647 13110621
    tronics
    Poziom 38  
    Posty: 5038
    Pomógł: 358
    Ocena: 838
    Myślę, że już podobnych tematów było całkiem sporo. Czemu nie użyjesz wyszukiwarki forumowej by je odnaleźć? Jeśli chodzi o to na co raczej tam nie ma odpowiedzi, to udzielę tutaj. Xmega ma fabrycznie max 32MHz fcpu i OC do 150MHz nie wchodzi w grę, tak samo zresztą jak nie podkręcisz o tyle LPC111x (max fcpu 50MHz, osiągalne stabilne oc około 80 - wyżej są problemy z flash). Inna sprawa, że znajdziesz bez problemu ARM pracującego w 150MHz.
  • #1648 13111270
    leonow32
    Poziom 30  
    Posty: 2027
    Pomógł: 37
    Ocena: 1232
    mobiline napisał:
    Czy jest sens sie pchać a ARMy ? Czy XMEGI wystarczą na moje potrzeby ?

    To jest pytanie na które sam musisz sobie odpowiedzieć ;) jeśli potrzebujesz przetwarzać duże ilości danych zmiennoprzecinkowych to bierz się za STM32F4. XMEGA to jak ktoś opisał "AVR na sterydach" i rzeczywiście tak jest. Wszystkie peryferia zostały zaprojektowane od nowa, rdzeń procesora też jest odświeżony i zmieniła się trochę metodologia pisania programów. Ale to nie są na tyle duże zmiany by trzeba było ślęcześ na dokumentacjami przez długie zimowe wieczory - jeśli znacz tradycyjne AVRy to w kilka godzin załapiesz jak to się programuje. A XMEGA możliwości ma naprawdę sporo, np. ludzie oscyloskopy na tym robią z FFT i całkiem fajnie to wychodzi. Od kiedy wziąłem się za XMEGA to na starych AVR-ach już nic więcej nie robiłem :)

    Tu masz kurs programowania mikrokontrolerów XMEGA na dobry początek.
  • #1649 13112957
    mobiline
    Poziom 11  
    Posty: 31
    Dzięki za odp. Trochę mi się naświetliło , ale resztę chyba sam sobie dopowiem. Zaciekawiło mnie natomiast, że STM32 DISCOVERY F4 ma wbudowane kwarce 8MHz i obsługuje z powodzeniem TFT z dotykiem. No ale jakby nie patrzeć to 32bitowce więc wydajność lepsza od 8bitów. @Leonow kurs znam i chyba przejdę na XMEGA. Dzięki raz jeszcze za odp
    pozdrawiam
  • #1650 13113026
    tmf
    VIP Zasłużony dla elektroda
    Posty: 14318
    Pomógł: 2090
    Ocena: 2203
    Kwarc może być 8 MHz i to nic nie znaczy - i ARM i XMEGA mają układy PLL dzięki czemu można częstotliwość kwarcu przemnożyć, np. PLL w XMEGA mnoży w zakresie 1-31 razy.
REKLAMA