Wyświetlacz z paneli LED

[marek1707]

Rany, Elvis, nie przesadzaj. Przecież nie zależy mi żeby wytykać Cię palcami tylko żebyś zwrócił uwagę na pewne szczegóły. Ani też na promocji siebie - jak możesz pisać takie głupoty? Jestem zaskoczony, to fakt, bo znając Twoje doświadczenie nie powinieneś mieć kłopotu z tak podstawowymi rzeczami jak dopasowanie impedancji, terminacje itp. To podstawy techniki cyfrowej, tak jak brameczki, przerzutniki, czasy propagacji czy blokowanie zasilania. No ale OK, rzeczy dla mnie oczywiste mogą być dla Ciebie nowością i vice versa - tu nie mam wątpliwości.

Zegar w stosunku do danych jest kluczowy - bez tego nie prześlesz żadnego bitu/pixela dobrze. Bo albo coś będzie smużyć, albo niektóre kombinacje będą "zakazane" a przy innych kolory będą losowe i/lub zmieniające się w zależności od częstotliwości lub temperatury lub zasilania. Przecież to właśnie naruszenie czasów ustalania/przetrzymywania może być pierwszą przyczyną kłopotów. Elvis, czy jesteś w stanie odpowiedzieć na moje wcześniejsze pytanie: jak masz spozycjonowane dane względem zegara magistrali szeregowej na wyjściach FPGA do panelu? Na razie nie pytam o szczegóły, tylko napisz czy zmieniasz to jednocześnie czy masz jakoś porozsuwane (opóźnieniami lub wysokim zegarem FPGA). Przecież jeśli nie wiesz, bo np. użyłeś jakiegoś gotowego bloku VHDL to też rozumiem. Przy używaniu bibliotek programowych jest tak samo i czasem trzeba wniknąć w kod by obczaić szczegóły implementacji. Wolę taką dorosłą odpowiedź niż te farmazony jakimi mnie powyżej poczęstowałeś. Wtedy bierzesz oscyloskop do ręki i badasz organoleptycznie. Gdy nie ma się do czego przyczepić, problem leży gdzie indziej a jeśli widzisz coś podejrzanego, trzeba będzie wniknąć w kod. Być może to coś czego użyłeś jest przystosowane do krótkich połączeń chip-to-chip a nie do wysyłania sygnałów na panel LED i będziesz musiał pokombinować.

Do pozycjonowania danych w czasie dochodzi jeszcze signal integrity czyli to, by do panelu dochodziły prostokąty a nie coś co tylko z daleka je przypomina. Możesz zrobić to dobrze i te 6 bitów przesłać synchronicznie z zegarem nawet 50MHz a możesz spieprzyć a wtedy 5MHz będzie wyzwaniem.

Oczywiście wciąż istnieje ograniczenie możliwości samych scalaków w panelu - czy je znamy?

I przecież nie piszę tego wszystkiego po to że Cię dołować, mam lepsze zajęcia. Daj mi pożywkę w postaci liczb, a przetrawię to i napiszę co o tym myślę (czyt: chętnie pomogę), ale nie każ mi ciągnąć Cię za język jak jakiegoś gimnazjalistę co trafił tu z przypadku i nawet nie wie o co pytam. Nie wiesz jak ustawiłeś wyjścia? To sprawdź, przecież jakoś tego IDE używasz, pogrzeb w plikach konfiguracyjnych projektu czy coś.

Fakt, może brakuje dobrego kursu o przesyłaniu sygnałów z zachowaniem integralności, ale nie jest to przecież jakaś magia. Być może na tym przykładzie można by coś wyjaśnić - to dobra okazja, ale daj szansę, opisuj szczegóły i podawaj liczby. Przecież chyba rozumiesz, że jeśli mówimy o czasach rzędu nanosekund to wrzucanie wykresu obejmującego całą ramkę obrazu jest złym pomysłem. Chodzi o jeden-dwa okresy zegara i dane na jego tle, to wszystko

