XMega, DMA i sygna? strobe

Dobrze że się trafiłeś :-) ja ci nie pomogę z xmega, bo dopiero robię na nim projekt, właśnie na 128A1 ale chciałbym cie o coś zapytać jako, że jesteś o krok dalej :-) Zwykłe AVR-y znam dobrze :-)

1. Czy to DMA w xmega kradnie cykle procesorowi? Czy jeżeli zapuszczę kopiowanie dużego obszaru zewnętrznej pamięci do innego obszaru tej pamięci lub do wewnętrznego SRAM czy procek idzie w odstawkę na ten czas?. jakoś nigdzie nie jest to jasno opisane czy np transfer DMA od SPi do UART-u (przykładowo) absorbuje egzekucję rozkazów z pamięci programów i dostep do rejestrów?

1. Gdzie i za ile kupiłeś tani SDRAM? Jaki? 4 czy 8 bitowy? jaka pojemność?

Użytkownik "newxmega" snipped-for-privacy@mmm.mm napisał w wiadomości news:i08g5v$1g1$ snipped-for-privacy@opal.futuro.pl...

Jakby procek szedł w odstawkę to... to już by nie było DMA. Ponieważ pamięć programu jest inna (FLASH) to procek sobie normalnie wykonuje swój program, a jak potrzebuje odwołać się do SRAM, to przejmuje kontrolę nad magistralą pobiera dane i zwalnia magistralę, a wtedy kontroler DMA dalej dłubie swoje, a jak skończy to wygeneruje przerwanie, że znów się nudzi :)

Więc jedyne co ci grozi to oczekiwanie 1 cyklu na przejęcie magistrali przez procesor, w momencie odwołania do SRAM.

A peryferia? Przecież są zamapowane do przestrzeni wewnętrznej pamięci danych. Jeżeli procek -rdzeń się odwołuje dużo do ramu wewnątrz to co z uartami i innymi?

Użytkownik "newxmega" snipped-for-privacy@mmm.mm napisał w wiadomości news:i0a5nn$bhv$ snipped-for-privacy@opal.futuro.pl...

Nie jest to tak do końca jedna przestrzeń (przynajmniej dla części urządzeń I/O), gdyż działają dla nich instrukcje IN, OUT, które się wykonują w jednym cyklu, dla porównania STS i LDS (ich ekwiwalent dla urządzeń spoza I/O) wykonuje się 4 cykle (LD, ST - dwa cykle). Poza tym pomiędzy przestrzenią I/O i SRAM jest jeszcze przestrzeń EEPROM.

Atmel jest niestety bardzo powściągliwy w swojej dokumentacji, niemniej DMA ma także dostęp do przestrzeni I/O i EEPROM. Więc tak do końca nie wiadomo jak to będzie. Jednak jest pewne, że:

- to CPU ma wyższy priorytet nad DMA,

- jeśli DMA zajmuje szynę, to CPU go od razu nie wytnie, tylko dopiero po zakończeniu aktualnego cyklu dostępu do pamięci, jednakże z uwagi na

Właśnie. Ale czy widzisz jednak pomocną dłoń ze strony tego DMA? Gdyby pamięć była wieloportowa, rejestry też z możliwością odczytu równoczesnego z innymi to by coś to DMA dało ale jeżeli piszesz między dwoma SPI po DMA wielkimi burstami to czy możesz korzystać z z trzeciego SPI przez procesor i jak to wpływa jedno na drugie?

Użytkownik "newxmega" snipped-for-privacy@mmm.mm napisał w wiadomości news:i0aogk$sd1$ snipped-for-privacy@opal.futuro.pl...

Jest o tyle pomocna, że gdy potrzebujesz skopiować jakiś obszar pamięci (również z EEPROM do RAM), to inicjujesz proces i o nim "zapominasz". Jest też na pewno bardziej wydajne niż kopiowanie danych w pętli raz, że nie zajmujemy wtedy procesora, dwa, że odpada sprawdzanie warunku pętli, na co normalnie odpada trochę cykli.

