RTV forum PL | NewsGroups PL

HD44780 i szybkie MCU

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - HD44780 i szybkie MCU

Atlantis
Guest

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?

Marek
Guest

Tue Jan 23, 2024 8:12 pm   



On Tue, 23 Jan 2024 17:53:07 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:
Quote:
Ktoś ma pomysł co może być nie tak?

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

--
Marek

Zbych
Guest

Tue Jan 23, 2024 10:26 pm   



On 23.01.2024 17:53, Atlantis wrote:
Quote:
Ktoś z was ma doświadczenie z uruchamianiem wyświetlaczy HD44780 na
(relatywnie) współczesnych mikrokontrolerach?

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

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

Quote:
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?

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.

Grzegorz Niemirowski
Guest

Tue Jan 23, 2024 10:45 pm   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
Ktoś z was ma doświadczenie z uruchamianiem wyświetlaczy HD44780 na
(relatywnie) współczesnych mikrokontrolerach?

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

Quote:
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?

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/

Atlantis
Guest

Wed Jan 24, 2024 9:11 am   



On 23.01.2024 21:45, Grzegorz Niemirowski wrote:

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

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.


Quote:
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

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

Grzegorz Niemirowski
Guest

Wed Jan 24, 2024 11:26 am   



Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Quote:
Moja robocza hipoteza była taka, że pewnie jakiś sygnał jest wystawiany na
magistralę zbyt szybko.

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.

Quote:
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.

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

Quote:
Robiłem sprawdzanie flagi na STM32: https://pastebin.com/qr0A3CnK

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

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

Nie pamiętam już gdzie kupowałem.

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

J.F
Guest

Wed Jan 24, 2024 1:59 pm   



On Tue, 23 Jan 2024 17:53:07 +0100, Atlantis wrote:
Quote:
Ktoś z was ma doświadczenie z uruchamianiem wyświetlaczy HD44780 na
(relatywnie) współczesnych mikrokontrolerach?

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

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

Quote:
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...

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.

Quote:
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?

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.

Atlantis
Guest

Wed Jan 24, 2024 2:44 pm   



On 24.01.2024 12:59, J.F wrote:

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

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.

J.F
Guest

Thu Jan 25, 2024 4:51 pm   



On Tue, 23 Jan 2024 21:45:48 +0100, Grzegorz Niemirowski wrote:
Quote:
Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):
Ktoś z was ma doświadczenie z uruchamianiem wyświetlaczy HD44780 na
(relatywnie) współczesnych mikrokontrolerach?

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

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

J.

J.F
Guest

Fri Jan 26, 2024 10:57 pm   



On Wed, 24 Jan 2024 13:44:38 +0100, Atlantis wrote:
Quote:
On 24.01.2024 12:59, J.F wrote:

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

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.

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.

elektroda NewsGroups Forum Index - Elektronika Polska - HD44780 i szybkie MCU

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map