Sygnały typu LATCH czy OE są o tyle mniej ważne, że są asychroniczne. Mogą wystąpić 1us później lub wcześniej - gdy magistrala stoi - i nic się nie wydarzy złego. W nich dbamy tylko o poprawne ich dostarczenie do panelu, czyli żeby nie było odbić a odbiornik widział jedn impuls zamiast kilku lub żadnego.

Dobra, widzę, że dopisałeś o skupianiu się na czymś innym, bo interfejs do panelu działa wystarczająco dobrze. Masz rację, nic tu po mnie. Przykro mi, że uwagi n/t interfejsu i prośby o dodatkowe dane odniosłeś jako wytykanie błędów i chyba jeszcze coś.

Udanej delegacji.

[Elvis]

Nie znam się na wszystkim, co począć. Może muszę też zainwestować w nowe narzędzia, 15-letni oscyloskop to nie najlepsza sprawa, analizator jak widać też kiepski.

Ale nie o to mi chodziło gdy zakładałem ten temat. Chciałem zachęcić inne osoby do tworzenia i dzielenia się własnymi projektami - nawet nie idealnymi, niekoniecznie profesjonalnymi. Bardzo dziękuję koledze

Zealota za udział w dyskusji - o coś takiego mi chodziło, o wspólne motywowanie się do działania, pomaganie, ale bez wywyższania się i leczenia własnych kompleksów.

A sam projekt, czy działanie końcowego rezultatu jest tutaj najmniej ważny - chodzi o mile spędzony czas, jeśli się uda to nauczenie czegoś. Na pewno nie o udowadnianie swojej wyższości i wiedzy.

[Zealota]

Zealota za udział w dyskusji - o coś takiego mi chodziło, o wspólne motywowanie się do działania, pomaganie,

Proszę 🙂. Sam też znowu trochę zmusiłem się do myślenia. Nie jestem jakimś tam specjalistą w dziedzinie elektroniki cyfrowej, ale swoje godziny czy nawet miesiące spędziłem z tymi panelami i sporo mnie to nauczyło, a to jest moja dodatkowa motywacja 🙂

A sam projekt, czy działanie końcowego rezultatu jest tutaj najmniej ważny - chodzi o mile spędzony czas, jeśli się uda to nauczenie czegoś. Na pewno nie o udowadnianie swojej wyższości i wiedzy.

Tu się nie zgodzę 🙂 Warto go dokończyć, a najlepiej opublikować. Mojemu jeszcze sporo do doskonałości, ale nie zamierzam się łatwo poddać 🙂

Sam się zabieram również do FPGA, ale na razie skończyło się na zakupie zestawu i "programatora", leży sobie tak już rok, bo jeszcze nawet tych esteemów jakoś specjalnie nie opanowałem.

[Elvis]

Trochę zniechęciłem się do publikowania wszystkich zmian na forum, ale nieco się napracowałem więc mogę opisać jak idą postępy prac z panelem.

Pierwsza ważna zmiana to zasilanie. Wcześniej używałem dość już wiekowego, a do tego po przejściach zasilacza laboratoryjnego o wydajności prądowej 10A. Plusem była możliwość regulacji napięcia, ale poza tym już same minusy. Okazało się również że wydajność prądowa jest za mała.

Zmieniłem zasilacz na 5V 18A i panel pięknie działa. Taktowanie zegara wróciło do 25MHz i obraz jest dużo stabilniejszy - do poprawki mam jedną linię, ale to w tej chwili mało istotne. Przy okazji ważny wniosek - 3.3V to dla tych paneli za mało. Co prawda świecą ładnie, ale ich rejestry przesuwające nie działają w pełni poprawnie.

Kolejna zmiana to wreszcie docelowa płytka ewaluacyjna, czyli DE0-Nano-SoC (http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=941 ). Zamiast układu MAX10 ma na pokładzie Cyclone V wyposażony w dwa rdzenie ARM Cortex-A9. Jest to więc w pewnym sensie dopowiednik Zynq produkowanego przez Xilinx.

