Sterownik matryc LEDowych z interfejsem hub75 na STM32F730

[kaworu]

Po niefajnych przygodach z 20mm/1.9mm matrycami zbudowanymi na max7219:

Które to o prawda mają piękny dyfuzor, ale okazały się upierdliwe w montażu i uruchomieniu*, przyszła pora na coś bardziej zaawansowanego. Miałem w planach zrobienie własnego PCB na matrycę z ponad 1500 jednokolorowych ledów 0603, 3 rejestrów przesuwnych i paru elementów dyskretnych, ale jak już ją zaprojektowałem, to przypadkiem trafiłem na matryce hub75. Ich głównym zastosowaniem są telebimy, ale wygląda na to, że ze względu na swoją dostępność i cenę (70zł za 64x32 2,5mm pitch), mają także bardziej prozaiczne zastosowania. Minus jest taki, że to tylko LEDy (w dodatku ze słabym dyfuzorem), rejestry i dekoder adresów, więc trzeba nimi samemu sterować, do tego z dużą częstotliwością, ale jak się człowiek by postarał, to nawet ponad 48bit da się z tych 1bit matryc wydusić.

* - mają analogowe sterowanie PWMem, ale ciężko stwierdzić czy działają całkowicie poprawnie przed przylutowaniem matrycy, a bardzo ciężko je potem wylutować w razie wpadki. Plus lustra prądowe na dyskretnych tranzystorach nie są najlepsze na świecie.

Tak oto powstał projekt:

Założenia początkowe były następujące:
* jak najwięcej rzeczy realizowanych w sprzęcie;
* montowane bezpośrednio pod PCB matrycy;
* pomiar prądu pobieranego przez wyświetlacz (do automatycznej kalibracji maksymalnej jasności)
* odświeżanie na poziomie około 200Hz
* kolor RGB444 + 6bit globalnej jasności
* do matryc 64x32, maks 192x64
* komunikacja po SPI, I2C i szeregowym RS485

Po przestudiowaniu tego co jest dostępne w CubeMX i z grubsza posiada co jest potrzebne (dwa timery advanced), pamięć przynajmniej 128kiB (w najgorszym wypadku 2 bufory po 50k każdy, double buffering), wybór padł na STM32F730. Do tego koszt 12zł, idealnie.

Podstawy sterowania matrycami:

Matryce maja różne kombinacje pinów w zależności od wielkości (i co za tym idzie różny scan-rate), ale generalnie najczęściej występującą kombinacją jest taka jak powyżej. Mamy tutaj 6 pinów danych o kolorze, po dwa na składową (Rx, Gx, Bx), zegar (CLK), zatrzask (LAT), wybór wiersza (A, B, C, D, czasem z E, czasem do C), i Output Enable. Działa to mniej więcej tak:

* Pinami ABCD wybieramy wiersz (no, właściwie dwa), który będzie aktualnie wyświetlony 1-16. Jeśli przykładowo wybierzemy wiersz 0, to wyświetlone po podaniu sygnału niskiego na OE zostaną wiersze 0 i 16 (scan 1/16... choć jak dla  mnie to bardziej 2/32);
* Wejścia zatrzasków wierszy z górnej połowy ekranu są podłączone do pinów R/G/B1, dolnej do R/G/B2. Są to rejestry przesuwne, 1bit na LED. Przy matrycy x64 trzeba podać 64 takty zegara na pin CLK i wystawić adekwatną liczbę bitów danych na pinach RGBx;
* Machnąć pinem LAT, przejście niski -> wysoki zatrzaskuje daje w rejestrach;
* Włączyć na jakiś czas pin OE, poczekać chwilę i wrócić do pierwszego punktu;

Niestety żaden STM32 nie ma interfejsu HexSPI o ile taki w ogóle istnieje, dlatego wysyłka danych została zrealizowana na zaawansowanym timerze i DMA. Aby wszystko działało timer musi być połączony z kontrolerem DMA, który ma możliwość zapisywania danych do urządzeń na AHB. W przypadku wielu STMów musi być to timer na APB2, bo te współpracują z DMA2, a tylko DMA2 może wykonywać transfery z/do AHB (gdzie jest GPIO). Dodatkowo timer musi posiadać tryb one pulse i rejestr powtórzeń RCR. Wszystkie warunki spełniają TIM1 i TIM8, które F730 posiada.
Konfiguracja TIM8 do wysyłki danych:

    lpTimerSpi = TIM8;
    RCC->APB2ENR |= RCC_APB2ENR_TIM8EN;

    gpioConfig(_GPIO_PC6, _GPIO_MODE_AF_PP | _GPIO_AF_MODE_3 | _GPIO_SPEED_HI);

    lpTimerSpi->CR1 = 0;
    lpTimerSpi->PSC = 1 - 1;
    lpTimerSpi->ARR = 16 - 1; // 13,5MHz
    lpTimerSpi->DIER = TIM_DIER_CC1DE;
    lpTimerSpi->SMCR = 0;
    lpTimerSpi->RCR = gFrameX;
    lpTimerSpi->CR2 = 0;
    lpTimerSpi->BDTR = TIM_BDTR_MOE;

    lpTimerSpi->CCMR1 = (0b111 << TIM_CCMR1_OC1M_Pos);
    lpTimerSpi->CCMR2 = 0;

    lpTimerSpi->CCER = TIM_CCER_CC1E;

    lpTimerSpi->CCR1 = 8;

    DMA2_Stream2->CR = 0;
    DMA2_Stream2->M0AR = (uint32_t)&lpBsrrData0[0];
    DMA2_Stream2->PAR = (uint32_t)&GPIOC->BSRR;
    DMA2_Stream2->NDTR = 0;

