Płytka developerska PIC wyświetlająca obraz na TV (generacja sygnału PAL)

Witajcie moi drodzy

Dzisiaj pokażę wam moją kolejną płytkę rozwojową z mikrokontrolerem PIC, tym razem pozwalającą na generowanie sygnału PAL, czyli na wyświetlanie danych na telewizorze.

Wstęp
Są różne sposoby na wyświetlanie informacji z mikrokontrolera. Najczęściej korzysta się z wyświetlaczy LCD (z reguły opartych na HD44780), wyświetlaczy LED 7-segmentowych, bądź takimi od Nokii 3310 i podobnych. Ale te wszystkie metody są już opisane wiele razy w sieci na wszelke możliwe sposoby. Ja chcialem zająć się czymś bardziej nietypowym i mniej popularnym, więc wybrałem... wyświetlanie danych na TV!

Parametry płytki
Mikroprocesor: PIC18F4620
Taktowanie: 32MHz (oscylator 8MHz z PLL x 4)
Rodzaj generowanego sygnału: PAL (czarno-biały)
Rozdzielczość generowanego obrazku: 128x128 (można zwiększyć, ale ogranicza nas ilość pamięci RAM)
Czcionka: 256 znaków (ASCII+dodatkowe znaki)
Programowanie: poprzez ICSP programatora takiego jak PICKIT2 lub PICKIT3
Zasilanie: bezpośrednio z ICSP (5V, wymaga ściągnięcia zworki) bądź z zasilacza 9V lub 12V poprzez stabilizator 7805.
Złącza: SCART, RCA
Wymiary: 10cm x 9cm
Dodatkowo:
- gniazdo RS232 z MAX232
- dwie kości EEPROM (nie są potrzebne do generowania sygnału video)
Uwaga: cały PORTC na płytce jest zajęty ze względu na to jak działa generacja sygnału video. Pozostałe dostępne porty są wyprowadzone na goldpiny i dostępny do użytku.

Użycie innego mikroprocesora?
Projekt w przedstawionej tu wersji używa PIC18F4620, ale kod można by bez większego problemu skompilować pod innego PICa z rodziny 18F. Jednak należy rozważyć użycie pamięci RAM przez bufor obrazu.
W przedstawionej tu wersji mamy rozdzielczość 128 na 128.
Daje to w sumie 16384 pikseli.
Jest to obraz czarno biały, więc mamy 1 bit na piksel, co daje nam 2048 bajtów pamięci RAM potrzebnych na sam bufor obrazu.
PIC18F4620 użyty tutaj ma 3968 bajtów RAM, więc całość się mieści.
Natomiast np. popularniejszy PIC18F4550 ma 2048 bajtów RAM, więc nie dałby tutaj rady, bo jeszcze w RAM musi być miejsce na parę innych drobniejszych rzeczy.
Kod można by odpalić też na PIC18F4550, ale tylko przy mniejszej rozdzielczości generowanego obrazu.






Projekt płytki
Projekt płytki wykonałem w Eagle. Płytka jest jednostronna, ścieżki są grubsze, wszystko można bez problemu wykonać metodą termotransferu.

Uwaga: na projekcie płytki nie są uwzględnione kondensatory 22pF (lub zbliżona wartość) pomiędzy pinami rezonatora a masą. Powinno się je tam dodać, tak jak sugeruje datasheet, bo bez nich PIC może działać niestabilnie.

Tak prezentowała się płytka po prawie całym wykonaniu (brakuje m. in. opcjonalnych rezystorów pull-up przy porcie A i przycisku RESET):



Kosztorys
Podstawowa wersja, tzn. bez pamięci i RS232:
- PIC18F4620 - 24 zł
- 7805 - 1 zł
- rezonator 8MHz - 1 zł
- złącze SCART z wylutu - 0 zł
- złącze RCA z wylutu - 0 zł
- drobnica (kondensatory, goldpiny) - 5 zł
SUMA (wersja podstawowa): niecałe 30 zł
Wersja pełna:
- MAX232 - 6 zł
- 24AA128P x 2- 8 zł
- złącze RS232 DSUB9 - 1 zł
- drobnica (kondensatory, goldpiny) - 5 zł
SUMA (wersja pełna): 50 zł


