Mam jeden projekt wykorzystujący w miarę współczesny procesor (PIC32), pracujący na logice 3,3V. Jako wyświetlacz wykorzystałem HD44780. Oryginalnie używał on ekspandera I2C do komunikacji z resztą systemu, co załatwiało także kwestię konwersji poziomów napięć - wystarczyło jedynie zapewnić dwustronną konwersją na liniach SCL i SDA, za pomocą MKOSFET-ów. Ponieważ jednak zależało mi na szybkości komunikacji, a MCU miał całkiem sporo niewykrozystanych pinów, postanowiłem przerobić moduł wyświetlacza z myślą o bezpośredniej komunikacji. Do konwersji poziomów napięć wykorzystałem układ TXB0108. W teorii powinien on automatycznie zapewniać dwustronną komunikację pomiędzy liniami w domenie 5V i 3,3V. W praktyce już przy pierwszych próbach okazało się, że za nic nie jestem w stanie uruchomić kodu korzystającego z odczytu bitu dostępności. Przerzuciłem się więc na jednostronną komunikację i wprowadziłem stałe opóźnienie. Jednak nawet pomimo tego wyświetlacz nie chce działać w 100% poprawnie. Przez większość czasu działa normalnie, jednak okazjonalnie zawartość się rozjeżdża - wyświetlany tekst trafia nie w to miejsce, gdzie powinien. Logika generująca interfejs użytkownika nie zmieniła się od czasu wersji z I2C, więc podejrzewam problem z komunikacją. W międzyczasie trochę czytałem i widzę, że w paru miejscach w sieci ludzi wspominali o problemach generowanych przez te automatyczne, dwustronne konwertery napięć. W związku z tym mam pytanie: czy ktoś z was korzystał z jakiejś sprawdzonej (i prostej w implementacji) metody podpięcia HD44780 do współczesnego systemu?
HD44780 i urządzenia 3,3V
Aug 22, 2024
Last reply: 1 year ago
5 Replies
W dniu 22.08.2024 o 08:05, Atlantis pisze:
A ty nie umiesz napisać że chodzi ci o zwykły wyświetlacz lcd 1602 czy 2004?
On żadnej konwersji nie potrzebuje, trzeba czytać pdf-y, a tam pisze że działa od 2.7V. Więc wywal ten konwerter, linie we-wy zmostkuj i powinno działać.
Mam z nim złe doświadczenia, szumi, przeszkadza magistrali kiedy ma siedzieć cicho, łatwo coś się w nim przestawia w wyniku szpilek na zasilaniu. IMHO lepiej używać buforów typu 74LVC4245, tym bardziej, że masz dostęp do kierunku lini danych.
Ale jak napisał Janusz, wszystko współczesne powinno sobie poradzić na niższym napięciu. Mam jeden stary HD44780 który nie działa z sterowaniem
3.3V, ale ja go kupiłem na początku wieku. Nie sprawdzałem wszystkich, ale kilka działa.
Na jakiej szybkości Ci zależy? Przerysowanie od początku do końca
32-znakowego wyświetlacza przy 100kHz I2C to ok 15ms. Jak to jest mało to popularne PCF8574 ktore nominalnie są na 100kHz max chodzą do 400kHz. Ale przez 15ms nie przeczytasz tekstu na wyświetlaczu, więc w praktyce to wystarcza. Jak Ci chodzi o czas procesora, to np. na STM można zrobić transmisję przez DMA, procesor robi co innego a sprzęt transmituje.Jak inni pisali wyświetlacz proprawnie rozpoznaje sygnały 3.3V, jedyny problem to ta flaga dostępności, jak chcesz ją czytać to nóżki procka muszą wytrzymać 5V. Ale nie widzę po co, to flaga nie daje wielkiego przyspieszenia.
I2C działa OK i wystarczająco szybko. Ja sobie wymyśliłem że zamiast I2C użyję 74HC595 + SPI (to powinno być tak szybkie jak dostęp równoległy a bez odczytu flag wystarczają trzy linie), ale jeszcze tego nie przetestowałem.
Jak masz problemy to radzę popatrzeć na soft. Ja miałem problem, wyglądało że wyświetlacz sterowany przez I2C się nie wyrabia, jak zjechałem poniżej 18kHz to było OK, ale szybciej działy się dziwne rzeczy, np. zjadał pierwszy wyświetlany znak, czasami były jakieś losowo wyglądające wzorki. W końcu się zorientowałem że program wysyłał złą sekwencję sygnałów, tzn. zmieniał dane razem ze strobe. Jak to poprawiłem, to chodzi powyżej 400 kHz. Tzn. teraz sekwencja jest 'dane|En', 'dane' jeśli nie ma zmiany RS i R/W gdzie 'dane' to blok 4 bitów + flagi. Jak jest zmiana RS to trzeba wcześnije słowo bez En.
A propo: po I2C transmiuję bloki, tak że jeden blok przesyła dwie 4 bitowe paczki czyli bajt do HD.
O ile pamietam, wyswietlacz nie jest zbyt szybki, a niektóre operacje ma bardzo wolne. I2C prawdopodobnie załatwia kwestię większości operacji, tzn transmisja na tyle powolna, ze wyświetlacz wyrabia, ale zostają te naprawdę wolne.
J.
Zgadza się. Po każdem bajcie trzeba odczekać aż wyświetlacz go przerobi. Najpowolniejszy jest reset wyświetalcza (rzędu dziesiątek milisekund). Czyszczenie ekranu i powrót kursora do początkowej pozycji to nominalnie 1.5ms. Pozostałe operacje są nominalnie na poziomie 40us. Dodając margines czasowy, większość operacji mieści się w 55us. Czyszczenie ekranu to zwykle dość rzadka operacja (w przeciwnym razie wyświetlacz może migać). Na razie nie znalazłem zastosowanie na "powrót kursora do początkowej pozycji" (przesunięcie go do "dowolnej" pozycji jest szybsze). Przy 100kHz przesłanie bajtu do wyświetlacza wymaga przesłania
4 bajtów po I2C, co daje koło 450us, to dużo więcej niż trzeba. Przy 400kHz mamy koło 113us co ciągle daje duży margines.Oczywiście, te wolne operacje trzeba jakoś załatwić. Najprostszy sposób to 'delay' w kodzie. Albo użycie timera i przerwania zagara.
Ogólnie, co do szybkości: wyświetlacz jest dużo szybszy niż człowiek, więc nie widzę potrzeby by samo wyświetlanie szło szybciej. Kłopotliwe jest to że w trakcie transmisji trzeba wyświetlacz "doglądać", tzn. co te 55us (czy jaki odstęp się wybierze) trzeba przesłać kolejny bajt. Naiwny kod wtedy nie będzie robił nic innego. Ale by to rozwiązać to raczej przerwania i/lub kanał DMA, a nie przechodzenie na transmisję równoległą.
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required