Procedura obsługi jest prosta, CPU przygotowuje dane, które zostaną wpakowane do rejestru BSRR portu C. Timer jest ustawiony w trybie OnePulse i 64 (ile pikseli jest w poziomie) powtórzenia. Na kanale CH1 generowany jest sygnał PWM z 50% wypełnieniem, który jest tu sygnałem CLK. Dane wystawiane są do pinów na porcie C przez DMA, wyzwalane zdarzeniem Capture/Compare kanalu 1. Kiedy DMA zakończy pracę timer wyłączy się sam (dzieki czemu przerwania "komunikacyjne" mogą mieć wyższy priorytet). Eksperymentalnie wyszło, że najszybszym zegarem naszego SPI, przy którym nie następują przekłamania, to około 14MHz. Obliczanie kolejnego pakietu danych jest wykonywane równolegle z ich wysyłką.

Konfiguracja TIM1 (BCM/OE): 

   lpTimerOe = TIM1;
    RCC->APB2ENR |= RCC_APB2ENR_TIM1EN;

    gpioConfig(_GPIO_PB1, _GPIO_MODE_AF_PP | _GPIO_AF_MODE_1 | _GPIO_SPEED_HI);

    lpTimerOe->CR1 = TIM_CR1_OPM | TIM_CR1_URS;
    lpTimerOe->PSC = 0;
    lpTimerOe->ARR = 0x03FF;
    lpTimerOe->DIER = TIM_DIER_UIE;
    lpTimerOe->SMCR = 0;
    lpTimerOe->CR2 = 0;
    lpTimerOe->BDTR = TIM_BDTR_MOE;

    lpTimerOe->CCMR1 = 0;
    lpTimerOe->CCMR2 = (0b110 << TIM_CCMR2_OC3M_Pos) | TIM_CCMR2_OC3FE;

    lpTimerOe->CCER = TIM_CCER_CC3NE;

    lpTimerOe->CCR3 = 0x300;
    lpTimerOe->EGR = TIM_EGR_UG;

Kiedy DMA zakończy wysyłkę danych, odpalane jest przerwanie. W tymże uruchamiany jest kolejny timer TIM1 w trybie OnePulse. Ten timer aktywuje sygnał OE, co powoduje wyświetlenie załadowanych wcześniej danych i wyzwolenie kolejnego przerwania gdzie wcześniej przygotowane dane są ładowane do nowego zestawu rejestrów.

Poczałkowo chciałem zrealizować wielobitowy kolor za pomocą PWM, ale po przekopaniu internetu zdecydowałem się na zastosowanie Binary Code Modulation. Co pozwala na zredukowanie liczby wysyłanych danych (8 razy przy 8 bitach) i czasu wyświetlania wiersza z 8 * 256 przy PWM do 256 przy BCM. Co daje minimalne wymaganie dla zegara naszego SPI na poziomie 3,3MHz. Dla każdego wiersza przemiatane są wszystkie ustawione bity koloru, a dopiero po ich wyświetleniu wiersz zmieniany jest na kolejny.
Kod przerwań:
 

__fast_func void nextRowBit()
{
    //SCB_CleanInvalidateDCache();

    uint32_t *pBuffer;

    if (buffer & 1)
    {
        pBuffer = &lpBsrrData1[0];
    }
    else
    {
        pBuffer = &lpBsrrData0[0];
    }

    DMA2_Stream2->M0AR = (uint32_t)pBuffer;
    DMA2_Stream2->NDTR = gFrameX + 1;
    DMA2_Stream2->CR = DMA_SPI_CONF;

    if (prevRow != row)
    {
        prevRow = row;
        selectNewRow(row);
    }

    lpTimerSpi->EGR = TIM_EGR_UG;
    lpTimerSpi->CR1 = TIM_CR1_CEN | TIM_CR1_OPM;

    lpTimerOe->PSC = lLut[bit];

    bit++;

    if (bit > (gScanBits - 1))
    {
        bit = 0;
        row++;

        if (row > (gScanRows - 1))
        {
            row = 0;
            lFrameCount++;
        }

    }

    buffer++;

    if (buffer & 1)
    {
        pBuffer = &lpBsrrData1[0];
    }
    else
    {
        pBuffer = &lpBsrrData0[0];
    }

    calcNewBsrr();
}

