Atmel Studio 6 IDE - alternatywa czy konkurencja

Czyżby visual studio dla AVR



Co o tym sądzicie

Przecież to IDE istnieje już grubo ponad rok (wcześniej v.5)
Czy konkurencja - raczej niemrawa podróbka.
Pójście Atmela w stronę Windows'a jest nieco głupie (chcą uzależnić programistów od środowiska, jak to zrobili z programatorami i JTAG-iem). To takie rzucanie kłody pod nogi.
Można się obruszać na konkurencję (eclipse), ale 90% pozostałych środowisk wzorowane jest na nim (albo oparte).
Moim zdaniem - sztuczny twór.

Ten Pan z tego filmiku tak fajnie mówi, że jedyne czego potrzebujesz to "ONE SIGLE FILE" ... zapominając dodać, że ten łan single fajl ma 750MB !!! Jakaś masakra. Instalacja nawet na szybkich kompach trwa wieki. Pół windowsa zostaje przeorane najnowszymi dodatkami i katowane DOT NET'ami ... a start samego środowiska to po prostu porażka. Jeszcze wolniej i jeszcze gorzej niż AS5 .... Coś czuję że kolejna wersja AS7 to będzie kolejny łan single file 1,4GB i jeszcze wolniejsza kobyła. Jak ktoś mówi że AS5/6 jest tak samo mułowate jak Eclipse to nie wie co mówi albo nigdy w Eclipse nie działał. Instalka Eclipse w postaci także jednego pliku i to ZIP, zajmuje nie więcej niż 200MB i wystarczy tylko rozpakować na dysku. Już jest gotowe do działania.

Co więcej Eclipse bardzo dobrze działa z najnowszym toolchainem ver. 3.4 od Atmela (mamy więc do dyspozycji WSZYSTKIE procki AVR łącznie z XMEGA jeśli ktoś potrzebuje), więc całe to AS6 to można sobie trzymać na dysku jeśli się chce ew zajrzeć do MFC albo skorzystać z tego symulatora lub debugera.

Sam jestem ciekaw czy Atmel zmieni politykę w tym względzie czy jeszcze pogorszy, wypuszczając kolejnego potwora ala MS Visual Studio.

AS6 jest pisany w środowisku visual i po prostu korzysta z tego co udostępnił Microsoft. Jest podobny do VS, bo to po prostu de facto nakładka na VS - oba korzystają ze wspólnego silnika. I jak całe to środowisko wymaga dosyć mocnego komputera, ale nie przesadzajmy. Na starym AMD X2 uruchamiał mi się ze 20 sekund, na nowym może 2-3s. .NET i tak na większości komputerów jest, bo się to instaluje przy różnych okazjach, a programów zależnych od .NET jest co raz więcej. Warto się też zastanowić dlaczego AS6 ma 1,5GB - samo środowisko jest małe, to co tworzy taką objętość to fakt, że wraz z AS6 instaluje się wszystkie noty procesorów, ponad 1100 przykładów, całe ASF i kompletne toolchainy dla AVR8, AVR32 i ARM. Więc trudno się dziwić, że ma to taką długość. Z drugiej strony w czasach, gdy jedno zdjęcie z aparatu ma 23 MB, 1,5 GB nie szokuje.
A już rada, żeby pisać w Eclipse i instalować AS6 do debugowania jest co najmniej śmieszna - skoro przeszkadza nam jego długość, to długość AS6 + 200 MB Eclipse + ileśtam MB toolchaina to jeszcze więcej.
Poza brakiem debuggera i symulatora (co jest niezbędne do pisania czegokolwiek bardziej skomplikowanego niż "miganie diodami"), Eclipse też nie ma kreatora do ASF, a kto próbował w to wchodzić wie, że ręczna konfiguracja projektu jest drogą przez mękę. Warto też pamiętać, że AS6 ma gotowe szablony pod wszystkie płytki developerskie Atmela, co znakomicie ułatwia start. Właściwie napisanie całkiem zaawansowanej aplikacji przy pewnym szczęściu (obecności gotowych driverów w ASF) ogranicza się wtedy do kilku kliknięć i wybraniu potrzebnych modułów.
Niewątpliwą wadą jest to, że działa tylko w MS Windows, ale co zrobić.

Oprócz wielkogabarytowego AS6 i mulącego Javą Eclipse istnieją inne rozwiązania, np. Code::Blocks. ale i tak jestem najbardziej przyzwyczajony do prostego edytora tekstowego z możliwością zapisywania wielu sesji zestawów plików, trzymania opcji projektu w Makefile i klepania poleceń w zsh pod Linuksem.

tmf wrote:

...Warto się też zastanowić dlaczego AS6 ma 1,5GB - samo środowisko jest małe, to co tworzy taką objętość to fakt, że wraz z AS6 instaluje się wszystkie noty procesorów, ponad 1100 przykładów, całe ASF i kompletne toolchainy dla AVR8, AVR32 i ARM. Więc trudno się dziwić, że ma to taką długość. Z drugiej strony w czasach, gdy jedno zdjęcie z aparatu ma 23 MB, 1,5 GB nie szokuje.

Z całą pewnością kolega o wiele lepiej się zna na AVR niz ja. Pozwolę sobie (a jednak) nie zgodzić z tym, co szanowny kolega napisał.
Środowisko AtmelStudio 6 z powodzeniem mógłbym nazwać "Mydło i Powidło 6".

Czego tam nie ma: oprócz tego, czego większość z nas chce - jest 99% rzeczy - których nigdy nie użyjemy. - Przynajmniej ja nie użyję A32, XMEGA, czy atmelowskich ARM-ów (w ten sposób).
Nie użyję debugera STK600 na którego nie stać większości z nas, ani drogich płyt ewaluacyjnych.

Dla osoby, takiej jak ja - a pewnie wyjątkiem nie będę - która pisze pod 8-bitowe AVR-y (tylko te 8-bitowe) środowisko to jest "absolutną porażką".

Pozwolę sobie stwierdzić - że eclipse - nawet z ułomnym AVR-plugin bez "ficzerów/bajerów" w stylu ASF zapewnia wygodniejszą pracę.
I da się pod nie podłączyć USBASP czy nawet STK200!