Dzięki temu można uruchomić linuksa - i to jest kolejny punkt w postępach nad projektem. Mianowicie Linux już działa, do pierwszych testów podłączyłem przez FPGA diody dostępne na płytce - można nimi sterować przez zapis w przestrzeni adresowej procesora.

Do testowania używam programu devmem (https://github.com/pavel-a/devmemX/wiki/Using-devmem), ale na płytce zainstalowałem całe Ubuntu, więc można byłoby równie dobrze pobawić się Pythonem.

Co ważniejsze udało mi się również podłączyć mój sterownik wyświetlacza - linux ma do niego dostęp tak jak do diodek, czyli widzi go jak pamięć w określonym obszarze adresowym.

Te kropki które są widoczne na zdjęciu to właśnie efekt używania programu devmem do zapalania pojedynczych pikseli.

Teraz czeka mnie ostatni krok, czyli napisanie drivera dla linuxa - będzie to prosty framebuffer, który powinien pozwolić na używanie panelu jak każdego innego wyświetlacza.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Zealota]

Trochę zniechęciłem się do publikowania wszystkich zmian na forum, ale nieco się napracowałem więc mogę opisać jak idą postępy prac z panelem

Przecież pisałem Ci, że masz się nie zniechęcać 🙂

Moja "osobista płyta" pod STM32F3 też już przyszła i została polutowana, ale jeszcze nie hula.

[Elvis]

Muszę teraz trochę nad gammą popracować, ale pierwszy efekt wygląda następująco:

[ Dodano: 30-07-2018, 21:08 ]

Na razie kolory nadal dalekie od ideału - do tego trzeba będzie jeszcze wrócić, ale reszta działa całkiem fajnie 🙂

[deshipu]

Nie było mnie tydzień, a tu dużo się przez ten czas działo. Kolory to duży problem, nawet producenci monitorów sobie z tym nie radzą...

[Zealota]

Elvis, możesz troszkę opowiedzieć jak zabrać się za takie sterowanie od strony FPGA?

Na tę chwilę niestety nie jestem w stanie zadać konkretnego pytania, więc może być ogólnikowo.

Interesuje mnie czy to "duża sprawa", czy może wystarczy podstawowy kurs, a może trzeba więcej.

Jestem na razie na etapie skompletowania literatury i zakupu płytki deweloperskiej do Xilinxa

(Spartan 3 - bodajże 🙂 )- a kupowałem to właśnie pod kątem sterowania takimi panelami i też obsługą szybkich przetworników AC.

Doświadczenia praktycznego z techniką cyfrową nie mam za dużego, aczkolwiek teoretycznie jestem w tym kierunku wykształcony i do kilku lat już programuję mikrokontrolery w C - ciekawy paradoks, niemniej jednak tak jest 🙂

Jak się do tego zabrać? Co radzisz na początek?

[Elvis]

Ja też nie jestem ekspertem od układów cyfrowych - układami programowalnymi zainteresowałem się niejako przy okazji programowania niskopoziomowego. Moim zdaniem takie sterowanie paneli to jeden z łatwiejszych projektów jakie można wymyślić dla praktycznego zastosowania FPGA.

Nie bardzo wiem jak i co mam opowiedzieć o sterowaniu - najlepiej zacząć od czegoś prostego, możesz więc napisać kod który wysteruje jedną linię na wyświetlaczu. To powinno się udać po podstawowym kursie FPGA. Później można iść dalej - wysterowanie kilku linii jest proste, właściwie wystarczy przełączać linie i wysyłać inne dane.

Moim zdaniem właśnie z danymi jest najtrudniej - ale na początek można generować obraz za pomocą kodu, więc wszelkie szlaczki, ramki, czy cieniowania idealnie się do tego nadają. Co więcej wystarczy nawet CPLD, a Spartan 3 to rakieta.

