Czyżby visual studio dla AVR
Co o tym sądzicie

Co o tym sądzicie
Do you prefer the English version of the page elektroda?
No, thank you Send me over theretmf 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.
LordBlick wrote:Oprócz wielkogabarytowego AS6 i mulącego Javą Eclipse istnieją inne rozwiązania, np. Code::Blocks. .
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".
drzasiek wrote:W starszych rdzeniach sprawdza się tylko już dawno opracowane debugowanie po RS232. A i w nowszych nie jest wykluczone.Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak.
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ą.
LordBlick wrote:drzasiek wrote:W starszych rdzeniach sprawdza się tylko już dawno opracowane debugowanie po RS232. A i w nowszych nie jest wykluczone.Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak.
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.
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...
tplewa wrote:
Choc faktem jest ze nowe AS to nie jest szczyt wygody - musza ten soft jeszcze dopracowac. Przynajmniej do Visual Studio mu sporo brakujeJednak i tak oferuje o wiele wiecej niz jakikolwiek sklejanie Eclipse z roznymi dodatkowymi programami.
tplewa wrote:Inna sprawa AS to juz nie tylko male AVR-y...
drzasiek wrote:Jedyną przyczyną nie korzystania z debugera jest po prostu jego brak.
Quote:Do zabicia muchy wystarczy złożona gazeta, nie potrzeba sterowanego zdalnie laserowego działka
tmf wrote: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.BTW, o ile się nie mylę Atmel daje jakieś narzędzie do konwersji XMLi do plików nagłówkowych.
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 lepszeWiem 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.
mickpr wrote:
Nie czarujmy się - stosowanie większych AVR-ów : XMEGA czy A32 oraz PIC24/32/33 zamiast ARM-ów to trochę "retro-elektronika".
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
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.
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).
tplewa wrote:Powiedz mi tez dlaczego przyklad z STM jest niezbyt trafiony ?
tmf wrote:Z ostatnim zdaniem się nie zgodzę, zestaw instrukcji Thumb w ARM Cortex-M0 oparty jest na słowach 16-bit, podobnie jak AVR.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.
tplewa wrote:Na koniec dodam ze chyba niezbyt dobrze przeczytales, bo twoje argumenty powinny isc w kierunku innych osob...
LordBlick wrote:tmf wrote:Z tym się nie zgodzę, zestaw instrukcji Thumb w ARM Cortex-M0 oparty jest na słowach 16-bit, podobnie jak AVR.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.
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ć.
tplewa wrote:LordBlick wrote:tmf wrote:Z tym się nie zgodzę, zestaw instrukcji Thumb w ARM Cortex-M0 oparty jest na słowach 16-bit, podobnie jak AVR.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.
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.
drzasiek wrote:To, że projekty nie są pokazywane na elektrodzie, nie znaczy, że nie powstają.
mickpr wrote:
Nie czarujmy się - stosowanie większych AVR-ów : XMEGA czy A32 oraz PIC24/32/33 zamiast ARM-ów to trochę "retro-elektronika".
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".