+- HomeMade (http://sp-hm.pl)
+-- Dział: Urządzenia nadawczo odbiorcze KF (/forum-62.html)
+--- Dział: Transceivery HomeMade (/forum-64.html)
+--- Wątek: Transceiver wg. M0NKA (/thread-1984.html)
Strony: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161
RE: Transceiver wg. M0NKA - SP9BSL - 08-10-2017 15:04
Artur, masz schemat tej płytki?
Trochę nie rozumiem wcześniejszego postu, jak myślisz co bardziej szumi 3 linie czy 18? Bo prędkości są podobne. A tak wogóle to mcHF od dawna tak pracuje jak tak zostanie ustawiony, zawsze można jednak włączyć tryb równoległy.
Przyciski są do przesunięcia bo sam tak robiłem, wszystko zależy od pcb.
RE: Transceiver wg. M0NKA - SP3OSJ - 08-10-2017 15:53
.....
RE: Transceiver wg. M0NKA - SP9BSL - 08-10-2017 22:29
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.
RE: Transceiver wg. M0NKA - SQ8MVY - 08-10-2017 23:34
Witam,
Sławku, tak zapytam. Wiesz kiedy H7 będą na rynku ? Zapowiedziane były na pierwszy kwartał tego roku. A do dzisiaj ich nie ma - sam czekam na nie z niecielrpliwością....
Co do SPI2 - został użyty pewnie dlatego, szyna szeregowa danych w tych LCD-kach katalogowo pracuje do 10 Mhz - więc pewnie autorzy doszli do wniosku, że nie ma potrzeby użyć szybszego SPI. Rzeczywistość jednak pokazuje coś innego - bo i przy SPI pędzonym na 42Mhz LCD pracuje dobrze.
RE: Transceiver wg. M0NKA - SP9BSL - 09-10-2017 7:31
Witaj Pawle,
nikt nic nie wie odnośnie H7. Mouser ma już nawet pozycje wprowadzone z cenami od jakiegoś czasu. St każe czekać. Są już dostępne startery do H7 z wyświetlaczem 640x480 (cena około 2kPLN np. tu). St na razie przeciąga z miesiąca na miesiąc. Na Q1 2018 są zapowiedziane inne procesory tej serii więc może razem to wprowadzą.
A co do SPI to chyba faktycznie nikt tego nie brał pod uwagę i tak po prostu zostało. SPI1 jest podpięty pod przycisk i enkoder więc trzeba by ciąć albo zrobić tak na nowej płytce. Andreas chce jednak główny nacisk położyć na interface równoległy - ze względu na prędkość.
Artur,
wygląda na to że będziemy mieć też obsługę RA8875 w UHSDR.
RE: Transceiver wg. M0NKA - SP4EBI - 10-10-2017 11:18
Witaj Sławku,
Widzę że w temacie lcd dużo się dzieje tak więc muszę poczekać.
Po mojej ostatniej próbie podłączeniia jednak tego lcd o króry Ciebie Sławku pytałem, musiałem chyba upalić w procku jakąś szynę danych bo teraz oryginalny display świeci tylko na biało i daje się ściemniać chociaż radio z tego co słyszę w głośniku pracuje normalnie. Nowy procek już w drodze. Hi hi
Pozdrawiam
Wojtek
RE: Transceiver wg. M0NKA - SP3OSJ - 10-10-2017 15:46
.....
RE: Transceiver wg. M0NKA - SP9BSL - 10-10-2017 17:17
Wojtek, to przykro, ale niestety zdarza się. Procesory od ST są dużo bardziej wrażliwe na ESD i inne głupoty niż np. Atmel/Microchip lub NXP. Taką widocznie mają technologię. Zdarzyło mi się ubić kilka F103 w mojej karierze.
Artur, ja się nad tym poważnie zastanawiam, ale jak skończę wprowadzać to co zacząłem i pojawią się H7. Mam możliwość sprawdzenia emisji tak jak pisałem. Też nie widziałem nic sensownego na RGB poniżej 5". Niektóre mają możliwość pracy (pomimo kontrolera) w trybie RGB.
RE: Transceiver wg. M0NKA - SP9KN - 10-10-2017 20:07
Pytanie trochę oderwane od tematu wyświetlaczy...
Właśnie skłądam (czekając oczywiście aż oficjalnie pokarzą się nowe płytki z DL-u) mcHF na płytkach w wersji 0.6...
Biorąc pod uwagę że skończę jak zawsze, czyli najpierw oficjalny soft, później przeróbka i DL-owy, czy na płytkę obsadzać procesor taki jak jest w oryginale (tj. STM32F407VGT6TR) czy wstawić inny w tej samej obudowie, biorąc oczywiście pod uwagę soft z DL-u.
RE: Transceiver wg. M0NKA - SP4EBI - 10-10-2017 20:12
Przemek,
Ten nowy procek będzie miał 144 kopyta, czyli do mchf-a nie będzie pasował.
73