Wyświetlacz z paneli LED

[FlyingDutch]

Ostatnio w ramach wątku https://www.forbot.pl/forum/topics1/zmiany-w-dzialalnosci-forum-i-jego-tematyce-vt15666.htm#128049 pojawiła się dyskusja o zmianach na forum, w tym odejście od wymogów opisywania projektów robotycznych.

Zaplanowałem rozdzielczość 128x128 - jest to kompromis między ceną, wielkością, a czytelnością z drugiej strony. Mniej pikseli wydawało mi się po prostu niewystarczające.

Ponieważ jeden panel składa się z 64x32 diodek, zamówiłem 8 paneli - będą podłączone w 2 kolumnach po 4 rzędy.

Wczoraj prowizorycznie poskładałem prototyp konstrukcji i wygląda ona w tej chwili następująco:

Obrazek

Samo sterowanie wyświetlaniem jest dość ciekawe - są to zwykłe diody LED oraz rejestry przesuwające. Nie ma więc "inteligentnych" diod, jak np. WS2812 i z generowaniem obrazu trzeba się trochę napracować.

To był właśnie powód umieszczenia tego projektu w dziale "Układy programowalne". Do pierwszych eksperymentów używałem Arduino, ale docelowy sterownik będzie oparty o FPGA.

Cześć Elvis,

trzeba przyznać, że masz fantazję (taką w pozytywnym sensie) 😃

Ja trzymam kciuki za powodzenie twojego projektu.

Pozdrawiam

[Elvis]

Niewiele jeszcze zrobiłem, a już mam problem którego nie rozumiem - może ktoś będzie miał pomysł skąd takie cuda.

Na razie staram się wysterować prosty wzorek na wyświetlaczu. Wygląda, że działa:

Górne połowy każdego panelu są sterowane przez R1,B1,G1 i na nich chciałem mieć odcienie wszystkich składowych, to działa ok.

Dolne połowy wyświetlają tylko pionową białą linie - tak miało być, działa i jest ok.

Ale jeśli spróbuję na górnej i dolnej połowie wyświetlić to samo - co teoretycznie jest łatwiejsze, w końcu wystarczy że R2,B2,G2 ma te same wartości co R1,B1,G2, dostaję niestabilny / zamazany obraz:

Zupełnie nie rozumiem skąd taki objaw, może jakaś podpowiedź gdzie szukać przyczyny?

BTW: coś mi obraca zdjęcia jak wgrywam na forbota... Wcześniej tak było z gniazdem, ale to mały problem. Teraz trzeba mieć sporo wyobraźni - zdjęcia są obrócone o 90 stopni, czerwony pasek jest po lewej, niebieski po prawej. Ale zakłócenia są takie same.

[deshipu]

Usuń ze zdjęć EXIF — pewnie jest w nim info o obrocie i skrypt, który zmienia rozmiar obrazków bierze to pod uwagę...

[ Dodano: 17-07-2018, 00:05 ]

Obraz wygląda tak, jakbyś gubił co jakiś czas wartości. Może te rejestry przesuwne jednak nie są takie szybkie?

[Elvis]

Zagadka już wyjaśniona - jak zwykle wszystkiemu winne zasilanie. Po podwyższeniu napięcia wszystko działa jak należy:

[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

[Treker (Damian Szymański)]

Ciekawy pomysł na projekt, świetny temat i jeszcze lepszy dowód na to, że warto będzie zmienić forum 🙂

[Elvis]

Kolejny mały update:

Zrobiłem prostą komunikację przez SPI, na razie obraz mono - chciałem wykorzystać kod przykładowy z kursu STM32, ale po długich próbach przypomniałem sobie że wyświetlacz Nokii ma inną rozdzielczość. Na razie coś zaczyna działać, są jakieś błędy transmisji, ale to pierwszy prototyp:

Tych kilka poziomych linii to pozostałość po animacji - jak widać wyświetlacz jest szybszy niż aparat 😉

[deshipu]

Naprawdę szybko ci to idzie. Aż miło patrzeć.

[Treker (Damian Szymański)]

Elvis, super, czekamy na jakiś filmik 🙂

[Elvis]

Filmik będzie, ale muszę jeszcze trochę dopracować komunikację po SPI. Kod napisałem bardzo byle jak i obraz czasem "skacze" o kilka linii. Wydaje mi się że to błędy związane z SPI - jak poprawię to przygotuję filmik. Z drugiej strony może najpierw uruchomię kolorowy obraz, teraz wszystko i tak jest w 16b koloru, więc to mała zmiana a powinno ładniej wyglądać.

[Elvis]

Kolejny etap, czyli dodane kolorki. Na razie niestety widoczne błędy w transmisji, ale chociaż coś działa.

Sam panel podłączony jest do zestawu FPGA Maximator firmy Kamami, a za generowanie obrazu odpowiada STM32F429-discovery. Komunikacja między układami za pomocą wspomnianego SPI.

[ Dodano: 21-07-2018, 15:28 ]

Kolejna aktualizacja. Tym razem do generowania obrazu podłączyłem Raspberry Pi. Pierwsze próby robiłem używając 1.44" wyświetlacza firmy Waveshare: https://www.waveshare.com/1.44inch-lcd-hat.htm

Następnie odłączyłem wyświetlacz i podłączyłem panel led. Okazało się, że zasilacz nie radzi sobie z jasnym obrazem, więc zmieniłem tło na czarne - wynik na zdjęciu poniżej:

Niestety chyba muszę coś z tym zasilaniem zrobić - ale jeszcze kilka prób zabawy z pythonem i zaczynam szukać porządnego zasilacza.

[ Dodano: 21-07-2018, 15:59 ]

Jeszcze jeden efekt ciekawostka - komunikaty jądra linuksa na panelu 🙂

[Treker (Damian Szymański)]

Elvis, idziesz jak burza! Daj znać jak odpalisz przeglądarkę i będziesz czytał na tym Forbota 😃

[JTyburski]

Projekt nawet bardzo fajny - taki bym powiedział, że wręcz studencki (czymś takim się bowiem w praktyce bawią studenci, choć potem bardzo szybko im się takie coś nudzi - ale nieważne).

Odnosząc się do SPI - zwykle tutaj problemy wynikają z trzech klasycznych (i doskonale znanych od dawien dawna) problemów jakie zachodzą przy transmisjach synchronicznych:

1. Sygnał z danymi na wyprowadzeniach MISO oraz MOSI jest chcąc nie chcąc z racji opóźnień i tak nieznacznie przesunięty względem sygnału zegarowego, co sprawia, że choć powinieneś na danym zboczu narastającym zegara odebrać konkretny oczekiwany bit, to go nie odbierzesz i zamiast 1 otrzymasz 0, a zamiast 0 otrzymasz 1. I teraz starczy, że przekłamiesz tak parę bitów i wychodzi co wychodzi (A dlaczego tak? Bo sygnały przechodzą w końcu różnymi ścieżkami w takim mikroprocku po prostu).

2. Sygnał zegarowy nie jest też w końcu idealny - albo będą odchylenia od częstotliwości nominalnej albo też będzie zachodził jitter, który dodatkowo będzie powodował "przesunięcia" między sygnałem danych i kolejne przekłamania bitów.

3. Taki sygnał zegarowy i sygnał danych choć z założenia są niezależne od siebie, ale jednak zawsze w układach cyfrowych jest tak, że jeden sygnał wpływa czasem na drugi i to jeszcze powoduje dodatkowe problemy.

Oczywiście wydaje się, że takie przesunięcia są niewielkie - i rzeczywiście zwykle są (no może poza paroma wyjątkami) - ale właśnie diabeł tkwi w tej mniejszości już nawet dla rzędu MHz (dla człowieka wydaje się to nic, ale dla takiej elektroniki ma kolosalne znaczenie!). W każdym razie - to już nie jest kwestia pisania kodu (który może być nie wiem jak wydajny, czy jak krótki - to nie ma znaczenia) ,a czystej elektroniki i rozmieszczania elementów np w FPGA w taki sposób, aby ścieżki między elementami były jak najkrótsze, a co za tym idzie aby wynikające stąd opóźnienia były jak najmniejsze (bardzo trudne zadanie, zwłaszcza przy bardzo precyzyjnej metrologii czasu na poziomie pikosekund i mniej, którą się m.in i ja zajmuje na swojej uczelni jako jedna ze specjalizacji). I tyle 🙂

[ Dodano: 22-07-2018, 11:46 ]

Swoją drogą - ja to mam taki nawyk, że jak biorę dany wyświetlacz do ręki to zaraz piszę pod niego porządny tester, żeby zobaczyć drobiazgowo niczym Niemiec jego jakość - począwszy od pasów, skończywszy na migających w różnych sekwencjach i tempach dane screeny i obrazy. Do tego test rozdzielczości, częstotliwości odświeżania, szczegółowe testy i pomiary przesunięć między liniami komunikacyjnymi, testy jasności, kontrastów, określanie jasności świecenia itp. Słowem - jestem autentycznym maniakiem urządzeń przeznaczonych do wyświetlania czegokolwiek. Można zapytać dlaczego - bo i mój ojciec to też elektronik, który zresztą ponad 40 lat przesiedział w takiej technice i zna ją jak rzemieślnik od podszewki i mógłby godzinami nawijać, począwszy od kineskopowych telewizorów Unitry skończywszy na współczesnych Panasonicach i Samsungach (jeszcze wliczając w to nadawanie telewizyjne) i mnie przy okazji zaraził tym wszystkim jeszcze w latach 90-tych, gdy byłem dzieciakiem 🙂 I tak mi zostało 😃

[ Dodano: 22-07-2018, 12:01 ]

A i oczywiście powodzonka przy dalszym "sztukowaniu" projektu! (tylko nie dziękuj, aby nie zapeszyć!)

[Elvis]

W przypadku tego wyświetlacza aż tak dużo nie da się potestować - nie ma w nim regulacji jasności, ani kontrastu. Są tylko proste rejestry przesuwające i diody RGB. Same diody można przetestować (u mnie jest co najmniej jedna popsuta) - ale niewiele to daje. Na następny panel nie chce mi się czekać, a bez jednego piksela i tak będzie działać.

Napisałem że na początku używałem Arduino do obsługi wyświetlacza - to właśnie były moje testy. Pomysł z SPI jest tylko przejściowy - przyczyną były zakłócenia na linii CE. Tak to bywa jak się łączy na kabelkach od płytki stykowej sygnały w MHz... Teraz komunikacja po SPI działa już bardzo dobrze.

A projekt jest jak najbardziej studencki - co prawda nie związany z moimi studiami, ale realizowany żeby się czegoś nauczyć. Chociaż sam wyświetlacz wygląda okazale, chyba na koniec zawiśnie na ścianie jako dekoracja, ale to jeszcze trochę pracy.

[JTyburski]

Elvis - i z takiego wyświetlacza da się dużo wycisnąć! Kto powiedział, że musi być natywnie w takowym możliwość odrębnego ustawiania kontrastu czy jasności nawet w komendach- po to się sprytnie przesyła obrazy i się tak nimi kombinuje, aby to właśnie przetestować! Więc da się jak najbardziej 😃 A do tego w takich testach nie chodzi o to aby wyłąznie dead piksele sprawdzić - chodzi też o odwzorowanie odcieni kolorów chociażby, aby zobaczyć jak się w rzeczywistości prezentują i jak się wiernie prezentuje obraz czy szybkość reakcji takiej matrycy zwłaszcza na szybkie zmiany obrazu. A także właśnie celem takich testów jest sprawdzenie jak sobie daje radę taki wyświetlacz przy odbieganiu sygnałów od założonych parametrów (czyli czy jest cienki i muszę obchodzić się z nim jak z jajkiem bo taki wrażliwy jak małe dziecko na wszelkie choróbska zaraz po urodzeniu, czy też jest pancerny niczym radziecki czołg i śmiało wytrzyma i pobyt w Czarnobylu przy nie wiadomo jakim poziomie promieniowania). To wszystko jest bardzo istotne i ważne, dlatego jest co testować nawet na takim skromnym wyświetlaczu!

I nie mów przy tym "niewiele to da" - bo właśnie przez takie myślenie potem w tym kraju nic się nie zmienia mimo 30 lat kapitalizmu (za granicą się cholera interesują śmiało takimi drobiazgami, w tym w Niemczech, a tu w Polsce - ot machnąć ręką bo co mnie to, mi tylko przyziemny chleb). Ale to taka już ode mnie praktyczna rada, bo ciągle to słychać wszędzie gdzie by się nie poszło (nawet w takim Multikinie) i co za tym idzie nie ma co się dziwić, że jest jak jest jak to się słyszy po raz kolejny 😉 I studenci u mnie o tym doskonale wiedzą i ich właśnie kuruję od tego przy każdej okazji ile popadnie i przynosi to już pierwsze skuteczne efekty 😃

[Zealota]

Elvis, nie wiem na jakich materiałach się opierasz, ale jeśli jeszcze tego nie widziałeś, to polecam stronkę:

https://bikerglen.com/projects/lighting/led-panel-1up/

Od a do z przedstawiono teorię i praktykę sterowania, łącznie z obsługą drivera na FPGA.

JTyburski, o czym Kolega właściwie pisze? Czytałem wypowiedzi kilka razy, ale ciężko znaleźć w tym nawiązanie do pracy Elvisa i sugeruje niestety, że Kolega nigdy sterowania nie robił do tych paneli.

"że jak biorę dany wyświetlacz do ręki to zaraz piszę pod niego porządny tester"

Przecież Autor właśnie pisze driver do diod, a Ty piszesz o testowaniu gotowych wyświetlaczy, jak mniemam. Nawiązania do SPI? Po stronie diod właściwie nie ma SPI, już bardziej równolegle - szeregowe sterowanie. W jednym takcie zegara są przesyłane 6 linii danych.

SPI, jeśli dobrze rozumiem, jest zastosowane do transmisji komputer - FPGA.

Jeśli pojawiają się artefakty, to właśnie, z dużym prawdopodobieństwem, z powodu niedoskonałości sygnałów od FPGA.

A co do geopolitycznych wycieczek, wg mnie powinny zostać zmoderowane, bo nic nie wnoszą do tej, technicznej dyskusji, szczególnie, że są zupełnie niepotrzebne i nieprawdziwe, czego właśnie dowodem jest dociekliwość Elvisa.