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

DMA w Xmega i toczenie danych z tablicy do tablicy.

jacynka84 17 Kwi 2018 13:10 795 6
  • #1 17172606
    jacynka84
    Poziom 26  
    No więc kiedyś kolega drzasiek dumał nad powieszeniem ADC 8 bit na szynie EBI w xmega. Nie wiem czy to zrobił czy nie ale ja tak zrobiłem.
    I niestety jestem nieco zawiedziony.
    Przykładowo na wewn ADC da się wyciągnąć ok 6-8MSPS w 8bitowej rozdzielczości przy 48Mhz, nie jest to wcale zły wynik na adc w avr i bascom.
    Problem jest w tym że DMA w połączeniu z szyną danych poprzez którą się łączę z ADC powinna chyba wycisnąć więcej niż pożal się boże 9MSPS któe wyciskam z zewn ADC na EBI. Bo tyle chyba udało mi się wydusić, i to przy kręceniu Cora na 50Mhz a fabrycznie powinno być 32Mhz (nie dzwońcie na policję). Może jest ekspert na sali od DMA? Może bez znaczenia dla języka wie czy da się wykombinować większą prędkość toczenia danych bo chyba tu jest problem w prędkości owego DMA. Może nie toczyć tablic bo inkrementacja adresów to też zabiera cenny czas.
    ADC udaje ram bo przy każdym cyklu zegara który bierzemy z pinu ramu read enable otrzymujemy próbkę na szynie danych. Tak jakbyśmy wyciągali dane z array z zewn RAMu. array>array. Proste. Ale ponoć DMA miałobyć takie szybkie że niby 2x zegar, a ten marnuje masę cykli na przetoczenie. A szyna ustawiona na max, bez waitstait. Co prawda to blisko prędkości granicznej ADC1173 czyli 15MSPS ale szkoda nie wykorzystać tych 5-6MSPS.
    Kod: VB.net
    Zaloguj się, aby zobaczyć kod

    Na obrazku widać po kolei 300 sampli.
    Zrobiłem też żeby toczył ten sam bajt z ADC by nie inkrementował niepotrzebnie adresu źródła którego i tak nie potrzeba ale bez skutku.
    DMA w Xmega i toczenie danych z tablicy do tablicy.
  • #2 17173050
    tmf
    VIP Zasłużony dla elektroda
    jacynka84 napisał:
    Może bez znaczenia dla języka wie czy da się wykombinować większą prędkość toczenia danych bo chyba tu jest problem w prędkości owego DMA. Może nie toczyć tablic bo inkrementacja adresów to też zabiera cenny czas.


    W innym poście pisałem, bo nie widziałem tego, więc jeszcze raz - idea DMA nie polega na przesyłaniu danych z szybkością większą niż by to robił CPU, ale na odciążeniu CPU od przesyłu. Dlatego transfer z udziałem DMA wcale nie musi być szybszy. Poza tym popełniłeś kilka błędów - po pierwsze nie spojrzałeś na timingi EBI. Zastanów się dlaczego normalnie EBI jest taktowane dwukrotnie szybciej niż CPU. Pewnie jest ku temu jakiś powód... Tak więc popędzanie procka na 50 MHz z EBI na 50 MHz niekoniecznie ma sens. Kolejna sprawa związana jest jednak z pewną teorią stojącą za budową procesora. W skrócie - DMA musi uzyskać dostęp do magistrali współdzielonej z CPU (i bynajmniej nie ma tu priorytetu nad CPU), po uzyskaniu kontroli nad magistralą musi wystawić adres, odczytać dane, po czym musi wystawić adres docelowy i te dane zapisać. Łatwo policzyć ile co najmniej cykli to zajmie. Oczywiście DMA w XMEGA ma swój bufor, więc to trochę bardziej skompilowane, niemniej w jednym cyklu operacja się nie zamknie. O ile pamiętam minimalnie przesłanie bajta trwa 4 cykle zegara. W dodatku konieczność dostępu do magistrali pamięci RAM przez CPU wywłaszczy DMA, co dodatkowo zwolni transfer.
    Kolejna sprawa - uważam, że 8-bitowce są fajne, a XMEGA to naprawdę wypasiony procesor. Ale wszystko ma swoje granice - jeśli chcesz przesyłać 15 MB/s i jakoś to obrobić to naprawdę użycie tego procesora to nie jest najlepszy pomysł.
  • #3 17173063
    jacynka84
    Poziom 26  
    Dzięki za odpowiedź, tak wiem że EBI nie ma być szybkie lecz odciążyć i zautomatyzować. A jaka jest prędkość ebi? Taka jak rdzenia czy 2x większa jak EBI?
    Bo już się pogubiłem.
    Miałem nadzieję że EBI jest 2x szybsze niż rdzeń, i wtedy pomimo obecności obliczeń da radę wycisnąć przetoczenie danych (z inkr adresu) przynajmniej na połowie prędkości rdzenia, ale otrzymałem jedynie 1/5. To normalne?

    Ważne pytanie czy umiejscowienie i sposób detonacji transakcji DMA ma wpływ na prędkość tego transferu bloku danych?
    Jeśli tak to jak to zrobić by poprawiło to MB/s? niby 1/5 to nadal bez dramatu ale minimalnie lepiej byłoby super. z drugiej strony czego ja
    oczekiwałem bo avrku.

    Mam zamiar niedługo pomęczyć się z STM32 ale nie wiem jak się za zabrać za środowisko i biblioteki i co i kiedy jest dołączane do kodu.
  • #4 17173114
    tronics
    Poziom 38  
    @jacynka84 - środowisko dla STM32? Jest Atollic, jest SW4STM32, jest PlatformIO na Atomie, jest Keil MDK w końcu... A jeśli chodzi o sprzęt to za jakąś dychę (PLN) jest nieco archaiczny, ale i tak raczej szybszy niż xmega dev board będący klonem Maple - na układzie STM32F103C8T6 jak mi się dobrze wydaje. Max częstotliwość zdaje się 96MHz, 64KB Flash i 20KB RAM. Do tego kilka kanałów DMA (32bit). Do zabawy wystarczy... Można zacząć z arduino, można zacząć z HAL, można zacząć z LL (niby lżejsze, ale nie do końca), a można klepać po rejestrach. Tutoriali akurat jest mnogość.
  • #5 17173116
    tmf
    VIP Zasłużony dla elektroda
    EBI ma być szybkie, to DMA ma odciążać CPU. EBI możesz taktować 2x szybciej niż CPU. Czyli dla taktowania CPU 32 MHz, EBI może działać z częstotliwością 64 MHz. Ma to duże znaczenie, o czym możesz się przekonać oglądając timingi operacji zapisu i odczytu dla EBI. Np. odczyt trwa co najmniej 2 takty EBI, czyli jeśli go taktujesz 2x szybciej niż CPU to odpowiada to jednemu taktowi CPU. Zapis jest ciut dłuższy, bo trwa 3 takty EBI.
    jacynka84 napisał:
    Miałem nadzieję że EBI jest 2x szybsze niż rdzeń, i wtedy pomimo obecności obliczeń da radę wycisnąć przetoczenie danych (z inkr adresu) przynajmniej na połowie prędkości rdzenia, ale otrzymałem jedynie 1/5. To normalne?

    To zależy. Jak pisałem, magistrala pamięci RAM i peryferiów jest współdzielona przez DMA i CPU. Oba układy nie moga uzyskać jednoczesnego dostępu. Stad też, jeśli CPU wykonuje instrukcje wymagające dostępu do RAM lub rejestrów ukł. peryferyjnych to wstrzymuje to pracę DMA. Z symulacji w symulatorze w Atmel Studio wychodzi, że DMA potrzebuje co najmniej 4 taktów CPU na przesłanie 1 bajta danych. Stąd też dla taktowania 32 MHz możesz teoretycznie przesłać 8 MB/s (zakładając, że CPU nie będzie żądał dostępu do pamięci lub peryferii). Nie sprawdzałem, ale przy 2x zwiększonym taktowaniu EBI, być może transfer skróci się do 3 taktów/bajt.
    Weź też pod uwagę cuda, które może wyczyniać BASCOM. Dlatego wartoby podgladnąć jak naprawdę to wszystko jest skonfigurowane.

    Dodano po 7 [minuty]:

    BTW, EBI w trybie no CS, no ALE ma timingi po 1 takt CLK EBI, czyli 1/2 taktu CPU.
  • #6 17173369
    jacynka84
    Poziom 26  
    Mogę zobaczyć rejestry ale podejrzewam że wszystko będzie czysto i tylko operacje będą kradły czas. No cóż. Trzeba na stmy się przesiąść.
  • #7 17190152
    jacynka84
    Poziom 26  
    Byłem w błędzie. Po prostu transfer dotarł do maksymalnej ilości MSPS tego ADC. Na wewn adc 8bit da się dotrzeć nawet do chyba 30MSPS, ale rozdzielczość spada sam nie wiem do ilu na zegarze 48MSPS i preskalerze 16. Jednak nie wiem czy sygnał jest zniekształcony. 50-150Khz sinusy i trójkąty wyglądają prawidłowo.
REKLAMA