Kod projektu i jego kompilacja
Projekt napisany jest w mikroC PRO for PIC. Generacja PAL oparta jest na bibliotece autorstwa Bruno Gavand. Przy kompilacji projektu proszę zwrócić uwagę na dwa istotne szczegóły:
- wartość rezonatora w ustawieniach projektu wpisana jest po przemnożeniu przez PLL, czyli 32MHz, a nie 8MHz, mimo iż taki rezonator jest użyty.

- przy kompilacji należy wyłączyć optymalizacje (ustawić jej poziom na 0), ponieważ optymalizacja psuje timingi generacji PAL i TV traci synchronizacje


Testowanie płytki
Na początek mały testowy program. Wyświetla najpierw parę linii- animacje rysowania, pokazuje czcionkę, a następnie wykonuje skan urządzeń podlączonych do magistrali I2C na płytce. Gdy obie pamięci są w socketach, to na ekranie powinny wyświetlić sie ich adresy.

Początkowy ekran

Test czcionki

Test animacji (do tego jest jeszcze ruch obiektu po ekranie, ale nie udało mi się tego ładnie uchwycić aparatem):

Skan I2C wraz z odczytanymi adresami EEPROMów:


Zastosowanie płytki - prosta gra Tetris
Mało praktyczne, ale ciekawe zastosowanie. Na płytce można zrealizować proste, czarno-białe gry od telewizor. Programowanie ich różni się znacznie od programowania gier na PC, ponieważ trzeba wziąć pod uwagę wiele czynników takich jak np. migotanie ekranu przy odświeżeniu. W tym celu w moim Tetrisie przy przesunięciu klocka tylko odświeżam te piksele, które uległy zmianie.
Tak prezentuje się ekran początkowy gry:

No i gra w akcji:

Game over:


Gra korzysta z dwóch przycisków, które są już na płytce. Pozwalają one przesuwać klocek w obie strony, a jednoczesne wciśnięcie ich obraca klocek.

Zastosowanie płytki - prosty terminal RS232
Teraz coś bardziej praktycznego. Prosty terminal RS232, który wyświetla odebrane informacje na ekranie telewizora. Na płytce znajduje się gniazdo RS232 i MAX232, więc nie potrzebna żadnych dodatkowych konwerterów by odebrać informacje bezpośrednio z kompa, ale oczywiście można też podpiąć się bezpośrednio do wyprowadzonych pinów RX/TX od PICa (tam są już poziomy TTL).
Całość prezentuje się tak:


Moduł testowałem z pomocą Arduino:

Jak widać, zaimplementowane jest również "dzielenie linii" jeśli całość nie mieści się w jednym wierszu.
Może i wydawać się banalne, ale w połączeniu z małym telewizorkiem przenośnym (ja mam model TOP2001) taki terminalek może być przydatny. Sam z niego korzystam, jeśli chodzi o sam odbiór danych UART jest to dla mnie wygodniejsze niż konwerter na USB (zajmujący jeden slot USB) i otwieranie terminala na komputerze.
Całość można by jeszcze rozwinąć o wsparcie klawiatury na PS/2 i wtedy można by było również wysyłać dane po UART.

Testy z nowszym telewizorem (LCD firmy LG)
Nowoczesne telewizory również nie mają problemu z odbiorem generowanego sygnału. Płytkę można podłączyć zarówno kablem SCART jak i RCA, w obu przypadkach sygnał odbierany jest bez problemów i zakłóceń.

Test podłączenia kable RCA

Po podłączeniu i uruchomieniu płytki telewizor wykrywa sygnał:

I poprawnie wyświetla obraz:

Test podłączenia kablem SCART

Po podłączeniu i uruchomieniu płytki telewizor wykrywa sygnał:

I również poprawnie wyświetla obraz:

Zatem jak najbardziej można użyć całości z nowszym sprzętem.

Podsumowanie
Ten projekt był jednym z ciekawszych, które do tej pory udało mi się zrobić. Co prawda może nie jest za bardzo praktyczny, ale na pewno jest czymś nowym w porównaniu z wałkowanymi setki razy wyświetlaczami na HD itp. Zrobiona płytka do tej pory służy mi w postaci terminalu UART i ułatwia testowanie nastepych projektów.

