Witam

Szukam rozwiązania jak w temacie. Mam wyświetlacz który działa po SPI. niestety przy wykonaniu jakiej kolwiek operacji na nim otrzymuję efekt "wlewania" zmian na ekran. Narazie pracuję na procku z 8MHz zegarem planuję przyśpieszyć do 12-16Mhz na zewnętrznym kwarcu. i tu pytanie

1) znam noty katalogowe dla procesorów atmega ale czy ktoś przyśpieszał te procki powyżej podanych częstotliwości w nocie? Jeżeli tak to jakie i na ile dało się je podkręcic? czy potrzebne było jakieś chłodzenie czy co kolwiek?

2) inicjalizuję moje SPI tak

czy mogę jeszcze coś ustawić aby zwiększyć SCK? teoretycznie ten wiświetlacz może działać przy SCK 25Mhz.

3) zanim zabiorę się za napisanie biblioteki dla komunikacji równoległej po D[0-17] chciał bym się upewnić że taka komunikacja jest szybsza niż SPI. Czy może się ktoś wypowiedzieć?

Przy zewnętrznym generatorze nawet przy 40 MHz nie zauważyłem problemów.
Obecnie odpaliłem przy taktowaniu 33MHz UART i bez problemu działa 115200. RX i TX

Jest kilka ciekawych graficznych projektów z użyciem AVR na forum. Ale rewelacji się po 8bitowym nie spodziewaj, to nie tylko kwestia prędkości SPI, ale i konieczności przerzucania sporej ilości danych.
Np. taki 429i STMa ma już podwójne buforowanie, wsparcie dla przeźroczystości itp. Można w sumie prostą implementacją biblioteki zrobić ikonki jak na win7 z obsługą dotykową.

Na AVRku jest nawet "palmtop" na forum, oraz Mirek w zielonej pokazuje pazura, ale mimo wszystko przewalanie nawet 32kb obrazka to dla AVRka trochę tytaniczna praca.

No 8 bitów to 8 bitów....
Ale ja tak sobie wspominam jak to było kiedyś. W latach 80-tych. Komputery typu Atari 800XL czy 65/130XE. Procesor 6502, taktowany 1,77 MHz
16 KB ROM. A ile rzeczy działało.
W porównaniu z tym to AVRki to są demony prędkości.

Akurat układ z tym generatorem 33 MHz działa u mnie już ponad poł roku.
Jest w nim tak:
1. LCD HD44780
2. 3 PWMy
3. Timer1 i jego ICP obsługujący podczerwień.
4. Przerwanie od Timera2 jako podstawa czasu
5. I teraz dodatkowo UART.

MCU to ATmega328.

Moja Atmega 32 bezproblemowo współpracowała z kwarcem 24,576MHz, SPI działało jak powinno, nie zauważyłem żadnych problemów

Wysłane z mojego Nexusa 5 przy użyciu Tapatalka

_________________
sig off ;(

Dziękuję za wypowiedzi

@mokrowski - tak chodziło mi o porównanie prędkości tych 2 sposobów transmisji danych a nie zwiększenia mocy obliczeniowej, bo nawet przy 8Mhz procek się nudzi w moim programie.
Co do wyświetlacza to sterownik ili9325c 240x320TFT

Czy są jakieś wersje procesorów z rodziny atmega które nie mają dzielnika częstotliwości dla SPI w stosunku do częstotliwości procesora? to /2 boli najbardziej.

Nie ma takiego procka. Z AVR to jedynie Xmega jest szybsza, bo domyślnie pędzi na 32 MHz, a pętla PLL pozwala jeszcze bardziej przyspieszać

Wysłane z mojego Nexusa 5 przy użyciu Tapatalka

_________________
sig off ;(

zastanawiam się troszkę w kwesti tych wyliczeń. otóż.

mam wyświetlacz 320*240 co daje mi 76800 pikseli.

tak wygląda funkcja kasowania lcd.


a zatem poza stratą kilku taktów zegara na ustawienie lini CS, konwersje 16 bit na 2x8 bit i wyslanie komend sterujących, mamy praktycznie pentlę w której cały czas wysyłamy do SPI to samo.
i teraz tak ..
76800 pikseli * 16 bit = 1,228,800 bitów. czyli 1/10 ilości jaką mogę wysłać w 1 sek przy taktowaniu 25MHz (ja wsadziłęm kwarc 32Mhz). Z tego wynikało by że mogę mieć frame rate 10 klatek na sek. Ale tu ciekawostka
przy wykożystaniu wskazanej funkcji oraz (dla całkowitej jasności) funkcji

w rzeczywistości uzyskuję ok 1,5 sek na zapełnienie ekranu!!! to jest 15 razy wolniej niż byśmy oczekiwali na podstawie teoretycznych wyliczeń. gdzie tak mocno zatykamy transmisję???

Tylko bierz uwagę, że to było przy rozdzielczości 320x240 przy 16kolorach bez przenikania, podwójnego buforowania, a spritów mogło być tylko 8 .

Wywołanie funkcji i powrót sporo taktów pożera. Najlepiej widać to w pliku lss z folderu Release (dodatkowo należy w specyfikacji procesora znaleźć tabelkę Instruction set summary). Wywołanie funkcji to instrukcja asemblerowa call - 5 cykli, a powrót to ret - 5 cykli. Możesz spróbować tak:

To coś da, ale pozostaje ten nieszczęsny for ze zmienną index o rozmiarze 32 bity. Procesor 8-bitowy wrzuci sobie tą zmienną do 4 rejestrów i porównanie ze stałą 32-bitową zajmie pewnie 4 cykle i inkrementacja też 4. Szybciej pewnie będzie jakbyś wysyłał po 2 piksele i miał 2 fory i w każdym zmienną 8-bitową np.:


PS. do wstawiania kodu w C używa się samego syntax=C, a do kodu z pliku lss możesz sobie użyć Code

_________________
Dragonus Cracovus: Biomagia

Atmega8 bez problemu chodzi na 20MHz.

_________________
Pomysły na podpis - wyślij SMSa +1 769 243 0011

Dlatego zaproponowałem wysyłać dane o 2 pikselach, a wartość do porównania to MAX_X / 2. Nawet inkrementacja/dekrementacja 16-bitowej zmiennej to nie 2 operacje. Zmiana młodszego bajtu może wymagać zmiany starszego, a więc dochodzi to dodatkowe sprawdzenie.

_________________
Dragonus Cracovus: Biomagia