Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Wykorzystanie LCD z centralki samochodowej

marycyś 02 Wrz 2017 12:17 921 27
  • #1 02 Wrz 2017 12:17
    marycyś
    Poziom 10  

    Witam,

    Trafiła mi w ręce uszkodzona centralka z instalacji gazowej. Wygląda tak:
    Wykorzystanie LCD z centralki samochodowej
    Chciałbym wykorzystać ekran LCD, ale nie wiem co to za model. Ciężko po ścieżkach na płytce dojść do czego dochodzą wyprowadzenia z LCD.
    Czy ma ktoś schemat tej centralki, albo część schematu związaną z LCD?

    Pozdrawiam.

    0 27
  • #2 03 Wrz 2017 04:20
    szymon122
    Poziom 37  

    A może z łaski swojej podasz model oraz zdjęcia wnętrza?

    0
  • #3 03 Wrz 2017 09:15
    marycyś
    Poziom 10  

    Nie wiem, czy to nr. modelu, ale na płytce jest napis: D811-01-03
    Wykorzystanie LCD z centralki samochodowejWykorzystanie LCD z centralki samochodowej

    Złącze LCD ma 8 ścieżek, chyba takie wyprowadzenia:
    1- nie wiem
    2- masa
    3- masa
    4- sygnałowy
    5- sygnałowy
    6- chyba reset
    7- 3,3V
    8- 3,3V

    0
  • #4 03 Wrz 2017 19:32
    magik332
    Poziom 20  

    Witam wyświetlacz jest od D.T. Gas System typ GT01 .

    0
  • #5 04 Wrz 2017 11:34
    marycyś
    Poziom 10  

    @magik332, pewnie to i GT01. Tylko, że ta informacja nie pomaga mi w określeniu co to za LCD. Dlatego bez schematu i informacji o wyświetlaczu, problem pozostaje.

    0
  • #6 04 Wrz 2017 11:39
    szymon122
    Poziom 37  

    Schematu nie znajdziesz, zapomnij, że producent Ci go udostępni...
    Poszukiwania wyświetlacza w internecie również nic nie dały.
    Pozostaje chyba tylko kupić analizator stanów logicznych i bawić się w dekodowanie.

    0
  • #7 04 Wrz 2017 23:54
    marycyś
    Poziom 10  

    Czy jest możliwe, aby LCD sam sobie wystawiał napięcie Vlcd?
    Pytam, ponieważ do pinu 1 w złączu LCD podłączony jest tylko kondensator.

    0
  • #8 05 Wrz 2017 09:23
    tmf
    Moderator Mikrokontrolery Projektowanie

    Oczywiście jest to możliwe. Sądząc po ilości linii sterujących LCD jest połączony przez jakąś magistralę szeregową. Zapewne ma kontroler, który wymaga poprawnej inicjalizacji, czyli trzeba znać jego notę, bo na ślepo niewiele zdziałasz. Pytanie czy warto tracić czas, jeśli taki LCD kupisz z opisem za kilkanaście złotych?

    0
  • #9 05 Wrz 2017 11:38
    marycyś
    Poziom 10  

    Wiem, że można kupić całkiem tanio, ale żal wyrzucać :)
    Z tego co wyczytałem z chińskich stron, to jest na PCF8548 i i2c.
    Można byłoby dorobić do niego pseudo kartę graficzną na AVR i sterując przez SPI zmniejszyć obciążenie uC zajmującego się np. CNC.

    0
  • #10 05 Wrz 2017 11:52
    tmf
    Moderator Mikrokontrolery Projektowanie

    Jeśli wiesz jaki w nim jest kontroler to masz z górki. Po pokazanej rozpisce też widać które sygnały to będą I2C, pozostaje tylko wykryś SCL i SDA, co jest proste. Natomiast na jakieś znaczące zmniejszenie MCU sterującego CNC bym nie liczył - to mały wyświetlacz, nieabsorbujący dużych zasobów.

    0
  • #11 05 Wrz 2017 12:21
    marycyś
    Poziom 10  

    Ciekawe, jak duży wpływ na obciążenie uC, miałby porównanie dwóch LCD najpierw sterowanego i2c, a potem zamienionego na LCD sterowanego SPI (w obydwu przypadkach z pomocą przerwań sprzętowych).

    0
  • #12 05 Wrz 2017 12:34
    tmf
    Moderator Mikrokontrolery Projektowanie

    marycyś napisał:
    Ciekawe, jak duży wpływ na obciążenie uC, miałby porównanie dwóch LCD najpierw sterowanego i2c, a potem zamienionego na LCD sterowanego SPI (w obydwu przypadkach z pomocą przerwań sprzętowych).


    Domyślam się, że autorowi chodziło o to, że ten dodatkowy MCU nie tylko robiłby konwersję SPI-I2C, ale także zajmował się tworzeniem grafiki - np. renderowaniem tekstu itd.

    0
  • #13 05 Wrz 2017 16:58
    marycyś
    Poziom 10  

    Tak, autorowi chodziło o kartę graficzną, czyli np. renderowaniem tekstu, linii, itp na podstawie krótkich rozkazów przez SPI.

    Ale również, tak jak napisałem w poprzednim poście, ciekawi mnie czy duża byłaby różnica między SPI, a i2c w przypadku korzystania z przerwań, jeśli chodzi o obciążenie uC Mastera.
    I czy ta różnica obciążenia (dla SPI/i2c) jest podobna w STM32 i Atmegach?

    0
  • #14 05 Wrz 2017 17:43
    tmf
    Moderator Mikrokontrolery Projektowanie

    Wszystko zależy od ilości transmitowanych danych. Przy takim wyświetlaczu nie byłoby istotnej różnicy. Przy dużej liczbie danych przy SPI STM by wygrał, bo mógłbyś korzystać z DMA (podobnie jak w AVR XMEGA).

    0
  • #15 05 Wrz 2017 17:50
    marycyś
    Poziom 10  

    A między SPI i i2c?
    Bez stosowania przerwań różnica byłaby olbrzymia, ale gdy stosujemy przerwania to widać dużą różnicę w obciążeniu uC?

    0
  • #16 05 Wrz 2017 18:11
    tmf
    Moderator Mikrokontrolery Projektowanie

    Przy tewj samej szybkości transmisji danych na przerwaniach nie powinno być różnicy, bez przerwań zresztą też nie. W obu przypadkach wysyłasz bajt i czekasz na gotowość hardware. Jedyną różnicę robi DMA, co eliminuje konieczność czekania. Tu I2C IMHO będzie gorszy, bo trudniej go sensownie z DMA połączyć, chyba, że hardware jest naprawdę sprytny, tylko jaki MCU takowym dysponuje?

    0
  • #17 05 Wrz 2017 18:18
    marycyś
    Poziom 10  

    tmf napisał:
    Jedyną różnicę robi DMA, co eliminuje konieczność czekania.

    Wydaje mi się, że nie tyle czekania, co konieczności obciążenia uC przerwaniem.

    0
  • #18 05 Wrz 2017 18:30
    tmf
    Moderator Mikrokontrolery Projektowanie

    Oczywiście przy dużych szybkościach transmisji obsługa przerwań staje się problematyczna, lub wręcz (dla SPI) bezsensowna, bo obsługa trwa dłużej niż transmisja bajtu. Natomiast DMA oprócz eliminacij narzutu związanego z przerwaniami zmienia też styl programowania. Np. dla SPI z maksymalną szybkością programowe nadawanie zajmuje 100% czasu MCU, pomimo, że praktycznie dla AVR pomiędzy przesłaniami mamy 16 wolnych taktów. Trudno się jednak pisze kod wysyłający coś po SPI przepleciny z innymi instrukcjami. Dla DMA programujesz transfer bloku, a w międzyczasie program może robić coś innego.

    0
  • #19 05 Wrz 2017 18:36
    marycyś
    Poziom 10  

    Ale wydaje mi się, że jednak i2c bardziej obciąża uC niż SPI, ponieważ trzeba przesłać dodatkowe bajty/bity sterujące transmisją (adres, acki, itp)

    0
  • #20 05 Wrz 2017 21:00
    tmf
    Moderator Mikrokontrolery Projektowanie
  • #21 05 Wrz 2017 21:22
    22053
    Użytkownik usunął konto  
  • #22 05 Wrz 2017 21:32
    Marek_Skalski
    Moderator Projektowanie

    tmf napisał:
    Tu I2C IMHO będzie gorszy, bo trudniej go sensownie z DMA połączyć, chyba, że hardware jest naprawdę sprytny, tylko jaki MCU takowym dysponuje?

    Sporo uC z rodziny STM32 ma taki I2C, szczególnie L0, L4, F7. Ładujesz do rejestru w jednej operacji adres urządzenia, kierunek transmisji oraz ilość bajtów do transmisji. Ustawiasz Start i w przerwaniu po adresie reagujesz na NACK lub włączasz DMA, aby przesłać dane. Stop jest wystawiany automatycznie po przesłaniu wszystkich danych. Można też włączyć przerwanie po zakończeniu transmisji, kiedy stop już poszedł, albo po przesłaniu danych, aby zminimalizować czas jałowy.

    0
  • #23 05 Wrz 2017 22:41
    tmf
    Moderator Mikrokontrolery Projektowanie

    @Marek_Skalski Taką funkcjonalność (i tak całkiem zaawansowaną) ma sporo procesorów. Jednak jak piszesz pewna ingerencja oprogramowania jest potrzebna. Niestety nie ma tak, że przygotujesz sobie transakcję, ustawisz DMA i magicznie wszystko samo się zrobi. W tym sensie SPI jest mniej obciążające MCU (co zresztą wynika z prymitywności tego protokołu).

    0
  • #24 06 Wrz 2017 08:50
    marycyś
    Poziom 10  

    Jak się nazywa taka funkcjonalność, bo chciałbym sprawdzić w których uC występuje?

    0
  • #25 06 Wrz 2017 08:57
    tmf
    Moderator Mikrokontrolery Projektowanie

    Chyba się specjalnie nie nazywa - po prostu trzeba przeglądnąć notę i opisy I2C oraz DMA. Funkcjopnalność o jakiej pisze @Marek_Skalski jest chyba w większości ARMów oraz z AVR w XMEGAch.

    0
  • #26 06 Wrz 2017 14:09
    Marek_Skalski
    Moderator Projektowanie

    tmf napisał:
    Funkcjopnalność o jakiej pisze @Marek_Skalski jest chyba w większości ARMów

    Napisałem wcześniej, że takie funkcje ma interfejs I2C implementowany w mikrokontrolerach firmy ST Microelectronics, STM32 z rodzin L0, L4, F7 i H7, np. STM32F746ZG lub STM32L031K6. Być może też niektóre F4, ale nie sprawdzałem. Na pewno nie mają tego L1, F1, F2 i F4 z grupy 407, 417.
    ARM to nazwa firmy projektującej i sprzedającej licencje na rdzenie (mikro)procesorów i mikrokontrolerów. Ja wiem, że niektórzy używają tej nazwy niezgodnie z jej znaczeniem i zamiennie na określenie dowolnych struktur z 32-bitowym rdzeniem, ale to nie jest prawidłowe. Tym bardziej, że tak rozumiane ARMy, to układy produkowane przez wiele firm, wyposażone w 32-bitowy rdzeń, który może być w wielu różnych wariantach, np, Cortex-R, Cortex-A5x, Cortex-M0+, Cortex-M7, itp, itd... Ale z całą pewnością, żaden z tych rdzeni nie posiada sprzętowego interfejsu I2C.
    Ponadto, takie układy produkuje wiele firm, np. ST, NXP (dawniej Freescale), Microchip (dawniej Atmel), SiliconLabs, Toshiba i ponieważ nie znam ich wszystkich, to nigdy nie zaryzykowałbym stwierdzenia, że w większości z nich są takie albo inne interfejsy. To już zbyt duże uogólnienie, które może wprowadzać w błąd.

    0
  • #27 06 Wrz 2017 17:41
    marycyś
    Poziom 10  

    @Marek_Skalski, chcesz powiedzieć, że chociażby F1 nie ma sprzętowego i2c?

    0
  • #28 06 Wrz 2017 18:43
    Marek_Skalski
    Moderator Projektowanie

    Wziąłem udział w dyskusji, ponieważ chciałem napisać o uC, które mają "naprawdę sprytny hardware" i tego dotyczy wyliczanka. W żadnym miejscu nie napisałem, że uC z innych rodzin, od innych producentów, ani też z innymi rdzeniami nie posiadają sprzętowego i2c. Moja uwaga dotycząca sprzętowego i2c odnosi się do produktu ARM, do rdzenia Cortex, który sam w sobie nie ma sprzętowego interfejsu i2c. Patrząc w dowolną dokumentację, rdzeń jest jednym modułem, niezależnym od producenta układu, np. ST, NXP, Atmel. Z kolei peryferia, ich rodzaj, ilość, funkcje zależą głównie od producenta uC, mogą być bardzo różne i najczęściej nie zależą od typu rdzenia uC. Dotyczy to również implementacji i2c; od bardzo prostych do całkiem sprytnych.
    STM32F1xx z całą pewnością ma i2c. Dość prosty, ograniczony funkcjonalnie, wymagający sporo interwencji programowych, ale jest. Maksymalnie 2 takie moduły w jednym uC. Dlatego właśnie zaproponowałem inne, w których i2c jest bardziej zaawansowany. Bardziej niż w AVR, PIC, czy STM32F1xx.

    0