Co do debugowania mógłbym się zgodzić z kolegą - osobiście nie pisałem na AVR programów przekraczających 32kB, więc sens wykrywania błędu debuggerem w tak "wielkim" kodzie uważam za "sztukę dla sztuki".
Oczwiście używałem debuggera - począwszy od PIC18 (128kB) - skończywszy na ARM11 (32MB), w których to mikrokontrolerach/procesorach stosowanie debuggera podczas programowania jest oczywiście niezbędną koniecznością.

LordBlick wrote:

Oprócz wielkogabarytowego AS6 i mulącego Javą Eclipse istnieją inne rozwiązania, np. Code::Blocks. .

Zdecydowanie wolałbym CodeBlocks gdybym nawet Eclipsa nie lubił niż potworka AS6 z jego czarodziejskim wspomaganiem zestawów lansowanych na siłę. Po to biorę środowisko, żeby szybko i wygodnie pisać swoje projekty na zestawie, który mi się żywnie spodoba i w oparciu o programator który mi się żywnie spodoba.

Dodano po 4 [minuty]:

mickpr wrote:

osobiście nie pisałem na AVR programów przekraczających 32kB, więc sens wykrywania błędu debuggerem w tak "wielkim" kodzie uważam za "sztukę dla sztuki".

Bardzo słuszna uwaga. Myślałem że to tylko ja tak mam. Tymczasem warto uczyć się radzić sobie przy tak prostych kodach bez debuggera i tym podobnych dobrodziejstw ... Bo potem okaże się, że migania LED'em ktoś nie jest w stanie bez debugera i MSF zrobić

@mirekk36

Bez obrazy wiem ze lubisz Eclipse, ja uzywam bo nie mam wyboru pod OS X-em. Ale niestety Eclipse to tez kobyla w Javie ktora czasami jak zamuli to wszystkiego sie odechciewa... Nie wspominajac o tym ze czasem jest cholernie nie wygodne...

Choc faktem jest ze nowe AS to nie jest szczyt wygody - musza ten soft jeszcze dopracowac. Przynajmniej do Visual Studio mu sporo brakuje Jednak i tak oferuje o wiele wiecej niz jakikolwiek sklejanie Eclipse z roznymi dodatkowymi programami.
Inna sprawa AS to juz nie tylko male AVR-y...

Niestety Java jak i .NET to nie sa idealne rozwiazania jednak mocno promowane i trzeba do tego przywyknac ze producent woli pisac kobylasty kod ale szybciej niz cos bardziej wydajnego ale spedzajac na to wiecej czasu. Java jak i .NET rozwiazuje wiele problemow niemal z automatu, ale niestety kosztem wydajnosci itd.

Natomiast co do prostych kodow i debuggera to czasem uzywam do liczenia cykli jesli jest to dla mnie istotne jak szybko cos ma sie wykonywac... Mozna recznie na kartce - tylko po co tak sie meczyc ?

Panowie, a jak samochód kupujecie a nie lubicie szybko jeździć to szukacie takiego, coto tylko 80 na godzinę pojedzie maksymalnie?
Nie lubicie korzystać z klimatyzacji to nie kupicie dobrego samochodu, tylko powiecie: Nie, jednak może kupię starego malucha, bo nie pojedzie za szybko i nie ma klimatyzacji? No bez przesady. A komu teraz 1.5 GB na dysku przeszkadza?
To, że ktoś korzysta tylko z małych AVR nie znaczy, że Atmel musi rozdzielać każdemu według potrzeb, bo tak to nigdy wszystkim nie wygodzi. Kolejna sprawa, przeszkadza wam czasu uruchamiania. A ileż to razy na dzień się go włącza? Co 5 minut, żeby to przeszkadzało? To, że ktoś nie umie/nie lubi/nie chce mu się korzystać z debugera, nie znaczy, że ma go nie być. Wielkość kodu to dziwne kryterium oceny, kiedy debuger jest potrzebny. Debugera używa się w razie problemów i nie tylko. Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak. Więc jeśli się nie ma debugera, to trzeba sobie radzić, kombinować i się męczyć nieraz długi czas z małymi problemami. Ale jeśli ktoś posiada programator/debuger to to musi mieć nieźle pokręcone pod sufitem, żeby w razie potrzeb kombinować na piechotę zamiast po prostu z niego skorzystać.

drzasiek wrote:

Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak.

W starszych rdzeniach sprawdza się tylko już dawno opracowane debugowanie po RS232. A i w nowszych nie jest wykluczone.
Jest jeszcze VMLAB, ale przyschnięty. AS6 nawet nie próbowałem odpalać w wine... Z AS6 najbardziej mnie interesowały tylko pliki XML z rozpiską I/O, a reszta (prze konwertowanie w pliki nagłówkowe) to kwestia skryptu w Python.

mickpr wrote:

Co do debugowania mógłbym się zgodzić z kolegą - osobiście nie pisałem na AVR programów przekraczających 32kB, więc sens wykrywania błędu debuggerem w tak "wielkim" kodzie uważam za "sztukę dla sztuki".
Oczwiście używałem debuggera - począwszy od PIC18 (128kB) - skończywszy na ARM11 (32MB), w których to mikrokontrolerach/procesorach stosowanie debuggera podczas programowania jest oczywiście niezbędną koniecznością.

A cóż takiego jest w kodzie ARM, co wymaga debuggera, czego nie ma w kodzie na AVR? Debugger to po prostu wygoda, jeśli coś jest nie tak. Nie tylko wygoda w debugowaniu programu, ale także hardware. Przez JTAG ma się pełną kontrolę nad pinami i podsystemami MCU. Wyobraź sobie, że na płytce gdzieś masz zwarcie, albo chcesz sobie sprawdzić jak się pozostałe układy zachowają przy pewnym stanie pinów IO. Podłączasz JTAG, wyklikujesz sobie potrzebny stan i już wszystko wiesz. Owszem, większość rzeczy da się zrobić bez, ale po co używać noża do wkręcania śrubek jeśli można mieć automatyczny wkrętak?
Poza tym podpisuję się wszystkimi kończynami pod tym co napisać kolega Drzasiek.
Oczywiście każdy sobie wybiera co lubi, ale to, że ktoś lubi syrenkę, to nie powód, żeby wyśmiewać tych co lubią mercedesy. A swoją drogą, jak ktoś szuka lekkiego i fajnego IDE, działającego na wielu platformach to CodeBlocks tak jak pisał LordBlick jest naprawdę świetny. Ma wszystkie podnoszone przez przeciwników AS6 zalety: krótki (kilka MB, a nie 200 jak opasły Eclise), szybki (natywnie napisany w C), wieloplatformowy i bardzo prosty, bez wszystkich zbędnych (niezbędnych) wodotrysków.

