Marek_Skalski napisał: tmf napisał: Lutowanie BGA (a stosowne ARMy chyba tylko w takich są obudowach)
Dementuję takie pogłoski. Przykładowa płytka STM32F429-DISCO. Ma prawdopodobnie wszystko co potrzebuje autor tego tematu, kosztuje śmieszne pieniądze. Na pokładzie 64Mbit SDRAM, więc wystarczy na wiele ekranów. Alpha blending + overlay (obraz statyczny + dynamiczny) robi sprzętowo. Sercem jest układ, który można kupić w każdym dobrym sklepie STM32F429ZI w obudowie TQFP144; żaden cud. Jest też w wersji QFP100, QFP176 i QFP208. Xmega z interfejsem EBI też jest w obudowie QFP100. Więc nie ma tutaj wielkiej różnicy.
W Q3 (lub Q4) będą dostępne układy z interfejsem MPI DSI; jeszcze szybsze przesyłanie obrazu na wyświetlacze montowane typowo w smartfonach i odtwarzaczach mm.
Marku, nie zapędziłeś się trochę? Piszemy o projekcie na ATMega128 w którym wg autora (co zresztą okazało się nieprawdą) zabrakło ciut mocy. Doszliśmy już do QFP208, 64 bitowej pamięci SDRAM... to ja przebijam ofertę - RaspberryPi w wersji z 1 GB DDR i quad-core ARM.
Czy chcesz mnie przekonać, że ARM może szybciej? Szkoda twojego wysiłku - doskonale to wiem. Czy jest potrzebny w takich projektach - IMHO nie. Jeśli ktoś siedzi w ARM to robi taki projekt na ARM, jeśli ktoś do tej pory siedział w AVR to nie ma najmniejszej potrzeby przesiadki.
Marek_Skalski napisał: Co do RAMu, to żadna Xmega nie ma na pokładzie 256kB RAM. Argument chybiony.
Marku, mam wrażenie, że nie miałeś czasu przeczytać tego co napisałem. Nigdzie nie twierdziłem, że AVR ma >32 kB RAM (wystarczy spojrzeć do product selector na stronie Atmela). Pisałem, że jeśli wykorzystamy ARMa do bezpośredniego sterowania matrycą TFT to musimy zapewnić przynajmniej 230 kB RAM na bufor ramki, a tak napradę 2xtyle ze względu na double buffering. Czyli może prościej jest jednak wykorzystać dedykowany kontroler w cenie <1$ za sztukę mający wszystko (np. RA8875).
Marek_Skalski napisał: Co do FT801, to niestety, ale autor tego tematu napisał, że szybkość ma znaczenie. Jeżeli FT801 nadaje się do tego zadania, to Mega128 też podoła. Transmisja po SPI i grafika to pojęcia wzajemnie sprzeczne. A użycie kanału alpha w takim przypadku, to już tylko żart.
Tu się z tobą nie zgodzę. Pominę, że okazało się, że jednak szybkość nawet SPI i klasycznego LCD jednak wystarczy. Ale wróćmy do FT801. To nie jest kontroler typu framebuffer, do którego musisz ładować gotowe dane do VRAM, co wymaga sporego pasma. To akcelerator, który robi wszystko sprzętowo - a więc po SPI ładujesz polecenia. Np. wyświetlenie tekstu z antyaliasingiem, alfablendingiem, obróconego o zadany kąt to wysłanie polecenia określającego atrybuty (parę bajtów) + kodów ASCII znaków do wyświetlenia. Wyświetlenie obrazka to konieczność preloadowania danych graficznych, np. kilku kB JPEG + polecenie wyświetlenia tego w zadanym miejscu. Mogę się założyć, że wydajność tych operacji po SPI dla FT801 będzie wyższa niż dla wymienionych ARMów z wbudowanym kontrolerem. Ale jeśli to ciągle mało to weź FT813, który ma interfejs QSPI + sprzętowe dekodowanie video. Tu próbka możliwości (sterowany z 8 bitowego MCU):
Marek_Skalski napisał: Co do płytek... większość płytek do Cortex'ów jest robiona jako 2 warstwowe: ST, NXP, WaveShare. Jeżeli są 4 warstwy, to na ogół ze względu na obudowy BGA lub czasami ograniczenia powierzchniowe. I żadnych cudów tu nie ma. Poza tym, płytka 4 czy 6 warstw, to dzisiaj rzecz łatwo dostępna. 4x droższa niż 2 warstwy, ale dostępna.
Marku, koszt zrobienia płytki 2-warstwowej w firmie to 40-100 zł, do tego mamy darmowy soft do wyboru do koloru. Koszt płytki 4-warstwowej to 400-500 zł, a jeśli chodzi o możliwość jej zaprojektowania softem za free to jest problem. Czyli mamy kilkaset $ na soft jako bonus. Wiem, że się profesjonalnie zajmujesz elektroniką i po prostu masz dostęp do sprzętu, firm i co ważne - potrafisz takie płytki zaprojektować. Ale dla amatora wydanie np. 400 zł na płytkę, z dużą szansą, że jest błędnie zaprojektowana i trzeba ją zrobić ponownie to już nie takie łatwe do przełknięcia jest.
I nie uwierzę, że zrobisz na 2 warstwach LQFP144 z 64-bitowym SDRAM + złącze do matrycy LCD. Taki ze mnie niewierny Tomasz, że żeby uwierzyć muszę zobaczyć.
Marek_Skalski napisał: Prędkość magistrali: W Xmega dane są wypluwane jako 8-bitów... trzeba je składać używając zatrzasków, albo 3x write dla każdego piksela, albo programowe przestawianie bajtów. Tutaj jest pierwsze wąskie gardło.
Drugie, to DMA w Xmega, które kradnie cykle CPU. Dlatego te 25-50% przepustowości ma znaczenie. Dla mnie to nie ma znaczenia ponieważ DMA ma swój mostek na magistrali i dane pobiera nie blokując rdzenia.
A ogólnie, aby coś wyświetlić, to trzeba wcześniej przygotować dane i tutaj Xmega ze swoim powolnym, 8 bitowym rdzeniem, który nie potrafi przesunąć więcej niż 1 bit w operacji, niestety ginie. Proponuję poszukać wyników CoreMark dla Xmega i porównać je z wynikami Cortex-M. Nawet z tymi M0

