Sterowanie wyświetlaczem TFT - część 1

[Elvis]

Jeszcze niedawno pisałeś o 1m. RS-232 na 30m raczej nie wystarczy, do tego to raczej RS-485 by się przydał, ale chyba prościej dać zwykły ethernet.

[marek1707]

22 minuty temu, SOYER napisał:

wiem, że są takie podłączane do kompa, wystarczy?

Gdy używasz wytrycha, suwmiarka nie jest już potrzebna.

22 minuty temu, SOYER napisał:

jeden przy Arduino, drugi przy ekranie i 30 metrów to nie problem?

Tak, bierz ten moduł w ciemno. Zadziała. Jedyne co przemyśl to sposób zasilania dwóch odległych stacji. Czy puścisz zasilanie po kablu (no ale wtedy jakieś wyższe by była szansa zrobienia po drugiej stronie dobrych 5V) czy dwa osobne zasilacze z jakiegoś najbliższego gniazdka AC. Tak czy tak, RS232 nie ma izolacji więc masy muszą być połączone.

EDIT: Ha, ciekawe co SOYER teraz zrobi  

Edytowano Luty 11, 2021 przez marek1707

[SOYER]

1 godzinę temu, marek1707 napisał:

Gdy używasz wytrycha, suwmiarka nie jest już potrzebna

Nie łapię.

1 godzinę temu, Elvis napisał:

ale chyba prościej dać zwykły ethernet.

Tzn.?

1 godzinę temu, marek1707 napisał:

Ha, ciekawe co SOYER teraz zrobi

Soyer najpierw musi znaleźć czas by oprogramować ten wyświetlacz.

Druga rzecz, jedno ardu Mega, dwa nextiony sterowane przez uart, to wyższe wtajemniczenie, czy igraszka? Na obu ekranach generalnie to samo, po prostu jeden w salonie, drugi w piwnicy.

Edytowano Luty 11, 2021 przez SOYER

[Elvis]

@SOYER Chodziło mi o to, że dla RS-232 jest bardzo łatwo, wystarczy dodać dwa konwertery, które linkowałeś poprzednio i gotowe. Ale to nie jest interfejs do komunikacji na większe odległości, do tego nadaje się przykładowo RS-485, jednak jego użycie będzie już wymagało trochę więcej pracy. Natomiast jeśli masz w domu sieć Ethernet, albo WiFi to może łatwiej będzie wykorzystać zamiast nowego kabla? Z ethernetem masz dużo więcej możliwości, np. dać Arduino + shield przy każdym wyświetlaczu, albo ESP i komunikować się bezprzewodowo. Możesz też kupić gotowy konwerter ethernet-uart np. https://elty.pl/pl/p/Konwerter-UART-TTL-na-Ethernet-/2447

[marek1707]

1 godzinę temu, SOYER napisał:

Nie łapię.

Juz tłumaczę: gdy decydujesz się na wykorzystanie gotowych modułów robiących jakiś standardowy, sprawdzony i pewny interfejs (czyli używasz elektronicznego wytrycha), to oscyloskop (czyli suwmiarka w ślusarskim świecie) nie jest w zasadzie potrzebny. I to nie jest żadna krytyka. Po to są gotowce.

1 godzinę temu, SOYER napisał:

dwa nextiony sterowane przez uart, to wyższe wtajemniczenie, czy igraszka?

To zależy od tego, czy musisz czytać ich odpowiedzi. Jeśli tak (a na 99% tak jest), to musisz zrobić dwa osobne fizycznie połączenia i dwie instancje tego samego obiektu w kodzie. Każdy będzie musiał mieć swój własny stan (choćby interfejsu), ale mogą dostawać wspólne dane do wyświetlenia od aplikacji. Gdzieś "po drodze" w programie będziesz musiał zrobić podział, by "góra" widziała jeden ekran a oba "doły" miały swoje struktury danych. Pytanie jak zrobisz interfejs do akcji użytkownika (touch screen? przyciski?). Bo jeśli dwoje ludzi podejdzie jednocześnie do dwóch terminali, to sprawa zaczyna być ciekawa.