Dodano po 5 [minuty]:

LordBlick wrote:

drzasiek wrote:

Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak.

W starszych rdzeniach sprawdza się tylko już dawno opracowane debugowanie po RS232. A i w nowszych nie jest wykluczone.
Jest jeszcze VMLAB, ale przyschnięty. AS6 nawet nie próbowałem odpalać w wine... Z AS6 najbardziej mnie interesowały tylko pliki XML z rozpiską I/O, a reszta (prze konwertowanie w pliki nagłówkowe) to kwestia skryptu w Python.

Pamiętaj, że dla wszystkich MCU istnieje jeszcze symulator, co też nie wymaga żadnego hardware i jest dostępne dla wszystkich. Dzięki temu można sobie sprawdzić przynajmniej fragmenty kodu. Od razu można w ten sposób wykryć np. błędną konfigurację peryferii, błędy typu x=y zamiast x|=y itd. Symulator AS6 ma jedną kolosalną zaletę - korzysta z plików opisu wykorzystywanych przy tworzeniu rdzenia AVR, to te same pliki na podstawie których generowany jest zawierający go kawałek krzemu. Dzięki temu symulator w 100% oddaje zachowanie MCU, w tym błędy w krzemie. Idealne jest coś naprawdę poszło nie tak.
BTW, o ile się nie mylę Atmel daje jakieś narzędzie do konwersji XMLi do plików nagłówkowych.

tplewa wrote:

@mirekk36
Bez obrazy wiem ze lubisz Eclipse, ja uzywam bo nie mam wyboru pod OS X-em. Ale niestety Eclipse to tez kobyla w Javie ktora czasami jak zamuli to wszystkiego sie odechciewa... Nie wspominajac o tym ze czasem jest cholernie nie wygodne...

Ależ za co miałbym się obrażać? Przecież ja nikomu na siłę nie narzucam swojej opinii a każdy wybierze i tak to sam uważa za stosowne. Pewnie, że Eclipse to nie jest NotePad.Exe .... Po prostu podałem taki np hyhyhy toolchain narzędzi jakie ja bym wybrał a w tym toolchainie AS6 jest dla mnie na szarym końcu. Generalnie zgadzam się z całą twoją wypowiedzią i nie widzę żadnej sprzeczności.

A co do debugowania to tak jak pisze LordBlick .... (ja też o tym wspominam często) ... byle RS232 i już jest debug. Ale też nie mam nic przeciwko tym osobom, które z symulatora czy debugera korzystają. Co za problem? ludzie czy my tu mamy jak ława przysięgłych ocenić co jest najlepsze a co najgorsze? Każdy wypowie swoje zdanie i już.

Nawiasem mówiąc to sam mam w duchu nadzieję (tak jak czekałem po niewypale AS5), że kolejna wersja AS będzie w końcu porządna. Na razie jednak się na to nie zanosi jak widać i szkoda.....

Dodano po 10 [minuty]:

tplewa wrote:

Choc faktem jest ze nowe AS to nie jest szczyt wygody - musza ten soft jeszcze dopracowac. Przynajmniej do Visual Studio mu sporo brakuje Jednak i tak oferuje o wiele wiecej niz jakikolwiek sklejanie Eclipse z roznymi dodatkowymi programami.

Z tym jednak pozwolę sobie się nie zgodzić, chociaż to moja subiektywna opinia, a sporo piszę kodu na PC (i pisałem) to mam porównanie co do dobrych edytorów dla programisty. Dlatego wg mnie to co oferuje AS to nadal pościg króliczka za Eclipse. I jest wręcz odwrotnie niż ty mówisz (dla mnie oczywiście), to AS brakuje pod tym względem dużo do Eclipse. Mówię o edytorze. I to bez dwóch zdań.

tplewa wrote:

Inna sprawa AS to juz nie tylko male AVR-y...

Tak ale zauważ że temat raczej krąży wokół tych małych AVRów i w tym aspekcie się o tym pisze (AVR, Xmega). A jak na razie to nie widzę też entuzjastów pisania kodu pod ARM'y w opasłym AS6. Tu oczywiście, króluje Eclipse w najróżniejszych odmianach itp

drzasiek wrote:

Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak.

Jedyną przyczyną nie korzystania (czasem) z debuggera jest rozumowanie logiczne.

Przypomina mi się cytat z jakiejś gazety:

Quote:

Do zabicia muchy wystarczy złożona gazeta, nie potrzeba sterowanego zdalnie laserowego działka

Zauważmy też, że Atmel wyposażył w JTAG jedynie niektóre AVR-y, a DebugWire - cóż.... pozostawię bez komentarza.

Wszyscy moim krytykanci oczywiście skrzętnie pomijają cenę debuggera - przykładowo STK600: http://www.seguro.pl/sklep/?zobacz=4885 ---- TYLKO 843 zł.
Wybaczcie panowie - ale szkoda mi kasy na urządzenie - które wykorzystam raz, dziesięć czy nawet dwadzieścia razy (bo na pewno nie więcej) - gdyż ceny ARM-ów spadły na tyle,
że wolę włożyć w projekt np. taki LPC1114 - który kosztuje taniej niż niejeden AVR i jest wydajniejszy.
Nie czarujmy się - stosowanie większych AVR-ów : XMEGA czy A32 oraz PIC24/32/33 zamiast ARM-ów to trochę "retro-elektronika".

Jeśli mam 32kB kodu, a 80% tego zajmuje sprawdzony kod, który reużywam (procedury do UART, SPI, I2C, FAT, SD czy Ethernetu) - to po co mi narzędzie do sprawdzenia 20% z 32kB = 6KB kodu?
Znaczniej dłuzej zajmie mi podłączenie całości do płytki i uruchomienie dziadostwa, niż przejżenie kodu. Skórka nie warta wyprawki.

Gdybym zawodowo pisał pod AVR-y (te większe, przy których jest wogóle sens podpinac JTAG) - z pewnością bym sobie go kupił, jednak wolę tak zaoszczędzoną kasę włożyć w sprzęt do ARM-ów.

Zamiast kłótni na elektrodzie proponuję trochę ochłonąć - a zaoszczędzoną energię włożyć w projekty - te z JTAG-iem i te bez niego.

@mickpr

