Wyświetlacz z paneli LED

[Elvis]

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.

Postanowiłem wyjść przed szereg i przetestować jak takie podejście mogłoby wyglądać - jeśli to nielegalne na forum proszę o usunięcie tematu. Mój plan jest taki: chciałbym opisać projekt, który teraz hobbistycznie realizuję, mam nadzieję że pojawią się uwagi, komentarze, pomoc w wyborze rozwiązań. Na koniec mogę wszystkie kody umieścić w repozytorium, nie mam nic do ukrycia 🙂

Pomysł jest nieco podpatrzony, a moim celem jest zbudowanie wyświetlacza LED o rozdzielczości 128x128 pixeli.

Do budowy wyświetlacza używam typowych paneli 64x32, coś jak: https://www.adafruit.com/product/2279 W Polsce takie panele sprzedaje np. Botland, https://botland.com.pl/paski-led-adresowane/8363-matryca-64x32-2048-led-rgb-indywidualnie-adresowane.html Ja swoje panele zamówiłem w Chinach, jak łatwo się domyślić ze względów finansowych.

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:

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.

[marek1707]

Po co to robisz, tj. jaki masz pomysł na wykorzystanie panelu w domu? W pracy? Ciekaw jestem czy jest to tylko próba odpowiedzi na pytanie czy da się prosto i tanio, czy jakaś aplikacja FPGA bo i tak to ostatnio trenujesz czy jednak jakiś praktyczny aspekt też istnieje. To jednak duża rzecz więc i prądu sporo a zarazem rozdzielczość wciąż za mała by pograć "w czołgi". No może Tetris by na tym jeszcze poszedł jakoś 🙂

[Elvis]

Pomysł jest taki, żeby na FPGA przygotować sterownik, a na Cortex-A9 odpalić linuxa. Wtedy nawet na 128x128 zadziała doom 😉

Robię to wyłącznie hobbistycznie, jak będzie przyzowicie wyglądało to może zawiśnie na ścianie jako wyświetlacz - ale poza tym cel jest wyłącznie edukacyjny, chciałbym po prostu nauczyć się jak coś takiego zrobić.

Pobór prądu oczywiście będzie znaczny, to nieco komplikuje zabawę, ale na szczęście standardowe zasilacze na 5V są dostępne. W tej chwili korzystam z zasilacza laboratoryjnego, przy dwóch panelach prądy były poniżej 3A - więc to co mam, czyli 10A na początek powinno dać radę. Później pewnie będzie ATX albo coś innego. Ale zasilacza nie zamierzam projektować 🙂

[deshipu]

Bardzo ładnie! Na 128×128 już da się pograć — moja pythonowa konsolka ma taką właśnie rozdzielczość. Ciekawym mogłoby być dorobienie do tego interfejsu SPI symulującego standardowe wyświetlacze — wówczas byłby to drop-in-replacement (pomijając zasilanie) i można by to używać na przykład do "klonowania" wyświetlacza mniejszego urządzenia w celu zademonstrowania szerszej publiczności na przykład na jakiejś wystawie.

