Problemy z odczytem flagi zajętości HD44780 na PIC32MX795F512L

Tue Jan 23, 2024 6:53 pm   

Ktoś z was ma doświadczenie z uruchamianiem wyświetlaczy HD44780 na
(relatywnie) współczesnych mikrokontrolerach?
Mam urządzenie zbudowane w oparciu o PIC32MX795F512L. Do tej pory
korzystałem z wyświetlacza HD44780 (4x20) za pośrednictwem ekspandera na
I2C. Niestety komunikacja była dość wolna - tym bardziej, że układ
reprezentuje rewizję, która miała hardware'owego buga i na tym
konkretnym porcie I2C trzeba było ponawiać konfigurację przed każdą
kolejną transmisją.

W wolnej chwili postanowiłem więc przeprojektować moduł wyświetlacza i w
miejscu ekspandera zastosowałem dwukierunkowy translator poziomów
TXB0108. Dwukierunkowy, bo zamierzam korzystać z funkcji odczytu flagi
zajętości (była ona również wykorzystywana w wersji z I2C).

Przepisałem sterownik, wywalając z niego obsługę I2C. Zamiast tego
komunikację oparłem na na GPIO. Po podpięciu nowej wersji interfejsu LCD
okazało się, że działa on tylko częściowo. Mianowicie jeśli wyłączę
obsługę linii RW (i zamiast sprawdzania flagi zajętości dam
standardowego delay'a 120 us) to wszystko działa zupełnie poprawnie. A
to oznacza, że GPIO są skonfigurowane poprawnie i komunikacja w stronę
wyświetlacza działa.

Problem pojawia się, gdy próbuję włączyć obsługę RW i czytać flagę
zajętości. Wtedy wyświetlacz niby się inicjuje i nawet jest w stanie
poprawnie wyświetlić kilka tekstów, ale w chwilę później układ się
zawiesza (podejrzewam, że własnie na pętli sprawdzania bitu zajętości) i
zalicza reset WDT. I tak w kółko...

Próbowałem dodawać delay'e 1-10 us po zmianach stanów linii RW i EN, a
także po zmianie konfiguracji pinów skaładających się na czterobitową
magistralę danych (wejście lub wyjście), jednak nie przyniosło to
żadnego rezultatu.

Ktoś ma pomysł co może być nie tak?

Tue Jan 23, 2024 8:12 pm   

On Tue, 23 Jan 2024 17:53:07 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Czy translator nie przekłamuje poziomów w drugą stronę podczas
odczytu bitu zajętości?

--
Marek

Tue Jan 23, 2024 10:26 pm   

On 23.01.2024 17:53, Atlantis wrote:

Podłącz Jtag i sprawdź gdzie program utyka.


Sprawdź analizatorem/oscyloskopem, czy odczyt flagi na pewno działa. Po
obu stronach translatora poziomów.
Zdarzają się chińskie implementacje 44780, które mają skopaną flagę
zajętości np. jest ustawiana z opóźnieniem.

Tue Jan 23, 2024 10:45 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

A jakie to ma znaczenie czy mikrokontroler jest szybki? Z HD44780 poradzi
sobie każdy.


Tak jak Zbych podejrzewam chińszczyznę. Sprawdzałeś na innych wyświetlaczach
z tym sterownikiem? Bo ogólnie to powinno działać. Robiłem sprawdzanie flagi
na STM32: https://pastebin.com/qr0A3CnK

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Wed Jan 24, 2024 9:11 am   

On 23.01.2024 21:45, Grzegorz Niemirowski wrote:


Moja robocza hipoteza była taka, że pewnie jakiś sygnał jest wystawiany
na magistralę zbyt szybko. Zgadzałoby się to z faktem, że na I2C
wszystko działało poprawnie - pewnie dlatego, że komunikacja szeregowa
wprowadzała dodatkowe opóźnienia pomiędzy kolejnymi zmianami stanów na
liniach. Z drugiej strony ręczne dodanie opóźnień 10 us niczego nie
zmieniło.
Jest bardzo prawdopodobne, że sterownik wyświetlacza pochodzi z jakiegoś
starego projektu na AVR, który potem zmodyfikowałem na I2C, aby w końcy
teraz znów powrócić do bezpośredniej magistrali na PIC32, który jest
zauważalnie szybszy.



Niestety, w tej chwili nie mam pod ręką innego egzemplarza. Musiałbym
dopiero zamówić. Polecasz jakieś zaufane źródło?

Wed Jan 24, 2024 11:26 am   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

Chodziło mi o to, że na każdym MCU mamy dostępne różne metody odmierzania
czasu i dzięki nim możemy generować opóźnienia o takiej wielkości jaka jest
potrzebna. Kiedyś robiłem obsługę LCD na Blackfinie (taktowanie chyba 400
MHz) i nie było problemów.


Na I2C sprawdzałeś flagę zajętości?
Przy szybkich MCU dochodzi jeszcze stromość zboczy, na STM32 można ją
konfigurować.


Przepraszam, pomyliłem pliki, w tym nie ma sprawdzania flagi. Poprawny jest
tu: https://pastebin.com/vUCVDp1Q


Nie pamiętam już gdzie kupowałem.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Wed Jan 24, 2024 1:59 pm   

On Tue, 23 Jan 2024 17:53:07 +0100, Atlantis wrote:

oryginały były dosc powolne, ale ... powinny być juz dawno, nowe,
lepsze, szybsze.

Tylko ktore to, szczegolnie jak pod wyswietlaczem kropla tworzywa :-)


