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

ATMEL - jak zacząć programowanie w asemblerze ?

zbynio_k 30 Wrz 2013 17:38 3810 26
  • #1 30 Wrz 2013 17:38
    zbynio_k
    Poziom 10  

    witam, jestem w biegły w programowaniu procesorów w asemblerze
    chciałem zająć się "jednoukładówkami" ATMEL'a, mam zamiar
    programować TYLKO w asemblerze (odpada BASCOM czy C Arduino)
    wydaje mi się, że układy uruchomieniowe ARDUINO (starter kit) doskonale się do tego nadają
    jako początkujący w TYM temacie ma kilka pytań do bardziej
    doświadczonych kolegów

    1. czy od razu "rzucić" się na Atmel STUDIO 6 czy może zacząć
    od starszych wersji, np AVR studio 4 lub 5 ?
    2. czy soft narzędziowy do ARDUINO tiny czy mega umożliwia wgrywanie
    programów skompilowanych pod programami j.w.
    3. czy soft ATMEL'a umożliwia np. pracę krokową "na procku" a nie tylko
    w emulatorze ?
    4. jaki programator wybrać ? czy np. STK200 (chyba ISP jest najlepszy)
    współpracuje z AVR Studio (lub wyższym) i z softem do ARDUINO ?

    a może jakieś inne propozycje kolegów ...

    przepraszam, jeśli pytania są trywialne lub wręcz "głupie"

    pozdrawiam

    0 26
  • Pomocny post
    #2 30 Wrz 2013 17:54
    Grzegorz77
    Poziom 25  

    Zostań przy starszych wersjach AVR studio , 6 strasznie zamula

    0
  • Pomocny post
    #3 30 Wrz 2013 18:35
    p.mezydlo
    Poziom 11  

    Pisałem kilka miesięcy temu w asm i używałem arduino mega 2560. Programator już wbudowany, stabilna praca i przed wszystkim dobrze odfiltrowane zasilanie. Pisałem w środowisku avr studio 4 a do wgrywania hex używałem xloader. Wszystko działało nie miałem żadnych problemów.

    0
  • Pomocny post
    #4 30 Wrz 2013 19:15
    piotrva
    Moderator na urlopie...

    1. Atmel Studio 6 jako środowisko jest bardzo dopracowane, ale też ciężkie (nawet na nowszych komputerach chodzi jak chodzi). Jeśli nie zamierzasz korzystać z nowych procesorów (ATTiny4/5/9/10, ATXMega) to weź AVR Studio 4. wersji 5 unikaj jak ognia.
    2. Nie za bardzo - niby da się, ale to jest kombinowanie i niebyt wygodnie i szybko to działa
    3. Tak, ale do tego potrzebny jest Ci debugger sprzętowy, a nie tylko programator.
    4. Hehe, nie za bardzo wszystko chyba ogarniasz - STK200 od razu posłać między bajki.

    A teraz po kolei - rozumiem, że:
    A. chcesz programować w ASM (z sobie tylko wiadomych powodów) procesory AVR z serii Tiny i Mega (pytanie dodatkowe - jakież to procesory programowałeś w ASM?)
    B. Chcesz mieć możliwość podglądu pracy procesora na ekranie (wykonywanie krokowe + podgląd wszystkiego co się dzieje w kostce)

    Jeśli tak to:
    a) Kup sobie jakąś płytkę (nie ARDUINO) z procesorem i podstawowymi peryferiami na pokładzie (przyciski, diody, wyświetlacze, ...) + posiadającą złącze / dostęp do pinów JTAG - wyjdzie Ci to dużo taniej niż Arduino i "Shieldy". Względnie możesz pójść drogą płytki stykowej, ale widzę, że zależy Ci na gotowym "bezproblemowym hardware".
    b) Będzie Ci potrzebny programator/debugger JTAG do podglądu pracy procesora/pracy krokowej itp. - tu albo musisz kupić sobie jakiś klon debuggera JTAG, ale zastanów się nad zainwestowaniem pieniędzy zaoszczędzonych na rezygnacji z Arduino w AVR Dragon - to jest kombajn programistyczny - obsługuje praktycznie wszystkie procesory ATMEL'a zarówno jako programator jak i debugger (tu tylko układy posiadające możliwość debugowania).
    c) Do tego AVR Studio 4 lub Atmel Studio 6

    0
  • Pomocny post
    #5 30 Wrz 2013 19:19
    tmf
    Moderator Mikrokontrolery Projektowanie

    1. W zależności od procków, które chcesz użyć. AVR Studio nie wspiera wszystkich, ale poza niektórymi XMEGA działa na nim wszystko. Do prostych projektów (a innych w asmie nie napiszesz) jest ok. Atmel Studio ma dużo bajerów przydatnych przy programowaniu w językach wyższego poziomu. Działa całkiem sprawnie na współczesnym komputerze.
    2. Wszystko co wgrywa HEXy się nadaje.
    3. Soft Atmela umożliwia pracę krokową na procku, o ile posiadasz JTAG/PDI. Najtańszy na dzień dzisiejszy JTAG/PDI do AVR to AVR Dragon.
    4. Jeśli zależy ci na możliwości debuggowania (a pewnie zależy, bo bez tego pisanie w asm to już prawdziwy hardcore), to AVR Dragon, jeśli nie to najtańszy klon AVR ISPMkII.

    Teraz ja mam pytanie, bo jestem bardzo ciekawy:
    1. Dlaczego wykluczasz języki wyższego poziomu, typu C? O tyle jestem ciekaw powodów, że 90% programistów na AVR wybiera C/C++, używając asemblera co najwyżej jako wstawek.

    0
  • #6 01 Paź 2013 09:38
    zbynio_k
    Poziom 10  

    witam,
    dzięki wszystkim za info, trochę się rozjaśniło a myślę, że reszta przyjdzie w praktyce

    do piotrva
    ad. A - zarzekanie se w programowaniu w ASM być może trochę na wyrost,
    ponieważ żaden kompilator nie zrobi kodu minimalnego i pewnie optymalnego też nie :)
    cóż, pewnie "skuszę" się na C jeśli pamięci starczy
    a jakie procesory programowałem ....początek był na intelu 8080 (robiłem dyplom z tego)
    później Z80 i pierwszy porządny procek z indeksowaniem rejestrowym 6502 - ten z ATARi
    później intel'e do 80286,. póki nie pojawił się tryb chroniony :)
    miałem nawet eksces z 8051 więc mam jakby powrót do jednoukładówek
    ad. B - właśnie tak, obecnie "siedzę" w S7-200. i chodziło mi o coś takiego jak MicroWin (który niestety NIE emuluje - jak to u Siemens'a :D)

    dzięki

    do tmf

    ad. 1 - nie wykluczam całkowicie ale lubię ASM'a - patrz wyżej
    co do d00pnych projektów to kilka już popełniłem
    wstawiałem także całkiem spore kody do Delphi ale niestety ... HAL bruździ w tym niesamowicie
    a na starym lapku nie chce mi się zainstalować Win98 :D

    dzięki


    cóż reasumując,
    Wasze odpowiedzi są konkretne i na temat

    chwilowo jeszcze nie zamykam tematu choć "jasność już zaposiadam"

    0
  • #7 01 Paź 2013 10:03
    pawel_mr
    Poziom 14  

    Ja tylko dorzucę od siebie, że jeśli jedynym "za" jest:

    zbynio_k napisał:
    ponieważ żaden kompilator nie zrobi kodu minimalnego i pewnie optymalnego też nie :)
    cóż, pewnie "skuszę" się na C jeśli pamięci starczy

    to wg mnie warto już teraz rozważyć przejście na C. Wstawki w asm są potrzebne i niekiedy warto je stosować ale pisanie całych programów w asm obecnie wg mnie mija się z celem. Ja tak robiłem jak pisałem na 89C2051, gdzie było 2kB kodu. Teraz uC mają "trochę" więcej pamięci i trzeba się nieźle napocić, żeby wykorzystać całą dostępną pamięć. Prędzej zatniesz się na ograniczeniach sprzętowych niż na ilości dostępnej pamięci flash. Co do optymalizacji i minimalizacji to faktycznie kompilator nie zawsze zrobi to najlepiej ale są też sytuacje, gdy użytkownik robi to gorej od niego. W newralgicznych miejscach można użyć asm, reszta, gdzie szybkość działania programu nie jest najważniejsza C sprawdzi się w 100%. I jeszcze jedna ważna zaleta C. Jak asm nie okomentujesz bardzo dokładnie to powrót do programu po roku kończy się tym, że zaczynasz pisać go od nowa, bo nie pamiętasz co miałeś na myśli pisząc dany kod, w C jesteś w stanie rozpracować program w zasadzie bez komentarzy. Dużo łatwiejsze jest też przejście na inny procesor, owszem, trzeba pozmieniać pewne rzeczy ale wydaje mi się, że asm wymaga więcej pracy.

    0
  • #8 01 Paź 2013 10:04
    tmf
    Moderator Mikrokontrolery Projektowanie

    Nie, żebym chciał cię do czegoś przekonywać, ale:
    - obecnie assembler stosuje się tylko tam gdzie to ma sens - czyli na naprawdę małych prockach, np. ATTiny10, gdzie nawet jeśli by się dało coś w C zrobić to nie miałoby to sensu, lub wymagało takich manipulacji linkerem, że traciłoby to sens. Asembler stosuje się też tam, gdzie optymalizacja jest niezbędna, ale w praktycznie każdym programie są to co najwyżej krókie fragmenty, ale prawie nigdy całość.
    - kompilator C umożliwia wygodne łączenie asemblera z C - np. poprzez wstawki inline, albo dołączanie plików napisanych w asemblerze.
    - co do stwierdzenia, że "żaden kompilator nie zrobi kodu minimalnego i pewnie optymalnego też nie" to możesz nie mieć racji. W przypadku prostych i krótkich programów owszem, ale w przypadku dużych programów, kompilator zazwyczaj jest sprawniejszy niż człowiek i produkuje lepszy kod. Jeśli masz doświadczenia z Z80, czy Delphi, to możesz być bardzo zaskoczony tym jak wydajnym i dobrym narzędziem stały się kompilatory C/C++.
    - unikaj też pułapki typu "jak starczy pamięci" - co znaczy, że nie starczy? To znaczy tylko tyle, że wybrałeś zły procek i potem na siłę starasz się ten błąd naprawić. Obecnie nawet proste AVRy oferują pamięć FLASH w zakresie 1-384 kB, a SRAM 64 bajty do 32 kB (+możliwość podłączenia do 24 MB zewnętrznej pamięci SRAM/SDRAM). Jeśli tego brakuje to należy zmienić już na początku procesor na np. ARM.

    0
  • #9 01 Paź 2013 10:26
    dondu
    Moderator Mikrokontrolery Projektowanie

    Ja dodam tylko dwa argumenty:
    - jakieś 10 lat temu producenci mikrokontrolerów, swoje przykładowe projekty realizowali w ASM. Od paru ładnych lat wszelkie przykłady realizowane są w C.
    - ogólnodostępne biblioteki, także są w C.

    Jeżeli więc chcesz poświęcać na realizację jakiegoś zadania w ASM znacznie więcej czasu niż w przypadku C, to to ma sens :)

    Ode mnie w prezencie 50 pkt, bo masz mniej niż 1, a mogą się przydać.

    0
  • #10 01 Paź 2013 12:43
    zbynio_k
    Poziom 10  

    do pawel_mr i tmf

    qrna, żeby nie było .... przekonaliście mnie
    jakoś nie mogłem się przekonać do C :D
    stale tylko Pascal w różnych odmianach :)
    tym bardziej, że czasami coś napiszę w JavaScript i nawet
    trochę Javy "liznąłem" więc składnia nie będzie problemem
    a i rzeczywiście nie wziąłem pod uwagę rozwoju technologii
    gdzie nawet dyski "twarde" są SSD :) :) :)

    specjalne podziękowania dla dondu
    już widzę nieprzespane noce - więc punkty się przydadzą z pewnością
    i .... rzeczywiście - latka lecą :D
    (a i w Fortranie się coś popełniło)

    dzięki wszystkim

    0
  • #11 01 Paź 2013 13:19
    Tomasz Gumny
    Poziom 27  

    Kompilatory C potrafią zaskoczyć sprytną konstrukcją w asemblerze, ale trzeba to umieć odczytać. Często trywialne błędy w źródle zauważa się dopiero w przekładzie, dlatego trochę na przekór wszystkim zaproponuję, żebyś zaczął od niewielkiego programu w asemblerze i zrobił go od początku do końca. Potem już tylko C. :)

    0
  • #12 01 Paź 2013 13:28
    BlueDraco
    Specjalista - Mikrokontrolery

    No to skoro już udało się Ciebie przekonać do C, to może za jednym zamachem zmieniłbyś mikrokontrolery z zabytkowych i niedebugowalnych ATmega na tańsze, 20 razy szybsze i debugowalne Cortexy, np. firmy ST lub NXP...

    0
  • #13 01 Paź 2013 14:35
    dondu
    Moderator Mikrokontrolery Projektowanie

    W przypadku zbynio_k to dobry pomysł :-)

    zbynio_k napisał:
    specjalne podziękowania dla dondu
    już widzę nieprzespane noce - więc punkty się przydadzą z pewnością
    i .... rzeczywiście - latka lecą :D
    (a i w Fortranie się coś popełniło)

    Nie ma za co, ja punktów nie zbieram więc jeżeli komuś brakuje to z chęcią daruję.
    Na szczęście Fortran-a mi oszczędzono - Basic był pierwszy :)

    A jeśli mikrokontrolery ARM, to może się jeszcze załapiesz: https://www.elektroda.pl/rtvforum/viewtopic.php?p=12796323#12796323

    Powodzenia!

    0
  • #14 01 Paź 2013 15:02
    tmf
    Moderator Mikrokontrolery Projektowanie

    Tomasz Gumny napisał:
    Kompilatory C potrafią zaskoczyć sprytną konstrukcją w asemblerze, ale trzeba to umieć odczytać. Często trywialne błędy w źródle zauważa się dopiero w przekładzie, dlatego trochę na przekór wszystkim zaproponuję, żebyś zaczął od niewielkiego programu w asemblerze i zrobił go od początku do końca. Potem już tylko C. :)


    To prawda, że znajomość przekładu z C na asembler się przydaje i przydaje się znajomość asemblera. Ale w tym celu lepszym rozwiązaniem jest pisać w C i potem podglądać pliki lss lub okno debug w symulatorze/debuggerze porównując kod C i jego tłumaczenie.

    Dodano po 4 [minuty]:

    BlueDraco napisał:
    No to skoro już udało się Ciebie przekonać do C, to może za jednym zamachem zmieniłbyś mikrokontrolery z zabytkowych i niedebugowalnych ATmega na tańsze, 20 razy szybsze i debugowalne Cortexy, np. firmy ST lub NXP...


    Nie wprowadzaj kolegi w błąd - ATMega (z wyjątkiem ATMega8) są tak samo debugowalne jak ARMy (interfejs JTAG, który jest standardem przemysłowym).
    No i szybszy nie jest mikrokontroler, tylko co najwyżej jego rdzeń i to niekoniecznie 20x, bo to by znaczyło, że ARM ma 400-640 MIPS, a tyle z pewnością nie mają ARMy o których piszesz. Rdzeń ARM jest co najwyżej kilka razy szybszy (piszę o tanich ARMach w obudowach dla hobbysty) i to tylko pod warunkiem intensywnego wykorzystywania operacji na liczbach 32-bitowych lub zmiennopozycyjnych.

    0
  • #15 01 Paź 2013 15:29
    BlueDraco
    Specjalista - Mikrokontrolery

    Nie chodzi o MIPS, a o DMIPS, czyli instrukcje "znormalizowane" (a więc realną wydajność obliczeniową) Jedna instrukcja Cortex to 0.84..1.25 tej "znormalizowanej", podczas gdy w AVR zgaduję, że jakieś 0.2..0.35 (może się mylę, ale chyba niewiele). Już z tego wynika, że przy tej samej częstotliwości zegara wydajność CM0 jest min. ze trzy razy wyższa od AVR.

    0
  • #16 01 Paź 2013 17:51
    tmf
    Moderator Mikrokontrolery Projektowanie

    Ok, ale nawet gdyby przyjąć twoje przeliczniki DMIPS to wychodzi raptem różnica 3,5 razy, a nie 20 razy jak napisałeś. Nawet dodając do tego różnicę w zegarach (20-32 MHz), vs. max 48 MHz nie wychodzi owe 20-razy. Czepiam się, ale sam lubisz być precyzyjny.
    No i wiesz, że znormalizowane instrukcje, to jak znormalizowane buty. DMIPSy będą różne (być może nawet takie jak podałeś) dla aplikacji intensywnie obliczających coś na dłuższych typach, ale dla wielu operacji przelicznik będzie jak 1:1. Żeby nie być gołosłownym to mamy niedawny wątek kolegi Michałko, na temat liczenia sumy dla danych. Porównamy efektywność ARM vs. AVR?

    0
  • #17 01 Paź 2013 18:11
    zbynio_k
    Poziom 10  

    dzięki za wszystkie informacje i spostrzeżenia
    wydaje się, że wymiana doświadczeń idzie w zbyt zaawansowanym kierunku

    wobec tego muszę wyjawić skąd u mnie zainteresowanie TYM tematem

    zrobiłem sobie matrycę LED 16x16 do wyświetlania różnych "pierd00ł"
    sterowana jest z portu LPT (karta PCMCIA zakupiona do starego lapka)
    no i okazało się, że win ZDECYDOWANIE nie jest systemem czasu rzeczywistego
    wydawało mi się, że częstotliwość rzędu 90-100Hz na obsługę wszystkich LED'ów
    wystarczy .... no i wystarczy (bezwładność oka około 25ms) ale nawet ustawienie
    priorytetu wątku wyświetlającego na Higher daje niekotrolowaną "poświatę"
    highest i critical raczej nieuzasadnione :D :D

    więc wejdę w te AVR'y - każda nauka nie idzie w las :)
    i pewnie przyda się w innych projektach - być może i AMR'y (ale niekoniecznie)
    a CORTEX'y to w moim przypadku to raczej przerost formy nad treścią
    (tak mi powiedział wujek google)

    a, że z wykształcenia jestem elektronikiem "cyfrowcem" i nigdy nie wszedłem
    w programowanie "pełną gębą" - wchodzić nie będę :)

    0
  • #18 01 Paź 2013 19:04
    BlueDraco
    Specjalista - Mikrokontrolery

    Z tą różnicą w zegarach to raczej 8 MHz vs. 48 MHz (ATmega8 vs. CM0) albo 32 MHz vs. 168 MHz (XMEGA vs. CM4), czyli 5:1 lub 6:1 na zegarze i 4:1 na CPI - razem 20:1 - tak precyzyjnie.

    0
  • #19 01 Paź 2013 19:51
    tmf
    Moderator Mikrokontrolery Projektowanie

    BlueDraco napisał:
    Z tą różnicą w zegarach to raczej 8 MHz vs. 48 MHz (ATmega8 vs. CM0) albo 32 MHz vs. 168 MHz (XMEGA vs. CM4), czyli 5:1 lub 6:1 na zegarze i 4:1 na CPI - razem 20:1 - tak precyzyjnie.


    Może coś przeoczyłem, ale skąd wziąłeś to M8? No i nawet M8 to zegar 16 MHz. Cieszę się też, że porównujesz XMEGA co CM4 :)
    A na poważnie, jeśli porównujesz na podstawie relacji cenowych, to XMEGA podchodzi cenowo pod CM4 ale z zegarem max 50 MHz, procki z zegarem 100 MHz i wyższym to już ceny 2-3 wyższe i obudowy LQFP100-144 i ciekawsze. Z drugiej strony mamy 32 MHz XMEGA E5 za 5-9 zł w zależności od wielkości FLASH, czyli jednak 32 vs. 48 MHz.

    Dodano po 2 [minuty]:

    zbynio_k napisał:

    zrobiłem sobie matrycę LED 16x16 do wyświetlania różnych "pierd00ł"
    sterowana jest z portu LPT (karta PCMCIA zakupiona do starego lapka)
    no i okazało się, że win ZDECYDOWANIE nie jest systemem czasu rzeczywistego
    wydawało mi się, że częstotliwość rzędu 90-100Hz na obsługę wszystkich LED'ów
    wystarczy .... no i wystarczy (bezwładność oka około 25ms) ale nawet ustawienie
    priorytetu wątku wyświetlającego na Higher daje niekotrolowaną "poświatę"
    highest i critical raczej nieuzasadnione :D :D


    To ściągnij sobie darmowe przykłady do mojej książki o XMEGA, tam masz przykładowy kod sterowania matrycą LED (mono, 2- i RGB). Wypaśny procek nie jest do tego potrzebny, wystarczy XMEGA E5 za 6 zł, bo sterowanie jest realizowane sprzętowo. Z drugiej strony kupując za 8 zł XMEGA A4U zrobisz sterowanie + interfejs USB do komputera.
    Przejrzyj sobie kody, skompiluj i zobacz jak wygląda asembler vs. C :)

    0
  • #20 01 Paź 2013 20:43
    BlueDraco
    Specjalista - Mikrokontrolery

    zbynio_k:
    100 Hz wystarczy, jeśli głowę obserwatora umieścisz w imadle. W przeciwnym przypadku należy przyjąć częstotliwość rzędu 300 Hz (minimalistycznie - 150 Hz). Częstotliwość przełączania wierszy matrycy musi być w Twoim przypadku 16 razy większa, czyli 4800 Hz.

    0
  • #21 01 Paź 2013 21:23
    zbynio_k
    Poziom 10  

    do BlueDraco

    nie do końca chyba zrozumiale napisałem ...
    załączanie WSZYSTKICH diód to ok. 100 Hz
    dioda nie załączona nie "wchodzi" w wątek

    a tak BTW czy bezwładność plamki w ekranach LED TV jest o rząd (albo o dwa)
    mniejsza od 25ms ??

    mam sporo doświadczenia w VIDEO i wyświetlacz w systemie VITY (cokolwiek to znaczy) pracuje a odświeżaniem 20ms :D

    Dodano po 5 [minuty]:

    może jedno krótkie pytanko ....

    mam projekt uruchomiony i działający na dowolnym starter kicie

    jak zaprogramować "goły" AVR Tiny czy Mega ????

    0
  • #22 01 Paź 2013 21:28
    tmf
    Moderator Mikrokontrolery Projektowanie

    Owszem, wyświetlacz ma takie odświeżanie, ale plamka w CRT nie przestaje świecić natychmiast po przejściu wiązki, podobnie w LCD, kryształ nie skręca się natychmiast. Ta bezwładność powoduje, że przy sotsunkowo niskim odświeżaniu nie widzisz nieprzyjemnych efektów. Z LED jest inaczej - po wyłączeniu zasilania przestaje świecić w ciągu ns. Wysteruj LED z 25 Hz, zobaczysz wyraźne miganie. Nawet przy 50-100 Hz widać nieprzyjemny efekt, a jak do tego jeszcze masz zewnętrzne źródła światła z którymi to może interferować lub ruszasz głową to się robi masakra. Także tak jak pisze DlueDraco, 150-300 Hz to minimum, co przy multipleksowaniu wymaga odpowiednio częstszego przełączania. A jeśli jeszcze chcesz do tego uzyskać zmianę intensywności kolorów poszczególnych diod przez PWM, to jeszcze wielokrotnie częściej trzeba odświeżać.

    Dodano po 3 [minuty]:

    zbynio_k napisał:

    może jedno krótkie pytanko ....

    mam projekt uruchomiony i działający na dowolnym starter kicie

    jak zaprogramować "goły" AVR Tiny czy Mega ????


    Potrzebujesz programator lub procek z wgranym bootloaderem.

    0
  • #23 01 Paź 2013 21:46
    zbynio_k
    Poziom 10  

    tmf
    1. czyli moja diagnoza jest słuszna - 100Hz to mało

    2. i powtórzę pytanie - jaki programator ??
    (STK-200 został odrzucony) pomijam bootloadera

    0
  • #24 02 Paź 2013 09:33
    tmf
    Moderator Mikrokontrolery Projektowanie

    ad 1. Oczywiście, 100 Hz to mało.
    ad 2. To zależy jakie procki - dla AVR masz od tanich i prymitywnych programatorów typu USBASP (badziewie, ale za 20 zł), poprzez lepsze (np. klony AVRISPMkII za 50 zł) do programatorów z możliwością sprzętowego debugowania (AVR Dragon za 240 zł). Można kupić też np. gotowy minimoduł z prockiem np. w modulowo.pl lub Leon Instruments, który już ma wgrany bootloader i można go programować przez USB bez dedykowanego programatora:
    http://mikrokontrolery.blogspot.com/2011/02/mikrokontrolery-xmega-wybrane-moduly.html

    0
  • #25 02 Paź 2013 10:36
    zbynio_k
    Poziom 10  

    dzięki wszystkim :)
    więc na początek ... trochę teorii, żeby skończyć z zadawaniem trywialnych pytań :)

    0
  • #26 02 Paź 2013 11:13
    BlueDraco
    Specjalista - Mikrokontrolery

    Ogólnie programator do AVR jest tylko trochę droższy od płytki uruchomieniowej z mikrokontrolerem Cortex-M i programatorem/debuggerem do niego umieszczonym na tej samej płytce, którego można również używać do debugowania i programowania własnych płytek. ;) Przyjrzyj się modułom np. STM32F0DISCOVERY, STM32F4DISCOVERY, Freescale FRDM, NXP LPCxpresso i parametrom mikrokontrolerów w nich zastosowanych, a przejdzie Ci sympatia do AVR.

    0
  • #27 02 Paź 2013 12:16
    zbynio_k
    Poziom 10  

    na początek zakupiłem 2 e-book'i autorstwa tmr
    i myślę, że moje pytania o podstawy się skończą :)

    do BlueDraco
    jeśli zajdzie konieczność rozwijania projektów to na pewno zainteresuję się CORTEX'ami

    dzięki wszystkim

    temat zamykam

    0
  Szukaj w 5mln produktów