Tego nie możesz wykluczyć. To że w AT(X)MEGACH dostęp do rejestrów procesora i pewnej przestrzeni I/O jest dualny (wszystkie rejestry procesora oraz pewna część I/O widziana jest zarówno jako rejestry, jak też zarówno jako zwykła pamięć), tzn. że i "mov R17,R16" i "lds R17,16" i "sts 17,R16" da nam taki sam efekt:

Proponuję obejrzeć w debugerze wykonanie poniższego kodu:

ldi R16,$55 mov R17,R16 clr R17 lds R17,16 clr R17 sts 17,R16

To że dostęp do przestrzni I/O można zrobić poprzez instrukcje IN, OUT, czy też odwołać się do tego jak do zwykłej pamięci SRAM (z inną adresacją) oznacza raczej, że są jakieś mechanizmy dublujące dostęp do tego obszaru, co więcej instrukcje IN/OUT/MOV są szybsze, tak więc być może istnieje jakaś druga magistrala systemowa o np. szynie adresowej szerokości 7 bitów wspomagająca dostęp do tego obszaru. Kłopot w tym, że ATMEL nic szerzej na temat nie pisze, wspominając jedynie o podwójnym bycie tego obszaru. Zastanawiające jest, że nawet rejestry typu SPL/SPH, SR są umieszczone w przestrzeni I/O, a przecież wydawało by się, że są to rejestry bardzo silnie związane z jądra procesora.

Chociaż teraz gdy w procku istnieje DMA łatwo to sprawdzić - zrobić procedurkę która cały czas mielić będzie po tym obszarze i liczyć po ilu taktach skończy się kopiować inny obszar po DMA.

No to pozostaje sprawdzić w realu niestety.

ja właśnie dumam nad urządzeniem. Zbawiennym okazało się 16 wejść ADC i 12 bitów. Właściwie z tego powodu go biorę i z powodu 100 nóżek, no może 2 sztuki SPI się przydadzą naraz.

Czy używasz do czegoś tego mechanizmu zdarzeń routowanych niezależnie między peryferiami?

I wracając do DMA. Czy dużp jest zachodu żeby zapuścić transfer ?

Jak wygląda sprawa WINAVR 2010 i tego procka ? Czy są jakieś gotowe funkcje pod niego?

Użytkownik "newxmega" snipped-for-privacy@mmm.mm napisał w wiadomości news:i0b0on$hma$ snipped-for-privacy@opal.futuro.pl...

Ja dopiero do przesiadki na ATXMEGA dojrzewam...

Ale właśnie dotarłem do

Data Memory and Bus Arbitration

As the Data Memory organized as four separate sets of memories, the different bus masters

(CPU, DMA Controller read and DMA Controller write) can access different memories at the

same time. As Figure 4-3 on page 24 shows, the CPU can access the External Memory while

the DMA (DMA) Controller is transferring data from Internal SRAM to I/O Memory.

Czyli wynika do tego, że dostęp do:

- wewnętrznej SRAM

- zewnętrznej SRAM

- I/O

- EEPROM

jest możliwy w tym samym czasie.

Nie wiem, ja to lubie sobie w assemblerze dłubać, do C się dopiero przymierzam. Co do zapuszczenia transferu, to kilka rejestrów wypełnić trzeba.

Użytkownik "newxmega" snipped-for-privacy@mmm.mm napisał w wiadomości news:i0bcqh$h40$ snipped-for-privacy@opal.futuro.pl...

No ja znam windziany C++ i C#, to i zwykłego C na AVR się nauczę :)

Ano tak, nawet głupie TWI którego obsługa wydaje się potem banalna, za pierwszym razem potrafi trochę czasu zjeść. Portowanie kodu z ATMEGI16/32 na