Witam

Zagadnienie jak w temacie.
Staram się dopracować bibliotekę do obsługi wyświetlacza opartego o sterownik SANYO LC7981.
Biblioteka jest autorstwa Sebastian Schumb'a.

W kodzie znajduję że tak powiem elementarne najbardziej niskopoziomowe fukcje odpowiadające za wysłanie komendy do sterownika oraz za "pyknięcie" linią E (wykonanie komendy).
Biblioteka nie posiadała obsługi flagi zajętości. Więc ją dorobiłem.
Jako, że jest to wyświetlacz graficzny, szybkość wykonywania operacji ma znaczenie dużo większe niż w przypadku 44780.
Dodatkowo przeglądając notę sterownika okazało się czasy wykonania komend są dość krótkie (ns), więc obecność delay'ow na poziomie 30 us w tak elementarnych funkcjach wydaje się nie na miejscu.

Autor fukcje napisał tak:




Jak widać fukcje są rodzaju INLINE i to zagnieżdżone.
Niestety w pliku lss nie zostały one rozwinięte. I wykonywany jest rozkaz call.
Wiem, że specyfikator INLINE nie jest dla kompilatora obligatoryjny i może on go nie zrealizować.
Funkcję strobe() (gdzie umieściłem sprawdzanie BF) oczywiście mogę literalnie (ręcznie) wkleić do lcd_write_command().

Ale czy da się jakoś zmusić kompilator, żeby jednak wykonał kompilację z uwzględnieniem specyfikatora INLINE?

No to są funkcje KOBYŁY i powiem ci że dodatkowy narzut CALL jest niczym przy ich budowie

ale gdybyś się uparł to jest taki atrybut

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

To prawda, kod urośnie mocno. Bo to jest wołane przecież przy każdej okazji. CALL to chyba 5 cykli i RET kolejne 5 cykli. Więc 10 cykli cykli zegarowych. To jest jakieś 500 - 600 ns. Najdłuższe czasy reakcji tego sterownika są na poziomie 250ns.

Te delay'e, szczególnie ten 30us, już usunąłem. Sprawdzam po prostu BF w pętli while. W trybie tekstowym (bo to ma własny tryb tekstowy, zresztą dość ciekawy) to nie jest tab bardzo odczuwalne, ale w trybie graficznym prędkość rysowania wzrosła masakrycznie.

a, no to dokładnie najlepszy sposób niż delaje

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Obecnie funkcje wyglądają tak:





Ja widać nie ma inline... Gdy je zrobiłem jako INLINE wyświetlacz zaczął się niepoprawnie zachowywać.
Zuważyłem to przy działaniu funkcji clear. Która wykonuje po prostu zapisanie spacjami całego obszaru pamięci sterownika. Rozpoczynając od pozycji 0,0. Kasowanie nie dochodzi do końca. Kilkanaście ostatnich bajtów pozostaje nietkniętych.
Gdy funkcje są bez INLINE, tak jak powyżej, wszystko jest OK.
Ma to jakiś związek z czasem trwania stanu wysokiego na linii E. Gdy tam wstawię opóźnienie o 3 cykle zegara wszystko działa dobrze.

a co robią u ciebie takie funkcje jak np:

lcd_rw_low();

??

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

To jest tylko makro.


Biblioteka nie jest moja. Ja się staram ją nieco udoskonalić.
Autor tak dziwnie makra zdefiniował, że wyglądają jak funkcje.

a no właśnie bo jakby były dużymi literami napisane to od razu można byłoby się domyśleć że to proste makra i łatwiej myśleć o ich inline'owaniu

ale skoro to jednak takie makra proste to dziwne że jak dasz inline na siłę to coś nie działa.

Próbowałeś np najpierw jedną z tych funkcji (najprosztą) zinlajnować i sprawdzić postępy ? poza tym wywalasz wtedy ten specyfikator static ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Inline'owanie lcd_strobe() powoduje problem. Static usunąłem, on tam jest bo ta funkcja nie jest udostępniana poza poza plikiem.
Jak sądzę jest to związane właśnie z obsługą linii E. Widzę, że występują teraz poważne błędy w transmisji / odczycie danych przez sterownik.
Tak sobie myślę, że ten CALL (gdy nie ma inline) powoduje odsuniecie w czasie momentu w którym wystawiany jest sygnał E. I wtedy jest dobrze. Zapewne tam jest jakaś krytyczna zależność czasowa.

Teraz wygląda tak:


I oczywiście działa.

------------------------ [ Dodano po: 12 minutach ]



Jeju, ale tych atrybutów jest... Dobrze to wiedzieć. Ale ja zbym mało znam asemblera, żeby widzieć dokładnie istotę tych różnic.
Bo nawet jak nie piszemy w asm, to ostatecznie sposób pracy kompilatora się przekłada na to i trzeba wiedzieć, co do czego.
I tak jakoś (dzięki Mirkowi) nie przeraża mnie już widok pliku .lss

Ale obecnie jestem niemal pewny, że po inline'owaniu funkcji lcd_strobe() stan wysoki na linii E pojawiał się zbyt szybko i transmisja się "rozjeżdżała". Nie które bajty były odbierane poprawnie przez sterownik a niektóre nie.
Przyglądam się timeingom trasmisji z noty PDF:



Czas po którym (przy zapisie) powinno pojawić się E to jest minimum 90ns po ustawieniu lini RS i RW
Zanik E minimum 10ns przez zmianą na liniach RS i RW.
Ale procesor chodzi na 10MHz więc jeden cykl trwa 100ns. Więc teoretycznie nie powinno to przeszkadzać.

Sterownik już ogarnięty. Inlinowanie tych najbardziej niskopoziomowych funkcji skracało wykonanie kodu o kilka cykli. Co już było dla sterownika zbyt krótko. Po prostu nie spełniało to kryteriów czasowych wymaganych przez układ LC 7981.
Tak czy inaczej dorobiłem do biblioteki obsługę busy flag A delay'e na poziomie 500ns muszę w pewnych miejscach pozostać.
Dorobię trochę funkcji i się podzielę. LC 7981 nie jest może jakiś bardzo popularny, ale można spotkać wyświetlacze z tym sterownikiem.