Fajne! Ranking DIY

Na schemacie jest PIC 4550, a nie 4620 - cos pomyliłeś.

Freddy napisał:

Na schemacie jest PIC 4550, a nie 4620 - cos pomyliłeś.

Dobra uwaga, ale w rzeczywistości jest to 4620 tak jak napisałem. Po prostu nie mogłem znaleźć 4620 w Eagle więc wstawiłem niemalże identycznego 4550. Ich wyjścia się niemalże zgadzają, z tą różnicą, że 4550 ma USB, a 4620 nie, oraz I2C jest pod innymi pinami.

PDF schematu zaktualizowałem, by PIC był podpisany jako 4620.

No i jeszcze jedno - w tym przypadku to nie może być 4550, bo by brakło RAMu.
Proste obliczenie:
Rozdzielczość ekranu 128 na 128, daje nam 16384 pikseli.
Przyjmujemy 1 bit na piksel, więc potrzebujemy 16384/8 = 2048 bajtów pamięci RAM.
PIC18F4550 ma 2048 bajtów RAM, ale wiadomo, że jeszcze są dodatkowe zmienne, więc odpada, ma za mało pamięci.
PIC18F4620 ma 3968 bajtów RAM, więc dla obrazu 128 na 128 starcza z nadwyżką.

Całość można by odpalić na PIC18F4550, ale:
- przy troszkę mniejszej rozdzielczości
- trzeba by inaczej pociągnąć zworki/kabelki od I2C
- nie gwarantuję, że USB z tą generacją PAL zadziała, bo ona jest trochę wybredna i zajmuje jedne przerwanie oraz czas procesora (jak się przesadzi z zajmowaniem czasu mikroprocesora to po prostu timingi są złe i obraz się nie generuje - trafiłem na ten problem gdy chciałem zrobić w jednym hexie i demko wyświetlania, i skaner I2C, i odbiór UART, i tetrisa)

PS: Dla jasności dopisałem do pierwszego postu akapit o użyciu innego PICa.

AVE...

Czemu nie dodać do portu SPI pamięci SRAM za złotówkę? Nie dość, że będziesz mógł wywalić pamięć obrazu z RAMu mikrokontrolera, to jeszcze bez problemów będziesz miał i większą rozdzielczość, i opcjonalnie wszystkie kolory, o jakich mógłbyś marzyć. Minusem byłaby konieczność zamiany stabilizatora 7805 na jakiś dający 3,3V lub na małą przetwornicę step-down (dla lepszej wydajności)...

Umieszczenie bufora ramki w zewnętrznej pamięci SPI strasznie komplikuje dostęp do pamięci z aplikacji, chociaż tu w sumie i tak dane są przesyłane całkowicie programowo, więc modyfikacja obrazu może zachodzić tylko w czasie sygnałów synchronizacji, czyli też łatwo nie jest. Z kolorami byłby problem w PAL, bo rzeba jeszcze wygenerować odpowiedni sygnał koloru, a to nie jest tylko proste złożenie kilku bitów.
Ja bym przede wszystkim użył procka z DMA, co znacznie odciąża rdzeń i ułatwia modyfikację GRAM przez aplikację, niezależnie od wyświetlania obrazu. Sensowne timery do generacji synchronizacji też są wskazane.
BTW, widzę, że procek nie jest taktowany z kwarcu, jitter zegara nie przeszkadza zbytnio? W AVR jak robiłem coś takiego to na wewnętrznym oscylatorze było widać delikatne drgania obrazu, które zniknęły po zastosowaniu kwarcu. Jitter zegara był na poziomie ns. Co ciekawe taki jitter uniemożliwał synchronizację monitora.

Lubie takie projekty, ale zawsze przed oczami mam przy takiej okazji znane demo
http://www.linusakesson.net/scene/craft/
i zawsze się przy tym zastanawiam co jeszcze ludzie wymyślą na te "biedne" mikrokontrolery - a to tylko atmega88

tmf napisał:

Umieszczenie bufora ramki w zewnętrznej pamięci SPI strasznie komplikuje dostęp do pamięci z aplikacji, ...