Problemy zaczynają się gdy chcemy coś bardziej ambitnego wyświetlić - można pisać nawet proste gry na samym FPGA, ale to nie zawsze jest proste i raczej ograniczone do Pong-a i podobnych. Więc takie coś zawsze można zrobić - ja poszedłem w nieco inną stronę, w FPGA zarezerwowałem odpowiednią pamięć na dane obrazu i je wyświetlam. A same dane pobieram z procesora - najpierw podłączonego przez SPI, następnie procesora w FPGA (MicroBlaze), a na koniec ARM. To chyba trochę trudniejsze, ale małymi krokami wszystko da się zrobić.

Nie wiem tylko czy zasoby Spartan XC3S50A z kursu nie będą dość szybko za małe - to świetny układ do nauki, bardzo polecam - niestety dość szybko okazuje się, że jest nieco ograniczony. Jak chodzi o panel to warto pomyśleć co chcesz z nim zrobić. Jeśli grę w Pong-a, to na pewno XC3S50A sobie poradzi.

Ale do bufora obrazu potrzebna jest pamięć, której XC3S50A ma raptem 54Kb (bity), czyli 6.75KB - jeden panel 64x32 x 16b koloru to 4KB, więc tym układem dużego wyświetlacza się raczej nie obsłuży.

Tak jak napisałem - jest idealny do nauki, ale wydaje mi się że warto od razu przygotować się na użycie innego układu po opanowaniu podstaw, albo wybraniu czegość nieco "większego". Jednym z moich ulubionych jest Maximator od Kamami: https://kamami.pl/zestawy-uruchomieniowe/561438-zestaw-maximator-maximator-expander-kamami-usb-blaster.html?search_query=maximator&results=29 - kosztuje trochę więcej, ale ma znacznie większe możliwości niż staruszek Spartan 3. Oczywiście jest mnóstwo płytek ewaluacyjnych dostępnych, więc można spokojnie wybrać co komu odpowiada.

[ Dodano: 31-07-2018, 16:04 ]

A jak chodzi o stopień trudności to ja sterowanie wyświetlaczem zorganizowałem tak:

* mam automat (podobnie do https://forbot.pl/blog/kurs-fpga-drgania-stykow-automaty-cd-id24065), który ma 4 stany

1) OFF - wyświetlacz jest wyłączany

2) SWITCH - przełączanie linii

3) ON - zatrzaśnięcie danych i włączenie

4) DATA - przesyłanie danych dla kolejnej linii

* te pierwsze 3 stany są odpowiedzialne za przebiegi sterujące o których wcześniej wspominałeś - u mnie nie są idealne, przyznam że trzeba je będzie poprawić z analizatorem logicznym w dłoni 😉

* stan DATA to większa część kodu i właściwie realizuje zwykły rejestr przesuwający. W każdym cyklu wystawiane są dane na 6 liniach koloru a następnie generwany impuls na linii zegara

[Zealota]

Dziękują bardzo za rozbudowany wpis 🙂

Powoli trzeba w to wchodzić... 🙂

[Elvis]

Jak chodzi o kolory to z tego co widzę problemy są dwa. Pierwszy jest znacznie łatwiejszy do naprawienia - chodzi o korekcję gamma. W tej chwili czas świecenia zależy liniowo od podanej wartości, co niestety zupełnie nie sprawdza się w praktyce.

Drugi problem jest znacznie trudniejszy - konieczna jest wyższa rozdzielczość PWM dla niskich poziomów świecenia. Aktualnie używam 32 poziomów, co idealnie pasowało do 5 bitów na składową koloru. Niestety większość poziomów (mniej więcej od połowy) jest nierozróżnialna...

Co więcej zapalenie diody na minimalny czas daje już całkiem sporą jasność. Oznacza to że aby panel sprawdzał się do odtwarzania filmów lub gry w Doom-a, muszę zwiększyć częstotliwość odświeżania.