RS232 na MAX232 spokojnie da radę na 30m nawet na 57600. To naprawdę dobre rozwiązanie. Ech panie, kiedyś to robili interfejsy...

Gdybyś chciał mieć jeszcze szybciej, to powyżej 115200 powinieneś już przejść na transmisję różnicową, ale to też głównie dlatego, że RS232 ma ograniczone prędkości narastania sygnału (z powodu walki z zakłóceniami i przesłuchami w kablach) i odbiorniki mogą się zacząć gubić gdy czas nadawania bitu schodzi do <10us. Można kupić szybsze, ale trzeba się postarać. Dlatego kupujesz wtedy moduły RS422/485. Niestety przyjęło się, że jeśli już ta warstwa fizyczna, to transmisja dwukierunkowa po jednej magistali (czyli 485) i związane z tym kłopoty z arbitrażem itp. Ty tutaj masz tylko dwa urządzenia (a połączenie trzech czyli dwóch wyświetlaczy i Arduino  na jednej parze - choć wygląda smakowicie - nie będzie możliwe ze względu na to, że dostęp do magistrali 485 wymaga pewnej inteligencji, której wyświetlacz nie posiada) więc musisz wykorzystać zwykłą transmisję jednokierunkową. "Przedłużasz" zatem UARTowe linie TXD/RXD za pomocą pary różnicowej a zamiast modułów RS232 kupujesz 2 sztuki RS422. Sygnalizacja w każdą stronę odbywa się tu na parze przewodów, więc nadajnik ma swoją a odbiornik swoją i w rezultacie masz kostkę 4-zaciskową. Łączysz je na krzyż (parę AB jednej do YZ drugiej) i tyle. Z tego wyciągniesz dobrze ponad 2Mbit/s na kilkudziesięciu metrach skrętki (znów ograniczeniem jest użyty scalak, istnieją dużo szybsze i sporo wolniejsze), oczywiście kosztem prądu, bo nic za darmo. Po obu stronach musisz mieć dobre 5V.

[SOYER]

28 minut temu, marek1707 napisał:

na kilkudziesięciu metrach skrętki

Właśnie miałem dopytać o kwestię przewodów. Jaki najlepszy do takiej transmisji? Do rs232 jakiś dedykowany? Zrobiony własnoręcznie ze skrętki? Do 422 podobnie?

Z ciekawości jaki typ transmisji jest w monitoringu przy przesyłaniu sygnału analogowego przy pomocy skrętki na niezłe odległości przy pomocy tego i dlaczego ten jest taki tani, a ten już kosztuje kupę kasy?.

Może inaczej, jak Wy byście rozwiązali problem mega plus 2-3 nextiony. Kabel zwykły, ethernet, wifi?

[marek1707]

Dedykowane kable do RS232 to wiązka przewodów we wspólnym ekranie. Nie potrzebujesz tu żadnej skrętki a przesłuchy między liniami są zminimalizowane dzięki ograniczeniu pasma nadajników. Możesz to zatem puścić zwykłym kablem "alarmowym", płaską tasiemką, 3-żyłowym przewodem instalacyjnym sieci AC, w zasadzie czymkolwiek. Jeżeli masz trochę wolnego przewodu LAN, to skorzystaj z tego: weź dwie z czterech obecnych tam skrętek i w każdej z nich puść jednym przewodem masę a drugim linię TXD lub RXD. To zminimalizuje przesłuchy, da optymalną odporność na zakłócenia i wyrówna impedancje obu linii. Pozostałe dwie skrętki moga posłużyć do przesyłania dodatkowej masy (cała jedna para) i zasilania (druga para).