__fast_func void TIM1_UP_TIM10_IRQHandler()
{
    lpTimerOe->SR = 0;
    nextRowBit();
}

__fast_func void DMA2_Stream2_IRQHandler()
{
    GPIOC->BSRR = BIT_LAT_S;
    __ISB();
    __DSB();
    GPIOC->BSRR = BIT_LAT_R;
    
    lpTimerOe->SR = 0;
    lpTimerOe->EGR = TIM_EGR_UG;
    lpTimerOe->CR1 = TIM_CR1_CEN | TIM_CR1_OPM | TIM_CR1_URS;
    DMA2->LIFCR = DMA_LIFCR_CTCIF2;
}

Sumarycznie przy włączonym DCache, ICache oraz 216MHz da się uzyskać 54bitowy kolor, o ile można tolerować FPS na poziomie 48 klatek na sekundę. Ten wynik pewnie jeszcze dało by się poprawić nieco przeorganizowując wysyłkę danych i obliczenia. No ale 48Hz to stanowczo za mało, a mi starcza gorsze parametry, także zostałem przy 12bit kolorze (444) + 10bit globalnej jasności, przy którym FPS wzrasta do 460 klatek. To przy matrycy rozdzielczości 64x32, poszerzenie do 128x32 obniża FPS o około 40.

Sam układ projekt jest względnie prosty, bo to w sumie zasilanie, konwertery poziomów napięć i sam procesor, parę zbędnych pierdół jak odbiornik IR.

Do tego data flash 128Mbit (był najtańszy) dual SPI - na fonty i grafiki, mapowany do pamięci. Software poza tym, ze jest względnie kompatybilny z formatem danych używanym w max7219 to pozwala na rysowanie rzeczy przez kontroler, skoro i tak mam w urządzeniu dwa MCU z czego jeden obsługuje tylko ekran, to może w całości przejąć na siebie zadania rysowania i przechowywania potrzebnych do tego danych (a sam F730 ma tylko 64k flasha... no, w sumie to 512, ale pewne są tylko 64k).

Przy okazji okazało się, że da się uzyskać przerwanie końca transmisji SPI przy niewiadomej ilości danych + w pełni sprzętową obsługa transmisji przez urządzenie, choć konfiguracja jest nietypowa.
Normalnie kiedy pin NSS jest w trybie AF jako NSS ustawienie przerwania na EXTI nic nie daje, przerwanie nie działa. Ale kiedy ustawi się pin z przerwaniem w EXTI, włączy i skonfiguruje SPI i dopiero wtedy zmieni się na AF - to i SPI ma kontrolę nad pinem dzięki czemu samo zarządza transferem/DMA i możemy dostać przerwanie kiedy pin NSS zmienił stan na wysoki bez podłączania go do 2 pinów.

[marek1707]

A nie myślałeś o zwykłym FSMC (Flexible Static Memory Controller) w trybie NOR lub SRAM? Tam miałbyś transfer równoległy 8 bitów ze strobami/zegarami bez takiego wydziwiania. A moduł LTDC (LCD-TFT Display Controller)? Przecież to jest właśnie do tego, co Ty zrobiłeś "na piechotę".  No i są STMy z "poósmnym" SPI (Octo-SPI), ale to już raczej większe maszynki.

https://www.st.com/resource/en/application_note/dm00287603-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf

Trochę martwi te słabe 14MHz. Ciekawe czy ograniczenie jest po stronie panelu (wolne scalaki CD4000 lub HC czy nawet jakieś filtry na liniach lub brak terminacji), czy jednak nie dopasowałeś czegoś po swojej stronie? Jaki dokładnie jest timing tego co masz teraz? Jaki jest setup i hold time danych? Czy znasz wymagania panelu na te czasy? Użyłeś buforów 74ACT a to bardzo niebezpieczne układy na 5V. Są szybkie i mają spore wydajności (>70mA) a to przy braku dopasowania impedancji (po jednej lub drugiej stronie) prosta droga do dzwonów, odbić i błędów choćby z powodu wielokrotnych, fałszywych zegarów. Czy możesz pokazać jak wyglądają CLK i któryś bit danych zdjęte oscyloskopem >100MHz z masą sondy zapiętą bezpośrednio na masie w okolicach wejścia panelu?