Tutaj wraca problem zegara. W tej chwili wydaje mi się, że najlepiej będzie zmienić podłączenia i zamiast mieć 8 paneli połączonych szeregowo, połączyć je po dwa - wtedy będzie w każdej linii 128 pikseli, a układ FPGA bez problemu powinien poradzić sobie z 13x4 czyli 52 liniami sterującymi.

[FlyingDutch]

Kolejna zmiana to wreszcie docelowa płytka ewaluacyjna, czyli DE0-Nano-SoC (http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=941 ). Zamiast układu MAX10 ma na pokładzie Cyclone V wyposażony w dwa rdzenie ARM Cortex-A9. Jest to więc w pewnym sensie dopowiednik Zynq produkowanego przez Xilinx.

Dzięki temu można uruchomić linuksa - i to jest kolejny punkt w postępach nad projektem. Mianowicie Linux już działa, do pierwszych testów podłączyłem przez FPGA diody dostępne na płytce - można nimi sterować przez zapis w przestrzeni adresowej procesora.

Teraz czeka mnie ostatni krok, czyli napisanie drivera dla linuxa - będzie to prosty framebuffer, który powinien pozwolić na używanie panelu jak każdego innego wyświetlacza.

Cześć Elvis,

świetny projekt. chciałem tylko zapytać, czy końcowa wersja sterownika paneli jest na DE0-Nano-SoC ?

Pozdrawiam

[Elvis]

Tak, zdjęcia z działającym Doom-em i wyświetlaniem filmu robiłem na wersji z DE0-Nano-SoC. Na procesorze ARM działa Linux, a w FPGA jest zaimplementowany bufor obrazu oraz sterownik.

Natomiast nie jestem pewien czy to ostateczna wersja - powiedziałbym, że pierwszy działający prototyp. Teraz gdy wiem jak tak wyświetlacz obsłużyć, planuję zrobić wszystko od początku, ale lepiej. A przy okazji może zmienię z Altery na Xilinx-a. Mam w końcu płytkę MYIR z Zynq na pokładzie, która idealnie by się do takiego zastosowania nadawała.

[FlyingDutch]

Natomiast nie jestem pewien czy to ostateczna wersja - powiedziałbym, że pierwszy działający prototyp. Teraz gdy wiem jak tak wyświetlacz obsłużyć, planuję zrobić wszystko od początku, ale lepiej. A przy okazji może zmienię z Altery na Xilinx-a. Mam w końcu płytkę MYIR z Zynq na pokładzie, która idealnie by się do takiego zastosowania nadawała.

Elvis,

dzięki za odpowiedź. Tylko po co zmieniać jak na Alterze działa OK? (chociaż nie ukrywam, że z chęcią bym zobaczył jak to zrobić na Zynq 😉 )

Pozdrawiam

[Elvis]

Zmieniać muszę, bo bardzo dużo zrobiłem "na skróty". Zaczynając od mechaniki - poskładałem z tego co było pod ręką ramę do której przykręciłem panele, ale to się ledwo trzyma. Teraz jak wiem że panel mi się podoba, muszę rozrysować i zamówić wycięcie porządnego szkieletu - uwzględniając miejsce na mocowanie zasilacza oraz elektroniki.

Kolejna sprawa to sterowanie jasnością świecenia - znowu pierwszą wersję robiłem żeby spróbować jak całość działa i czy dam radę projekt zrealizować. Teraz wiem że liniowe sterowanie PWM nie spełnia moich oczekiwań, muszę więc trochę więcej posiedzieć i pokombinować jak poprawić sterowanie diodami. Przy okazji pewnie wróci konieczność zwiększenia częstotliwości odświeżania - więc może i bardziej równoległe sterowanie.

Na koniec sam interfejs między ARM-em, a FPGA - używam teraz magistrali Avalon, a chciałem nauczyć się pisać komponenty AXI...

Więc reasumując - przy tylu zmianach, użycie innego układu to wręcz drobnostka. Natomiast Xilinx ma lepsze wsparcie dla AXI - albo tak mi się teraz wydaje.