Z tym się właściwie w pełni nie zgodzę. Jeżeli zastosować pamięć SPI np. 23K256 można wykorzystać jej wyjście danych jako od razu wyjście jednobitowego obrazu. Naturalnie trzeba dołożyć sygnały synchronizacji a obraz zmieniać będzie można w trakcie powrotów pionowych. Układ 23K256 może przesyłać dane otrzymując same impulsy zegara po odpowiednim zaprogramowaniu stosownym poleceniem i adresem początkowym. To właśnie proponowałbym wykorzystać. W takiej sytuacji każda linia jest generowana w dużej mierze sprzętowo. Konieczne byłyby odpowiednio bramkowane impulsy zegara pamięci SPI.

maciej_333 napisał:

tmf napisał:

Umieszczenie bufora ramki w zewnętrznej pamięci SPI strasznie komplikuje dostęp do pamięci z aplikacji, ...

Z tym się właściwie w pełni nie zgodzę. Jeżeli zastosować pamięć SPI np. 23K256 można wykorzystać jej wyjście danych jako od razu wyjście jednobitowego obrazu. Naturalnie trzeba dołożyć sygnały synchronizacji a obraz zmieniać będzie można w trakcie powrotów pionowych. Układ 23K256 może przesyłać dane otrzymując same impulsy zegara po odpowiednim zaprogramowaniu stosownym poleceniem i adresem początkowym. To właśnie proponowałbym wykorzystać. W takiej sytuacji każda linia jest generowana w dużej mierze sprzętowo. Konieczne byłyby odpowiednio bramkowane impulsy zegara pamięci SPI.

Sprzętowo możnaby obraz wysyłać, gdyby na SCK podać przebieg z timera, który ma możliwość generowania określonej liczby impulsów (jedna linia obrazu). To samo można osiągnąć przez DMA + SPI, jeśli procek DMA posiada.
Niemniej wykorzystanie zewnętrznej pamięci SPI wcale nie ułatwia życia.Na czas generowania linii program nie ma dostępu do pamięci (adres komórki jest autoinkrementowany i zaburzenie tego spowoduje zaburzenie generowania obrazu). Dostęp będzie jedynie podczas synchronizacji poziomej/pionowej, i będzie wymagał zapisu rejestru adresowego pamięci, następnie modyfikacji danych i odtworzeniu rejestru adresowego, tak aby wskazywał na kolejną linię obrazu przez zakończeniem synchronizacji. Jeśli wykorzystujemy wewnętrzną pamięć i DMA wyświetlanie i dostęp do pamięci to będą dwie niezależne od siebie sprawy. Dodatkowo życie ułatwia to, że często SPI lub USART w trybie SPI mają zbuforowany rejestr nadajnika, tak, że masz 2-3 bajtowy bufor i ew. zaburzenia dostępu do RAM nie powodują zaburzenia generowania obrazu, bo dane jeszcze lecą z bufora. Daje to też więcej czasu na dostęp do RAM w czasie synchronizacji. W przypadku pamięci SPI nie masz bufora, a dodatkowo linia MISO będzie wykorzystywana do transferu danych MCU-pamięć. Jest jeszcze jeden problem - MISO w czasie synchronizacji powinno mieć stan niski, więc zachodzi jeszcze potrzeba dodania bufora trójstanowego sterowanego z MCU. Są pamięci szeregowo-równoległe, np. z firmy VLSI, które nieco ułatwiają implementację bufora ramki.

Można by wziąć dwie pamięci SPI i podłączyć je do dróch różnych interfejsów. Z jednej byłby generowany obraz do wyświetlenia, a jednocześnie do drugiej można by ładować nowy obraz. Kiedy będzie już załadowany, to multiplekserem przełączyć wyjścia z tych pamięci i heja. To wcale nie takie trudne

Witam, ten projekt nadaje się do sterowania telewizora LCD ?

Tak, ale tylko po wejściu composite. Lepiej go przerobić, żeby skorzystać z wejścia RGB - masz wtedy prosty do realizacji kolor.

tmf napisał:

masz wtedy prosty do realizacji kolor

Tyle, że wtedy braknie pamięci na obraz i bardziej skomplikowane jest sterowanie .