Stosowanie ARM-ow jest niestety czasem mniej wygodne i lepiej dac AVR-a itp. Co zrobisz jak potrzebujesz TTL 5V ?, a porty 5V tolerant cie nie urzadzaja. Pakujesz konwertery ktore kosztuja i w dodatku podnosza cene PCB.

Dalej zamiast dawac trudniej dostepne ARM-y z serii motor control, mozna znalezc jakiegod dsPIC-a itd. (jesli potrzebujemy jakis sprzetowych wejsc fault itd.)

Mozna wymienic jeszcze kilka spraw gdzie pakowanie na sile tanszego ARM-a nie jest dobrym rozwiazaniem...

To ze cos jest tansze to nie znaczy ze zawsze lepsze Wiem wiem i zawsze to mowie ze jest moda na ARM-y i pcha sie je wszedzie bez zastanowienia bo akurat ARM jest tanszy. Finalnie uklad czasem wychodzi drozej bo sam procesor to nie caly uklad.

Po prostu poraz kolejny twierdze na tym forum ze procesor dobiera sie do projektu z glowa, a nie tylko patrzac na cene i MIPS-y.

Odnosnie ceny debuger-a dla AVR-ow to niestety za oryginal Jlinka tez trzeba troche dac ? Mozna je porownac Do tego taki Jlink srednio dziala z OpenOCD... a Keil, IAR to niestety kolejne koszty. FTDI jest tanie i tylko tanie - na tym konczy sie zaleta takiego jtag-a

Natomiast mam porownanie bo mam i graty do AVR-ow, PIC-ow, ARM-ow (Jlink, FTDI, STLink)... Natomiast jak porownujesz ceny (mowa o STK600) to porownaj do oryginalnego JLINK-a (z sensownymi licencjami), bo do AVR-ow masz i Dragona i wiele klonow, do PIC-ow podobnie ktorych cena juz jest inna.


@mirekk36
Odnosnie ARM-ow i Eclipse to tutaj akurat jest to popularne, od biedy zintegruje sobie i VS czy XCode do toolchainu dla ARM-ow. Tylko to raczej taka sztuka dla sztuki.

Owszem jak pisalem AS nie jest idealne, ale ma swoje zalety... przepraszam bo wczesniej zle napisalem. Oczywiscie nie chodzilo mi o debugger, a o symulator ktory czasami mocno sie przydaje wlasnie jak musimy napisac cos co sie miesci w danej licznie cykli itp.

Natomiast sam edytor to nie wszystko, owszem jest wygodny - ale bez niego latwiej sie obejsc niz bez debugera czy symulatora. Ot po prostu trzeba sie tylko wiecej naklepac.

Teraz co do Eclipse i ARM-ow to niestety tutaj wiekszosc ciekawego softu jest komerycjna i ludzie wybieraja Eclipse + openocd itd. Mozna sam tego uzywam... ale czy to jest wygodne kwestia dyskusyjna...

Po prostu przywalic mozna sie praktycznie do kazdego IDE lub calego srodowiska.
Nawet do produktow MS jakim jest VS, czy Borlanda mozna sie przyczepic. Co prawda czesciej uzywam VS, ale Borlanda (Object Pascal i C) uzywalem troche lat temu i tez nie byl to ideal... Zreszta tutaj zalezy tez czy chcemy rzezbic w czystym WinAPI - czy wyklikac sobie soft w .NET lub Delphi pracuje sie troche inaczej. W tym pierwszym edytor juz nie jest najwieksza potrzeba...

tmf wrote:

BTW, o ile się nie mylę Atmel daje jakieś narzędzie do konwersji XMLi do plików nagłówkowych.

Zmienili format z wprowadzeniem AS6 na rzecz bardziej rozbudowanego z uwzględnieniem AVR32 i ARM. Pomimo najszczerszych chęci nie dogrzebałem się do nowszej wersji konwertera.

tplewa wrote:

Stosowanie ARM-ow jest niestety czasem mniej wygodne i lepiej dac AVR-a itp. Co zrobisz jak potrzebujesz TTL 5V ?, a porty 5V tolerant cie nie urzadzaja. Pakujesz konwertery ktore kosztuja i w dodatku podnosza cene PCB.

Dalej zamiast dawac trudniej dostepne ARM-y z serii motor control, mozna znalezc jakiegod dsPIC-a itd. (jesli potrzebujemy jakis sprzetowych wejsc fault itd.)

Mozna wymienic jeszcze kilka spraw gdzie pakowanie na sile tanszego ARM-a nie jest dobrym rozwiazaniem...

To ze cos jest tansze to nie znaczy ze zawsze lepsze Wiem wiem i zawsze to mowie ze jest moda na ARM-y i pcha sie je wszedzie bez zastanowienia bo akurat ARM jest tanszy. Finalnie uklad czasem wychodzi drozej bo sam procesor to nie caly uklad.

Po prostu poraz kolejny twierdze na tym forum ze procesor dobiera sie do projektu z glowa, a nie tylko patrzac na cene i MIPS-y.

Dobiera się mikrokontroler do projektu, sam rdzeń do sprawa drugorzędna i rybka co tam siedzi. Na rynku jest taka różnorodność, że wszystko można znaleźć:
Motor-Control 5V Supply ARM Cortex-M3

Wspólny rdzeń ma ujednolić narzędzia, żeby nie skakać ciągle po AVR Toolchain, PIC Toolchain i tak dalej, a nie determinuje projekt urządzenia.

Dobra to podaj mi ARM-a z FPU serii MC ktory mozna latwo kupic (nie wiadro)... akurat szukam do wektorowego sterowania (akurat BLDC). Mam Frescalle w domu i co z tego, jak chce kupic wiecej niz ten co mam i robi sie problem (chodzi o rozsadna cene)... To ze cos jest to ok, tylko trzeba brac pod uwage tez dostepnosc dla hobbysty... Jest wiele ciakwych ukladow Broadcom-a, Realteka itd. - tylko wlasnie ta dostepnosc

odnosnie tych 5V i tego TMPM370 ot na dzien dobry z tego co znalazlem:

https://old.iar.com/website1/1.0.1.0/3084/1/?item=prod_prod-s1%2F548

czyli na dzien dobry 230euro do wydania i to nie koniec kosztow... to tak przykladowo i mamy 5V...

Do tej pory w wiekszosci zastosowan gdzie musze miec TTL 5V zdaja egzamin PIC-e i AVR-y wiec dlaczego na sile ARM...

mickpr wrote:

Nie czarujmy się - stosowanie większych AVR-ów : XMEGA czy A32 oraz PIC24/32/33 zamiast ARM-ów to trochę "retro-elektronika".

Hahahaha podoba mi się to, chociaż może do tego worka nie wrzucałbym PIC'ków które wymieniłeś bo wśród nich jest trochę fajnych alternatywnych rozwiązań z tego co widziałem.

Dodano po 3 [minuty]:

tplewa --> dlatego pisałem że nie ma co mieć klapek na oczach i można sobie zainstalować i jedno i drugie a nawet trzecie - co za problem mieć kilka różnych narzędzi i użyć co się podoba w danym momencie. Jak potrzebuję skorzystać z symulka to sobie odpalę ew kocie AS6

mirekk36 wrote:

tplewa --> dlatego pisałem że nie ma co mieć klapek na oczach i można sobie zainstalować i jedno i drugie a nawet trzecie - co za problem mieć kilka różnych narzędzi i użyć co się podoba w danym momencie. Jak potrzebuję skorzystać z symulka to sobie odpalę ew kocie AS6

No wlasnie o to chodzi by nie miec klapek na oczach na AVR,ARM,PIC i to samo dotyczy kompilatorow i IDE. Najgorsze co mozna zrobic to sie ograniczyc do jednego i pchac na sile wszedzie gdzie sie da, mowiac ze reszta jest bee, droga, stara itd.

Zwlaszcza ze to juz poruszalem rdzen ARM to nie wszystko i nie zawsze jest tak samo. Przyklad STM i jego biblioteka - jak ktos jej uzywa to faktycznie przeniesie sie super latwo na innego ARM-a Niestety prawda jest taka ze 99% osob ktore wybieraja STM to robi... wystarczy zerknac w necie ile mozna znalezc jak pisac uzywajac bezposrednich odwolan do hardware czytajac sobie RM.

Dyskusja natomiast odnosnie wlasnego startupu itd. to niekonczace sie tasiemce i z tego co widac kupa problemow dla wielu osob... Ile osob tak promujacych ARM-y sobie to rozwiazala samemu, z tego co wiem na tym forum chyba tylko Freddie

Do tego na prawde chcial bym tutaj zobaczyc projekt na ARM-e ktory potrzebuje jego mocy obliczeniowej - bo wiekszosc to niemal miganie dioda (bez obrazy). To co widzialem za zwyczaj mozna zrobic na starym AVR-ku, czy jakims PIC-u. Jesli chodzi o te ostatnie zazwyczaj lepiej... Niestety z takich ciekawych projektow co widzialem na ARM-ach (gdzie uzasadnione jest jego uzycie) to mozna policzyc na palcach jednej reki... Chyba najciekawszy to Linux itd. (centrum multimedialne) wykonany przez kolege PiotrGo (o ile dobrze pamietam).

mickpr wrote:

drzasiek wrote:

Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak.

Jedyną przyczyną nie korzystania (czasem) z debuggera jest rozumowanie logiczne.

Przypomina mi się cytat z jakiejś gazety:

Quote:

Do zabicia muchy wystarczy złożona gazeta, nie potrzeba sterowanego zdalnie laserowego działka

Zauważmy też, że Atmel wyposażył w JTAG jedynie niektóre AVR-y, a DebugWire - cóż.... pozostawię bez komentarza.

Wszyscy moim krytykanci oczywiście skrzętnie pomijają cenę debuggera - przykładowo STK600: http://www.seguro.pl/sklep/?zobacz=4885 ---- TYLKO 843 zł.
Wybaczcie panowie - ale szkoda mi kasy na urządzenie - które wykorzystam raz, dziesięć czy nawet dwadzieścia razy (bo na pewno nie więcej) - gdyż ceny ARM-ów spadły na tyle,
że wolę włożyć w projekt np. taki LPC1114 - który kosztuje taniej niż niejeden AVR i jest wydajniejszy.
Nie czarujmy się - stosowanie większych AVR-ów : XMEGA czy A32 oraz PIC24/32/33 zamiast ARM-ów to trochę "retro-elektronika".

Jeśli mam 32kB kodu, a 80% tego zajmuje sprawdzony kod, który reużywam (procedury do UART, SPI, I2C, FAT, SD czy Ethernetu) - to po co mi narzędzie do sprawdzenia 20% z 32kB = 6KB kodu?
Znaczniej dłuzej zajmie mi podłączenie całości do płytki i uruchomienie dziadostwa, niż przejżenie kodu. Skórka nie warta wyprawki.

Gdybym zawodowo pisał pod AVR-y (te większe, przy których jest wogóle sens podpinac JTAG) - z pewnością bym sobie go kupił, jednak wolę tak zaoszczędzoną kasę włożyć w sprzęt do ARM-ów.

Zamiast kłótni na elektrodzie proponuję trochę ochłonąć - a zaoszczędzoną energię włożyć w projekty - te z JTAG-iem i te bez niego.

Zadam ci jeszcze raz proste pytanie - co takiego jest w kodzie ARM co wg ciebie wymaga debuggera, czego nie ma w kodzie C?
Co do reszty to niestety prawie wszystko co napisałeś nie jest prawdą. Zacznijmy od debuggera - debugger nie służy tylko do debuggowania kodu w C. Jeśli mam kod w C niezależny od sprzętu to sobie go mogę uruchomić na PC i tam wygodnie potestować. Debugger przydaje się na styku sprzęt-oprogramowanie. A tu nie ma znaczenia czy kod ma 10tys. linii kodu czy 5. Jak coś nie działa to czasami równie trudno jest znaleźć przyczynę. Do "małych" AVR Atmel nie dodaje JTAGa pewnie dlatego, że mają mało pinów i po prostu fizycznie nie ma gdzie tego sensownie upchnąć. Z drugiej strony prawie nikt nie robi developerki na np. ATTiny, skoro mogę wziąć płytę rozwojową z większym prockiem, na niej wszystko przetestować (a jakże, z wykorzystaniem JTAG) i potem sobie po prostu sprawdzony kod przekompilować żeby działało na docelowym maleństwie.
Kolejna rzecz - cena. JTAG do AVR można kupić w cenie ISP (klony), oryginalny AVR Dragon kosztuje 220zł, raczej nie majątek, szczególnie że zadziała z AVR8, AVR32 i ARM. A jeśli ktoś potrzebuje profesjonalnego sprzętu to ma też i odpowiednią cenę. Więc nie wprowadzaj w błąd podając ceny z sufitu.
Kolejny błąd - ceny ARM i AVR. Wspomniany LPC1114 to prosty ARM z ubogimi peryferiami. O wiele bogatsza w peryferia XMEGA16 jest tańsza i w 90% zastosowań będzie lepsza niż LPC1114. Ten ARM ma zaledwie 32 kB FLASH, biorąc pod uwagę, że kod na ARM jest o około 40-60% większy niż na AVR ma sens porównanie 32k ARMa do 16 k XMEGA.
Bynajmniej nie twierdzę, że ARMy są gorsze. Wszystko zależy co się chce robić. Zresztą używając argumentu kolegi - dla mnie nie ma sensu pisać na M8, M16, skoro za tą samą cenę mam XMEGA, które jest o wiele wygodniejsze. A jak mi nie wystarczy to dobieram coś większego, ale bynajmniej nie ze względu na prędkość CPU (bo projektów wymagających większych prędkości np. na elektrodzie jeszcze nie widziałem), ale ze względu na specyficzne peryferia, które przejmują dane zadanie.