RS422/485 to zupełnie inna sprawa. On opiera się na skrętce, oba sygnały jednej pary muszą być ze sobą fizycznie blisko, ale w kontrolowanej odległości. Typowa skrętka ma impedancję różnicową ok. 120Ω i tego rzędu opornik dajesz między drutami pary na końcu, po stronie odbiornika. Drivery nadajników są z definicji dopasowane "w fabryce". Najczęściej na modułach 422/485 są już takie oporniki, czasem (szczególnie w przypadku 485 gdzie w większości węzłów może ich nie być) "załączane" jakąś zworką. To min. dzięki dopasowaniu impedancji linii i jej obu zakończeń możesz przesyłać Mbity/s.

Ten tani wynalazek to zwykły transformator. Wchodzisz analogowym sygnałem video (pasmo ok. 5-6MHz) i wychodzisz w kabel tym samym. To jedynie dopasowanie impedancji 50 lub 75Ω (typowej w kablach koncentrycznych/video) do impedancji skrętki (tę już znasz).

Drugi patent to urządzenie odbierające cyfrowy sygnał HDMI i "serializujące" go w cyfrowy strumień danych przesyłany po 4 skrętkach.

Ja bym zaczął od sprawdzenia jakiej przepustowości potrzebujesz do płynnej współpracy z tym wyświetlaczem. Zrób próby albo wczytaj się w protokół i spróbuj estymować z tego co znajdziesz. Jeśli są tam komedy typu "narysuj pixel" a Ty już wiesz, że będziesz musiał odświeżyć np. pole 200x100, to będzie to żałosne. A jeśi masz polecenia typu "tu narysuj pole tekstowe, krój XYZ, wielkość N, zawierające ALA MA KOTA" lub "wyskaluji i narysuj zielony wykres na białym tle, tu są jego dane: 15, 17, 24, 21" to spoko, każdy interfejs się wyrobi. Po to wyświetlacz jest inteligentny, by transfer nie musiał być duży, ale jest różnica między 2400 a 115200, szczególnie dla interfejsów kodowanych jak UART.

Kabel - WiFi to zupełnie inna płaszczyzna, rozpatrywana raczej na gruncie inwestycji i wykonania. Po stronie wyświetlacza musisz zrobić jakiś komputerek przesyłający dane z WiFi do LCD i odwrotnie, zbierający jego odpowiedzi (jakie? kiedy się kończą?) i odsyłający w druga stronę. Albo w ogóle zarządzający całym ekranem - wtedy na poziomie WiFi wysyłasz tylko ogólne parametry tego co ma być akurat widać. A z drugiej strony połączenia to chyba będzie czas by zrezygnować z AVR-owych Arduino. No i dochodzą opóźnienia, ale jeśli nie ma tam żadnej komunikacji z użytkownikiem tylko pasywne wyświetlanie danych, to opóżnienia są bez znaczenia.

Wyświetlacz ma UART i to jest jego natywny interfejs. Ja bym starał się go wykorzystać tak jak jest, ew. z wymianą sygnałów z TTL na na 232/422. Także, trudno powiedzieć. Na teraz nie wiem jakbym to zrobił, na 80% raczej kabelek prowadzący dane i zasilanie.

[SOYER]

1 godzinę temu, marek1707 napisał:

Jeśli są tam komedy typu "narysuj pixel" a Ty już wiesz, że będziesz musiał odświeżyć np. pole 200x100, to będzie to żałosne. A jeśi masz polecenia typu "tu narysuj pole tekstowe, krój XYZ, wielkość N, zawierające ALA MA KOTA" lub "wyskaluji i narysuj zielony wykres na białym tle, tu są jego dane: 15, 17, 24, 21" to spoko, każdy interfejs się wyrobi. Po to wyświetlacz jest inteligentny, by transfer nie musiał być duży, ale jest różnica między 2400 a 115200, szczególnie dla interfejsów kodowanych jak UART.

Jeszcze nie mam tych nextionów, ale z tego co się zdążyłem zorientować, to całym rysowaniem zajmuje się procek(STM?) w wyświetlaczu. My wysyłamy tylko komendy w stylu "zmień kolor obiektu 001 na czerwony i zmień na nim napis na ok". Także ilość informacji znikoma wydaje się. 

[marek1707]