Zamiast korzystać z bufora obrazu (ramki), można generować obraz "w locie" - tak działały np. konsole Atari 2600, które miały zaledwie 128 bajów pamięci RAM.

komatssu napisał:

Zamiast korzystać z bufora obrazu (ramki), można generować obraz "w locie" - tak działały np. konsole Atari 2600, które miały zaledwie 128 bajów pamięci RAM.

... i specjalizowany układ graficzny .

Freddy napisał:

tmf napisał:

masz wtedy prosty do realizacji kolor

Tyle, że wtedy braknie pamięci na obraz i bardziej skomplikowane jest sterowanie .

To oczywista sprawa, że trzeba użyć procka, który ma odpowiednią ilość pamięci, lub interfejs do pamięci zewnętrznej. Sterowanie wcale nie jest bardziej skomplikowane. Generacja synchronizacji jest identyczna, a nawet prostsza, bo RGB ma rozdzielony H i V-sync, na RGB podaje się sygnał z DACa złożonego z drabinki R-2R, a sygnał na drabinkę przy pomocy np. 8-bitowego latcha synchronizowanego zegarem pikseli. Brzmi poważnie, ale kod realizujący to, to dosłownie kilka linii kodu - przykład dla AVR XMEGA pokazałem w którejś z książek i można pobrać darmowy kod do zabawy.
Jeśli wystarcza tryb alfanumeryczny, to nic nie stoi na przeszkodzie, aby generować obraz w locie na podstawie tablicy znaków. Wbrew pozorom nie jest to specjalnie obciążające dla procka i żadne specjalizowane układy nie są potrzebne. 8-bitowce się wyrabiają z zapasem.
Prawdziwym wyzwaniem byłoby wygenerowanie sygnału po HDMI

tmf napisał:

Prawdziwym wyzwaniem byłoby wygenerowanie sygnału po HDMI

Zgadza sie, choc z tego co pamiętam, Analog i Linear robi dośc pomocne układy do HDMI.

AVE...

Zawsze można zamienić ośmiobitowca na szesnastobitowca, na przykład na PIC24HJ128GP202, który zapewnia 8kB pamięci RAM i DMA dla większości peryferiów. Można sięgnąć po coś większego, jak na przykład dsPIC33EP512GP506 (dla którego robię płytkę prototypową (ale mam problemy z fototransferem))...

Do generowania monochromatycznego sygnału composite video wystarczą dwa piny, po co wykorzystujesz cały port?

leonow32 napisał:

Można by wziąć dwie pamięci SPI i podłączyć je do dróch różnych interfejsów. Z jednej byłby generowany obraz do wyświetlenia, a jednocześnie do drugiej można by ładować nowy obraz. Kiedy będzie już załadowany, to multiplekserem przełączyć wyjścia z tych pamięci i heja. To wcale nie takie trudne