tplewa możesz uświadomić mi Swój tok rozumowanie i postrzegania rzeczywistości ? Bo czegoś tu nie potrafię pojąć w tej mechanice myśli i rozważań.

Generalizowanie, że ARM to tylko logika 3.3V, przytłaczająca ilość MIPS, że są trudne w obsłudze jak prom kosmiczny, jest dla mnie... nie zrozumiałe. To jest tylko rdzeń, zestaw instrukcji z możliwością obsługi konkretnej magistrali, a co na niej się znajdzie, to zależy już od producenta mikrokontrolera, jak jest zasilane i w jakiej technologi jest wykonane, żeby osiągnąć wysoką częstotliwość taktowania. Tak samo jest z FPU, to jest kolejny układ peryferyjny, tak jest z Cortex-M4, która ma rozszerzony zestaw instrukcji do jego obsługi (M4F). Czyli równie dobrze można do STM32F4 włożyć rdzeń AVR, dać FPU na magistrali i obsłużyć do kilku w cyklach w dostępnych instrukcjach, zamiast jednej dedykowanej.

Więc szukasz mikrokontrolera z FPU i układami peryferyjnymi, które wspomogą Ciebie do obsługi BLDC, jeśli takie masz założenia w projekcie. Pisanie, że raz lepiej dać AVR albo PIC zamiast czegoś innego, bo coś tam, determinuje producent i dostępne układy peryferyjne, a nie rdzeń. Przykładowo EFM (ARM Cortex-M0) z serii Zero Gecko ma max 32MHz, minimum 4kB i 2kB, i jest dostosowany do urządzeń o niskim poborze mocy, ale równie dobrze można dać PIC z serii eXtreme low power. Podałem przykład Gecko, żeby pokazać, gdzie te ogromne MIPS i zasoby do nie wykorzystania mimo że to ARM, na pierwszym miejscu są układy peryferyjne do działania w danym miejscu pracy, tryby niskiego poboru mocy, to nie determinuje rdzeń.

Złożoność, skomplikowaność, zastosowanie decyduje sam producent mikrokontrolera, a nie rdzeń.

Stosowanie ARM zamiast Swojego rdzenia ma ułatwić przede wszystkim twórcom mikrokontrolera i przyspieszyć cały proces wdrożenia, kompilator, magistrala, debugowanie i testowanie. Spójrzcie jaki ostatni jest wysyp mikrokontrolerów, kiedyś nie było takich możliwości jak teraz. Mamy rynku kilka nowych firm produkujący mikrokontrolery.

Przykład z STM jest mało trafny, ogólnie jak każdy, co ma rozwiązanie przykładowo I2C z firmy NXP czy Ti do ST ? Rozmieszczeniem pamięci, rejestrów. Tego się nie da ustandaryzować. Wspólny rdzeń miał ułatwić developing producentom jak i ich klientom (przede wszystkim toolchain). Problem z przenośnością mają osoby, które nie są za znajomymi przykładowo z HAL i pisaniem tak softu, żeby łatwo dało się przenieść na wszystko i tu rdzeń nie z tym nic wspólnego.

Dlatego błędem jest takie generalizowanie.

@tymon_x

Wiesz tolchain to naprawde nie wiele, mam ich obecnie kilak i jakos nie mam problemu. Kod obecnie najczesciej pisze w C i jest najczesciej w duzym stopniu przenoscy. Nie pisze tutaj o kodzie do obslugi SPI, I2C itd. bo ten za zwyczaj pisze pod katem tego co mam na tej magistrali (jakie uklady) i zajmuje to moment...

Ja nie generalizuje tylko wlasnie twierdze ze sam rdzen to nie wszystko i z mojego punktu widzenia jest to jeden z mniej istotnych spraw jesli nie bawimy sie w pisanie na poziomie assemblera. Zreszta o tym juz pisalem w jakims poscie gdzie wywiazala sie podobna dyskusja typu co lepsze.

Tak samo nie napisalem ze ARM-y sa straszne i trudne jak prom kosmiczny, co nie zmienia niezaprzeczalnego faktu ze sa trudniejsze w programowaniu od AVR-ow czy PIC-ow.

Kolejna sprawa to dostepnosc - a tutaj poruszamy tematy hobbystyczne, a nie w zastosowaniach produkcyjnch. Gdzie niektore firmy od lat trzymaja sie przykladowo calkiem innych rdzeniow i maja tez gdzies ARM-y/AVR-y/PIC-e... ot bo kiedys zainwestowali w srodowiska/szkolenia/sprzet itd. wiec nie oplaca im sie tego nagle zmieniac... Mimo ze moga stosowac tansze i lepsze procki...

O tych 3.3V pisalem z punktu widzenia tego co moge kupic latwo w sklepie za rogiem i tyle, a nie tego co jest. Bo jak bym mial tak pisac to ja bym wybral do niektorych zastosowan np. MIPS-y Broadcoma tylko co z tego ze sa... jak ich nie uzyjesz... a nawet jak zdeklarujesz sie na setki tysiecy sztuk i podpiszesz NDA aby dostac czasami i tak nie pelna dokumentacje. To samo tyczy sie innych firm i ukladow z innymi rdzeniami (tez ARM).

