Preliminary datasheet do XMega - prawdziwy killer

T.M.F. napisał(a):

A co tu pisać? Wejść wysokiej impedancji wolnych zostawiac nie wolno - oczywista oczywistość. Linie icp pracują podobnie jak w i2c - muszą być podciągnięte do właściwego poziomu, bo może być problem z detekcją poziomów.

Zostawienie linii wolnych jest "złą praktyką", za to zostawienie wejść wolnych - poważnym błędem. Powinieneś deklarowac je wtedy jako WYJŚCIA.

Piotr "PitLab" Laskowski napisał(a):

Powinieneś mieć 99.7% conajmniej. Coś tam jest nie jak trzeba.

No nie, to taki moj pomysl. Ale patrzac na datasheet do XMegi powinien zadzialac. Puszczasz jeden kanal DMA w kolko w trybie czytania/zapisu do pamieci ( chodzi o wykorzystanie strobu zapisu jako zegara do taktowania zatrzaskow w LCD), tak, zeby po zakonczeniu transakcji (czyli przeslaniu calej ramki) generowal przerwanie w ktorym robisz programowo sygnal FRM. DMA odczytuje pamiec i wysyla gdzies pod adres XRAM, XMega ma 16MB zewnetrznej pamieci, czyli najstarczy bit adresu (niesadze, zebym potrzebowal wiecej niz 8MB do swoich celow) razem ze strobem zapisu WR moga posluzyc do generowania strobu dla latcha w LCD. W ten sposob mam juz zalatwiony automatyczny transfer linii. Teraz moge reszte robic na przerwaniu, nie jest juz tak zle, bo procesor tylko raz na linie bedzie zaangazowany w generowanie sygnalu przejscia do kolejnej linii. Ew. dodac licznik popedzany zegarem dla latcha ktory mi ten sygnal wygeneruje automatycznie. Nie mam rozpiski pinow do XMegi ale niewykluczone, ze bedzie mozna w tym celu wykorzystac ktorys z timerow w trybie pobierania zegara z pinu. Taki timer po zliczeniu zaprogramowanej ilosci impulsow (czyli bajtow na linie) wygeneruje sam sygnal przejscia do nowej linii. Problem sie pojawia w przypadku kolorowych LCD majacych wejscia po 24 bity na raz. Wykorzystanie 3 DMA nie wchodzi w gre, bo nie da sie ich zsynchronizowac w zaden sposob (chyba). Wiec pozostaje rozwiazanie typu 3x8-bitowy latch wybierany z multipleksera podlaczonego do bitow A0-A2 adresu pamieci. Ale to juz zakrawa na jakies male CPLD za pare zlotych :) Co i tak w sumie moze byc korzystne, bo nie wiem jak w tym procku bedzie wygladalo podlaczenie XRAM, ale jesli tak jak w ATMega128 to i tak potrzebujesz 1 zatrzask. To w sumie mozna jakies male CPLD wlozyc. Co o tym myslisz?

Piotr "PitLab" Laskowski napisał(a):

Akurat w tych procesorach nie wiem. PIC-e maja różne konstrukcje oscylatorów. Niektóre sa całkowicie zadowalająco stabilne i dokładne (np 16f6xx) ale zazwyczaj nie sa ani stabilne ani dokładne. W transmisja asynchronicznej trzeba robić króciutką pauzę między bajtami i to załatwia sprawę - błąd 2-3% nie czyni różnicy. Natomiast nie spotkałem się NIGDY z problemem programowania układów

To żadna mecyja.

chcesz dawac 8 MB SRAM ? masz takie kosci w sensownej cenie?

Powitanko,

Tak podejrzewalem, ze firma na mnie oszczedza;-)

Zasilalem, 2 procki pod rzad mialy ten sam objaw. Wniosek: Nie tu jest przyczyna.

Scalak programuje sie OK, verify OK, ino w czasie pracy sie wywala. Mozna go potem przeflashowac jeszcze raz, ale efekt w trakcie pracy bedzie ten sam. Inny w dokladnie tych samych warunkach dziala OK. Nie wiem jak jest w PICach, ale zwykly EEPROM (taki 24xx) - trzeba zachowac odpowiednie czasy (i to spore) po zapisie kazdego bajtu, inaczej bedzie (albo nie ) losowa kaszana.

Wydluzenie czasu produkcji to moja czysta i wymierna strata.

Pozdroofka, Pawel Chorzempa

Oj nie, napisalem, ze nie niesadze, zebym potrzebowal wiecej. Czyli jak dla mnie 512kB jest ok:) Po prostu chodzi o to, zeby wykorzystac najstarszy bit adresu do generowania strobu, bez pelnego dekodowania wszystkich linii, co zaweza ilosc uzytecznych zadresow dla pamieci z 16 do 8 MB.

Szkoda zapalarki ;-) Wiadomo co sie stanie...