Marku, nie przekonuj mnie, że ARM jest szybszy niż AVR. Nigdzie nie sugerowałem czegoś innego. Być może źle mnie zrozumiałeś. Chodziło mi o to, że jeśli to ARM ma generować sygnały dla matrycy LCD to musimy zapewnić pamięć na bufor. Musi to być pamięć zewnętrzna, bo wewnętrznej ARMy o których piszemy po prostu nie mają tyle ile potrzeba. Czyli komplikacja układu. Druga sprawa - DMA. OK, masz oddzielną magistralę, ale w takiej sytuacji tą pamięć dedykujesz tylko pod bufor ramki LCD. Niemniej procesor zajmuje się przetwarzaniem danych w tej pamięci więc też konkuruje z DMA. Nie jest to żaden problem oczywiście, lecz już wymusza taktowanie pamięci na jakimś tam poziomie. Do tego jeśli korzystamy z SDRAM to ze względu na budowę pamięci, przełączanie banków itd. taktowanie musi byc szybkie, bo w pojedynczych przypadkach dostęp do pamięci może trwać nawet kilkanaście taktów zegara - szybki jest tylko dostęp sekwencyjny burst. Czyli 40 MHz i LCD może okazać się niekompatybilne z SDRAM.
Marek_Skalski napisał: Dlaczego 32 linie danych jak Xmega obsługuje tylko 8? Linii adresowych też tyle nie trzeba. Wystarczy użyć SDRAM. Przecież dane do wyświetlania i tak lecą synchronicznie.
W moim przypadku potrzebuję 10 kondensatorów 100nF(0603) + 2x V_CAP (1411).
Nie jest to trudne, ponieważ ścieżki mogę mieć na 5mils'ów.
Dlatego 32 linie danych bo pisałem o ARM, nie o AVR. IMHO i tu się ze mną pewnie zgodzisz, kompletnie nie miałoby sensu budowanie układu kontrolera LCD na AVR z zewnętrzną pamięcią - chociażby dlatego, że AVR nie podołałby temu zadaniu, lub byłoby to na granicy możliwości tego procka.
BTW, 5 milsów to już lepsze firmy płytkarskie tylko oferują.
Dodano po 2 [minuty]: mikmas napisał: Czyli jeżeli sterując po SPI zejdę poniżej 1/4s, to przy 16b szynie będę mógł się spodziewać naprawdę dobrych osiągów?
Przepustowość będzie większa, ale... Komunikacja z LCD to nie tylko transmisja bloków danych - trzeba je jeszcze przetworzyć. Dla przykłądu - dla XMEGA taktowanej 32 MHz, z SPI na 16 MHz, masz bajt wysyłany co 16 taktów. Czyli w 16 taktach musisz przygotować kolejny bajt i go wysłać do SPI. W przypadku interfejsu równoległego kolejny bajt (lub dwa) możesz wysyłać częściej - powiedzmy, że jeśli programowo manglujesz liniami sterującymi interfejsu to na ich wysłanie potrzebujesz 4-5 taktów. Niby nawet 4-krotnie szybciej niż po SPI, ale jednak kolejne bajty też trzeba przygotować i już to wszystko tak pięknie nie wygląda.