Transceiver wg. M0NKA

[SP9BSL]

Artur,
Więc tak, nie chcę bynajmniej wyjść na mądralę ale pare spraw muszę wyjaśnić.
Po pierwsze odświeżanie obrazu: wyświetlacze LCD odświeżają obraz 30-60 razy na sekundę ale raczej bliżej tej górnej wartości. Jeśli chcemy wysyłać dane do wyświetlacza w trybie RGB (czyli 16 bitów danych, Hsync, Vsync i pixelclock) to trzeba transportować w trybie 16 bitowym (a taki używamy w mcHF/UHSDR) 480*320*2*60 bajtów czyli pixeclock ma około 10MHz (o harmonicznych wspomniałeś). Takie rozwiązanie (kontroler TFT) jest obecne dla STM32f429 F746 F769 i w nowych H7. Przeliczyłem sobie po Twoim wpisie z przed kilku dni możliwość użycia procesora bez SDRAM i wychodzi że dało by się zmieścić w F769 i nowszym H7 całą ramkę dla wyświetlacza o rozdzielczości do 800x480 (!) w trybie tablicowym 8 bit. Procesory F4 oczywiście odpadają i muszą mieć SDRAM. Kontroler który jest umieszczony w tych procesorach zlikwidowałby całkowicie problemy wąskiego gardła dla wysyłania danych. Po prostu dla procesora (rdzenia) jest to niewidoczne, procesor "widzi" jedynie ram. Wada: duże ilości wyprowadzeń z ciągłym generowaniem prostokąta. Jedyne wyjście to bardzo bliskie umieszczenie procesora do złącza wyświetlacza.
Teraz trochę o transmisji SPI. Dane są wysyłane obecnie w mcHF na prędkości około 10MHz w sposób przypadkowy (tzn. w tedy gdy trzeba coś odświeżyć) bo całym wyświetlaniem obrazu zajmuje się kontroler wbudowany (w technologii chip on glass, czyli bardzo blisko panelu który zresztą jest zaekranowany śliczną blachą). Ja musiałem zwiększyć tą prędkość do 21 MHz (niestety tylko) bo na więcej nie pozwala magistrala APB1 na której wisi SPI2. Chris z niewiadomych powodów nie użył SPI1 który jest 2 razy szybszy czyli może chodzić 42MHz.
Teraz o obciążeniu procesora. Nie ma czegoś takiego, nawet lepiej: procesor się w tym czasie nudzi bo musi czekać na zakończenie pracy DMA(direct memory access controller) które steruje wolnym SPI. Dla procesora jest to obszar pamięci który najpierw zapisuje danymi a następnie DMA odczytuje tą pamięć i wstawia do rejestru wyjściowego SPI. Dla mojej wersji SPI pracuje z prędkością 21 MHz, dane są 16 bitowe więc wysłanie 1 linii 480 punktów (np. dla wodospadu bo widmo chodzi inaczej) zajmuje ~360us to kupa czasu dla procesora którego cykl rozkazowy zajmuje około 6-12 ns. W czasie wysyłania danych procesor głównie czeka na SPI w między czasie przygotowując następna część do wysłania w innym obszarze ram. Oczywiście jeszcze nad tym pracują przerwania, inne peryferia itd...
Jak widzisz na moim filmie raczej nic się nie tnie. Kwestia strategii wewnątrz.
Jeśli będzie z kolei używany interface równoległy do kontrolera LCD to transfer przyspieszy kilkukrotnie, z tym że jeśli chodzi o przygotowanie danych dla DMA to nic się nie zmieni w stosunku do trybu szeregowego. Pobór prądu można pominąć bo podświetlanie bierze 3x więcej. Jak będę miał chwilę to porównam w komorze TEM lub lepiej GTEM emisję tego wyświetlacza.

A teraz płytka: widzę że użyłeś schematu z wątku Andreasa bez żadnych zmian. Pytanie czy warto bo i tak w ciągu miesiąca chłopaki z dl'u będą mieli płytki poprawione (czyli schemat się prawdopodobnie lekko zmieni) a dla mnie opłacalność przedsięwzięcia jest taka sobie. W mojej płytkarni (tej której używam do prototypów) cena z kosztami przygotowania produkcji wyniesie około 100 PLN za 2 płytki z przesyłką, czyli podejrzewam że podobnie jak u Andreasa. Ja mam obiecane próbki inżynierskie H7 od przedstawiciela ST więc jak będą to głownie je tam wsadzę bo obecnie nie ma sensu przechodzić na f7 (mam zresztą kilka sztuk).

Mam nadzieję że się nie obrazisz tym postem. Siedzę w wyświetlaniu obrazu i kontrolerach od lad 90-tych i zęby zjadłem na ich budowie (FPGA, blackfin) a potem używaniu kostek seiko-epson i podobnych. W STMach siedzę praktycznie od pojawienia się rdzenia cortex-M3 jakieś 10 lat temu.