Sterowanie wyświetlaczem LCD za pomocą mikrokontrolera.

[ElektronPL_WiTu]

Witam, szukam mikrokontrolera, który dałby radę sterować wyświetlaczem LCD, oto jego podstawy: matryca 160x240px 4:3 (piksele rozciągnięte w poziomie), 24-bitowy kolor (barwy wysyłane szeregowo po 8-bitowej magistrali), brak wbudowanej pamięci SRAM przez co sygnał o obrazie musi być ciągły a częstotliwość na linii zegarowej musi mieć około 9.7Mhz, wyświetlacz do pracy wymaga sygnałów D0-D7, VSYNC, HSYNC, CLK czyli łącznie potrzebne jest 11 pinów (jeszcze komunikacja a'la SPI do ustawień wyświetlacza, ale ją będę sterować z innego układu) 

Datasheet: https://www.beck-elektronik-display.de/fileadmin/user_upload/Produkte/BECK_Display/Downloads/AUO/A025CN05.V2.pdf

Ja myślę o użyciu ESP32, bo ma wystarczającą ilość pinów, jest szybkie i ma wymaganą ilość pamięci SRAM (115200 bajtów). Dodam, że odpaliłem ten wyświetlacz na Arduino DUE i było tylko trochę za wolno, a ESP32 jest 2-rdzeniowe, to jeszcze mogłoby się komunikować np. przez i2c z resztą projektu. (nie zależy mi na wifi czy bluetooth) Jeśli ESP32 było by ok, to proszę o pomoc jak zmusić to aby 1 rdzeń zajmował się tylko wyświetlaczem, a drugi tylko prostymi czynnościami jak komunikacja I2C. Chciałbym poznać opinię eksperta w tym temacie. 

Pozdrawiam!

[ethanak]

6 godzin temu, ElektronPL_WiTu napisał:

eśli ESP32 było by ok, to proszę o pomoc jak zmusić to aby 1 rdzeń zajmował się tylko wyświetlaczem, a drugi tylko prostymi czynnościami jak komunikacja I2C

Masz funkcję xTaskCreatePinnedToCore która do tego służy, oprócz tego portENTER_CRITICAL i portEXIT_CRITICAL do synchronizacji. Bliższe informacje: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/freertos.html#task-api

 

[Elvis]

Moim zdaniem przypisywanie zadania do rdzenia wcale nie jest potrzebne - wystarczy do zadania, które steruje LCD przypisać wyższy priorytet.

[ethanak]

13 minut temu, Elvis napisał:

wystarczy do zadania, które steruje LCD przypisać wyższy priorytet.

i wtedy wszystko się będzie kręcić na jednym rdzeniu - ćwiczyłem to przy okazji theremina.

[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]

Nie testowałem implementacji FreeRTOS-a na ESP32, ale ogólnie jeśli jest zadanie o wyższym priorytecie to powinno być zawsze wykonywane jako pierwsze. Więc na jednym rdzeniu nic poza nim nie powinno działać. Ale muszę to sprawdzić, bo w sumie ciekawe jak to faktycznie działa na esp.

[ethanak]

Na ESP jest trochę inaczej (w sumie z tego co wiem to różnice wynikają z dwóch rdzeni i konieczności synchronizacji dostępu do danych) - ale tu nie o to chodzi. Po prostu jeśli wyświetlacz potrzebuje dostarczania danych w czasie rzeczywistym (coś podobnego jak u mnie generowanie dźwięku) to wywalenie go na oddzielny rdzeń to chyba dobry pomysł - bo nic mu nie przeszkadza, a z drugiej strony wyświetlacz nie przeszkadza innym funkcjom programu. Tak mi się przynajmniej wydaje...

[Elvis]

Zakładałem że scheduler na ESP32 używa dwóch rdzeni i sam uruchomi zadanie na drugim. Ale możliwe, że to było zbyt optymistyczne założenie. Wydawało mi się, że użycie priorytetów jest mniej "inwazyjne" niż wskazywanie rdzenia, ale oczywiście użycie xTaskCreatePinnedToCore zadziała na pewno, a z priorytetami trzeba byłoby przetestować.

[ethanak]

O ile wiem, w ESP jest tak, że jeden rdzeń zajmuje się WiFi i innymi tego typu nudnymi sprawami, a drugi jest do dyspozycji użytkownika. Ale mogę się oczywiście mylić... mam tu co prawda na biurku jedną sztukę ESP ale ostatnio jakoś z czasem nietęgo... będziesz coś testować? Bo temat niezmiernie interesujący!

[Elvis]

Też mnie to zainteresowało, ale chwilowo trochę brak czasu 😞 Jeśli coś przetestujesz to chętnie się dowiem jak to z tym FreeRTOS-em na esp32 jest 🙂

[ElektronPL_WiTu]

Dzisiaj przyszło do mnie ESP32 i próbowałem bezskutecznie uruchomić ten wyświetlacz. Ale znam już powód tylko nie wiem jak to rozwiązać. Ale od początku, gdy ekran nie działał na porcie kodu z DUE napisałem kod który w teorii działa tak że rdzeń #0 jest nie w ogóle używany a #1 daje tylko sygnał linii zegarowej. Wygląda to tak:

TaskHandle_t Task2;

void setup() {
  pinMode(23, OUTPUT);
  pinMode(0, OUTPUT);

  xTaskCreatePinnedToCore(
    Task2code,   /* Task function. */
    "Task2",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task2,      /* Task handle to keep track of created task */
    1);          /* pin task to core 1 */
}

void Task2code( void * pvParameters )
{
  while (true)
  {
    GPIO.out_w1tc = 1;
    GPIO.out_w1ts = 1;
  }
}

void loop() {}

I jak przepinałem pin CLK wyświetlacza z DUE do ESP32 to nie działa. Niestety nie mam oscyloskopu, żeby zobaczyć co się dzieje na tej linii ESP32, ale w iście hakerski sposób zrobiłem "oscyloskop" z tego wyświetlacza który uruchamiam. A wygląda to tak: linie CLK VSYNC HSYNC są podłączone do DUE a linię D7 (bit największej wagi)  podłączyłem do ESP32 do pinu 0, (D7 to jest jak by wejście oscyloskopu) i wszystko stało się jasne - co chwilę rdzeń zatrzymuje prace i na wyjściu pojawia się stan 0. Widać to na zdjęciu, że co chwile jest czarny pasek. (generalnie ten kolorowy szum powinien być na całym wyświetlaczu)

 

Co mogę z tym zrobić?

Edytowano Maj 13, 2020 przez ElektronPL_WiTu

[ElektronPL_WiTu]

Dobra udało mi się coś ruszyć - gdy ustawiłem priorytet na 255 oraz uruchomiłem zadanie na rdzeniu #0 to wyświetlacz zadziałał. (na rdzeniu #1 nie rusza) Ale oczywiście, czego się spodziewałem, co chwilę ESP32 się resetuje...

Który rdzeń zajmuje się wifi/bt, i czy można te funkcje powyłączać, bo w projekcie tego nie potrzebuje a myślę że to też może być powodem nie działania wyświetlacza na rdzeniu #1. Poza tym, gdy odpalam kod sterowania wyświetlaczem na rdzeniu #1 to ESP32 się nie resetuje, więc teoretycznie gdyby się udało na nim uruchomić wyświetlacz to problem rozwiązany. Aha jeszcze jedna sprawa - mimo że wyświetlacz startuje to gdy spojrzałem na linię zegarową tym "oscyloskopem" to wciąż mini czarne paseczki się gdzieś tam pojawiały a to może powodować sporadyczny reset wyświetlacza i cholera wie co jeszcze. Czy jest jakiś sposób żebym miał większą kontrolę nad tym czym zajmuje się ta płytka?

[Elvis]

Oczywiście, że taki sposób istnieje. Możesz po prostu wyrzucić FreeRTOS, przejąć pełną kontrolę i wszystko sam zrobić. Będzie to dość trudne, ale jak najbardziej możliwe.

Wydaje mi się jednak, że po prostu źle do tego podchodzisz. W przypadku AVR takie sterowanie pinami mając policzone takty zegara działało - w nowszych układach będzie bardzo skomplikowane. O wiele łatwiej i dokładniej byłoby użyć do tego odpowiednich modułów peryferyjnych. Do odmierzania czasu - timer, a do transmisji DMA.

[ethanak]

4 godziny temu, ElektronPL_WiTu napisał:

Ale oczywiście, czego się spodziewałem, co chwilę ESP32 się resetuje...

Strzelam: watchdog?

Bo oczywiście sprawdziłeś dlaczego się resetuje...

[ElektronPL_WiTu]

No fajnie by było timery i DMA ale zupełnie nie wiem jak się do tego zabrać...

Fakt może być watchdog, nie sprawdziłem jestem w tym nowy i nawet nie zdawałem sobie sprawy że się da 😛 jak to można sprawdzić?

Edytowano Maj 14, 2020 przez ElektronPL_WiTu

[ethanak]

2 godziny temu, ElektronPL_WiTu napisał:

No fajnie by było timery i DMA ale zupełnie nie wiem jak się do tego zabrać...

Bez tego raczej nie ruszysz...

Możesz spróbować pokombinować z czymś takim: przypnij wyświetlacz do core 0 i co jakiś czas (np. przy VSYNC) daj mu vTaskDelay(1). Watchdog nie powinien się burzyć. Tyle że to będzie proteza... coś w stylu:
 

digitalWrite(VSYNC_PIN,1);
vTaskDelay(1);
digitalWrite(VSYNC_PIN,0);

(o ile milisekunda będzie dobrym czasem dla VSYNC). Sprawdź... może zadziała?

2 godziny temu, ElektronPL_WiTu napisał:

Fakt może być watchdog, nie sprawdziłem jestem w tym nowy i nawet nie zdawałem sobie sprawy że się da 😛 jak to można sprawdzić?

ESP przy starcie (jeśli ma ustawiony port debug oczywiście, w menu IDE się to ustawia) wypisuje na serialu m.in. informację dlaczego się zrestartował. Co prawda ta informacja jest niespecjalnie intuicyjna - ale jest. W Twoim przypadku najprawdopodobniej watchdog uznał, że program wlazł w jakąś nieskończoną pętlę i na wszelki wypadek zresetował całe ustrojstwo...

Oczywiście watchdoga można wyłączyć, ale co będzie jeśli program faktycznie wlezie w jakieś while(1){} Albo pochrzanisz coś z mutexami i będzie chciał czekać na dostęp do danych?