[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

[Elvis]

Fajny pomysł z SPI - na to nie wpadłem, a idealnie pasuje jako "krok pośredni" między testami prostych obrazów zaszytych w kodzie dla FPGA, a "pełną" wersją z linuksem.

[deshipu]

Na Linuksa masz nawet gotowe sterowniki używające SPI — więc mógłbyś to testować na przykład z RaspberryPi.

[marek1707]

Nie wiem jak dokładnie w tych panelach wygląda driver, ale skoro FPGA to może dałoby zrobić stopnie szarości? A może te Twoje są kolorowe?

Gdybyś do panelu wysłał choćby 10Mbit/s, to przy 8 bitach/pixel i 128x128 masz ponad 75 FPS 🙂

Planujesz zrobić pełny frame buffer w FPGA a interfejs do jego zapisywania (SPI? I2C? UART?) zupełnie niezależnie od wyświetlania? Tak duże pole LEDów powinno szybko się odświeżać żeby nie było widać migotania. Robiłeś już jakieś próby?

Jak planujesz podłączenie paneli do kontrolera? Szeregowo, czy wszystkie "obok siebie" na wspólnym zegarze, ale z równolegle pociągniętymi liniami danych?

[Elvis]

Driver jest bardzo prosty - to zwykłe rejestry przesuwające. Diody są kolorowe, więc planuję mieć co najmniej 64k kolorów 😉 Właśnie dlatego FPGA jest koniecznością.

Co do taktowania to celuję raczej w 50MHz, ale na razie testy robiłem na 10MHz - przy dwóch panelach to wystarcza, do 8 trzeba będzie przyspieszyć.

Pierwsze testy robiłem na Arduino - chciałem zrozumieć zasadę działania sterownika. W sieci dostępne są przykładowe kody, niestety mocno zoptymalizowane co nieco zaciemnia sposób działania.

Do sterowania zatrzaskami używane są 3 linie:

* OE

* LAT

* CLK

W każdym cyklu zegara wysyłane są 2 piksele, po 3 kolory każdy:

* R1, G1, B1

* R2, G2, B2

Do tego można wybrać numer linii która jest aktualnie rysowana - jest ich 16, więc 4 linie służą do wyboru:

* A,B,C,D

To tak w największym skrócie sterowanie - panele są łączone szeregowo, więc zamiast 64 pikseli w linii mam 512, poza tym i poborem prądu właściwie sterowanie jest jak dla jednego.

[marek1707]

Acha, dzięki. Skoro 4-bitowy wybór linii jest czysto statyczny i nie da się nie wybrać żadnej, to aby nie było widać poświaty między pixelami musisz kombinować z rejestrem. Czyli (piszę żeby samemu zrozumieć) proces wygląda jakoś tak:

1. Ładujesz nową zawartość szeregowo do rejestru SIPO (równolegle po 6 liniach danych) zegarem CK (16 impulsów daje 32 pixele RGB w linii?)

2. Wyłączasz wszystkie wyjścia rejestru sygnałem OE

3. Przepisujesz to co załadowałeś do wyjściowego latcha impulsem na LAT

4. Zmieniasz numer linii na ABCD

5. Włączasz nową linię przez uaktywnienie OE rejestru

Pkt. 3 i 4 możesz zrobić jednocześnie. Na pewno wyłączenie rejestru i jego załączenie musi odbyć się odpowiednio przed i po zmianie numeru linii. Czy dobrze myślę?

[Elvis]

Dokładnie tak - kod którym testowałem wyświetlacz za pomocą Arduino wyglądał następująco:

#define PIN_CLK   2
#define PIN_R1    3
#define PIN_G1    4
#define PIN_B1    5
#define PIN_OE    6
#define PIN_A     12
#define PIN_B     7
#define PIN_C     8
#define PIN_D     9
#define PIN_LAT   13

void setup() 
{
 pinMode(PIN_CLK, OUTPUT);
 pinMode(PIN_R1, OUTPUT);
 pinMode(PIN_G1, OUTPUT);
 pinMode(PIN_B1, OUTPUT);
 pinMode(PIN_OE, OUTPUT);
 pinMode(PIN_A, OUTPUT);
 pinMode(PIN_B, OUTPUT);
 pinMode(PIN_C, OUTPUT);
 pinMode(PIN_D, OUTPUT);
 pinMode(PIN_LAT, OUTPUT);

 digitalWrite(PIN_CLK, 0);
 digitalWrite(PIN_R1, 0);
 digitalWrite(PIN_G1, 0);
 digitalWrite(PIN_B1, 0);
 digitalWrite(PIN_OE, 1);
 digitalWrite(PIN_A, 0);
 digitalWrite(PIN_B, 0);
 digitalWrite(PIN_C, 0);
 digitalWrite(PIN_D, 0);
 digitalWrite(PIN_LAT, 0);
}

int row;

void loop() 
{
 // disable screen
 digitalWrite(PIN_OE, 1);
 digitalWrite(PIN_LAT, 1);
 // select row
 digitalWrite(PIN_A, row & 1);
 digitalWrite(PIN_B, row & 2);
 digitalWrite(PIN_C, row & 4);
 digitalWrite(PIN_D, row & 8);
 // show screen
 digitalWrite(PIN_LAT, 0);
 digitalWrite(PIN_OE, 0);

 // send data
 if (++row >= 16)
   row = 0;
 for (int i = 0; i < 64; i++) {
   if (i < 48) {
     digitalWrite(PIN_R1, row & 1);
     digitalWrite(PIN_G1, row & 2);
     digitalWrite(PIN_B1, row & 4);
   } else {
     digitalWrite(PIN_R1, 1);
     digitalWrite(PIN_G1, 0);
     digitalWrite(PIN_B1, 0);    
   }

   digitalWrite(PIN_CLK, 1);
   digitalWrite(PIN_CLK, 0);
 }

 //delay(10);
}

[marek1707]

Fajne. Ciekawe jak wyglądają po stronie panelu wejścia cyfrowe. Czy zrobili jakieś dopasowanie/terminację czy tak po prostu wyciągnęli piny cyfrowe i tyle (plus ew. niczego nie zmieniające pullupy/pulldowny). Wtedy, żeby szybko wysyłać będziesz musiał zrobić terminację szeregową po swojej stronie. Czy interfejs jest 5V? To i konwersję FPGA→5V z jakichś porządnych driverów 5V będzie trzeba wstawić. Na szczęście masę zrobili na kilku pinach złącza - sukces. Czy zasilanie wchodzi na panel przez osobne złącze? Nie widać na zdjęciu wszystkich oznaczeń.

[Elvis]

Tak, zasilanie jest oddzielone - w końcu są tam całkiem spore prądy. Natomiast do wyświetlaczy nie ma żadnej dokumentacji, więc napięcia trzeba będzie pomierzyć. Ale mam nadzieję, że po stronie wyświetlacza są tylko wejścia, więc uda się bezpośrednio 3.3V podpiąć. Na razie używałem po prostu maximatora do testów FPGA - wtedy nie ma problemu bo konwertery napięć są na płytce.

[Zealota]

Driver jest bardzo prosty - to zwykłe rejestry przesuwające. Diody są kolorowe, więc planuję mieć co najmniej 64k kolorów 😉 Właśnie dlatego FPGA jest koniecznością.

Co do taktowania to celuję raczej w 50MHz, ale na razie testy robiłem na 10MHz - przy dwóch panelach to wystarcza, do 8 trzeba będzie przyspieszyć.

Do prostego drivera - wyświetlacza nie potrzeba wcale FPGA, na pewno nie na początek 🙂

11 bitowy kolor, z 60 FPS jest możliwy nawet na STMF4.

Polecam zajrzeć do projektu:

https://hackaday.com/2015/01/05/rgb-led-matrices-with-the-stm32-and-dma/

Jedynym problemem tego rozwiązania jest "pazerność" na pamięć.

Opierając się na tym projekcie, stworzyłem prototyp z 'płynna regulacją' bitowej głębi, od 1 bit do 8 bit na nieco wolniejszym procku STM32F303.

Cały czas pracuję nad publikacją swoich prób z takim wyświetlaniem.

Przeszedłem już kilka etapów z tymi wyświetlaczami, od wersji na AVR:

poprzez statyczne obrazy na STM32F411:

Mam nadzieję, że kiedyś przeniosę to na FPGA...

A tak w ogóle, to cześć wszystkim użytkownikom tego zacnego forum 🙂

[Elvis]

Zapomniałem że na tym forum nie wolno używać słow nigdy, zawsze oraz "trzeba" - bo zaraz ktoś udowodni, że chłodzony ciekłym azotem AVR też daje radę... 🙂

Więc wycofuję "trzeba", niech będzie że stosuję FPGA bo chcę - stm32 na tyle poznałem, że nie widzę aż takiej frajdy w jego używaniu, a układy programowalne to dla mnie nadal wyzwanie.

A jak chodzi o uzasadnienie FPGA, to ja liczyłem tak: ekran składa się z 64 x 32 x 8 = 16384 pikseli. Ponieważ dwa są wysyłane jednocześnie, na jeden ekran potrzebuję 8192 cykli zegara obrazu. Rozważałem 64 lub 128 poziomy jasności, powiedzmy 8192 x 128, czyli 1048576 na klatkę. Teraz powiedzmy 50Hz i mamy 50MHz zegar.

Czy to da radę zrobić mikorkontroler? Pewnie tak, jak ma odpowiednie moduły peryferyjne. Natomiast moim celem jest nauczenie się, jak taki moduł samemu zaprojektować i uruchomić - stąd FPGA.

[Zealota]

Zapomniałem że na tym forum nie wolno używać słow nigdy, zawsze oraz "trzeba" - bo zaraz ktoś udowodni, że chłodzony ciekłym azotem AVR też daje radę... 🙂

To bardzo dobra zasada, sam ją staram się stosować, niemniej jednak mój post to żaden przytyk, trochę niefortunnie wyszło 🙂

Zresztą troszkę pojechałem, bo zaprezentowane przeze mnie rozwiązania nadadzą się do dość małych paneli, szczególnie dla słabszych STM32, a Twoje założenia są o wiele bardziej ambitne.

Prawdopodobnie zastosowanie zewnętrznej pamięci i STM32 z obsługą FSMC (100 nóżek wzwyż) również mogłoby zapewnić sterowanie dla 8 paneli.

Czy to da radę zrobić mikorkontroler? Pewnie tak, jak ma odpowiednie moduły peryferyjne. Natomiast moim celem jest nauczenie się, jak taki moduł samemu zaprojektować i uruchomić - stąd FPGA.

I to kolejne prawidłowe podejście, najpierw założenia, a dopiero potem wybór rozwiązania.