Elektroda.pl
Elektroda.pl
X
IGE-XAOIGE-XAO
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

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

Ślepiec 29 Gru 2013 20:11 532509 2015
  • #1651
    mobiline
    Poziom 11  
    tronics napisał:
    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.
    Czyli PLL w XMEGA nie działa stabilnie i nie wszystkie podukłady będą działać prawidłowo a w ARMach chodzi jak należy ? W datascheet pisze tylko że fcpu nie powinno być większe niż 200MHz . Jakieś szczegóły ?
  • IGE-XAOIGE-XAO
  • #1652
    tmf
    Moderator Mikrokontrolery Projektowanie
    mobiline napisał:
    tronics napisał:
    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.
    Czyli PLL w XMEGA nie działa stabilnie i nie wszystkie podukłady będą działać prawidłowo a w ARMach chodzi jak należy ? W datascheet pisze tylko że fcpu nie powinno być większe niż 200MHz . Jakieś szczegóły ?


    Przeczytaj dokładniej tą notę...
    PLL w XMEGA chodzi tak samo stabilnie jak w ARM, problem jest w maksymalnej dopuszczalnej przez producenta częstotlwości taktowania rdzenia. W XMEGA jest to 32 MHz, w ARM Cortex M0 zazwyczaj max 48 MHz.
  • IGE-XAOIGE-XAO
  • #1653
    mobiline
    Poziom 11  
    Czyli np. podpinam kwarc 8 MHz , przemnażam w PLL razy 12 i daje nam 96 MHz. W takim wypadku i XMEGA i ARM będą miały jednakową stabilność pracy ?
  • #1654
    tmf
    Moderator Mikrokontrolery Projektowanie
    W takim wypadku w przypadku XMEGA z pewnością jesteś poza zakresem dopuszczalnych częstotliwości taktowania rdzenia (jeszcze kwestia preskalera), a w przypadku ARM być może jesteś poza zakresem dopuszczalnych częstotliwości. To, że PLL coś może nie znaczy, że trzeba z tego korzystać. W XMEGA preskaler umożliwia wygenerowanie zegara o częstotliwości 200 MHz, nie znaczy to jednak, że tak szybko może być taktowany CPU...
    Poczytaj noty obu rodzin procesorów, jakie w nich występują zegary i do czego służą. Bo tu już nie jest tak prosto jak było w starych AVR - jeden zegar taktujący wszystko. Tu występuje kilka różnych zegarów (np. taktujący CPU, taktujący niektóre peryferia, czy interfejsy).
  • #1655
    leonow32

    Poziom 30  
    Co rozumiesz przez "stabilność pracy"? Jeśli chodzi o zabezpieczenie przez zawieszeniem się na skutek zaniku sygnału zegarowego to XMEGA ma ciekawy układ monitorujący sygnał zegarowy. W razie błędu automatycznie zostanie uruchomiony wbudowany generator 2MHz i zostanie zgłoszone przerwanie.

    W XMEGA poszczególne peryferia procesora mogą być taktowane różnymi zegarami. Rdzeń procesora chodzi max na 32MHz, ale niektóre układy mogą działać nawet na 128MHz (np. timery).
  • #1656
    tmf
    Moderator Mikrokontrolery Projektowanie
    leonow32 napisał:

    W XMEGA poszczególne peryferia procesora mogą być taktowane różnymi zegarami. Rdzeń procesora chodzi max na 32MHz, ale niektóre układy mogą działać nawet na 128MHz (np. timery).


    A nawet lepiej, bo w nowszych XMEGA można wykorzystywać oba zbocza zegara timera, co daje efektywne taktowanie timera równe 256 MHz!
  • #1657
    tplewa
    Poziom 38  
    mobiline napisał:
    Czyli np. podpinam kwarc 8 MHz , przemnażam w PLL razy 12 i daje nam 96 MHz. W takim wypadku i XMEGA i ARM będą miały jednakową stabilność pracy ?


    W ARM zalezy to od rdzenia i jest to zalezne od typu ukladu, gwarantowana czestotliwosc pracy podawana jest w nocie katalogowej procesora. Do tego sam zegar to nie wszystko tam jest dosc rozbudowane rozprowadzanie zegara do peryferiow i w niektorych warunkach nie mozna np. pracowac na minimalnej czy maksymalnej czestotliwosci bo przykladowo jakis blok przy danych podzialach moze nie dzialac ot. np. USB...

    Ale to temat na dluzsza dyskusje. Osobiscie jak bawiles sie AVR-ami pobawil bym sie z XMega na twoim miejscu... jak bedzie malo to mozesz przejsc na ARM-y, ale tutaj czeka cie nauka niemal od zera bo to calkiem inne procesory...

    Co do TFT to wiele zalezy od rozdzielczosci i co to wedlug ciebie wolno zmienna ;) ale mysle ze XMega sobie poradzi, a jak przegniesz z rozdzielczoscia i bedziesz chcial szybko cos rysowac na calym ekranie to i taki ARM 168MHz moze byc malo... Problemem jest tutaj najczesciej brak w wyswietlaczach Frame Buffora, a procek ma za malo RAM by taki stworzyc wiec rysujesz na bierzaco i aby nie bylo widac migotania sa pewne ograniczenia...

    Generalnie jesli chodzi o STM32F4 to wystepuja w wersjach 168MHz i 180MHz... teoretycznie da sie podkrecic do 200MHz... ale w kilu przypadkach przy 200MHz mialem problemy wiec lepiej trzymac sie tego co podaje dokumentacja (przynajmniej ja tak robie) bo potem nie do konca wiadomo co jest przyczyna problemu jak dzieja sie dziwne rzeczy...

    stm32f4 discovery ma w sumie przyzwoita cene i jak nie szkoda ci kasy mozesz kupic i ocenic czy poradzisz sobie z tymi prockami... Ale jak mowilem bedzie duzo trudniej niz przesiadka z AVR na XMega... (na poczatku ARMy moga nawet lekko zniechecic - do czasu przebicia sie przez ReferenceManual i dosc zawila dokumentacje nie zawsze w calosci dostepna u producenta procesora). Przynajmniej ja sporo nerwow stracilem przy dokumentacji SMT32 :)


    Do XMega masz tak samo bardo dobra ksiazke kolegi tmf, a do ARM-ow praktycznie w jezyku polskim nic sensownego nie znajdziesz...
  • #1658
    mobiline
    Poziom 11  
    Chyba jednak zostanę przy XMEGA. Wymagań nie mam wygórowanych, a jak braknie mocy przeliczeniowej, wezmę się za ARMy. Chyba że coś nowszego wejdzie pod strzechy :) Z dokumentacją nie ma problemu, sporo jest również kursów na XMEGA dzięki obecnym tutaj przodownikom AVR :) W ARMy nie pcham się na razie głównie z powodu braku czasu na naukę a trochę jest tego. Dzięki za odpowiedzi. Wszystkiego dobrego w Nowym Roku :)
    pozdrawiam
  • #1659
    Tomq
    Poziom 38  
    Jest możliwość zrobienia stopera/minutnika z poczwórnym wyświetlaczem 7-segmentowym używając mikrokontrolera z rodziny atmega?

    Wyświetlacze najlepiej multipleksować w przerwaniach timera, żeby mieć pewność, że każda cyfra będzie wyświetlana jednakową ilość czasu. Odmierzanie czasu dla stopera/minutnika oczywiście też trzeba oprzeć na przerwaniach timera.


    I tu pojawia się problem - czy jest możliwe zrobić to gdy atemga nie posiada systemu priorytetu przerwań? Nie może jedno przerwanie zostać przerwane przez inne przerwanie.

    Załóżmy, że będziemy używali dwóch różnych rejestrów timera (albo nawet dwóch różnych timerów). Pierwszy timer będzie generował przerwanie, załóżmy co 3ms, do multiplekosowania wyświetlacza, a drugi timer będzie co 1 skunde zwiększał liczbę policzonych sekund. Co jeśli jednak oba przerwania wypadną w tym samym momencie? Załóżmy, że przerwanie stopera będzie musiało zostać obsłużone po multipleksowaniu wyświetlacza, czyli będzie musiało na nie poczekać. A czekanie oznacza tu zmniejszenie dokładności odmierzanego czasy.
  • #1660
    tplewa
    Poziom 38  
    To mozna zrobic na jednym przerwaniu :) To od multipleksowania wywolujesz co okreslony czas wiec znasz interwal i mozesz tak samo na jego podstawie zwiekszac wartosc licznika czyli czasu. Ewentualnie mozna wykorzystac RTC itp. Do tego jak chcesz zliczac co 1s to tutaj nie ma wiekszego znaczenia bo lekkie opoznienie by dodac 1s nie ma znaczenia przy takiej rozdzielczosci. Do tego w AVR wykona sie pierwsze przerwanie o wyzszym priorytecie ktore sa ustalone na stale, patrz na tablice wektorow przerwan.
  • #1661
    leonow32

    Poziom 30  
    Tomq napisał:
    Załóżmy, że będziemy używali dwóch różnych rejestrów timera (albo nawet dwóch różnych timerów). Pierwszy timer będzie generował przerwanie, załóżmy co 3ms, do multiplekosowania wyświetlacza, a drugi timer będzie co 1 skunde zwiększał liczbę policzonych sekund. Co jeśli jednak oba przerwania wypadną w tym samym momencie? Załóżmy, że przerwanie stopera będzie musiało zostać obsłużone po multipleksowaniu wyświetlacza, czyli będzie musiało na nie poczekać. A czekanie oznacza tu zmniejszenie dokładności odmierzanego czasy.


    A guzik prawda, bo układ peryferyjny zgłaszający przerwanie dalej zajmuje się swoją pracą i na nic nie czeka. Następne przerwanie zostanie zgłoszone dokładnie sekundę po pierwszym przerwaniu, obojętnie jak długo by czekało na to aż procesor je obsłuży.

    Jeśli bardzo zależy Ci na tym by przerwać przerwanie, to na początku procedury obsługi przerwania można wstawić instrukcję sei i nie trzeba będzie czekać na zakończenie obsługi bieżącego przerwania.
  • #1662
    tronics
    Poziom 38  
    @leonow - tak, prawda, kwestia jest taka że licznik może zgłosi za kolejną sekundę kolejne przerwanie, ale czy ono będzie w równych interwałach tak samo szybko przetwarzane to zupełnie coś innego - bo jeśli co 666 przerwań drugiego timera wydłuży się obsługa przerwania pierwszego o ileś tam mikrosekund to o tyle będzie już gorzej nasz zegarek działał.
  • #1663
    tplewa
    Poziom 38  
    @tronics

    Tylko tak dyskusja jest bez sensu, bo ile instrukcji może się wykonać w 1s ? Problem robi się gdy czas wykonania obsługi przerwania przekracza czas wystąpienia przerwania i tego należy unikać.

    Nawet trochę abstrachując bo w realu te czasy będą inne. Jeśli zliczany co 1s i zmienna uaktualni się 0.01s później, a wyświetlona zostanie kolejne 0.01s później to przy interwale zliczania 1s nie ma to większego wpływu. Natomiast timer zostaje i tak wyzwolony równo jedynie czas wykonania obsługi przerwania wprowadza nam jakiś delay którego nie unikniemy. W jednym procesorze będzie on większy w drugim mniejszy.
  • #1664
    Tomq
    Poziom 38  
    Cytat:
    To od multipleksowania wywolujesz co okreslony czas wiec znasz interwal i mozesz tak samo na jego podstawie zwiekszac wartosc licznika czyli czasu.

    Właśnie tam mam zrobione w tej chwili. Wyświetlacz (wspólne anody) multipleksuje co 2 ms i przy okazji jego obsługi zwiększam licznik stopera. Gdy sekundnik dojdzie do 500 to już poza przerwaniem robię jego obsługę.

    Przerwanie wygląda tak:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Cytat:

    A guzik prawda, bo układ peryferyjny zgłaszający przerwanie dalej zajmuje się swoją pracą i na nic nie czeka. Następne przerwanie zostanie zgłoszone dokładnie sekundę po pierwszym przerwaniu, obojętnie jak długo by czekało na to aż procesor je obsłuży.

    Na jedno racja, bo timer zgłosi przerwanie i wyczyści swój rejestr porównawczy, a zanim doliczy do następnego przerwania, to już na pewno zdąży zostać obsłużony. Kwestia tylko tego na ile akcja związana z tym przerwaniem zostanie rozpoczęta w odpowiednim czasie.


    Cytat:
    Nawet trochę abstrachując bo w realu te czasy będą inne. Jeśli zliczany co 1s i zmienna uaktualni się 0.01s później, a wyświetlona zostanie kolejne 0.01s później to przy interwale zliczania 1s nie ma to większego wpływu. Natomiast timer zostaje i tak wyzwolony równo jedynie czas wykonania obsługi przerwania wprowadza nam jakiś delay którego nie unikniemy.

    To fakt, nie pomyślałem. Ewentualne błędy nie będą się kumulować, tylko będą przesuwały czas wystąpienia akcji. Wcześniej myślałem, że przy każdym przerwaniu dodajemy opóźnienie i sumuje się ono z poprzednimi opóźnieniami.




    Podsumowując - nie ma problemu gdy mamy na celu o dokładne liczenie czasu (błędy się nie kumulują, bo timer liczy sobie dalej. Jest problem gdy mamy na celu wykonanie akcji dokładnie w tej setnej sekundy w której upłynął zadany czas (być może trzeb będzie poczekać aż się obsłuży pierwsze przerwanie). Drugie zadanie nie jest zbyt często spotykane (mało jest aż tak wymagających aplikacji), więc moje wątpliwości zostały rozwiane (wystarczy użyć dwóch niezależnych timerów i dwóch osobnych przerwań). Dodatkowo można przerwania tak ustawić by ich czasy pokrywały się jak najrzadziej. Przykładowo multipleksując wyświetlacz co 2ms na pewno "trafimy" na przerwanie wykonywane co 1000ms. Gdy wyświetlacz będzie multipleksowany co 3ms na to drugie przerwanie będziemy trafiali 3 razy rzadziej. Do tego jeszcze kwestia uruchamiania timerów - nie jest chyba możliwe, żeby wystartowały w tym samym czasie?
  • #1665
    leonow32

    Poziom 30  
    Tomq napisał:
    nie jest chyba możliwe, żeby wystartowały w tym samym czasie?

    Jest to możliwe. Np. w ATmega128 w rejestrze SFIOR jest bit TSM (Timer/Counter Synchronization Mode). Kiedy bit jest ustawiony na 1, wówczas wszystkie timery są zatrzymane i możesz je skonfigurować w dowolny sposób. Kiedy bit TSM ustawisz na zero, wówczas wszystkie preskalery timerów się wyzerują i timery wystartują dokładnie w tym samym czasie. Taka opcja nie jest dostępna w starszych AVRach.

    W ten sposób możesz ustawić wartości początkowe timerów. Aby przerwania nie kolidowały ze sobą, możesz ustawić, by przerwanie od multipleksowania wyświetlacza odbywało się w 1, 3, 5, 7, 9...997, 999, 1001, 1003 milisekundzie, a zwiększenie sekundnika w 1000, 2000, 3000. W ten sposób nie ma szans by oba timery jednocześnie zgłosiły przerwanie.


    ...a swoją drogą do budowy zegarków lepiej wykorzystać RTC, które mają wbudowane wszystkie procki od ATmega8 i bardziej zaawansowane. Kwarc 32kHz podłącza się do wejść TOSC i to pięknie sobie działa :)
  • #1666
    Tomq
    Poziom 38  
    Myślę, że sobie poradzę. Do obecnego projektu użyje zaproponowanego przez Ciebie rozsunięcia (jeden timer zlicza co dwie nieparzyste ms drugi tysiące ms, które zawsze są parzyste), jeśli chodzi o budowę normalnego zegarka to już zacząłem szukać materiałów na ten temat (m.in http://mikrokontrolery.blogspot.com/2011/04/stopery-timery-itp.html ).



    EDIT:
    Cytat:
    by przerwanie od multipleksowania wyświetlacza odbywało się w 1, 3, 5, 7, 9...997, 999, 1001, 1003 milisekundzie


    Może głupie pytanie - zgłaszał przerwanie co 2 ms w nieparzystych sekundach muszę go wystartować od 1 a nie od zera? Czyli do Timer/Counter Register danego timera wpisuje 1 jako wartość początkową? W każdym przerwaniu muszę od nowa wpisywać tą wartość do tego rejestru?
  • #1668
    dancios
    Poziom 10  
    witam :D
    chce toglowac bit odpowiedzialny za port w kontrolerze cortex-m stellaris
    #define GPIO_PORTF_DATA_R (*((volatile unsigned long *)0x400253FC))
    GPIO_PORTF_DATA_R ^= (1 << 0x04);
    co robie źle ?
  • #1669
    wolek14
    Poziom 31  
    Czy tak ma wyglądać okno programu po zakończeniu punktu nr. 6 w tym poradniku? Bo intuicja podpowiada mi, że coś się skopało. Aktualnie jestem na etapie elementarza z uC, i pomimo znalezienia genialnej książki do nauki (która mnie w sumie do tego zachęciła) z dnia na dzień coraz bardziej się denerwuję, bo nie chce to ustrojstwo działać.
    Pierwsze starcie z mikrokontrolerami (dozwolone linki Allegro, eBay, itp)
    Bardzo proszę o pomoc, siwiejących elektroników Ci u nas dostatek - nie potrzeba kolejnego :)
  • #1670
    dziurex
    Poziom 10  
    Witam. Chciałem zacząć zabawę z mikrokontrolerami i tu moje pytanie. Czym różni się Arduino od takiego zestawu uruchomieniowego dla AVR?Czym charakteryzuje się Arduino. I jeszcze zastanawiam się jeśli stworzę jakiś projekt na takim zestawie startowym Arduino (np. sterowanie roletami) to cały ten zestaw musi być wykorzystany czy później mogę wyciągnąć sobie mikroprocesor i wstawić nowy do zaprogramowania?
  • #1671
    Tomq
    Poziom 38  
    Nie ma sensu bawić się w arduino, lepiej zacząć od razu od bezpośredniego programowania w języku C.
    Arduino jest czymś w rodzaju nakładki tłumaczącej swój własny język na C. Tak czy inaczej musiałbyś poznać składnie języka i działanie mikrokontrolerów, więc lepiej od razu zacząć w C.

    Możesz poczytać np https://www.elektroda.pl/rtvforum/topic2740420.html
  • #1672
    tmf
    Moderator Mikrokontrolery Projektowanie
    Tomq napisał:
    Nie ma sensu bawić się w arduino, lepiej zacząć od razu od bezpośredniego programowania w języku C.
    Arduino jest czymś w rodzaju nakładki tłumaczącej swój własny język na C. Tak czy inaczej musiałbyś poznać składnie języka i działanie mikrokontrolerów, więc lepiej od razu zacząć w C.

    Możesz poczytać np https://www.elektroda.pl/rtvforum/topic2740420.html


    Jakkolwiek zgadzam się z twoimi argumentami przeciwko Arduino, to dla uzupelnienia - nie używa własnego języka tłumaczonego na C lecz używa C++. Z jednej strony jest to wygodne i daje przejrzysty kod, z drugiej strony Arduino jest pewnym frameworkiem tworzącym warstwę pośrednią pomiędzy sprzętem a aplikacją, co znacznie spowalnia działanie tej ostatniej. Także jak dla mnie Arduino jest fajne dla osób, które nie chcą się zagłębiać w tajniki działania mikrokontrolera i szybko chcą osiągnąć sukces - czyli jest to alternatywa dla Bascoma. Po jakimś czasie okazuje się, że Arduino zbytnio ogranicza i trzeba będzie i tak się przesiąść bliżej sprzętu.
  • #1673
    McMonster
    Poziom 32  
    tmf napisał:
    Jakkolwiek zgadzam się z twoimi argumentami przeciwko Arduino, to dla uzupelnienia - nie używa własnego języka tłumaczonego na C lecz używa C++. Z jednej strony jest to wygodne i daje przejrzysty kod, z drugiej strony Arduino jest pewnym frameworkiem tworzącym warstwę pośrednią pomiędzy sprzętem a aplikacją, co znacznie spowalnia działanie tej ostatniej. Także jak dla mnie Arduino jest fajne dla osób, które nie chcą się zagłębiać w tajniki działania mikrokontrolera i szybko chcą osiągnąć sukces - czyli jest to alternatywa dla Bascoma. Po jakimś czasie okazuje się, że Arduino zbytnio ogranicza i trzeba będzie i tak się przesiąść bliżej sprzętu.

    A ja dodam, że również w znaczny sposób ogranicza. Programując Arduino człowiek poznaje tylko Arduino. Ucząc się C i czytania kart katalogowych ma się dostęp do wszystkiego.
  • #1674
    dziurex
    Poziom 10  
    Dzięki Panowie. Czyli wniosek taki, że jeśli chcę zrozumieć o co w tym wszystkich chodzi lepiej zacząć programować bezpośrednio w C. Czy warto kupować jakiś zestaw uruchomieniowy?
  • #1675
    dondu
    Moderator Mikrokontrolery Projektowanie
    Arduino można przyrównać do np. Excell-a. Masz w nim bardzo dużo gotowych funkcji do liczenia np. różnych wskaźników finansowych. To ułatwia szybki start, ale nie daje pełni kontroli nad daną funkcją. Jeżeli więc chcesz ją nieznacznie przerobić, to się nie da i musisz stworzyć własną.


    Zestaw jest jeden, a projektów pewnie będziesz chciał wiele zrobić i wykorzystywać je równolegle. Jak podzielić zestaw? Można użyć piły do metalu ;)
    Posiadanie zestawu może być przydatne, ale warto rozważyć płytkę stykową i garść elementów: http://mikrokontrolery.blogspot.com/2011/04/jak-najtaniej-zaczac.html
    Coś zepsujesz - wywalasz do kosza i zapominasz - w zestawie już nie jest tak łatwo ...
    Poza tym najważniejsza sprawa - w ten sposób uczysz się także elektroniki, a nie tylko programowania.

    A później, gdy zdobędziesz doświadczenie, albo kupisz zestaw wybierając na podstawie własnych potrzeb i posiadanej wiedzy, albo ... zbudujesz własny.

    Elektronika, to ciągłe wydatki ... nie znając tematu należy uważać, co się kupuje, by nie leżało w szafie.
  • #1676
    Tomq
    Poziom 38  
    Podpisuje się pod każdym zdaniem napisanym przez Dondu.
    Jeśli skłonisz się ku produktom Atmela (najpopularniejsze wśród polskich hobbystów), to polecam Atmega 16 lub 168. Uruchomisz na nim wszystkie przykłądy z popularnych kursów dla atmega8, a "większy" mikrokontroler ma sensowniej poukładane wyprowadzenia portów i oczywiście ich samych też jest więcej. Gdybyś chciał w niedługim czasie po rozpoczęciu nauki zrobić coś wymagającego wielu linii wyjściowych to nie będziesz musiał kupować nowego mikrokontrolera.
    Oprócz blogu podlinkowanego wyżej polecam na początek - http://hobby.abxyz.bplaced.net/index.php?pid=4&aid=2
    I nie zaczynaj od WinAVR tylko od razu od Atmel Studio4 lub Atmel Studio6. O ile treść kursów internetowych się nie postarzała zbytnio o tyle samo środowisko WinAVR jest już w bardzo sędziwym wieku.
  • #1677
    tmf
    Moderator Mikrokontrolery Projektowanie
    Polemizowałbym z wyborem mikrokontrolerów. Jeśli już coś z ATMega to zdecydowanie te trzycyfrowe, niemniej z własnego doświadczenia wydaje mi się, że na dzień dzisiejszy start od XMEGA jest lepszy. Prostsze peryferia, o możliwościa podobnych do peryferii z wypasionych ARMów, obecnie dostępne są kursy (np. z Leon Instruments) i nie trzeba z nimi kombinować np. podłączając do USB, bo je po prostu mają. Do tego są fajne zestawy, np. ze wspomnianej firmy Leon Instruments lub Modułowa płytki-przejściówki na stykówkę. Naprawdę fajna sprawa. Oczywiście wszystko zależy co kto lubi. Z nowości mogę polecić:
    http://blog.modulowo.pl/xmega-explorego-nowy-modul-z-mikrokontrolerem-atxmega-i-mp3/
    Bardzo prosty i efektowny start z mikrokontrolerami, wystarczy podłączyć kabel USB i mamy i zasilanie i możliwość programowania przez bootloader + SD + mp3 i kompatybilność z shieldami Arduino.
    Od razu mówię, że nie jestem w żaden sposób (finansowo) z wymienionymi przeze mnie firmami powiązany.
  • #1678
    plotek5
    Poziom 11  
    witam

    poszukuję jakiegoś taniego programatora pod USB. Głównym kryterium jest cena i możliwość "brania" zasilania do układu z komputera - czyli brak konieczności stosowania dodatkowego zasilacza.

    Z tego co widzę moje kryteria spełniłby: ---
    a czy inne tańsze też mają taką możliwość?
    Na przykład: ---
    kolejny: ---
    Czy może wszystkie programatory tego typu mają możliwość ustawienia zasilania za pomocą zworki ?

    Moderowany przez dondu:

    Nawet nie zadałeś sobie trudu, by przeczytać opisy aukcji.

    Ja wiem, że początki wymagają pytań, ale niestety regulamin zakazuje wklejania linków do treści, które znikają jak aukcje, dlatego muszę je usunąć.

    Dodam także, że te pytania powinieneś zadać sprzedawcom lub poszukać dokumentacji na ich stronach.

    Jestem jednak przekonany, że każdy który pokazałeś ma tę opcję.

    3.1.18. Zabronione jest publikowanie informacji do źródeł, które po pewnym czasie wygasają (publikowanie odnośników do stron o charakterze krótkotrwałym).

  • #1679
    ka_3
    Poziom 16  
    Witam, Zacząłem się uczyć programowania mikrokontrolerów AVR w języku C. Przerobiłem sobie książkę niebieską wydawnictwa Atnel. Zrozumiałem podstawy działania mikrokontrolera. Teraz zastanawiam się co dalej? Ja chciałbym się zająć tym nie hobbystycznie ale zawodowo. Za rok chciałbym iść na jakiż staż. W większości ofert widzę wymagania odnośnie mikrokontrolerów ARM. Co się właściwie buduje na AVR(wydaje mi się że sterowniki C.O i inne systemy sterujące a co na ARM(chyba tablety, telefony, nawigacje, komputery pokładowe, TV, czyli wszystko co ma wyświetlacz i potrzebuje większej mocy obliczeniowej?). Jeżeli chciałbym pracować jako programista ARM, to warto jeszcze ciągnąć AVR, i jak je dobrze opanuję, to przesiąść się na ARM, czy od razu brać się za ARM? Jak duża jest różnica pomiędzy programowaniem AVR a ARM?
  • #1680
    dondu
    Moderator Mikrokontrolery Projektowanie
    Na ARM spotkasz także i proste projekty, o tyle na AVR, projektów wymagających dużej wydajności już niekoniecznie. Innymi słowy odpowiedź jest taka sama jak na pytanie do czego służy samochód typu Lamborghini, a do czego Renault w wersji kombi. Oba są dobre i w pewnych zadaniach wygrywają, w innych przegrywają.

    Każda wiedza - jest przydatna - w jednej firmie spotkasz PICe, w innej AVRy, .... a w innych kilka rodzin ... wszelkie możliwe kombinacje są możliwe. I nie wierz w powszechną opinię że 8-bitowce wymrą za kilka lat - nie wymrą, bo będą tańsze, a rynek na ceny zawsze patrzy. :)

    Dlatego jeśli masz ograniczony czas to specjalizuj się w ARM, jeśli czas nie jest ograniczony, to poznawaj wszystkie ważniejsze (na polskim rynku) rodziny.

    Zastosowanie konkretnej rodziny zależy od wielu czynników, a nie tylko mocy obliczeniowej:
    http://mikrokontrolery.blogspot.com/2011/04/jaki-mikrokontroler-wybrac-do-projektu.html

    EDIT:
    Dodałem Ci trochę punktów, bo mogą się przydać, a miałeś zaledwie 2 :)