[kaworu]

6 godzin temu, marek1707 napisał:

A nie myślałeś o zwykłym FSMC (Flexible Static Memory Controller) w trybie NOR lub SRAM? Tam miałbyś transfer równoległy 8 bitów ze strobami/zegarami bez takiego wydziwiania. A moduł LTDC (LCD-TFT Display Controller)? Przecież to jest właśnie do tego, co Ty zrobiłeś "na piechotę".

Myśleć myślałem, ale przykładowo F746I jest tylko ponad 3x droższy (2,5$ vs 9$) i ze cztery razy fizycznie większy. Akurat ten podany dla przykładu bo jest akurat dostępny, ale to i tak najtańsze co znalazłem i jest aktualnie dostępne z F7, o H7 (OSPI) to nawet nie wspomnę... a F4, kurde jeszcze większy potwór, STM32F469IIT6 do tego 16$. JLC ma widać problemy z dostawami.

6 godzin temu, marek1707 napisał:

Trochę martwi te słabe 14MHz. Ciekawe czy ograniczenie jest po stronie panelu (wolne scalaki CD4000 lub HC czy nawet jakieś filtry na liniach lub brak terminacji), czy jednak nie dopasowałeś czegoś po swojej stronie?

Po drodze doszedłem do tego, że w zasadzie działa szybciej, ponad 20, ale gdzieś w logice przerwań jest błąd i przestają działać po paru sekundach, potropię to w wolnej chwili.

6 godzin temu, marek1707 napisał:

Jaki dokładnie jest timing tego co masz teraz? Jaki jest setup i hold time danych? Czy znasz wymagania panelu na te czasy?

Oscyloskop twierdzi, ze dane są wystawiane równo na zboczu, więc przy 14MHz... nie wiem ile setup, ale hold jest praktycznie równy przez to okresowi zegara.

6 godzin temu, marek1707 napisał:

Czy możesz pokazać jak wyglądają CLK i któryś bit danych zdjęte oscyloskopem >100MHz z masą sondy zapiętą bezpośrednio na masie w okolicach wejścia panelu?

Jak będę miał potem chwile i złapię i podrzucę przebiegi.

Edytowano Luty 8, 2021 przez kaworu

[marek1707]

Jeśli zachowana jest signal integrity (to właśnie musisz sprawdzić po stronie panelu), to ten zerowy setup może być kluczowy. W jaki sposób wchodzi zegar na panel? Czy jest tam jakieś buforowanie? Może bramką/buforem Schmitta? To byłoby idealnie. Wtedy możesz spokojnie opóźnić zegar o kilka(naście) ns prostym układem RC (np. 51R+100pF). Bo jeśli niestety sygnał wchodzi bezpośrednio na wszystkie rejestry, to.. marny ten projekt. Wtedy linia musi być sterowana bardzo "sztywno" i raczej wypadałoby zrobić opóźnienie zegara na Twojej płytce, gdzieś między prockiem a 541, np. wspomnianym RC lub wstawiając tam szeregowo jedną-dwie nieodwracające brameczki 74LVC2G17 (dwie w jednym) lub przepuszaczajac zegar przez niewykorzystany, wolny kanał drugiego 541 (choć to może być za mało). No ale kluczowe jest upewnienie się, że panel widzi poprawny sygnał zegara bez odbić czy jakoś inaczej zniekształconego przedniego zbocza.

[kaworu]

1 minutę temu, marek1707 napisał:

W jaki sposób wchodzi zegar na panel? Czy jest tam jakieś buforowanie? Może bramką/buforem Schmitta?

O ile pamiętam, a wnioskuję z dzwonienia na linii zegarowej (jakby z winy ACT), nie ma tam żadnego bufora.

4 minuty temu, marek1707 napisał:

No ale kluczowe jest upewnienie się, że panel widzi poprawny sygnał zegara bez odbić czy jakoś inaczej zniekształconego przedniego zbocza.

Ale tak w sumie, to osiągi przy nawet 3MHz są wystarczające, więc nie jestem pewny czy jakieś intensywne walczenie z tym tematem ma głębszy sens (i jestem prawie pewien, brak poprawnego działania na 20MHz to wina programu, bo chwilę działa poprawnie). Jeszcze się zastanawiam nad wymianą 541 na HCT...

Tak w sumie to aktualnie F730 nawet nie mają na stanie, i nie wiadomo kiedy będą, więc nowych wersji i by mi nie zlutowali.

Tak czy inaczej jak będę w okolicy oscyloskopu to rzucę okiem na to co ciekawego się tam dzieje, bo w sumie nie sprawdzałem sygnału na wejściu, tylko na wyjściu bo coś nie grało z taktami.