Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[AVR/XMEGA] - Mikrokontrolery AVR jakich używasz - ankieta

tmf 28 Mar 2013 00:16 13539 54
Altium Designer Computer Controls
  • #31
    rekinisko
    Level 22  
    Ja także chętnie przeskoczę na xmegi, cena kusząca, możliwości więcej. Do tej pory jedyny avr z usb jaki miałem w dłoni to 90usb1287, mam jeszcze kilka z wylutu na czarną godzinę.
  • Altium Designer Computer Controls
  • #33
    Ostry23
    Level 18  
    aaadamw wrote:
    Teraz tylko muszę zrobić jakąś płytkę testową i programator do tego

    Z tego co się orientuję programator musi być zgodny z AVRIsp Mk.II, a on już chodzi na USB. Nie wiem, czy sa programatory nie pracujące wg tego protokołu.
    Możesz zrobić wsad programatora w oparciu o projekt LUFA - Link (framework do USB, notabene napisany przez pracownika Atmela). Ja mam klon AVRIsp Mk.II z firmy Sibit i bardzo sobie chwalę. Aha, zaletą AVRIsp Mk. II jest możliwość programowania zarówno zwykłych AVR (ISP) jak i XMEGA (PDI).
    Natomiast jeśli chcesz mieć oprócz programowania również debuggowanie to musisz się zaopatrzyć w JTAGICE Mk.II lub JTAGICE 3, a to już jest koszt rzędu 400-500 PLN. (Atmel Studio ma symulator również dla XMEGA, więc w większości przypadków można się obejść bez debuggera).

    Rodzina XMEGA A4 to bardzo fajne MCU, a przesiadka ze starych Atmeg jest baaardzo przyjemna (masz 4 x więcej MIPS, DMA, Event System, kaskadowe łączenie liczników, CRC - połowa roboty się sama robi a CPU może np. lekko drzemać w tym czasie; do tego szybszy i dokładniejszy niż w ATmegach ADC - nie ma z nim problemów, jeśli się tylko omija pewne tryby jego pracy).
  • #35
    tmf
    Moderator of Microcontroller designs
    Ostry23 wrote:

    Natomiast jeśli chcesz mieć oprócz programowania również debuggowanie to musisz się zaopatrzyć w JTAGICE Mk.II lub JTAGICE 3, a to już jest koszt rzędu 400-500 PLN. (Atmel Studio ma symulator również dla XMEGA, więc w większości przypadków można się obejść bez debuggera).


    Tylko małe sprostowanie, JTAG i możliwość debugowania w układzie można uzyskać kupując AVR Dragon za 240zł - pełne wsparcie z Atmel Studio i programowanie wszystkich AVR8 i AVR32 przez wszystkie możliwe interfejsy.

    Dodano po 12 [minuty]:

    RitterX wrote:
    Rozważałem używanie XMEGA jednak zrezygnowałem z ich wykorzystania. Powód jest bardzo prosty. Przyrost wydajności i możliwości peryferiów nie jest powalający w stosunku do zwykłych AVRów. Ot podrasowany AVR i nic więcej. Czasy gdy przerabiałem każdy napotkany procesor mam już poza sobą. Nie ma większego sensu pchać się w usychającą, w moim przekonaniu, gałąź. Już lepiej skupić się na MSP430 lub czymś podobnym nie wyłączając ARM CM0/CM0+.


    Trudno się z tym zgodzić. Nominalnie przyrost wydajności jest "zaledwie" dwukrotny, 32 vs. typowo 16 MIPS dla innych AVR. Czy 32 MIPSy to mało? Zależy, oczywiście MIPS MIPSowi nierówny. Warto więc się bliżej przyjrzeć. XMEGA ma wiele układów wspomagania, w efekcie przy wielu zastosowaniach przyrost prędkości jest o wiele większy. Np. szyfrowanie/deszyfrowanie AES - przyrost ponad 100-krotny, czyli odpowiednik ATMega taktowanej zegarem 3,2 GHz! Przy CRC16 - przyrost 10-14 krotny, ale już przy CRC32 przyrost ponad 100-krotny. Dostęp do portów, co jest typową operacją dla MCU - atomowe operacje RMW -przyrost 3 krotny, czyli porównując do ATMega - musielibyśmy ją taktować zegarem prawie 100 MHz. DMA - przyrost zależny od zastosowania, trudno oszacować. Ale operacje IO, które na ATMega zajmują 100% czasu procesora, na XMEGA z DMA będą zajmować 1-3%. Event System - możliwość robienia wielu rzeczy całkowicie sprzętowo. Trudno oszacować wzrost. Czasami daje to możliwość realizacji całkowicie sprzętowo skomplikowanych algorytmów, takie przykłady pokażę dzisiaj w Katowicach na spotkaniu. Układy logiki programowalnej (można sobie programowo skonfigurować prarę ukłądów sekwencyjnych i kombinatoryjnych, w efekcie znika potrzeba stosowania tzw. glue-logic). Tak można wymieniać dosyć długo. Z drugiej strony - pisząc w c rdzeń MCU ma co raz mniejsze znaczenie. Kod jest taki sam, to co się różni to peryferia. W efekcie przesiadka na dowolny inny MCU to w praktyce poznanie jego peryferii. Atmel o tyle nam to ułatwia, że mamy to samo IDE (AS 6.x) do AVR, XMEGA, AVR32 (UC3) i ARM. To samo IDE, ten sam toolchain (praktycznie ten sam), mamy też mały HAL, czyli ASF. W efekcie obecnie przy wyborze Atmela przesiadki są maksymalnie bezbolesne.
    I co najważniejsze - świetne IDE i doskonały toolchain dla AVR, ARM i AVR32 Atmel dodaje całkowicie za darmo, a nie za darmo z ograniczeniami jak inni. IMHO to najważniejsza zaleta dla hobbysty i właściciela małej firmy.
  • #36
    Ostry23
    Level 18  
    tmf wrote:

    Tylko małe sprostowanie, JTAG i możliwość debugowania w układzie można uzyskać kupując AVR Dragon za 240zł - pełne wsparcie z Atmel Studio i programowanie wszystkich AVR8 i AVR32 przez wszystkie możliwe interfejsy.

    Jasne, nie wiedziałem tego. Różnica w cenie dwukrotna, ale też Dragon jest wolniejszy 4 razy, jednak przy większości projektów, jeśli się tylko nie debugguje co pół minuty, nie powinno mieć to znaczenia.

    Co do reszty, zgadzam się zupełnie - MIPS AVRa to MIPS XMEGI, bo lista rozkazów jest taka sama, ale XMEGA dzięki peryferiom w stosunku do zwykłych AVR'ów wchodzi w nadświetlną :).
    A samych MIPS'ów ma często 4 a nie 2 razy więcej - np. gdy ktoś zamienia starą ATmegę w wersji L, albo nawet 16AU, ale zasilaną z 3,3V, czyli taktowaną maksymalnie 8MHz, to po przesiadce może mieć od razu 4 razy więcej MIPSów.

    tmf wrote:
    Kod jest taki sam, to co się różni to peryferia.

    Tu się przyczepię do sformułowania. Kod jednak jest bardzo blisko sprzętu, więc przeportowanie przykładowo transmisji UART zrobionej na przerwaniach w AVR na AVR XMEGa nie wymaga zmian (poza HAL), gdy chcemy ją też zrobić przerwaniowo. Ale gdy chcemy wykorzystać DMA, to kod wymaga zmian. No ale to jest oczywista oczywistość, nie działamy tu przecież na wysokopoziomywm Linuksie embedded.
  • Altium Designer Computer Controls
  • #37
    tmf
    Moderator of Microcontroller designs
    Z tymi wersjami L i zasilaniem niskonapięciowym to cenna uwaga. Nie pomyślałem o tym, a rzeczywiście dla osób pracujących na 2,5-3,3V to bardzo istotna różnica.
    Co do peryferii. Chyba mówimy o tym samym lecz nieco inaczej. Oczywiście kod jest blisko sprzętu, ale to co musimy zmienić to sam styk kod-sprzęt, więc coś co jest właśnie od peryferii zależne. Gdyby przyjąć hipotetyczną sytuację, w której mamy AVR i ARM, a więc różne rdzenie, ale identyczny układ peryferyjny, np. USART, to kod w c nie wymagałby żadnej zmiany. Czyli rdzeń tak naprawdę jest nie aż tak istotny. To właśnie miałem na myśli.
  • #38
    Ostry23
    Level 18  
    tmf wrote:
    Gdyby przyjąć hipotetyczną sytuację, w której mamy AVR i ARM, a więc różne rdzenie, ale identyczny układ peryferyjny, np. USART, to kod w c nie wymagałby żadnej zmiany. Czyli rdzeń tak naprawdę jest nie aż tak istotny. To właśnie miałem na myśli.

    Jasne, ja cię rozumiem i też uważam, że myślimy o tym samym i się w tym zgadzamy. Ja się tylko do sformułowania przyczepiłem :). Podsumowując, generalnie duży procent kodu często nie zależy od architektury i im wyższy poziom abstrakcji, tym mniej kodu aplikacji zależy od sprzętu (vide JVM, albo chociaż zwykły OS). Na małych MCU jest trochę gorzej, bo się zazwyczaj wyciska ze sprzętu tyle ile fabryka daje i często nie tworzy się zbyt wielu warstw aplikacji, żeby nie tracić cykli CPU na przechodzenie pomiędzy warstwami. Oczywiście wszystko w granicach rozsądku. Taki Atmel Software Framework jest przecież strasznie nieoptymalnie napisany (ma np. milion niepotrzebnych switch'y) (chociaż z tego co wiem standardowe biblioteki dla STM32 wypadają gorzej a w dodatku trzeba do każdej rodziny ściągać inny pakiet), ale za to, tak jak piszesz, jest bardzo uniwersalny i pomaga bardzo szybko wystartować z działającą aplikacją a obsługuje 4 różne architektury i ich podrodziny. Coś za coś. A w miarę potrzeb można sobie wszystko optymalizować.

    aaadamw wrote:
    myślę, o wykonaniu tego oto programatora;
    http://mdiy.pl/programator-usbtiny-mkii-slim/

    No to rób go! Trzeba wspierać rodzimą myśl open-hardware'ową a i kolega Manekinen się pewnie ucieszy :D
  • #39
    manekinen
    Level 29  
    aaadamw wrote:
    myślę, o wykonaniu tego oto programatora;
    http://mdiy.pl/programator-usbtiny-mkii-slim/

    I się kolego nie zawiedziesz, a taki programator jest o wiele wygodniejszy w użyciu aniżeli bootloader USB - ponieważ za każdym razem aby w niego wejść musisz na płytce wcisnąć przycisk za to odpowiedzialny. Czy będzie szybszy/wolniejszy? Nie wiem, nie miałem okazji porównać.
    aaadamw wrote:
    A ja już mam ATXMEGA64A4U. Teraz tylko muszę zrobić jakąś płytkę testową i programator do tego.

    Na tej samej stronie znajdziesz projekty modułów pod różne Xmegi do wpięcia w płytkę stykową, już nie chcę tu spamować linkami. Na takim module właśnie będę robić "przeprowadzkę" na xmegi :)
  • #40
    RitterX
    Level 39  
    @Tmf Jestem w pełni przekonany, że Atmel nie dokonał w XMegach regresu względem ATMeg. To byłoby po prostu głupie. Zlikwidowano braki, które doskwierały w stosunku do konkurencji. Ot choćby Microchipa.
    Nie bardzo pojmuję jaki segment aplikacji chce zająć XMEGA? Nie piszę tego przez złośliwość a z porzeby zrozumienia. Tylko mi nie pisz "szeroko rozumiany sterowania i pomiarów". Każdy procesor ma swoją specyfikę. Jeden lepiej współpracuje z szybkimi przebiegami inny ma lepszą odporność EMC jeszcze inny lepszą względem innych skalowalność obliczeniową. Choćby poprzez posiadanie sprzętowej jednostki FPU. A to nie to samo co sprzętowe CRC. Dlatego za porównywalną cenę procesor z FPU jest dużo atrakcyjniejszy jak ten bez jednostki zmiennoprzecinkowej. Tak na marginesie jak wygląda w XMegach wsparcie dla DSP?
    Nie zgodzę się też z twierdzeniem, że od kiedy zaczęto stosować język C rdzeń procesora ma pomijalne znaczenie. Dla jednych nie ma a dla innych ma. Ma przynajmniej dla tych, którzy mają ogrniczenia co do czasu wykonywania danych obliczeń i generacji odpowiedzi.
    Epatowanie "przeliczeniowymi częstotliwościami" też jest obarczone sporą wadą. Ot choćby z powodu rzeczywistej responsywności układu na zdarzenia gdy procesor pracuje z systemem twardego czasu rzeczywistego?
    Zerknąłem na stronę Atmela i sprawdziłem maksymalny FLASH. Coś ~384kB to raczej nie powalająca wartość szczególnie w czasach gdy wyświetlacze TFT 3.5" a nie 2x16char są już rzczywistością w aplikacjach.
    Zaś co do właściciela małej czy dużej firmy to nie sądzę, by po wpadce jaką zaliczył Atmel z dostawami i cenami pewien czas temu, napawało to owego człowieka zaufaniem. Dlatego, jak dla mnie, XMega nadal będzie jedynie podrasowanym AVRem z podobnym zakresem możliwych do obsłużenia aplikacji. Przy tym dodanie USB i 12bit. A/C nie wydaje się obecnie żadną łaską.
    Dlatego zadam proste pytanie. W jakiej aplikacji XMega jest znacząco lepsza od porównywalnej konkurencji?
  • #41
    tmf
    Moderator of Microcontroller designs
    Ale ja wcale nie wykazuję, że XMEGA to próba ataku na rynki procesorów 32-bitowych. To raczej sposób na obronę dotychczasowego rynku i ewentualne podgryzanie rynku mikrokontrolerów 16 bitowych lub większych, w których pewne rzeczy można zrobić sprzętowo, w efekcie jakaś większa moc jest niepotrzebna. Jest jeszcze jeden aspekt - energooszczędność. Statycznie XMEGA E5 bierze 100nA, chyba najmniej ze wszystkich, a dynamicznie 100 uA/MIPS. Jest to więc jakaś specyficzna grupa zastosowań. Niemniej ja traktuję XMEGA jako upgrade dla zwykłych AVR, gdzie poprawiono wiele niedoskonałości (m.in. wyeliminowano źródło błędów jakim były fusebity, czy uporządkowano chaos związany z różnymi układami peryferyjnymi w każdej ATMedze implementowanymi inaczej). Myślę, że jeśli producent zamienia w telefonie monochromatyczny LCD na kolorowy, to nie należy tego odbierać jako ataku na smartfony :) Po prostu naturalna ewolucja.
    Jeśli chodzi o c i rdzeń. To co piszesz nie ma nic wspólnego z c, wiadomo, że jak szybszy rdzeń to szybciej wykonywane są obliczenia. Ale wykorzystując w c np. funkcje trygonometryczne nie piszesz ich implementacji. Ten sam kod będzie działał na rdzeniu z FPU, jak i bez FPU. W tym pierwszym przypadku szybciej, co oczywiste, ale sam kod c będzie taki sam. To właśnie mam na myśli pisząc, że rdzeń nie ma aż takiego znaczenia.
    A propos responsywności - dużą zaletą AVR jest krótki i przewidywalny czas odpowiedzi, co jest problemem dla ARMa. W dodatku XMEGA ma event system, w efekcie odpowiedź na zdarzenie może zająć tylko 2 takty zegara, 62 ns, nieźle, prawda? Możliwość zasilania od 1,6V też w jakiś aplikacjach jest istotna i może być pewną zaletą.
    Co do LCD TFT, nie wiem co ma z tym wspólnego FLASH, czy 384 kB to mało? Na dane graficzne może istotnie nie wystarczyć. Ale większość ARM też ma nie więcej niż 256-512 kB. Zawsze można dodać zewnętrzną pamięć. Jeśli myślisz o RAM, to też, np. seria A1 ma obsługę SRAM i SDRAM o pojemności do 16 MB.
    Atmel zaliczył wpadkę, ale w tym czasie wiele innych firm też. Ale nie będę się wypowiadać na temat marketingu, bo nie mam takich danych. Nie mam pojęcia jak to wpłynęło na sprzedaż i jakie tego były konsekwencje, a spekulacje nie mają sensu.
    Na twoje pytanie w czym XMEGA jest znacząco lepsza - to raczej musi odpowiedzieć sobie osoba wybierająca MCU do projektu. Inaczej to będzie marketingowy bełkot i tyle. Są pewne fakty, które można łatwo sprawdzić, porównać do wymagań w projekcie i wybrać taki a nie inny mikrokontroler. Każde inne podejście IMHO jest wyrazem jakiegoś religijnego przekonania i fanatyzmu. Z pewnością XMEGA jest znacząco lepszym wyborem w 90% aplikacji w których stosowane są AVRy, może być lepszym wyborem w aplikacjach, w których stosowane są 8/16 bitowe PICe i low-endowe ARMy. Ale jeśli decyzję podejmuje się na podstawie ceny to powstaje problem - nie wiemy jakie są ceny ARM/PIC/AVR na rynku hurtowym, czy dla dużych odbiorców. Więc znowu musielibyśmy spekulować, bo ceny przy zamówieniu na 100 sztuk nic nie mówią.
  • #43
    Wacholek84
    Level 11  
    W sprawie XMEGI chciałbym dodać jeszcze jedno moje spostrzeżenie. Wykorzystywany jest tam bardzo ciekawy generator wewnętrzny zegara systemowego. Rozpoczynamy od 2MHz i dalej sobie można łatwo wszystko skonfigurować. Chciałoby się powiedzieć w końcu problem ze zbędnymi elementami rozwiązany. Niestety. Na grupie 500 szt. 7% układów padło ze względu na zastosowanie wewnętrznego generatora. Kolejne 500 na zewnętrznym kwarcu i wszystkie śmigają bez problemu. Taka awaryjność nie zdarzyła się do tej pory w żadnej partii Atmega128.
  • #44
    Ostry23
    Level 18  
    Wacholek84 wrote:
    Na grupie 500 szt. 7% układów padło ze względu na zastosowanie wewnętrznego generatora

    Co to znaczy padło? Program nie daje oznak działania? Nie ma komunikacji po PDI?
    Przecież po resecie MCU i tak początkowo działa na wewnętrznym RC 2MHz, za każdym razem trzeba się przełączyć na pożądany zegar, więc moduł RC 2 MHz musi działać i w moich XMEGAch zawsze działa, tzn. do tej pory nie zdarzył się wadliwy MCU.
  • #45
    ZbeeGin
    Level 39  
    Ostry23 wrote:
    Co to znaczy padło?

    Pewnie układ wystartował, ale przełączenie na rezonator kwarcowy nie dało rezultatu. Ale kto by tam flagi statusowe sprawdzał...
  • #46
    tmf
    Moderator of Microcontroller designs
    Ostry23 wrote:
    Wacholek84 wrote:
    Na grupie 500 szt. 7% układów padło ze względu na zastosowanie wewnętrznego generatora

    Co to znaczy padło? Program nie daje oznak działania? Nie ma komunikacji po PDI?
    Przecież po resecie MCU i tak początkowo działa na wewnętrznym RC 2MHz, za każdym razem trzeba się przełączyć na pożądany zegar, więc moduł RC 2 MHz musi działać i w moich XMEGAch zawsze działa, tzn. do tej pory nie zdarzył się wadliwy MCU.


    Słuszna uwaga. Jeśli RC 2 MHz padł, to jakim cudem XMEGA wstała? Warto wyjaśnić to tajemnicze zjawisko :)
  • #47
    sorex86
    Level 15  
    Proponuje sprawdźć kiedy można było kupić w Polsce pierwszą atmege32, a kiedy zostały wydana np ksiązki mirka lub tmf. Jeżeli aż tyle lat było potrzebnych na skompletowanie dobrych pozycji w języku polskim to ciężko aby po 2-3 latach ludzie przerzucali się na inną rodzinę uC. Natomiast jeśli ktoś jest programistą uC z zawodu to do przesiadki z avr na xmege czy arm nie potrzebuje żadnych kursów polskojęzycznych.
  • #48
    tmf
    Moderator of Microcontroller designs
    Książki o których piszesz nie były pierwszymi o AVR. Pierwsza pojawiła się co najmniej 7 lat wcześniej. Jak popatrzysz na rozwój portu gcc dla avr to zauważysz, że wcześniej nie było większego sensu pisać o c dla AVR, stąd dużo wcześniejsze książki poruszają inną tematykę (asembler, BASCOM). Co do kursów i książek - IMHO jeśli zajmuję się czymś profesjonalnie to tym bardziej mam potrzebę kursów i książek. Dlaczego? Bo na tym zarabiam. Skoro książka kosztuje tyle co dla pracodawcy 1-2 godziny pracy pracownika, to zakup książki w wyniku czego pracownik zaoszczędzi te 1-2 godziny już jest zyskiem.
    BTW, różnica pomiędzy XMEGA a innymi AVR jest mniej więcej taka jak pomiędzy ATTiny a ATMega. W efekcie koszty przesiadki są praktycznie żadne. A wręcz jest zysk - są tańsze, a przede wszystkim projekty, które wyciągały 100 i więcej % zasobów z ATMega i w efekcie wymagały migracji do czegoś szybszego (np. ARM) można zrealizować ciągle na tym samym - znanym nam rdzeniu AVR. |Czyli migrację na nową rodzinę można odłożyć i obniżyć koszty z tym związane.
  • #49
    Brutus_gsm
    Level 25  
    Ja powiem tak - cały czas się uczę i do tej pory nie wykorzystuję 100% możliwości zwykłych AVR, ale jeśli pojawi się książka napisana przez tmf, która będzie równie wyczerpująca, a przy tym profesjonalnie napisana i nadal bardzo przystępna jak poprzednia, to kupuję w ciemno!

    Dla mnie bardzo dużym "kopem" byłoby (i mam nadzieję, że będzie) sprzętowa realizacja wielu rzeczy. Czasami mam problem, żeby stworzyć program robiący pewne specyficzne rzeczy niemal jednocześnie. "Zwalenie" części pracy na sprzętowe peryferia jest świetnym rozwiązaniem.
  • #50
    dondu
    Moderator on vacation ...
    Brutus_gsm wrote:
    Dla mnie bardzo dużym "kopem" byłoby (i mam nadzieję, że będzie) sprzętowa realizacja wielu rzeczy. Czasami mam problem, żeby stworzyć program robiący pewne specyficzne rzeczy niemal jednocześnie. "Zwalenie" części pracy na sprzętowe peryferia jest świetnym rozwiązaniem.

    Temat jest na tapecie i w przyszłym tygodniu ukaże się case study takiego przypadku.
  • #51
    User removed account
    User removed account  
  • #52
    tmf
    Moderator of Microcontroller designs
    Mogę odpowiedzieć tak - z tymi pytaniami w 100% trafiłeś w pierwszą część książki, którą właśnie wydaje Helion - "AVR. Praktyczne przykłady". Wkrótce pojawi się zajawka na stronie.
    Ale zapewne taka odpowiedź cię nie satysfakcjonuje, więc krótko:
    1. Tak, DMA może transmitować blok danych z pamięci (ale nie FLASH) do portu, np. SPI z którym łączysz LCD.
    2. Jeśli wypluwasz dane równolegle i potrzebujesz sygnał E to z DMA możesz połączyć event system, który po przesłaniu bajtu wygeneruje E powodując zatrzaśnięcie danych w buforach zewnętrznych. Możesz też wykorzystać w tym celu EBI.
    3. DMA i RS232 - DMA nie musi wykryć początku ramki, to wykrywa interfejs USART. Po wykryciu początku i odebraniu bajtu wyzwala on transfer DMA, kolejny bajt - kolejne wyzwolenie itd.
    4. DMA i CRC - moduł CRC XMEGA można "podłączyć" pod DMA, wtedy automatycznie oblicza on CRC16/32 dla przesyłanych danych, po zakończeniu transferu po prostu odczytujesz wyliczone CRC lub też konfigurujesz DMA tak, aby "doklejało" 2-4 bajty CRC do przesłanego bloku danych.
    W nocie procka te informacje są podane w sposób pośredni - masz opis konfiuguracji poszczególnych peryferii, jak je posklejać razem musisz wymyślić sam. Stąd też IMHO potrzeba na książkę, która nie będzie tłumaczeniem noty, ale pokaże jak to wszystko razem posklejać. Mam nadzieję, że książka o której wspomniałem na początku to założenie spełni.
  • #53
    tmf
    Moderator of Microcontroller designs
    Tak, sygnalizowałem już ten problem i mam nadzieję, że jakość będzie lepsza. Ale jako czytelnik masz większą siłę przebicia :)

    3.1.14. Zabronione jest publikowanie wpisów niezgodnych z tematyką danego forum lub wątku dyskusji.
    Dar.El
  • #54
    willyvmm
    Level 29  
    Właśnie odkryłem Xmegi i w ostatniej chwili zrezygnowałem z Propellera żeby w Xmedze projekt zrobić :)

    Przy okazji czy ktoś mógłby mnie uświadomić (bo nie znalazłem) czy xmega przy pomocy DMA może wypluć stream 4 bitowy?

    1 bitowy bez problemu przy pomocy SPI, ale 4 bitowy?, konkretyzując: wczytać 1 bajt z pamięci i wysłać w porcjach po 4 bity równolegle na 4 piny jednocześnie.
  • #55
    tmf
    Moderator of Microcontroller designs
    Tak, możesz przesyłać dane na port IO przy pomocy DMA - będziesz miał wtedy co prawda 8 bitów, ale przecież 4 możesz nieużywać (o ile możesz sobie pozwolićna marnotrawstwo 4 pinów IO). Można to ominąć pisząc do tejestru TGL związanego z pinem, tylko wtedy trzeba przekodować ciąg wysyłanych bajtów.