Autor: tmf
Redakcja: Dondu
Atmel Studio to oryginalne, wielofunkcyjne środowisko programistyczne firmy Atmel. To jedyne środowisko jakie potrzebujesz, by:- pisać programy w Assemblerze, C oraz C++,
- dwie rodziny mikrokontrolerów Atmela: AVR i ARM,
- symulować działanie mikrokontrolera,
- debugować,
- studiować ponad 1.100 przykładów,
- mieć aktualną wersję datasheet każdego mikrokontrolera Atmel,
- i wiele innych funkcji przyspieszających pracę.
Postanowiłem przybliżyć Wam Atmel Studio, by rozwiać wszelkie mity z nim związane :-)
Spis treści
- Atmel Studio - czyli środowisko programistyczne (IDE)
- Atmel Studio - Programatory
- Atmel Studio i niefirmowe programatory (np. USBasp)
- Atmel ICE - Programator i debugger (nowość 2014r.)
- Dlaczego programatory współpracujące z Atmel Studio są fajne?
- Jak przyspieszyć Atmel Studio?
- Masowe dodawanie plików - szablony
- Symulator pomaga szybko znaleźć błędy !!!
- Słownik języka polskiego i kolory komentarzy
- Numerowanie linii programu
- Naggy - sprawdzanie poprawności programu w trakcie pisania
- Code Size - określa wykorzystanie pamięci mikrokontrolera
- Data Size Viewer - jak szukać oszczędności pamięci?
- cdn. ...
Dokumentacja Atmela:
Dla znających angielski:
Życzę wielu udanych projektów!
Dzień dobry bardzo.
OdpowiedzUsuńSporo już czasu upłynęło od ostatniego artykułu, stąd pytanie - czy (zgodnie z zapowiedziami pojawiającymi się w komentarzach) można spodziewać się dalszych części niniejszej serii?
Pozdrawiam życząc pomyślności i twórczości w nadchodzącym roku...
wszystkim tutejszym autorom (;
Tak, już wkrótce.
OdpowiedzUsuńWitam, dziękując za dotychczasowe artykuły nie tylko o Studio chciałbym zapytać, czy będzie coś na temat symulatora?
OdpowiedzUsuńTak, kolejne będą o JTAG i symulatorze.
UsuńJTAGA nie mam, więc gdybyś mógł najpierw o symulatorze, to było by fajnie. To znaczy co nieco go używam, ale tylko w niewielkim stopniu, a pewni ma spore możliwości, o których nie wiem. Z góry dziękuję! Pozdrawiam.
OdpowiedzUsuńDondu napisał:
OdpowiedzUsuń> Argument z rozplenieniem się nieoryginalnych środowisk jest trafiony :)
A ja powiem, że jest niezwykle ważne, żeby nieoryginalne środowiska się "rozpleniały".
Zawsze i wszędzie jeśli będziemy mieli dodatkową możliwość wyboru (w czymkolwiek - choćby doborze sobie małżonki) będzie to dla mnie PLUS (nigdy minus!!!).
Chyba, że tworzymy kolejny - jedynie słuszny trend - gdzie myślenie jest niewskazane, i trzeba iść za instynktem stadnym (jak np. owce).
Edytorowi z Atmel Studio (o AVR Studio nie wspominając) jeszcze baaaaardzo daleko do tak krytykowanego tutaj Eclipse. Cokolwiek byście nie psioczyli - taki jest fakt.
"Cuda" (niedostępne na razie w Eclipse CDT) zobaczycie - gdy uruchomicie sobie np. Eclipse do tworzenia aplikacji na Androida. Kiedy doczekam się podobnych cudów w Atmel Studio z przyjemnością "odszczekam" swoje obecne zdanie na ten temat.
Cieszę się, że środowisko się rozwija - choć moim zdaniem szkoda, że idzie w stronę łączenia ARM+AVR.
Co do symulatora - to jest to taki Atmelowski "plaster na ranę" mający zastąpić drogie sprzętowe debuggery - które dostępne są za ogromne pieniądze (w porównaniu do innych środowisk innych firm). Żaden symulator nie zastąpi porządnego debugger'a sprzętowego. Kropka.
I nie mówcie koledzy o Dragon-ie za 250 zł. To "atrapa" - nie debugger.
Symulator - jaki jest obecnie - nadaje się jak najbardziej do nauki - to jest również niezaprzeczalna prawda ( i jego plus).
Po wysłuchaniu peanów na cześć symulatora można dodać, że najważniejszy jego plus - to to, że jest darmowy. Daleko mu jednak do płatnych rozwiązań - jak np. Trace32 z Lauterbach-a.
Jednak z pewnością stanowić może pomocne narzędzie do kontroli kodu.
Pozdrawiam wszystkich - zwłaszcza tych, którzy nie zgadzają się z moją opinią, ale zdolni byli ją "przetrawić" i mam cichą nadzieję na wyrozumiałość cenzora :)
Michał
P.S.
Skopiowałem z tematu traktującego o samym symulatorze - zgodnie z zaleceniami kolegi Dondu :)
Dziękuję, że przeniosłeś swoją wypowiedź do tego tematu.
Usuń1. Konkurencja środowisk IDE jest oczywiście wskazana. Czy konkurencja Eclipse vs Atmel Studio wpływa na poprawę jakości możliwości oryginalnego IDE, nie jestem taki pewien, ponieważ moim zdaniem wpływ na to ma ogólna strategia producentów mikrokontrolerów i ich rywalizacja o wielkości sprzedaży mikrokontrolerów. Oryginalne IDE jest tylko jednym z narzędzi marketningowych pozwalających tę sprzedaż maksymalizować. Dlatego Eclipse w pojęciu ATmela (który dostarcza swoje IDE za darmo) nie jest żadnym konkurentem, jest co najwyżej pomocnikiem w realizacji strategii dostępności ich mikrokontrolerów.
2. Nasz blog ma konkretną grupę docelową - wyrażoną jego nazwą: "Mikrokontrolery - jak zacząć?". Grupa docelowa w naszym rozumieniu składa się z uczniów szkół średnich, studentów uczelni wyższych o kierunkach związanych z tematem bloga, oraz hobbystów.
Do tej grupy kierowane są (przynajmniej na razie) wszelkie treści zamieszczane na blogu. Jeżeli blog kierowany byłby, do zawodowców (którzy na prawdę na to miano zasługują), treści byłyby inne. Innymi słowy Kubicy nie doradzalibyśmy auta klasy N, tylko od razu co najmniej WRC2. Nie oznacza to oczywiście, że zawodowcom bezwzględnie polecam Eclipse.
Dodatkowo znaczna część grupy docelowej ma znacznie ograniczone możliwości finansowe. Naszym celem jest pokazywać, jak za drobne środki osiągnąć cel, którym jest umiejętność wykorzystania mikrokontrolerów i elektroniki. Dlatego też pierwszą treścią widzianą na głównej stronie oraz w spisie treści jest temat artykuł: Jak najtaniej zacząć?
Jeżeli więc weźmiesz pod uwagę, te czynniki, to dojdziesz do wniosku, że w naszych artykułach:
- narzędzia muszą być darmowe,
- programatory najtańsze,
- stosowane elementy najtańsze z możliwych,
- itd.
Skoro więc mają być najtańsze to nie posiadają one porządnych debuggerów sprzętowych (które i tak nie wszystkie procesory mogą obsługiwać). Dlatego też jednym z najistotniejszych elementów jest symulator. W tym przypadku także Ty, potwierdzasz jego zalety dla początkującego.
3. Atmel Studio to środowisko do AVR i ARM Atmela, i pod takim kątem o nim piszemy. Gdy będzie to środowisko obsługiwało Androida, i gdy na blogu ten temat będziemy omawiać, to wtedy opiszemy środowisko dedykowane takim celom. Dlatego proszę nie opisuj możliwości Eclipse pod innym kątem niż w/w, bo powinieneś napisać także, że Atmel Studio jest zły, gdyż nie obsługuje środowiska do PHP i MySQL, itp. (BTW: Eclipse używam właśnie do PHP i MySQL).
4. W każdej dziedzinie stosuje się kompromisy, także i tutaj są. Jednym z nich jest używanie Eclipse jako jedynego środowiska programistycznego, do wielu różnych zastosowań. Można w nim pisać zarówno w PHP + MySQL, AVR, PIC, C, Assembler, ... itd. To niewątpliwie jest zaletą - zna się wtedy środowisko "jak własną kieszeń". Ale kompromis ten ma swoją cenę - brak pełnej integracji środowiska z tematem, do którego się je wykorzystuje.
Odwrotnie także jest kompromis - mam pełną integrację w przypadku MPLABX, ATmel Studio, ale za to muszę znać dwa środowiska IDE. Coś za coś = kompromis. Uważam natomiast, że dla początkującego (naszego czytelnika) kompromis powinien być jeden - wykorzystywane przez niego IDE musi mieć symulator (no chyba, że stać go na porządny sprzętowy debugger, a mikrokontroler który stosuje ma możliwość debuggowania).
ciąg dalszy (bo jest ograniczenie ilości tekstu):
UsuńPropozycja
Dyskusje o wyższości jednego IDE nad drugim mają sens sens, gdy podaje się konkrety. Proponuję więc, byś Ty lub inny czytający tę dyskusję podali, jakie konkretnie funkcjonalności Eclipse nie występują w Atmel Studio dla osoby zajmującej się mikrokontrolerami AVR i ARM Atmela, i jest to osoba z naszej grupy docelowej (określonej powyżej). Proszę także o procentowe wskazanie ważności danej funkcjonalności - suma oczywiście ma wynosić 100%.
Takie podejście będzie konstruktywne i da czytającym argumenty dla każdego środowiska IDE.
Reasumując - pisząc odpowiedź pamiętaj proszę o naszej tematyce, celach, grupie docelowej i jej możliwościach finansowych.
---- Nie dotyczące tematyki -----------------------------
UsuńDrobne wyjaśnienie dot. administrowania komentarzami
Napisałeś cyt: "Pozdrawiam wszystkich - zwłaszcza tych, którzy nie zgadzają się z moją opinią, ale zdolni byli ją "przetrawić" i mam cichą nadzieję na wyrozumiałość cenzora :) "
Merytoryczne komentarze są zawsze przepuszczane, co można stwierdzić np. na tej długiej dyskusji Jaki język wybrać?. Nie przepuszczam natomiast komentarzy niekulturalnych lub spamu, co jasno zaznaczyłem czerwonym tekstem na dole strony.
Nie postępujemy jak na innych stronach pewnego pseudoGuru i nie kasujemy jak on "niewygodnych" komentarzy pokazujących błędy w treściach przez niego publikowanych. Na naszym blogu zawsze można merytorycznie porozmawiać i poprawić mnie, czy innych autorów, bo nie uzurpujemy sobie prawa do bycia wszechwiedzącymi guru i rozumiemy swoje kompetencje i ich granice.
Dlatego śmiało pisz co uważasz za stosowne, podawaj argumenty za i przeciw, a czytający te treści sami wyciągną odpowiednie dla siebie i swojego stanu zaawansowania.
Skoro Dondu właściwie mnie wywołał do tablicy to swoje trzy grosze też wrzucę.
UsuńWłaściwie z wypowiedzią kol. Michała zgadzam się tylko w jednym punkcie – to fakt, że im więcej opcji tym zazwyczaj lepiej. Z resztą nie, już piszę dlaczego. Niesądzę, aby edytorowi z Atmel Studio coś w stosunku do Eclipse brakowało. Tym bardziej, że to nie edytor z Atmel Studio tylko z Microsoft Visual Studio. Więc jeśli o edytorze mowa to należałoby porównać VS vs. Eclipse. VS jest jak najbardziej komercyjnym środowiskiem, używanym przez miliony programistów, którzy jakoś tych rażących braków w nim nie dostrzegają, wręcz przeciwnie. Ale tu wchodzimy na grunt religii, więc, żeby nie bić piany dobrze by było podać, czego VS brakuje, a co takiego ma Eclipse. Ja powiem dlaczego Eclipse nie lubię – jest piekielnie wolne co wynika z Javy i naprawdę tu nie pomaga żaden wypaśny sprzęt, VS działa przy Eclipse jak rakieta, chociaż dla posiadaczy słabszego sprzętu pewnie oba środowiska przymulają. Ale jest ważniejszy powód – moją awersję do Eclipse wywołały działania firm, które to Eclipse wciskają ze swoimi produktami. Dlaczego? Ano dlatego, że każda firma robi swoją wersję środowiska, w efekcie często mam w kompie siedem(!!!) różnych wersji Eclipse wzajmenie niekompatybilnych, w różnych wersjach itd. Ale długo by o tym pisać.
Co do debuggerów – AVR Dragon to pełnosprawny debugger, różni się tylko tym, że nie ma obudowy. Byłbym wdzieczny za wskazanie dlaczego to atrapa? Tym bardziej, że jeśli mówimy o interfejsie JTAG, to jest to standard przemysłowy i tu debugger nie ma za wiele do powiedzenia, bo funkcje definiuje minimalna implementacja JTAG w procesorze a nie debugger. Debugger może być co najwyżej szybszy lub wolniejszy, nic poza tym. AVR Dragon dają identyczną funkcjonalność jak drogi JTAGICEII czy JTAGICEIII, i taką samą jak sprzętowe debuggery dla np. ARM – nie może być inaczej, gdyż jak napisałem definiuje to standard. Wiem o czym piszę bo używam wszystkich trzech i jakiś porażających różnic pomiędzy nimi nie ma.
Symulator to też nie jest konkurencja dla debuggera sprzętowego. Symulator uzupełnia debugger sprzętowy. Dlaczego? Dondu dał na razie na zachętę marchewkę, ale nie opisał jeszcze nawet 10% możliwości symulatora. Mam nadzieję, że szybko to nadrobimy i pokażemy więcej. Symulator symuluje nie tylko procesor, umożliwia także stworzenie plików stymulacji umożliwiających symulowanie układów zewnętrznych, czy dowolnych stanów na pinach IO procesora oraz ich logowanie. W efekcie jeśli w układzie mamy jakiś specyficzny zestaw sygnałów to o wiele łatwiej użyć symulatora niż kombinować z debuggerem sprzętowym. Także nie jest to żaden „plaster na ranę” lecz kolejne narzędzie ułatwiające pisanie programów. Podobnie jak np. symulator do ISE Xilinxa też trudno nazwać plastrem na niedomogi programowania FPGA...
Żeby nie wywoływać kolejnej wojny w stylu "ja lubię Atari, a ty Commodore" postaram jak najkrócej - i merytorycznie.
OdpowiedzUsuńCo do porównania IDE Visual Studio i Eclipse - mogę powiedzieć, że oczywiście macie koledzy pełne prawo myśleć inaczej niż ja. Spędziłem sporo czasu pisząc na PC w Visual Studio i uważałem je za najlepsze środowisko do programowania aplikacji dla Windows (dalej tak uważam). Co więcej - uważałem za najlepsze środowisko w ogóle ... dopóki nie zostałem przez życie zmuszony niejako by usiąść przy tak bardzo omijanej przeze mnie szerokim łukiem - Javie (akurat w wersji dla Androida).
Poza możliwościami samego IDE + ADT + dodatki (wszystko elegancko integrujące się z Eclipse) - na kompletne łopatki rozłożył mnie debugger. Gdybym nie miał wątpliwej przyjemności używania debugger-ów AVR (Dragon i własnoręcznie zrobiony JTAGICE) - oraz szeregu debuggerów pod ARM-y (z firmowym Trace32 włącznie) - pewnie nie miałbym porównania.
Debugger pod Android działa dokładnie tak - jak powinien działać każdy inny. Dodatkowo w roli interfejsu nie potrzebujemy kosztującego tysiąc(e) złotych jedynego firmowego interfejsu - wystarczy kabelek USB + przestawienie Android'a w tryb "Debugowanie USB”.
Ja wiem – „micro” w tym przypadku ma znaczenie. MCU to nie „caly system” itd., ale - jak widać – nie jest to takie trudne. Bo jakaż to różnica (patrząc ze strony sprzętu) między debugowaniem ARM’a w urządzeniu opartym na Androidzie – a debugowaniem innego ARM’a/AVR-a? Da się?
Wracając do Atmel Studio vs Eclipse i kolejnego argumentu – jakoby Visual Studio wyznaczało ramy cywilizacji programistycznej w obecnych czasach. Pozwolę się z kolegą Tomkiem nie zgodzić . Ramy wyznaczają obecnie Java oraz C (do programowania w nich używane jest głównie Eclipse/NetBeans). http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Kolejny argument: AVR Dragon jest pełnosprawnym debuggerem.
Pewnie, że jest. Niestety jest bardzo podatny na uszkodzenie, nieprawdaż?
I nie chodzi mi tutaj o jego obudowę.
Ale pomówmy o „następnym w kolejce” - debuggerze – który kosztuje ile?
Można oczywiście się zasłaniać polityką firmy – która sobie tak to wymyśliła, ale popieranie jej postępowania za wszelką cenę nie jest "okej". Trzeba mówić co nam się nie podoba (a nie przyjmować słowa Atmel’a jako „wyrocznię”), to może panowie z Atmel w końcu nas wysłuchają?
Liczyłem na to, że podasz konkrety zgodnie z punktem Propozycja, bo tylko wtedy można porównać oba środowiska (poza symulatorem oczywiście). Gdybyś więc znalazł czas i chęci, i poparł swoje zdanie konkretami, to byłby materiał do porównania.
UsuńDo tej pory wszyscy zachwalający wykorzystanie Eclipse do AVRów, nie wykazali konkretnych jego zalet (przewagi) w stosunku do Atmel Studio, a przynajmniej nie na naszym blogu, czy na Elektroda.pl.
Ok, ale my nie piszemy w Javie... Więc trudno porównywać NetBeans, który został stworzony do Javy ze środowiskiem, które zostało stworzone do czegoś zupełnie innego i zarzucać mu, że równie fajnie nie pisze się w nim programów w Javie. Prawdę mówiąc nie rozumiem twojego argumentu.
OdpowiedzUsuńWeź też pod uwagę, że większe ARMy mają całe układy służące wyłącznie debuggowaniu. Nawet zwykłe cortexy ich nie mają – dla nich debuggowanie wygląda jak na AVR. Tu znowu – sprzęt nie ma nic do tego, sprzęt to tylko interfejs pomiędzy np. PC a interfejsem debuggowania udostępnianym przez procesor. W 4-rdzeniowym procku zawierającym setki milionów tranzystorów można sobie pozwolić na wrzucenie bloku debuggera o złożoności ARMa, z własną pamięcią i bajerami. Coś takiego zupełnie nie nadaje się do wrzucenia np. w małego Cortexa czy AVRa. Z drugiej strony jakiś olbrzymich różnic tu nie widzę, może po prostu soft androida wygląda przyjemniej.
Moge też zdementować twierdzenie, że jakoby AVR Dragon był podatny na uszkodzenia. Jest tak samo podatny jak JTAGICE MkII, czy JTAGI do ARMów. Na wyjściu ma bufor+translator poziomów i tyle. Pewnie opierasz swoją opinię na Dragonach produkowanych lata temu, które miały wadliwie zaprojektowaną przetwornicę, która łatwo ulegała uszkodzeniu. Te serie wyszły ze sprzedaży jakieś 4 lub więcej lat temu, ale jak widać mity są ciągle żywe. Następny w kolejce JTAGICE III kosztuje 350-490zł w zależności od promocji. IMHO niewielki jest sens jego kupowania. Zgadzam się, że Atmel powinien obniżyć ceny na narzędzia, bo takie jakie są to strzelanie sobie w kolano. A już zupełną porażką jest, że Xplained nie jest tak jak STM Discovery wyposażone w debugger, tym bardziej, że wiele z nich zawiera jako np. bridge do USB wypaśne 32-bitowe procki z serii UC3 i taki debugger to byłaby tylko kwestia wgrania softu. Ale za to mamy w pełni darmowe, wspierane przez producenta środowisko + toolchain, czego obecnie nie daje żadna inna firma.
Pokazane artykuły nie są też peanem na rzecz doskonałości Atmel Studio – mają pokazać jak się tym narzędziem posługiwać. Niezależnie co kto o AS myśli, lepiej mieć symulator niż go nie mieć. Korzystać nie musimy, lecz jeśli chcemy... cóż, Eclipse nam go nie oferuje.
Porównanie do Javy to tylko przykład. Nie mówię o specyfice języka - a o elementach, których mi brak w IDE - jak (inteligentniejsze niż w VS) podpowiadanie składni, automatyczna zmiana deklaracja/definicja - przykładowo - dodajesz do definicji dodatkowy parametr - automatycznie uaktualniany jest w deklaracji, wykrywanie błędów "online" - podczas pisania (nie samych błędów składniowych, a również kodu "przestarzałego", kodu o nieprzewidzianym/złym działaniu (zaznaczanie potencjalnych błędów), automatyczna zmiana np. nazwy zmiennej we wszystkich miejscach jej wystąpienia - bez konieczności ręcznego skakania po całej funkcji itd. itp..... To są zdaje się szczegóły - ale w olbrzymi sposób ułatwiają programowanie. Może w przypadku AVR nie jest to problem, ale w przypadku ARM - gdzie projekty potrafią być naprawdę rozbudowane - dobrze jest, żeby o takie szczegóły dbało nasze IDE, jeśli ma zasługiwać na miano "inteligentnego".
OdpowiedzUsuńNie zrozumcie mnie źle - cieszę się, że jest (że za darmo - tym bardziej). Cieszę się, że się rozwija - ale komentarze w stylu "Bo Eclipse jest gorszym IDE" do mnie nie docierają.
Jest gorszym środowiskiem do AVR (przez brak interfejsu debugger'a) - a to z racji kiepskiego "dezajningu" i poziomu AVR Plugin-a, a częściową winę ponosi za to Atmel - z tego co wiem - między innymi przez utajnienie części kodów debugowania własnych układów.
I to na tyle w temacie Eclipse.
Co do drugiego argumentu - o Cortex'ach i debugowaniu - otóż wspomniany Android który debugowałem - to właśnie jednordzeniowy Cortex A8. Żadne 4-rdzeniowe "cudo". Raczej nie sądzę (nie rozbierałem) żeby specjalnie w każdy tablet wpychali specjalizowany zewnętrzny układ do debugowania.
Rozumiem, że (być może) architektura Cortex-ów klasy "M" to co innego, jak i AVR - ale nie podejrzewam tych "większych" o specjalistyczne zachody w tym względzie.
Co do Dragona to chyba o to mi chodziło - dobrze, że zostałem wyprowadzony z błędu.
Byłem świadkiem uszkodzenia jednego AVR Dragona (na szczęście tylko świadkiem - nie winnym).
Mówił kolega o AVR Dragon - że nie jest złym wyjściem (nowa wersja), oraz, że sens kupowania JTAGICE III jest niewielki. Dlaczego? Chętnie się dowiem.
Wiem (ale nie sprawdzałem), że w roli programatora w Atmel Studio można używać AVRISP mkII.
A co z debugger'ami? Napisał kolega, że JTAGICE III można kupić za 350-490 zł.
Trochę to jednak za dużo, AVR Dragon kosztuje niewiele mniej. JTAGICE || (którego pełno ofert w Internecie) - to raczej ciekawostka.
Czy myśli kolega, że AVR Dragon jest dla początkującego dobrym rozwiązaniem? Czy różnica w cenie 50-70 zł między AVR Dragon a JTAGICE III przekłada się na korzyść tego drugiego?
I jeszcze jedno pytanie - gdzie można w miarę tanio dostać obydwa programatory?
Dziękuję za odpowiedź
Pozdrawiam
Michał
Bajery o których piszesz są w Atmel Studio/Visual Studio. Np. zmiana nazwy funkcji/zmiennej jest w menu kontekstowym Refactor, można sobie wybrać różne bajery z tym związane, ograniczyć refaktorowanie do pliku, części pliku czy wskazanych plików projektu. Jest możliwość wyświetlania nieaktywnych fragmentów kodu, czy uzyskiwanie informacji o błędach – możesz wybrać czy błedy będą podkreślane (tak jak w MS Word), czy info będzie na marginesie. Ba, nawet dostajesz informację na czym błąd polega i jak go poprawić. Także to wszystko jest, trzeba się tylko z AS zaprzyjaźnić Zobacz Extension Manager w AS.
UsuńCo do cortexów, np. A8 – mają one znacznie bardziej rozbudowany debugger w procku, nie chodzi o jakiś dodatkowy scalak, tylko część procka, która się zajmuje śledzeniem rejestrów, logowaniem stanu, operacji itd. Tego typu bajery są tylko w rozbudowanych procesorach, bo w prostych raz, że są niepotrzebne, dwa – żrą prąd i zajmują miejsce na krzemie.
Co do imho niewielkiego sensu kupowanie JTAGICE III – nie jest szybszy od dragona, jest w obudowie, ale funkcjonalnie to mniej więcej to samo. A jest droższy o 100-200zł. Oczywiście jeśli dla kogoś to żadna różnica to jak najbardziej można go kupić. Dragona i inne narzędzia atmela można kupić w Seguro, Kamami itd. IMHO Dragon dla początkującego z ambicjami to bardzo dobre narzędzie. Przy rozsądnej cenie (240-250 zł) ma się w pełni funkcjonalne narzędzie, naprawdę odporne. Mojego Dragona katuję niemiłosiernie, leży bez obudowy w plątaninie kabli, zdarza się odwrotnie wtyczki włożyć ale ciągle żyje (odpukać). JTAGICE gdzieś mi się kurzy na płytce, czeka chyba na śmierć Dragona, ale doczekać się nie może. Dragona jest sens kupić jeśli planujesz poważniej zabrać się za średnie i większe AVRy – jeśli siedzisz tylko w ATTiny, które nie mają interfejsu do debuggera to nie ma oczywiście sensu, lepiej kupić dużo tańszy klon AVRISPMkII/I. IMHO jest niezastąpiony jeśli planujesz używać ATMEGA 16 i większe, które mają interfejs do debuggowania lub XMEGA. Zresztą wkrótce pokażemy możliwości i działanie sprzętowego debuggera. Dragon programuje też wszystkie procki Atmela – zarówno 8-, jak i 32-bitowe (seria UC). Nie wiem jak będzie z nowymi ARMami od Atmela (seria SAM D). BTW, warto też wspomnieć, że AS to wspólne IDE dla AVR8, AVR32 i ARM, co ułatwia żonglowanie pomiędzy tymi rodzinami.
Michale - właśnie o to mi chodziło, byś podał jakieś konkretne funkcje, które są w Eclipse, a których nie ma w Atmel Studio. Większość o ile nie wszystkie, które wymieniłeś są w Atmel Studio. Nawet jeżeli którejś nie ma to zapewne w następnej wersji AS będzie.
UsuńW ten sposób rozwiewamy narosły mit wśród użytkowników Eclipse, o jego wyższości na Atmel Studio.
Przypominając, że blog jest kierowany do początkujących, którzy z reguły dodatkowo mają ograniczone zasoby gotówki, będę podkreślał zawsze, że dla tej grupy osób, posiadanie darmowego symulatora jest ważniejsze od wszelkich bajerów edycyjnych.
cyt. "Większość o ile nie wszystkie, które wymieniłeś są w Atmel Studio"
UsuńPotwierdzam, że tak jest. Używałem Eclipse, ale po przesiadce na Atmel Studio nie brakuje mi żadnych udoskonaleń edytora kodu Eclipse. Wszystko co używałem w Eclipse jest w Atmel Studio. Owszem musiałem się przyzwyczaić do interfejsu AS, ale to samo było, gdy zaczynałem z Eclipse.
Dorzucę swoje 3 grosze.
OdpowiedzUsuńPracuję na Eclipse od ładnych 4 lat przede wszystkim w PHP. Znam to środowisko całkiem dobrze. Do zabawy z AVR wykorzystuję Atmel Studio. Nie widzę przewagi Eclipse!!!!
Wręcz przeciwnie - brak w Eclipse symulatora mikrokontrolerów jest kluczowy w szczególności dla początkujących!!!!!!!
Jeśli chodzi o bajery edycyjne są porównywalne w obu środowiskach.
Pozdrawiam,
Piotr
(aktualnie z Holandii)
Twierdzenie, że Atmel Studio jest gorsze/lepsze od Eclipse pod względem edytora tekstu jest tak samo uzasadnione jak twierdzenie, że BMW jest gorsze/lepsze od Mercedesa. Oba środowiska mają wady i zalety, a szybkość pisania programu zależy od poznania wybranego środowiska.
OdpowiedzUsuńNatomiast dla początkującego BRAK SYMULATORA, to poważna wada Eclipse.
Pozdrawiam autorów!
Dołączę się do dyskusji i powiem, że używałem Eclipse przez wiele lat do różnych celów, ale odkąd zająłem się AVR, to doceniam to co pisze Dondu, czyli symulator.
OdpowiedzUsuńGdy po pierwszych moich prośbach o pomoc na Elce, ktoś zadał mi pytanie dlaczego nie sprawdzę w symulatorze zrobiłem wielkie oczy, że coś takiego w ogóle jest. A później już sam potrafiłem znaleźć problemy moich programach i nie potrzebowałem forum. Jako początkujący w tamtym okresie symulator zaoszczędził mi wiele czasu i nerwów.
Reszta, to tylko kwestia przyzwyczajenia się do danego środowiska programistycznego, tak jak do klawiatury, które są przecież różne, a umożliwiają to samo.
Pozdrawiam i Wesołych Świąt!