No to czekamy na decyzję, opis szczegółów a potem raporty z budowy, pisania kodu i uruchamiania  

[SOYER]

Teraz zrobiłem przebudowę mojego systemu, zamiast jednej Megi z podpiętymi wszystkimi czujnikami, mam 5xnodeMCU i 1xMEGA. Wszystko wysyła dane na serwer Blynka i jest dostępne jako jeden projekt. MEGA w sumie tylko teraz odpowiada za przekaźniki i krańcówki. Dojdą jej te ekrany, stary LCD20x4 wyleciał. 

Razem z ekranami zamówię te konwertery na 232 za 10zeta, gdzie trzeba poślę skrętkę. A właśnie:

2 godziny temu, marek1707 napisał:

3-żyłowym przewodem instalacyjnym

Czyli tx, RX i GND?

Każdy ekran na osobnym softwareSerialu? Czy "trójnik"? Ale co jak w tym samym czasie dwie osoby na różnych ekranach coś będą grzebać?

Edytowano Luty 11, 2021 przez SOYER

[marek1707]

Tak, minimalne połączenie to GND, RXD i TXD.

Nie, "trójniki" (czyli jak rozumiem kable "Y") w RS232 nie są możliwe. Nawet interfejs przygotowany sprzętowo pod wspólną dla wszystkich magistralę (czyli RS485) tutaj nie zadziała, bo każdy jego węzeł (komputer, wyświetlacz, cokolwiek) musi wiedzieć, jakie są reguły dostępu do magistrali i odpowiednio sterować swoim nadajnikiem aby innemu nie przeszkodzić. Twój wyświetlacz tego nie umie więc to odpada, on musi mieć linię dla siebie. Pozostają połączenia punkt-punkt i wtedy tak, dla każdego wyświetlacza osobny UART w jednostce centralnej lub hm.., jakiś elektroniczny przełącznik "podłączający" UART procesora np. do wybranego interfejsu RS232. W pierwszym przypadku masz komfort niezależnej komunikacji z każdym, ale musisz to oprogramować i np. trzymać równolegle wiele kontekstów ekranu/GUI w kodzie. Pewnie i tak musisz, skoro w przyszłości przewidujesz wyświetlanie na każdym czegoś innego. Drugi pomysł jest prosty: obsługujesz pierwszy ekran w całości, przełączasz UART, gadasz z drugim, potem trzecim i tak w kółko. Jeśli jednak wyświetlacze potrafią same z siebie coś nadać (np. "wykryłem touch screen o współrzędnych 1500, 2900") to kicha, nie możesz przełączać komunikacji i każdy UART musi być zawsze gotowy do odbioru. A kwestia niezależnego traktowania każdego ekranu jako interfejsu do osobnego użytkownika została rozwiązana jakieś.. 80 lat temu? Moc obliczeniowa, interfejsy, odpowiednio duży RAM (albo szybka pamięć zewnętrzna) i program - nic więcej nie trzeba.

Wiesz, nawet jeśli użyjesz małego 8266, Arduino Mini czy podobnego (pinowego) biedaczka, to scalaków UARTowych jest jak mrówków. To interfejs stary jak dalekopisy więc ludzkość dorobiła się w tym zakresie niezłego magazynu. Są takie na SPI, są na I2C, są na szynach równoległych, pojedyncze, podwójne, poczwórne i nawet poósmne, do wyboru do koloru więc liczba interfejsów nie stanowi tu ograniczenia. To już bardziej RAM na konteksty GUI, na bufory komunikacyjne i FLASH na bitmapy krojów pisma czy jakichś obrazków (jeśli wyświetlacze umieją pokazywać coś dosłanego z zewnątrz a nie tylko rzeczy "wprogramowane" do nich wcześniej). Nie mówiąc już o animacjach czy samplach dźwięku.

[kaworu]

7 minut temu, marek1707 napisał:

