Jak wygenerować sygnał strobe po każdym przesłaniu paczki przez DMA w XMega128A1?

Sun Jun 27, 2010 7:00 pm   

Mam do XMega128A1 podłączony wyświetlacz z interfejsem równoległym, do
obsługi którego chciałbym zaprząc DMA, jednak po ustawieniu danych na
wyjściu muszę puścić sygnał strobe. Myślałem żeby zrobić to w przerwaniu
DMA, ale jest ono generowane po przesłaniu bloku danych, a nie paczki
(burst). W sumie mógłbym przesyłać te dane właśnie blokami po 2 bajty
(16-bitowy interfejs do LCD) i w przerwaniu uruchamiać DMA dla kolejnych
2 bajtów, ale nie wiem czy to będzie szybsze od standardowego
przesyłania w pętli.
Choć z drugiej strony bufor obrazu mam w zewnętrznym SDRAM, DMA ma
24-bitowe adresy, a GCC tylko 16, więc tu pewnie byłby zysk.
W każdym razie moje pytanie brzmi - czy jest jakaś możliwość
wygenerowania sygnału strobe po każdej paczce (burst) przesłanej przez DMA?

Dariusz Żołna

Sun Jun 27, 2010 9:35 pm   

"Dariusz Zolna" <answer@usenet.com> wrote in message
news:i08744$88o$1@inews.gazeta.pl...

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?

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

Sun Jun 27, 2010 11:56 pm   

Użytkownik "newxmega" <mmm@mmm.mm> napisał w wiadomości
news:i08g5v$1g1$1@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.

Mon Jun 28, 2010 12:49 pm   

"Marcin Wasilewski" <jakis@adres.pewnie.je.st> wrote in message
news:i08ofd$o07$1@news.task.gda.pl...

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?

Mon Jun 28, 2010 2:27 pm   

Użytkownik "newxmega" <mmm@mmm.mm> napisał w wiadomości
news:i0a5nn$bhv$1@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
3-stopniwy pipelining procesor wie kilka taktów wcześniej, że będzie
potrzebny dostęp do pamięci, więc pewnie jakieś działania w tym kierunku
podejmuje. Kłopot może być w przypadku pętli i instrukcji wykonywanych
bezpośrednio po skoku, ale jak pisałem, jedyne co ci grozi to +1 cykl
oczekiwania na zwolnienie magistrali systemowej.

Mon Jun 28, 2010 6:10 pm   

"Marcin Wasilewski" <jakis@adres.pewnie.je.st> wrote in message
news:i0abgb$2gg$1@news.task.gda.pl...


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?

Mon Jun 28, 2010 7:35 pm   

Użytkownik "newxmega" <mmm@mmm.mm> napisał w wiadomości
news:i0aogk$sd1$1@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.

Mon Jun 28, 2010 8:30 pm   

"Marcin Wasilewski" <jakis@adres.pewnie.je.st> wrote in message
news:i0ath1$8af$1@news.task.gda.pl...

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?

Mon Jun 28, 2010 9:20 pm   

Użytkownik "newxmega" <mmm@mmm.mm> napisał w wiadomości
news:i0b0on$hma$1@opal.futuro.pl...


Ja dopiero do przesiadki na ATXMEGA dojrzewam...

Ale właśnie dotarłem do
http://www.atmel.com/dyn/resources/prod_documents/doc8077.pdf
i na stronie 23 i 24 jest opis, z którego jasno wynika, że jest bardzo
dobrze:

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.

Mon Jun 28, 2010 11:56 pm   

"Marcin Wasilewski" <jakis@adres.pewnie.je.st> wrote in message
news:i0b3md$bhq$1@news.task.gda.pl...


Ten eeprom to i tak ma małe znaczenie.
Fajnie, że procek umie wystawić adres w środku i na zewnątrz w pamieci
danych, równocześnie. Czyli przyspieszenie jest.chociaż jak DMA się przyśsie
do ramu, a procek będzie chciał wewnętrzny RAM -> LD, LDS, ST, STS to co się
stanie ?
Albo masz DMA pomiędzy dwoma SPI ale w środku siedzi szyfrowanie AES.
Strumień sanych niczego sobie. Można sie pokusić o drugi taki strumień tylko
z DES-em pośrodku. Co w takim razie sie stanie z przestrzenią I/O i z
rywalizacją o busa?
To są ciekawe zagadnienia Może ktoś to gdzieś już opisał. Trzeba
poszukać :-)


Ja od wielu lat tylko w ASM pisałem. W C mam dopiero 1 projekt ale następny
też będzie musiał być w C ze wzgledu na matematykę. Już się nie da pisać w
asmie tego co chcę teraz.

No i te PDF-y są jakby inaczej pisane niż tamte do zwykłych AVR-ów. tam
zwykle były przykłady od razu. Szukałeś np TWI i był przykład jak
zainicjować i jak wysłac. Tutaj rozdrobnili to na wiele plików.
Coś tam sobie skrobię na nim. Jak DMA nie ruszy od razu to później bedę
sukcesywnie przerabiał.

Tue Jun 29, 2010 5:39 am   

Użytkownik "newxmega" <mmm@mmm.mm> napisał w wiadomości
news:i0bcqh$h40$1@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
644P potrafi zaskoczyć jak się trafi np. na liczniki gdzie był jeden
rejestr, a teraz są dwa.