Zastanawiam się nad programowaniem AVR32. Używam Eclipsa z najnowszym Toolchainem. Ów zestaw potrafi programować także AVR32. Znalazłem nawet jednego osobnika w TME, to AT32UC3A0512.
Moje pytanie brzmi: jakiego programatora (sprzętowego) użyć? Jak się programuje taki AVR32, SPI, PDI, JTAG czy jeszcze jakoś inaczej? Czy warto się zajmować AVR32?
Witam,
ja osobiście miałem zająć się AVR32 ale na szczęście wpadły mi w ręce ATXMEGA - polecam. Z tego co wiem to programowane są jedynie interfejsem JTAG - proponuję również zakup programatora ATMEL ICE - uniwersalny z interfejsem PDI,SPI,JTAG
Rozumiem, że wg ciebie wszystko co nie jest ARM Cortex to ślepa uliczka? AVR32 to bardzo fajne procesorki, mają niezły rdzeń, część ma wydajne FPU, niezłe peryferia. Do tego w pełni darmowe IDE - Atmel Studio i toolchain, wszystko odpala z pudełka, jeśli ktoś wcześniej używał AVR to przesiadka jest łatwa - te same programatory (np. Atmel ICE), to samo IDE, do tego jeśli ktoś robił w ASF to ma jeszcze łatwiej z przesiadką. Pewny mankament to dostępność tych układów - ale jeśli ktoś zamawia przez Internet to zasadniczo nie ma problemu. A jeśli ktoś lubi podążać za masami, to ARMy Atmela też są ok - zasadniczo te same zalety co AVR32 - programatory, środowisko, ASF.
AVR32 chcę traktować jako pomost między Xmega, a ARM (może Atmel z ARM, nie wiem, aż tak daleko nie wybiegam myślami na przód).
Mam Eclipse z najnowszym Toolchainem, pytanie tylko, czym to programować? Czy nada się AVR Prog MKII? Czy trzeba kupować tego ICe'a?
AVR32 chcę traktować jako pomost między Xmega, a ARM (może Atmel z ARM, nie wiem, aż tak daleko nie wybiegam myślami na przód).
Jeśli tak to sobie faktycznie daruj i przesiądź się bezpośrednio na platformę docelową.
Choć popieram tmf, że avr32 to fajne procesory.
Ale przesiadać się na nie po to, by potem cofać się do M0-M3 to absurd.
Ja chciałbym te procki użyć do generowania dźwięku, a AVR32 mają 16-bit audio bistream, podczas gdy w ARMach napotkałem ledwie na 10-bitowy DAC, a taka rozdzielczość mi nie wystarcza, czasami spotykam 12-bit (jak w Xmega - testowane), co od biedy by wystarczyło.
To ja wtrącę swoje 5 groszy.
W kwestii AVR->Xmega->AVR32->Cortex Mx, to AVR32 nie jest demonem prędkości i do dźwięku to się średnio nadaje. Wszystko co zrobisz na AVR32, zrobisz też na Cortex M4. Nie wszystko co zrobisz na Cortex M4, możesz zrobić na AVR32. W sumie to nawet niewiele możesz zrobić. Jeżeli AVR32 będzie za słaby do algorytmu, to nie masz wyboru - musisz się przesiąść na Cortex'a. Pytanie czy wybierzesz wtedy M4 czy A5. Atmel produkuje układy oznaczone jako uP, np. SAMA5D4, ale nadal mają one wiele funkcji zarezerwowanych dla uC, przez co mogą być dla Ciebie dużo bardziej interesujące niż AVR32. Jak już dopasujesz AVR32 do wymagań, to teraz trzeba go kupić. W dużych seriach to nie problem, ale małe ilości są bardzo drogie.
Co do generowania dźwięku czy audio... Nigdy nie dostaniesz dobrego dźwięku z uC. Do tego celu są układy, które gwarantują odpowiednią jakość. DAC 10 czy 12 bitów to było dobre 20 lat temu. Dzisiaj 24 bitowe ADC/DAC są bardziej dostępne niż AVR32, nie są drogie i pracują w dowolnych standardach. Polecam ofertę Analog Devices i Cirrus Logic. Na Realteka nie licz, bo oni współpracują tylko z dużymi odbiorcami.
Przy generowaniu dźwięku wysokiej jakości raczej nie patrz na wbudowany DAC, lecz czy jest interfejs I2S. Jeśli tak, to jesteś w domu. Co do XMEGA - na siłę możesz zwiększyć rozdzielczość PWM przez prosty myk z dwoma wyjściami PWM + mieszacz na rezystorach. W ten sposób z łatwością zrobisz 14 bitów, przy hiperprecyzyjnych rezystorach może 15-16. Można też wykorzystać zewnętrzne DACe lub koprocesory muzyczne np. VS1003b lub VS1053 - to może byc prostsze niż przesiadka na inną platformę. Oczywiście jeśli masz więcej wymagających projektów to zdecydowanie lepiej zainwestować w AVR32/ARM.
Dodano po 11 [minuty]:
Marek_Skalski napisał:
To ja wtrącę swoje 5 groszy.
W kwestii AVR->Xmega->AVR32->Cortex Mx, to AVR32 nie jest demonem prędkości i do dźwięku to się średnio nadaje. Wszystko co zrobisz na AVR32, zrobisz też na Cortex M4. Nie wszystko co zrobisz na Cortex M4, możesz zrobić na AVR32. W sumie to nawet niewiele możesz zrobić.
Z ciekawości zapytam, możesz rozinąć? AVR32 taktowane do 84 MHz, 1,51 DMIPS/MHz, osiągają 126 DMIPS. Mają FPU (niektóre), bogate peryferia, I2S itd. Co można zrobić na cortex, czego nie można na AVR32? Niestety muszę się zgodzić z dostępnością i kosmiczną ceną w detalu...
tmf: u nie chodzi o to, czy coś jest lepsze, czy gorsze,a o to, jaką ma przyszłość. Ile nowych modeli wprowadził Atmel w ciągu ostatnich 2 lat w rodzinie AVR32,a ile w rodzinie SAM? Ile darmowych i komercyjnych kompilatorów/środowisk jest do AVR32, a ile do ARM?
Co do kompilatorów/środowisk to odpowiedź jest prosta - tyle samo. Chyba, że liczysz każdą odmianę gcc jako osobny kompilator - IMHO to tylko wprowadza śmietnik w świecie ARM i nie ułatwia. Dla AVR32 mamy avr32-gcc, mamy komercyjne imagecraft, IAR32 itd. Ze śrdowisk Atmel Studio, które jest takiej jakości, że nic więcej nie trzeba, ale jest i Eclipse jeśli ktoś woli. Co do nowych modeli - ja nie uważam, że 10 modeli rocznie to coś dobrego, to raczej znaczy, że mamy skopany projekt i go ratujemy wypuszczając co raz to nowe badziewie. Setki różnych ARMów, różniącyc się niuansami IMHO tylko wprowadzają chaos. W ciągu ostatnich 2 lat Atmel wprowadził jedną czy dwie nowe rodziny AVR32 - chyba z FPU i z jakimiś specyficznymi rozszerzeniami. Tu nie zachowują się marketingowo, bo zgodnie z wytycznymi marketingu powinni wprowadać coś nowego w odstępach nie większych niż pół roku, tłumacząc klientom, że nowe badziewie rozwiąże wszystkie problemy, których nie mogło rozwiązać stare badziewie. Tak robi Microsoft, Samsung, Apple itd. Niekoniecznie uważam, że takie podejście jest właściwe. Ale klienci się na to łapią. Oczywiście wadą AVR32 jest to, że nie są popularne. Ale stosując tylko ten argument, musiałbyś zacząć promować AVR8, bo przy ich popularności w Polsce, po prostu nie ma sensu zaczynać z ARM, bo to "ślepa uliczka"
Ciekawe, ile w ogóle jeszcze modeli powstanie w rodzinie AVR32. Myślę, że Atmel nie będzie jej rozwijał, bo wewnętrzna konkurencja pomiędzy AVR32 i SAM nie ma sensu żadnego.
To prawda i to jest tak naprawdę główny argument przeciw. Mogą w pewnym momencie zrobić to co zrobili ze świetnym prockiem AP7000 - produkujemy dalej, ale nie rozwijamy. Niemniej patrząc po forum AVRFreaks - mają subfora dla AVR32, ale nie ARM, więc jakoś ciągle chyba mają nadzieję, że się przebiją. IMHO AVR32 mają kilka fajnych bajerów, m.in. rozwiniętą koncepcję event system, bardzo elastyczne peryferia, to co obsysa to popularność i dostępność prostych procków dla hobbystów w rozsądnych cenach. Ale chyba Atmel idzie powoli po rozum do głowy i bierze przykład z innych firm - ostatnio wypuścili Xplained pro z wbudowanym sprzętowym debuggerem/programatorem czym skrócili dystans do STM, ostatnio wyszła tania płytka Xplained z SAM10/11 (Cortex M0+), w cenie Arduino, jak wypuszczą coś wiecej z AVR32 to będzie fajnie. IMHO ogromną przewagą Atmela jest w pełni darmowe IDE + kompilator (w pełni darmowe, a nie darmowe jeśli...) i to, że wszystko działa wprost z pudełka. Dla Ciebie to żaden zysk, ale dla osoby zaczynającej z MCU, nawet jeśli przesiada się z AVR na ARM to super ułatwienie. No i mamy jedno IDE/narzędzia do AVR8/AVR32/ARM.
AVR zawsze wyglądał mi na Atmelową wersję ARM Cortex-M. Jak widać ostatnio sięgnęli po oryginał, więc klona raczej zabiją.
"W pełni darmowych" środowisk dla ARM jest nie mniej niż "darmowych jeśli", więc to akurat nie jest żaden argument
A te "jeśli" też są coraz bardziej atrakcyjne, np. mamy darmowego Keila bez ograniczeń rozmiaru dla procesorów STM32F z rdzeniami Cortex M0 i M0+ oraz darmowe LPCXpresso dla NXP (wszystkie rdzenie) z ograniczeniem do 256 KiB, czyli darmowe dla wszystkich oprócz największych projektów na największych mikrokontrolerach rodziny.
Kwestia semantyki, ale dla mnie "darmowe jeśli" to nie darmowe Darmowe z ograniczeniem do CM0 i CM0+ to zupełnie nie darmowe, bo to nie są jakieś wypasione procesory i jeśli ktoś przechodzi z XMEGA to raczej nie na CM0+ bo tu wzrost mocy jest raczej symboliczny. Darmowe środowiska dla ARM są, tylko wskaż mi takie, które zadziałąja tak - ściągam plik, instaluję, działam. Na razie wygląda to tak - ściągam pliki, czytam jakieś how-to, kombinuję mniej lub bardziej, działam i modlę się, żeby było ok. Ew. ścągam "darmowe" i działam na wybranych kilku MCU.
Ale nie to mnie w ARMach boli, dla mnie największą wadą ARM jest to co jednocześnie jest ich największą zaletą - mnogość producentów. Problem w tym, że rdzeń + najbliższe otoczenie jest takie samo (chociaż różne definicje w nagłówkach i to potrafią zabić), ale peryferia już są zupełnie inne. Np. timer z Atmela to inny timer niż z ST, a ten jest inny niż z NXP. Efekt taki, że przejścia pomiędzy prockami są możliwe tylko w teorii, bo zmiana producenta, a nawet rodziny to prawie nauka od nowa.
Ja nie będę generował tym dźwięku wysokiej jakości. Nie będę robił odtwarzacza MP3 czy czegoś w tym rodzaju. Z innych moich postów powinniście wyciągnąć wnioski, że chcę zrobić urządzenie do grania na nim, jakiś syntezator może z tego wyjdzie, ale na razie tak się tylko przymierzam. Najtrudniejsze będzie zrobienie filtracji oraz rezonansu w sposób cyfrowy, ale zawsze można posiłkować się rozwiązaniem sprzętowym.
Co prawda zaproponowałem ci układy z serii VSxxxx, które są kojarzone z odtwarzaniem mp3, ale to nie jedyne co potrafią. Można je wykorzystać do generowania dźwięku przez PWM, ADPCM itd. Poza tym to kompletne, specjalizowane mikrokontrolery, które można normalnie programować. Są tanie, masz w nich kompletne tory analogowe, ze wzmacniaczami, regulacją wzmocnienia itd. Czyli jeden scalak załatwia ci kilka funkcji.
Podaj mi proszę jakiś konkretny przykład kostki? Zajrzę do noty katalogowej.
Moim marzeniem byłoby coś takiego, żeby kostka miała np. gotowy filtr dolnoprzepustowy, tylko wpisać parametry do rejestrów, tak jak się to robi np. z PWM w "zwykłych" prockach.
Już ci podałem - VS1003b lub VS1053. Ten pierwszy ma mniej pamięci, jest prostszy, idealny w połączeniu z XMEGA - przykłądy znajdziesz w przykładach do moich książek. Ten drugi ma więcej pamięci, nadaje się na jedyny MCU w systemie, aczkolwiek są to układy DSP i programuje się je trochę "dziwacznie".
@tmf Trochę offtopic, ale czuję się wywołany do odpowiedzi w poście #9.
Czy można zrobić na AVR32 kartę dźwiękową w systemie 7.1 podłączaną przez USB, która może również odtwarzać i nagrywać dźwięk na kartę pamięci? Ta karta ma również regulację głośności każdego z kanałów, korekcję opóźnienia czasowego każdego z kanałów i funkcję analizy i korekcji dźwięku.
Inne zadanie. Platforma robota napędzana 3 kołami wielokierunkowymi (omni-wheels) w układzie delta. Koła zamocowane do silników DC 24V z enkoderami kwadraturowymi. Kierunek i prędkość ruchu zadane z kamery oraz latarni radiowej. Dane radiowe szyfrowane, aby przeciwna drużyna nie przejęła kontroli nad robotem. Poprzednie rozwiązanie używało karty rozszerzeń RS485 + 3x (Xmega + specjalizowany stopień sterowania silnikiem). AVR32 też sobie nie poradzi.
AVR32 nie ma też interfejsu do kamery. Można się ratować protezą w postaci kamery na USB, ale to bardzo niepraktyczne rozwiązanie, ponieważ ten uC ma tylko jeden port USB.
Sprzętowy konwerter/sniffer/przedłużacz USB oparty na AVR32 też raczej odpada.
AVR32 jest wykastrowany z instrukcji SIMD. FPU jest tylko w kilku egzemplarzach, które mają max. zegar 66MHz. Poza tym FPU jest koprocesorem, więc wymagane są dodatkowe instrukcje.
@mas24 Jeżeli pracujesz z Matlabem, to możesz się zainteresować tym: http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF258513 Gotowy filtr dolnoprzepustowy i ciekawsze rzeczy znajdziesz w podstawowych bibliotekach ARM oraz na przykład tutaj: http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF261250
AVR32 były wydajniejsze od wielu armów jeśli chodzi o pojedynek zegar w zegar. Szkoda że ta architektura nie będzie miała okazji stać się tak popularna jak przez wszystkich produkowane ARMy.
No właśnie, z tego, co doczytałem, to AVR32 mają właśnie jakieś algorytmy DSP. Za to VS-y to kodeki audio, ale mogą zawierać funkcje filtrowania, pogłosu i inne.
Widzę także, że dla STMów są gotowe biblioteki z procesorami audio.
Inna sprawa, że to, o co mi chodzi, robią nawet na AVRach, przykładem jest tu AVRSynth autorstwa p. Jarka Ziembickiego. Mi by chodziło o coś podobnego, tylko chciałbym, by projekt był bardziej rozbudowany, także sprzętowo. Filtrowanie od biedy mogłoby być analogowe, z powodzeniem odpaliłem 3 szt filtru Mooga, co ma pewne zalety. Oscylator cyfrowy na Xmega też jest na ukończeniu (po to mi była potrzebna rozszerzona tablica PGMSPACE). Obydwa urządzenia w akcji można obejrzeć tutaj.
No właśnie, z tego, co doczytałem, to AVR32 mają właśnie jakieś algorytmy DSP.
Mogą mięć instrukcje DSP np MAC (Multiply and ACcumulate) ułatwiające implementacje np FIR czy FFT ale tu chodzi o podporządkowanie całej architektury przetwarzaniu danych z określoną zwloką.
Np prawdziwe DSP maja specjalne tryby adresowania ułatwiające np FFT czy iFFT.
Najtańsze XMOS to ok 3 - 4$ i masz 4 - 6 rdzeni z których każdy pociągnie 100 - 125MIPS - możesz zagwarantować małe opóźnienia które są krytyczne w interakcji z syntezatorem...
prawdziwe DSP maja specjalne tryby adresowania ułatwiające np FFT czy iFFT
I dużo innych rzeczy, np. dual access ram, autoinkrementacja/dekrementacja rejestrów czy adresów, sprzętowa realizacja pętli (zero overhead loop). Wszystko to sprawia, że można zrobić program ze stałym i niewielkim "opóźnieniem" wprowadzanym przez DSP. MCU nie potrafią tego zapewnić dlatego jak ktoś na siłę próbuje to musi taktować kilka razy większym zegarem.
@tmf Trochę offtopic, ale czuję się wywołany do odpowiedzi w poście #9.
Czy można zrobić na AVR32 kartę dźwiękową w systemie 7.1 podłączaną przez USB, która może również odtwarzać i nagrywać dźwięk na kartę pamięci? Ta karta ma również regulację głośności każdego z kanałów, korekcję opóźnienia czasowego każdego z kanałów i funkcję analizy i korekcji dźwięku.
Inne zadanie. Platforma robota napędzana 3 kołami wielokierunkowymi (omni-wheels) w układzie delta. Koła zamocowane do silników DC 24V z enkoderami kwadraturowymi. Kierunek i prędkość ruchu zadane z kamery oraz latarni radiowej. Dane radiowe szyfrowane, aby przeciwna drużyna nie przejęła kontroli nad robotem. Poprzednie rozwiązanie używało karty rozszerzeń RS485 + 3x (Xmega + specjalizowany stopień sterowania silnikiem). AVR32 też sobie nie poradzi.
AVR32 nie ma też interfejsu do kamery. Można się ratować protezą w postaci kamery na USB, ale to bardzo niepraktyczne rozwiązanie, ponieważ ten uC ma tylko jeden port USB.
Sprzętowy konwerter/sniffer/przedłużacz USB oparty na AVR32 też raczej odpada.
AVR32 jest wykastrowany z instrukcji SIMD. FPU jest tylko w kilku egzemplarzach, które mają max. zegar 66MHz. Poza tym FPU jest koprocesorem, więc wymagane są dodatkowe instrukcje.
Nie wiem jak z kartą, nigdy takich rzeczy nie robiłem. Ale IMHO sterowanie silnikami powinno na AVR32 pójść bez problemu. Samo sterowanie silnikiem + enkoder to nawet dla XMEGA nie jest żadne wyzwanie, więc przypuszczam, że jest tam jakiś bardzo specyficzny problem? Co do USB to oczywiście AVR32 mają tylko jeden. Natomiast mają instrukcje SIMD i wspomagające DSP - arytmetykę stałopozycyjną z saturacjami. FPU ma seria UC3C, nie wiem co rozumiesz przez wymagane dodatkowe instrukcje dla FPU? Oczywiście ma on własny zestaw instrukcji, ale to załatwia kompilator. Interfejs do kamery ma AP7, ale to oczywiście nie jest przedstawiciel prostej serii UC3.
Dodano po 7 [minuty]:
mas24 napisał:
No właśnie, z tego, co doczytałem, to AVR32 mają właśnie jakieś algorytmy DSP. Za to VS-y to kodeki audio, ale mogą zawierać funkcje filtrowania, pogłosu i inne.
Widzę także, że dla STMów są gotowe biblioteki z procesorami audio.
Inna sprawa, że to, o co mi chodzi, robią nawet na AVRach, przykładem jest tu AVRSynth autorstwa p. Jarka Ziembickiego. Mi by chodziło o coś podobnego, tylko chciałbym, by projekt był bardziej rozbudowany, także sprzętowo. Filtrowanie od biedy mogłoby być analogowe, z powodzeniem odpaliłem 3 szt filtru Mooga, co ma pewne zalety. Oscylator cyfrowy na Xmega też jest na ukończeniu (po to mi była potrzebna rozszerzona tablica PGMSPACE). Obydwa urządzenia w akcji można obejrzeć tutaj.
Atmel dla AVR32 serii AU daje własne biblioteki audio, z kodekami i interfejsami np. do iPoda, i innych zabawek. Samo wsparcie dla instrukcji DSP mają wszystkie AVR32, dzięki czemu implementacja algorytmów specyficznych dla DSP jest bardzo efektywna. Aczkolwiek nie wiem jak sobie z tym kompilator radzi, przypuszczam, że bez własnych bibliotek w asemblerze się nie obejdzie. Jeśli zmieniałbym procek to wybrałbym taki dla którego dostępne są gotowce z kodem jaki potrzebujesz. Trzeba przeglądnąć ofertę, być może niektórzy producenci ARMów dają za free coś więcej.
Ale IMHO jeśli chcesz tylko polepszyć to co oferuje XMEGA, to rozwiązanie z VS1003B za kilkanaście złotych + ew. trochę własnego kodu dla tego procesora rozwiąże problem. Napisanie na ten procek filtra jest banalne, podobnie banalne jest generowanie dźwięku - masz tam dobrej jakości DAC, ze wszystkimi potrzebnymi torami analogowymi. Biorąc pod uwagę prostotę rozwiązania XMEGA + VS1003B (XMEGA znasz, VS jest prosty) IMHO to jest optymalna kombinacja. Gdybyś robił naprawdę jakąś większą magię z dźwiękiem to miałoby sens uczyć się nowej architektury.
Dodano po 4 [minuty]:
mas24 napisał:
No właśnie, z tego, co doczytałem, to AVR32 mają właśnie jakieś algorytmy DSP. Za to VS-y to kodeki audio, ale mogą zawierać funkcje filtrowania, pogłosu i inne.
Nie, VSy to procesory DSP z niezbędnym otoczeniem (wzmacniacz, DAC itd), w których program realizuje np. funkcję dekodera audio. Ale program możesz wczytać własny, lub stworzyć własne callbacki do systemu VSa, dodając nowe funkcje, lub całkowicie zmieniając ten układ.
No dobrze, Koledzy. Zacznijmy więc od początku, czyli od pierwotnego pytania: jak zacząć z AVR32? Chciałbym poznać tą rodzinę, zanim pójdę dalej w cortexy czy specjalizowane DSP.
Tak więc jaki programator sprzętowy do tego użyć i jakim interfejsem się to programuje?
No dobrze, Koledzy. Zacznijmy więc od początku, czyli od pierwotnego pytania: jak zacząć z AVR32? Chciałbym poznać tą rodzinę, zanim pójdę dalej w cortexy czy specjalizowane DSP.
Tak więc jaki programator sprzętowy do tego użyć i jakim interfejsem się to programuje?
Ja polecam ATMEL-ICE-BASIC, ATMEL-ICE PCBA, ATMEL-ICE. To trzy wersje tego samego narzędzia. Różnią się tylko zestawem przejściówek, dodatkowo ATMEL-ICE PCBA jest to sama płytka bez obudowy. Dostępne w Seguro, TME, Farnell. Dodatkowo obsługuje AVR8 i ARM Atmela.