O to co mi chodzi to wlasnie to ze ktos na sile chce udowodnic ze jedyny sluszny kierunek to ARM bo sa tansze i lepsze... Natomiast ja sie staram pokazac ze w hobby niestety czasem lepiej wybrac cos innego, nawet takiego starocia jak 8bit AVR.

No i nadal czekam na polecenie ukladu ktory mozna latwo kupic, to akurat serio bo mi juz rece opadaja. Wlasnie chodzi o Cortex M4 z serii MC ewentualnie moze ktos ma dostep i odstapi z 5 szt.

Generalnie napisze jeszcze raz wyraznie - ja nie jestem za ograniczaniem sie do jednej rodziny procesorow i piszac ARM nie mam na mysli samego rdzenia bo to chyba raczej jasne, a dostepne dla wiekszosci uklady... Zreszta ci co mowia ze lepiej ARM niz AVR tez nie biora pod uwage samego rdzenia tylko konkretna serie ukladow ktora stosuja w swoich projektach (wiec to raczej oni generalizuja co jest lepsze). Ja natomiast walcze z bzdura jaka promuja ze ARM to lekarstwo na kazdy uklad, a ci co uzywaja PIC-ow czy AVR-ow to jakies zacofane towarzystwko.

Powiedz mi tez dlaczego przyklad z STM jest niezbyt trafiony ?

Na koniec dodam ze chyba niezbyt dobrze przeczytales, bo twoje argumenty powinny isc w kierunku innych osob...

tplewa wrote:

Generalnie napisze jeszcze raz wyraznie - ja nie jestem za ograniczaniem sie do jednej rodziny procesorow i piszac ARM nie mam na mysli samego rdzenia bo to chyba raczej jasne, a dostepne dla wiekszosci uklady... Zreszta ci co mowia ze lepiej ARM niz AVR tez nie biora pod uwage samego rdzenia tylko konkretna serie ukladow ktora stosuja w swoich projektach (wiec to raczej oni generalizuja co jest lepsze).

Albo mam jakieś dziwne wrażenie, ale z każdym postem masz inny pogląd na sprawę ? Piszesz, że nie spłycasz odnośnie tematów dotyczących fragmentów z użyciem słowa ARM, ale ja to odebrałem inaczej, które często się tutaj przejawiają, jak drogie narzędzia, strzelanie do muchy z armaty, niesłychana skomplikowaność i tak dalej... ale rdzeń jest tutaj najmniejszym winnym. W sumie to on nie ma nic z tym wspólnego.

tplewa wrote:

Powiedz mi tez dlaczego przyklad z STM jest niezbyt trafiony ?

Problem jest z osobą, która wytwarza firmware... A czy korzysta z bibliotek czy ma własne funkcje z ustawieniami, to jego sprawa.

tmf wrote:

Kolejny błąd - ceny ARM i AVR. Wspomniany LPC1114 to prosty ARM z ubogimi peryferiami. O wiele bogatsza w peryferia XMEGA16 jest tańsza i w 90% zastosowań będzie lepsza niż LPC1114. Ten ARM ma zaledwie 32 kB FLASH, biorąc pod uwagę, że kod na ARM jest o około 40-60% większy niż na AVR ma sens porównanie 32k ARMa do 16 k XMEGA.

Z ostatnim zdaniem się nie zgodzę, zestaw instrukcji Thumb w ARM Cortex-M0 oparty jest na słowach 16-bit, podobnie jak AVR.

tplewa wrote:

Na koniec dodam ze chyba niezbyt dobrze przeczytales, bo twoje argumenty powinny isc w kierunku innych osob...

Tak i nie. Zobacz co zacytowałem, 5V, MIPS, trudno dostępne... dalej ogromna moc, hobbysta ma problemy z dostaniem czegoś, musi kupić tego całe wiadro.

Tak to jest, każdy widzi to inaczej. Wiem o co Tobie chodziło, ale nie każdy musi to tak odbierać.

LordBlick wrote:

tmf wrote:

Ten ARM ma zaledwie 32 kB FLASH, biorąc pod uwagę, że kod na ARM jest o około 40-60% większy niż na AVR ma sens porównanie 32k ARMa do 16 k XMEGA.

Z tym się nie zgodzę, zestaw instrukcji Thumb w ARM Cortex-M0 oparty jest na słowach 16-bit, podobnie jak AVR.

Ale konfiguracja peryferiow i odwolanie sie do nich najczesciej niestety zajmuje wiecej instrukcji niz w AVR-ach. Choc nie wiem jak to procentowo wyjdzie jesli chodzi o calosc kodu - trzeba by porownac podobne aplikacje na obu procesorach.

Dodano po 9 [minuty]:

tymon_x wrote:

tplewa wrote:

Na koniec dodam ze chyba niezbyt dobrze przeczytales, bo twoje argumenty powinny isc w kierunku innych osob...

Tak i nie. Zobacz co zacytowałem, 5V, MIPS, trudno dostępne... dalej ogromna moc, hobbysta ma problemy z dostaniem czegoś, musi kupić tego całe wiadro.

Tak to jest, każdy widzi to inaczej. Wiem o co Tobie chodziło, ale nie każdy musi to tak odbierać.

Owszem ale tutaj raczej dyskutujemy o prostych projektach hobbystycznych, o takich komercyjnych raczej sie tutaj nie dyskutuje (przynajmniej ja o swoich nie pisze nawet jak mam duze problemy), po prostu po co zdracac na cos pomysly

Dlatego sadze ze dla hobbysty lepiej jest nie ograniczac sie do jedngo rdzenia, rodziny ukladow itd. Producent podchodzi za zwyczaj z innej strony bo dla niego to wieksze koszty przesiadka na cos innego. Pomijajac tutaj same koszty jtag-a czy kompilatora (ktore sa smiesznie niskie jesli o tym mowimy).

Ot podalem przyklad tych 5V itp. bo z tym sie spotkalem i lepiej bylo mi dac AVR-a niz ARM-a, mimo ze mial mniej mipsow (ale tego nie potrzebowalem zbyt wiele), natomiast cena wieksza od ARM-a (ot ATmega32U4 ktora tania nie jest patrzac na ARM-y). Jednak jej uzycie finalnie bylo tanszym rozwiazaniem (biorac pod uwage koszty calego ukladu).

Odnosnie MIPS-ow wspomnialem bo tez potrzebowalem uzyc, ot uzyelm plyty pewnego urzadzenia z takim prockiem i okolo roku siedzenia przy IDA by choc czesciowo poznac jak on dziala (chodzi o peryferia)... Dalo sie owszem Ale nie powiem ze to bylo optymalne... Choc jak widac mozna

