Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Szybki procek - sterowanie monitorem

Procek32 17 Jun 2007 22:55 3863 19
  • #1
    Procek32
    Level 2  
    Witam!

    Piszę "kartę graficzną" do mojego projektu, i nie wiem jaki procek wybrać.
    Najpierw zastosowałem AT91SAM7S64(na nim opiera sie projekt), przy kwarcu 12MHz niestety sie nie wyrabia, po zmianie na 48MHz nie ma prawie różnicy :| (np. stan diody zmienia się ok. 0,5s szybciej - nie wiem czemu taka mała różnica)
    Postanowiłem spróbować na:
    ATMega8 16MHz - też lichocina
    AT81C2051 24MHz - jeszcze gorzej niż avrek.

    Podpatrzyłem kartę graficzną od komputera to tam jest kwarc ok 14MHz.

    Steruje monitorem w trybie 640x400,
    Odświeżanie pionowe to ok 70Hz
    Odświeżanie poziome to ok 30KHz.
    Problem jest z wyświetleniem pixeli - najkrótszy "pixel" miał chyba ze 5 pixeli szerokości.

    Co teraz robić? Pomocy :!:
  • Helpful post
    #2
    yego666
    Level 33  
    Przy takich czestotliwosciach jakie podales masz 52 nanosekundy na wyswietlenie jednego piksela.
    Sa procki, ktore sobie radza z takimi predkosciami, ale AVRki nawet nie moga o tym marzyc bez dodatkowego sprzetowego wspomagania.

    Zastanow sie choc troszke czy przy czestotliwosci procka 12MHz jestes w stanie otrzymac czas porownywalny z 52 nanosekundami.

    Pocwicz najpierw proste rachunki ( chyba na poziomie klasy 5 szkoly powszechnej ) a dopiero potem zabieraj sie za takie ambitne projekty.

    W przeciwnym wypadku polegniesz juz na starcie.

    Karty graficzne posiadaja zwykle specjalizowane uklady wyswietlania i nie zawracaja procesorowi glowy wyswietlaniem pojedynczych pixeli.

    Jesli chcesz cos takiego uskutecznic to zainteresuj sie ukladami FPGA lub specjalizowanymi ukladami graficznymi.

    Byl gdzies na forum projekt sterowania ekranu LCD 320x240 za pomoca jakiejs ATMEGi ale to sie ledwie wyrabialo i na nic innego juz czasu nie bylo.
    Nawet pobieranie danych i instrukcji od systemu nadrzednego robione bylo jedynie podczas wygaszania pionowego z powodu niewydolnosci procesora wyswietlajacego.
    Zreszta problem i projekt byl bardziej zlozony i autor bardzo sie nad tym napracowal by w ogole dzialalo.
    Chwala mu za to bo musial posiadac ogromna wiedze i samozaparcie by taki projekt uskutecznic.
  • Helpful post
    #3
    szelus
    Level 34  
    Witam,

    Procek32 wrote:
    Witam!

    Piszę "kartę graficzną" do mojego projektu, i nie wiem jaki procek wybrać.
    Najpierw zastosowałem AT91SAM7S64(na nim opiera sie projekt), przy kwarcu 12MHz niestety sie nie wyrabia, po zmianie na 48MHz nie ma prawie różnicy :| (np. stan diody zmienia się ok. 0,5s szybciej - nie wiem czemu taka mała różnica)

    [...]

    Steruje monitorem w trybie 640x400,
    Odświeżanie pionowe to ok 70Hz
    Odświeżanie poziome to ok 30KHz.


    Z Atmelowymi ARM-ami nie mam doświadczenia, ale z szybkiego oglądu specyfikacji wygląda, że AT91SAM7S64 ma szansę się wyrobić, zwłaszcza przy zegarze 48MHz - oczywiście zakładając tryb monochromatyczny, bez półtonów.

    30kHz odchylania poziomego i 640 punktów widocznych w linii daje "dot clock" 24Mhz: 30KHz * 800. 800 punktów łącznie z wygaszaniem powinno pozwolić na 640 punktów widocznych. Przy wykorzystaniu SPI albo SSC do wyprowadzania pojedynczych pikseli potrzebujesz realizować odczyt + zapis raz na 16, ewentualnie 8 pikseli. Przy starannym pisaniu w asemblerze powinno się udać.

    Czy to ma być tryb graficzny, czy tekstowy? Na tryb graficzny masz trochę mało RAMu, dwa razy za mało. W trybie tekstowym potrzeba będzie gdzieś upchnąć jeszcze przejście: pamięć obrazu -> generator znaków -> zawartość pikseli.

    Niestety, jeżeli nie uda Ci się dojść, dlaczego prawie nie ma różnicy przy różnych kwarcach, to czarno to widzę...
  • Helpful post
    #4
    adamusx
    Level 27  
    Procek32 wrote:
    ...przy kwarcu 12MHz niestety sie nie wyrabia, po zmianie na 48MHz nie ma prawie różnicy :| (np. stan diody zmienia się ok. 0,5s szybciej - nie wiem czemu taka mała różnica)


    Kolega jakieś dziwne rzeczy z tym SAMem robi:) Rozumiem, ze na poczatku był kwarc 12Mhz,a potem co , kwarc 48Mhz??? Czy chodziło o wewnetrzna predkosc zegara ustawiona na 48Mhz? W dokumentacji pisze ze maksymalny kwarc dla SAMa to 20Mhz,a maks predkosc zegara 48 Mhz( czestotliwosc zegara otrzymuje sie przez zmiane mnoznika/dzielnika petli PLL). Z doswiadczenia moge powiedziec ze mozna SAMA puscic nawet na 98Mhz i też działa:)
    Czy kolega wziął pod uwagę to, że program wykonywany z Flasha tego mikrokontloera jest zawsze wolniejszy? Flash chodzi tam z prędkościa 30Mhz,więc są wprowadzane opoznienia przy jego odczycie. Dlatego warto kod który ma być wykonywany z maksymalna predkościa przenieśc do RAMu (atrybut funkcji RAMFUNC)

    Poza tym wszystko zalezy też od kodu, od jego optymalizacji itp.
  • #5
    volender
    Level 12  
    Może chodzi o prędkości portów i podwyższając zegar doszedłeś do maksymalnej prędkości z jaką pracują porty. Wewnątrz uC możesz mieć 48 mhz ale na zewnątrz wyślesz tylko to z czym sobie poradzą porty...
  • Helpful post
    #6
    GienekS
    Level 32  
    Może czas na AVR32 bit ? Nosi miano MCU/DSP
  • Helpful post
    #7
    TWl
    Level 21  
    Procek32 wrote:
    Witam!

    Piszę "kartę graficzną" do mojego projektu, i nie wiem jaki procek wybrać.
    Najpierw zastosowałem AT91SAM7S64
    Co teraz robić? Pomocy :!:


    Czy karta ma byc kolorowa czy czarnobiala (1-bitowa)? Jesli czarno-biala to da sie wykorzystac SSC do generowania sygnalu VGA bez obciazania proca. Moge Ci dac przykladowy kod.
  • Helpful post
    #8
    shg
    Level 35  
    Może i wsadził kwarc 48MHz. Jak to był taki zwykły, to znaczy że 48MHz to on ma na overtonie, pewnie na trzecim, czyli w oscylatorze uC kwarc wzbudził się na częstotliwości podstawowej - 48/3 = 16MHz

    Ja też czarno widzę ten projekt (a właściwie wykonanie), żeby najpierw próbować na szybkim procu, a potem sukcesywnie brać coraz wolniejsze myśląc że będą... szybsze :/

    Co zaś do wykonania tego na uC - na ARMie przy pomocy SSC, na AVR przy pomocy SPI.
    Na ARMie lepiej, bo dane do SSC można przesyłać kanałem DMA, ale to tylko w wypadku gdy w pamięci znajdzie się gotowy obraz. Przy rozdzielczości VGA trzeba 38400 bajtów RAMu (bez podwójnego buforowania).
    Na AVR niestety bez DMA, czyli procesor będzie ostro "mielił".
    O '51 należy w tym wypadku zapomnieć, przynajmniej jeżeli chodzi o procesory ze standardowym jądrem.

    Można by też wykorzystać kartę graficzną na ISA, albo sam GPU (o ile w dzisiejszych czasach można to tak nazwać) przelutować na nową płytkę, ale to zazwyczaj spory "klocek" jest, a i sam działać nie będzie, DRAMu mu trzeba i jeszcze paru elementów.
  • #9
    Procek32
    Level 2  
    Z ARMami bawię się od kilku dni...
    Napisałem coś tam w asm i prawie mi śmiga. Planowałem zrobić kolorowe, lecz czarnobiałe też mnie zadowoli :D
    Bardzo proszę o ten przykładowy kod :)
    Może jednak coś z tego mi wyjdzie...

    //dopisane..
    Jak "dodać" funkcje do ramu?
    Dopisałem przed funkcją __ramfunc i już myślałem że jest ok. a teraz zauważyłem że nie jest całkowicie zdefiniowana:
    #define __ramfunc
  • #10
    volender
    Level 12  
    Ja też jestem zainteresowany, zwłaszcza wykorzystaniem SPI w AVRach. Macie może jakiś kod dla przykładu?

    Oczywiście będzie trzeba dodać mu ramu, ale to nie jest wielki kłopot.
  • Helpful post
    #11
    adamusx
    Level 27  
    Code:
    #define RAMFUNC __attribute__ ((long_call, section (".fastrun")))

    a potem np:

    Code:
    RAMFUNC void wyslij(int costam);
  • #13
    gufiak
    Level 21  
    Wiele zależy od tego jakich portów używasz do wysyłania danych (pixeli). Najszybsze są porty PA0-PA3, według specyfikacji pójdą do 30MHz, co powinno wystarczyć. Porty PA17-PA20 są najwolniejsze i radzą sobie do 12.5MHz. Reszta portów pójdzie do 25MHz. Są to dane ze specyfikacji, nie miałem okazji sprawdzać, a sądząc po erracie, może być z tym różnie. A poza tym ważne jest sterowanie bezpośrednie poprzez PIO_ODSR, przy czym najpierw trzeba zrobić wpis do PIO_OWSR. I to co wcześniej było wspomniane, funkcja wysyłająca musi działać w pamięci RAM.
  • #15
    sadamb
    Level 21  
    Mam pytanko do adamusx. Powyzej 60MHz SAM64 mi nie poszedl a z mila checia sprobowalbym te 98 MHz. Takze nie wiem czy akurat na SAM64 wiecej nie idzie czy cosik ja zle robie. Moglbym liczyc na fragmencik kodu z ustawieniami.
    Pozdrawiam.
  • #16
    adamusx
    Level 27  
    Witam.
    W konfiguracji petli PLL, zamiast koncowego dzielnika /2 ustawilem podzial /1 i w rezultacie zamiast 48Mhz otrzymalem 96Mhz z tym ze jest to predkosc zegara procesora.
    W pliku Cstartup:
    Code:
    / 4. Selection of Master Clock and Processor Clock
    
     // select the PLL clock divided by 2
    pPMC->PMC_MCKR =  AT91C_PMC_PRES_CLK_2 ;
    zmienilem na
    pPMC->PMC_MCKR =  AT91C_PMC_PRES_CLK ;



    Wazne jest by opoznienie odczytu/zapisu pamieci bylo ustawione na wartośc 2/3 ( AT91C_MC_FWS_1FWS ((unsigned int) 0x1 << 8) // (MC) 2 cycles for Read, 3 for Write operations ) lub wiecej. Jesli nie chce Ci rudszyc mozesz sprobowac ustawic na AT91C_MC_FWS_2FWS, z tym ze bedzie znacznie wolniej pracowal z FLASHEM.

    Nie wiem jak zachwuja sie wszystkie peryferia przy czestotliwosci 96Mhz, ale sterowanie pinami i timer PIT działał:)
  • #17
    sadamb
    Level 21  
    OK dzieki. Calkiem olalem te FWS-y. Maks zegara na procku gdzie timer TC1 chodzil to:
    - 120 MHz na FWS1
    - 144 MHz na FWS2
    wiecej juz nie poszlo. Z odzytem z FLASH-a max 60 MHz i wiecej nie chce.
  • #19
    kubiaczek1982
    Level 12  
    Czy może mógłby ktoś napisać tak dość łopatologicznie jak sie steruje monitorem??
  • #20
    misiaty1985
    Level 16  
    Trochę czasu minęło. Pochwali się ktoś wynikami?