Przypomniało mi się
https://obrazki.elektroda.pl/87_1216908807.jpg
(źródło: https://www.elektroda.pl/rtvforum/topic1060540.html)

Freddy napisał:

... i specjalizowany układ graficzny .

Sugerujesz że się nie da?
http://belogic.com/uzebox/howitsmade.htm

Milek79 napisał:

Sugerujesz że się nie da?

Czytaj ze zrozumieniem, poza tym to jest w NTSC.

Urgon napisał:

AVE...

Zawsze można zamienić ośmiobitowca na szesnastobitowca, na przykład na PIC24HJ128GP202, który zapewnia 8kB pamięci RAM i DMA dla większości peryferiów. Można sięgnąć po coś większego, jak na przykład dsPIC33EP512GP506 (dla którego robię płytkę prototypową (ale mam problemy z fototransferem))...

Jeśli to musi być na PICu. Bo z 8-bitowców 32 kB RAM i DMA posiada np. XMEGA. Generalnie generowanie obrazu nie jest jakimś wielkim wyzwaniem dla procesora.

Freddy napisał:

Milek79 napisał:

Sugerujesz że się nie da?

Czytaj ze zrozumieniem, poza tym to jest w NTSC.

To może byś tak wytłumaczył co miałeś na myśli?
I co ma do tego że NTSC? Autor jest pewnie w USA to sobie zrobił NTSC, zmiana na PAL to tylko drobna zmiana timingów i zmiana scalaka do konwersji kolorów z RGB na NTSC.

@Milek79
Hmmm, tak, tak oczywiście masz rację - poczytaj o standardach .
Poczytaj też jeszcze raz cały temat - o czym piszemy.

@Armageddon22, wydaje mi się że nie masz racji. W handlu dostępne są bardzo tanie małe monitory analogowe, które z powodzeniem mogą służyć do podglądu danych generowanych przez taki i podobne układy.

@Armageddon22 nie mierz wszystkich swoją miarą. Takie rozwiązania sa bardzo popularne w systemach FPV gdzie z różnych względów króluje analogowe video. To też jest bez sensu?



Oczywiście dla takiego efektu potrzeby jest jeszcze układ umożliwiający synchronizacje dwóch obrazów np. LM1881

Nie trzeba żadnych układów, taki overlay zrobisz bez problemu na ATMedze...

http://www.embedds.com/simple-video-overlay-on-atmega8/
http://nootropicdesign.com/projectlab/2011/05/20/overlay-gps-on-video/

W FPV króluje analog, gdyż jest prosty i w czytelny sposób "informuje" o utracie zasięgu. Niemniej pewnie już nie długo, bo DSM-X w porównaniu z analogową aparaturą 27MHz to przełom (choć konserwatyzm, jest spory, bo DSM-X nadal generuje analogowe sygnały sterujące).

tzok napisał:

Nie trzeba żadnych układów, taki overlay zrobisz bez problemu na ATMedze...
http://www.embedds.com/simple-video-overlay-on-atmega8/
http://nootropicdesign.com/projectlab/2011/05/20/overlay-gps-on-video/

Może i nie trzeba, ale obydwa twoje przykłady są z użyciem separatora LM1881
Pewnie da się to zrobić programowo, ale to było by naprawdę skomplikowane, do tego dochodziło by generowanie obrazu. Wymagało by to mocnego procesora i szybkiego ADC. Nie ma sensu kombinowac jak jeden mały układzik załatwia wszystko to bezbłędnie.

tzok napisał:

W FPV króluje analog, gdyż jest prosty i w czytelny sposób "informuje" o utracie zasięgu. Niemniej pewnie już nie długo, bo DSM-X w porównaniu z analogową aparaturą 27MHz to przełom (choć konserwatyzm, jest spory, bo DSM-X nadal generuje analogowe sygnały sterujące).

Sterowanie jest już od dawna zdominowane przez cyfrowe systemy. Chodziło mi o analogowe video z kamer do podglądu "oczami" sterowanego pojazdu. Faktycznie przy utracie zasięgu jest szansa na to żeby coś tam jeszcze zobaczyć, ale przede wszystkim przewagą analoga jest to że wznowiona transmisja jest momentalnie widoczna, praktycznie bez opóźnień. W systemach cyfrowych wymaga to chwili czasu. Pomijam już to że odpadają układy kompresji które wnosza opóźnienia i pobierają dodatkowy prąd.

electro napisał:

tzok napisał:

Nie trzeba żadnych układów, taki overlay zrobisz bez problemu na ATMedze...
http://www.embedds.com/simple-video-overlay-on-atmega8/
http://nootropicdesign.com/projectlab/2011/05/20/overlay-gps-on-video/

Może i nie trzeba, ale obydwa twoje przykłady są z użyciem separatora LM1881
Pewnie da się to zrobić programowo, ale to było by naprawdę skomplikowane, do tego dochodziło by generowanie obrazu. Wymagało by to mocnego procesora i szybkiego ADC. Nie ma sensu kombinowac jak jeden mały układzik załatwia wszystko to bezbłędnie.

LM1881 nie jest potrzebny, a detekcja impulsów synchronizacji wcale nie obciąża procka. Jesli procek ma na pokładzie komparator analogowy i sensowny timer, to całość można zrobić sprzętowo. Zajrzyj do przykłądów z mojej stopki - znajdziesz tam overlay na LM1881 i na gołym procku (XMEGA). Całość jest prosta, bo impulsy synchronizacji są łatwowykrywalne - po prostu napięcie poniżej poziomu czerni.