J.F <j...@p...onet.pl> wrote:
> On Fri, 13 Sep 2024 03:04:38 -0000 (UTC), Waldek Hebisch wrote:
>> Atlantis <m...@w...pl> wrote:
>>> 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.
>>
>> 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.
>>
>>> 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?
>>
>> 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.
>
> 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.

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łą.

--
Waldek Hebisch