logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak zacząć zabawę z AVR32?

mas24 14 Kwi 2015 21:00 4917 55
  • #1 14617564
    mas24
    Poziom 16  
    Witam.

    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?
  • #2 14617586
    BlueDraco
    Specjalista - Mikrokontrolery
    A po co z tym zaczynać? To raczej ślepa uliczka.
  • #3 14617592
    electronics_design

    Poziom 14  
    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
  • #4 14617640
    tmf
    VIP Zasłużony dla elektroda
    BlueDraco napisał:
    A po co z tym zaczynać? To raczej ślepa uliczka.


    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.
  • #5 14618383
    mas24
    Poziom 16  
    Dzięki za odpowiedzi :)

    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?
  • #6 14618392
    Konto nie istnieje
    Konto nie istnieje  
  • #7 14618557
    mas24
    Poziom 16  
    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.
  • #8 14618662
    Konto nie istnieje
    Poziom 1  
  • #9 14618681
    tmf
    VIP Zasłużony dla elektroda
    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...
  • #10 14618706
    BlueDraco
    Specjalista - Mikrokontrolery
    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?
  • #11 14618745
    Konto nie istnieje
    Konto nie istnieje  
  • #12 14618771
    tmf
    VIP Zasłużony dla elektroda
    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" :)
  • #13 14618837
    BlueDraco
    Specjalista - Mikrokontrolery
    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.
  • #14 14618925
    tmf
    VIP Zasłużony dla elektroda
    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.
  • #15 14618995
    BlueDraco
    Specjalista - Mikrokontrolery
    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.
  • #16 14619058
    tmf
    VIP Zasłużony dla elektroda
    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.
  • #17 14619603
    mas24
    Poziom 16  
    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.
  • #18 14619969
    tmf
    VIP Zasłużony dla elektroda
    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.
  • #19 14620053
    mas24
    Poziom 16  
    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.
  • #20 14620074
    tmf
    VIP Zasłużony dla elektroda
    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".
  • #21 14620672
    Konto nie istnieje
    Poziom 1  
  • #22 14620770
    pawlik118
    Poziom 32  
    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.
  • #23 14620861
    deus.ex.machina
    Poziom 32  
    Nieśmiało wspomnę o produktach XMOS no i jednak nie da się ukryć ze w czysto sygnałowych rzeczach lepiej sprawdza się DSP...
  • #24 14621126
    mas24
    Poziom 16  
    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.
  • #25 14621568
    deus.ex.machina
    Poziom 32  
    mas24 napisał:
    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...
  • #26 14621664
    tronics
    Poziom 38  
    Cytat:
    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.
  • #27 14622274
    tmf
    VIP Zasłużony dla elektroda
    Marek_Skalski napisał:
    @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.
  • #28 14626113
    mas24
    Poziom 16  
    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?
  • #29 14626588
    vania
    Poziom 24  
    mas24 napisał:
    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.
  • #30 14626971
    dasej
    Poziom 32  
    @vania

    Zdaje mi się że też AVR32. Czy się mylę czy nie?

    @tmf
    Jaką literaturę (polską) poleciłbyś aby zacząć z AVR32.
REKLAMA