Ten np
https://www.tme.eu/pl/details/eadip205b-4nlw/wyswietlacze-lcd-alfanumeryczne/display-visions/ea-dip205b-4nlw/

ma wymagany "setup time" 140ns. Ale np dane na wyjsciu mogą sie
pojawic po 320ns.

Z kolei operacja czyszczenia ekranu i Cursor at Home to az 1.64ms.


Na mój gust - 10us to az za duzo. Ale działac powinno.
Na początek moze być, potem można dobrać ile wymaga .

Ale skoro nie działa ... WDG resetuje na pierwszym
czyszczeniu/inicjacji?

I tu widzę dwa Enable ...

A napisz jakis testowy program, ktory pokaże, czy BF w ogóle się
zmienia ...

J.

Wed Jan 24, 2024 2:44 pm   

On 24.01.2024 12:59, J.F wrote:


Właśnie nie, i to mnie zastanawia. Wyświetlacz działa jeszcze przez
jakiś czas po inicjacji. Jest w stanie wysłać trochę danych - mam m.in.
procedurę, która raz na sekundę aktualizuje czas na wyświetlaczu. I
przez tych kilka sekund widzę, jak wartość sekund się zmienia. Potem
jednak wyświetlacz zamiera, a po chwili reaguje watchdog.

Ponieważ wyłączenie define'a odpowiedzialnego za obsługę linii RW
rozwiązuje problem, pętla oczekiwania na wyczyszczenie flagi wydaje się
być głównym (jeśli nie jedynym) kandydatem na miejsce, w którym program
utyka.

Obecną wersję kodu można zobaczyć tutaj:
https://github.com/marekw1986/InternetRadioPIC32DP83848/blob/harmony/firmware/src/lcd/hd44780.h
https://github.com/marekw1986/InternetRadioPIC32DP83848/blob/harmony/firmware/src/lcd/hd44780.c

Wstępna inicjalizacja pinów GPIO jest robiona w innym miejscu, przy
okazji inicjalizacji wszystkich peryferiów.

Thu Jan 25, 2024 4:51 pm   

On Tue, 23 Jan 2024 21:45:48 +0100, Grzegorz Niemirowski wrote:

No ale własnie może być za szybki :-)

J.

Fri Jan 26, 2024 10:57 pm   

On Wed, 24 Jan 2024 13:44:38 +0100, Atlantis wrote:

Ja bym tu dorzucil jakies opóznienia między zmianami bitów.
i sprawdził wymagane zaleznosci czasowe chocby z tym
https://www.tme.eu/pl/details/eadip205b-4nlw/wyswietlacze-lcd-alfanumeryczne/display-visions/ea-dip205b-4nlw/

i moze nawet przeniosł ustawienie danych

CLR_RW;
data_dir_out();
?delay

lcd_sendHalf(_data >> 4);
?delay
SET_E;
delay
CLR_E;
delay

lcd_sendHalf(_data);
?delay
SET_E;
delay
CLR_E;
?delay

Niby dane są zapisywane/pobierane na opadającym zboczu E, ale po co
czekac.

uint8_t _lcd_read_byte(void) {
uint8_t result=0;
data_dir_in();

SET_RW;
delay

SET_E;
delay

result = (lcd_readHalf() << 4);

CLR_E;
delay

SET_E;
delay
result |= lcd_readHalf();
CLR_E;
delay

return result;
}

nieduzy ten delay - a, na początek testów z 1us, powinno wystarczyc z
nadmiarem.

I jeszcze jedno ... nie przeskakuja ci się gdzies w programie połówki?
Wystarczy, ze raz pykniesz E, i potem reszta programu będzie odwrotnie
połówki czytała czy zapisywała.

J.