Natomiast ogromna moc itd. To nie moje argumenty... Ot ktos tu powiedzial ze ARM jest szybszy/lepszy/tanszy itd. Wiec napisalem co o tym mysle i pokazalem ze nie zawsze dla hobbysty dobre jest trzymanie sie "jedynie slusznych ARM-ow" czy tam "jedynie slusznych prockow X". Tak samo bylo z porownaniem narzedzi AVR kontra ARM (wyszlo na to ze JTAG do AVR-ow to kosmos cenowy, a to ARM-ow jakis smieszny koszt).

tplewa wrote:

LordBlick wrote:

tmf wrote:

Ten ARM ma zaledwie 32 kB FLASH, biorąc pod uwagę, że kod na ARM jest o około 40-60% większy niż na AVR ma sens porównanie 32k ARMa do 16 k XMEGA.

Z tym się nie zgodzę, zestaw instrukcji Thumb w ARM Cortex-M0 oparty jest na słowach 16-bit, podobnie jak AVR.

Ale konfiguracja peryferiow i odwolanie sie do nich najczesciej niestety zajmuje wiecej instrukcji niz w AVR-ach. Choc nie wiem jak to procentowo wyjdzie jesli chodzi o calosc kodu - trzeba by porownac podobne aplikacje na obu procesorach.

No i widzisz, znowu to (chyba nie świadomie) robisz.

To będzie zależało już od producenta. Przykładowo odpalenie UART i SPI na STM32:
Link

Nie wiele więcej tyle samo co przykładowo na Atmega.

A teraz w takim LPC, zależnie od mkrokontrolera, bo pod LPC11xx, LPC12xx, LPC13xx czy LPC17xx są różnice jak cholera. Taki UART według NXP trzeba włączyć dostęp Latch Divisor, żeby zmienić Baud Rate, bawić się w IOCON do każdego pinu. A to też ARM.

Byś musiał włożyć przykładowo rdzeń Cortex powiedzmy do Atmega, że był to uczciwy test.

To, że projekty nie są pokazywane na elektrodzie, nie znaczy, że nie powstają.

@tymon_x

Z tym rozmiarem kodu mowa jest o konretnym procku ktory ktos wymienil Do tego napisalem ze nie wiem jak wyjdzie calosciowo, ale zdaje mi sie ze na obsludze peryferiow bedzie wiecej tych instrukcji w ASM.

drzasiek wrote:

To, że projekty nie są pokazywane na elektrodzie, nie znaczy, że nie powstają.

moze i tak... ale ja opieram sie o to co jest tutaj na forum, a nie o to ze ktos cos tam robi. Tzn. jakie ludzie zadaja pytania odnosnie ARM-ow itd. Sorry ale wiele osob ktore je promuja i neguja AVR-y nie wykorzysta nawet potencjalu prockow ktore uzywaja i takie sa fakty. To ze kilka osob robi cos konkretnego na ARM-ach to jest niestety promil...

Ja to odnioslem do wypowiedzi kolegi @mickpr ktorego chyba nagle oswiecilo, bo patrzac w jego posty gdzies tam pisal ze PIC-e to fajne procki... a tu nagle sa beee i tylko ARM-y Tak niestety jest w przypadkach innych osob bo ARM-y sa trendy i chyba tak wypada...

No nie czarujmy sie, jak zaczne popierac bezwzglednie taka wypowiedz:

mickpr wrote:

Nie czarujmy się - stosowanie większych AVR-ów : XMEGA czy A32 oraz PIC24/32/33 zamiast ARM-ów to trochę "retro-elektronika".

to bede trendy i ok ???

Ja specjalista od ARM-ow nie jestem jakims wielkim (mimo ze cos wiecej tam na nich robilem) ale staram sie realnie myslec i nie gadac ze ARM to jedyny sluszny procesor... Usilnie staram sie to udowodnic... ze niestety tak nie jest...

Natomiast na temat doswiadczenia z danymi prockami nie mam sie nawet zamiaru wypowiadac bo dla mnie taka argumentacja jest smieszna i sa to puste slowa...

mickpr wrote:

Z całą pewnością kolega o wiele lepiej się zna na AVR niz ja. Pozwolę sobie (a jednak) nie zgodzić z tym, co szanowny kolega napisał.
Środowisko AtmelStudio 6 z powodzeniem mógłbym nazwać "Mydło i Powidło 6".

no sorry Panowie co to ma do tego... uzywam AVR-ow gdzies od 1999/2000r (dokladnie nie pamietam - musial bym poszukac rachunku za zestaw Kanda System STK200)... i co to zmienia... jakie kto ma doswiadczenie i ile sie zajmuje danymi prockami... Ma ktos swoje zdanie na temat softu i tyle Jedni lubia rybki inni zmieniac znaczki... Wiec po co te swoje zdanie mieszac z znajomoscia danych prockow...

Zreszta wracajac do meritum czyli Atmel Studio 6 - to jak to mowia darowanemu koniowi nie patrzy sie w zeby... ktory producent ARM-ow daje za free chocby cos podobnego (nawet tak badziewiastego jak to niektorzy mowia) ? Gdyby nie jakies tam srodowisko opensource to o ARM-ach mozna by niemal zapomniec (bez piracenia) w zastosowaniach hobbysty...

Zreszta po co jakies IDE ja czasem uzywam konsoli i dla mnie o dziwo czasem jest to wygodne Tylko czy to musze tez traktowac za "objawione najlepsze jedynie sluszne rozwiazanie" ???

Ja się włączę do dyskusji przychylając się do przedmówcy. Po pierwsze popieram argument domowości środowiska - do ARM'ów producenci nie udostępniają swoich darmowych kompilatorów, a jeśli już jakieś się znajdą (poza open-source) to mają śmieszne ograniczenia. A tu dostajemy (jakby na to nie patrząc) całkiem za darmo nienajgorsze i całkiem przydatne narzędzie.
A co do konfrontacji Eclipse vs. AS6 - o gustach się nie dyskutuje. Jednemu bardziej odpowiada pierwsze, drugiemu drugie. Ja np. pisząc strony www używam do wszystkich projektów (nawet bardzo złożonych) tylko notepad++, a moi koledzy czasem do byle mini-stronki korzystają z kombajnów jak Adobe Dreamvawer... Czy to źle? Nie kwestia gustu.