Nawet interfejs przygotowany sprzętowo pod wspólną dla wszystkich magistralę (czyli RS485) tutaj nie zadziała, bo każdy jego węzeł (komputer, wyświetlacz, cokolwiek) musi wiedzieć, jakie są reguły dostępu do magistrali i odpowiednio sterować swoim nadajnikiem aby innemu nie przeszkodzić

Coście się tak uparli na to, że rs485 = rs485+port szeregowy? Przecież to tylko warstwa fizyczna, i równie dobrze można ja wykorzystać puszczając po nim jakikolwiek interfejs równoległy albo po prostu SPI.

A w konfiguracji gwiazdy (czy tam Y) z sensowną prędkością nie zadziała, bo albo sygnał zjedzą odbicia, albo drivery będą przeciążone za dużą liczbą rezystorów terminujących.

[SOYER]

11 minut temu, marek1707 napisał:

Wiesz, nawet jeśli użyjesz małego 8266, Arduino Mini czy podobnego (pinowego) biedaczka, to scalaków UARTowych jest jak mrówków. To interfejs stary jak dalekopisy więc ludzkość dorobiła się w tym zakresie niezłego magazynu. Są takie na SPI, są na I2C, są na szynach równoległych, pojedyncze, podwójne, poczwórne i nawet poósmne, do wyboru do koloru

Nie rozumiem o czym piszesz, jakich scalaków UARTowych?

 

[marek1707]

@kaworu Widzisz, jakbyś zadał sobie trud przeczytania wątku od początku, to byś się tak nie dziwił. Kolega @SOYER planuje kupić wyświetlacze wyposażone w interfejs UART/TTL. Jaki jest więc sens mówić o przesyłaniu czegoś innego po medium? Jasne, po jednej stronie jest drut TTL i po drugiej też a w środku skrętka albo jakaś linia asymetryczna. To co wyślesz w jednym przyjdzie po jakimś czasie do drugiego, bo po prymitywna warstwa fizyczna nie ma żadnego "protokołu" a rozróżnia i przenosi jedynie dwa stany - możesz na tym posadzić wiele różnych interfejsów, SPI także (dokładnie tak robiłem w wielu maszynach), tylko.. co z tego? To nie ten przypadek.

Oczywiście, że zadziała, bo a) tak jak napisałem (trzeba było czytać) tylko bardzo niektóre węzły 485 muszą mieć terminatory a i tak wszystko zależy od fizycznej topologii sieci więc nie ma co rozstrząsać na pusto, b) mówimy o "sieci" z 3-4 urządzeń (znów: warto sięgnąć do początku tematu) w ramach jednego domu więc nie rozumiem Twoich obaw o przeciążanie czegoś. Nawet gdyby Autor zrobił czystą gwiazdę (a tak nie zrobi bo mu to wybiję z głowy, z resztą jest to nieefektywne w przypadku domu) i na każdym końcu posadził terminator, to i tak driver 485 da radę. Więc nie irytuj się, tylko wnikaj w temat - wtedy porady są dużo bardziej trafione.

@SOYER Czego nie rozumiesz? Skoro istnieją scalaki do generowania dźwięków, pamięci, chipy video, ethernety, LoRa, wzmacniacze, stabilizatory itd to dlaczego nie miało by być osobnych UARTów? Przecież nie jest to jakaś integralna część procesorka takiego czy innego. Bierzesz jeden i masz przejście z I2C na UART, bierzesz paczkę innych, podłączasz ich 10 do swojego SPI i masz 10 nowych UARTów. Albo wreszcie kupujesz taki co ma 4 kanały szeregowe w środku i jednym scalakiem podłączonym do biednego UNO obsługujesz 4 wyświetlacze inteligentne po RS232 a "natywny" UART procka zostaje do komunikacji z PC. To przecież proste.

[SOYER]

6 godzin temu, marek1707 napisał:

kupujesz taki co ma 4 kanały szeregowe w środku i jednym scalakiem podłączonym do biednego UNO obsługujesz 4 wyświetlacze inteligentne po RS232 a "natywny" UART procka zostaje do komunikacji z PC

Coś jak pcf8574 dla zwykłego pina? Ekspander do uart?