Przeportowalem sobie dla Cypressa, biblioteke wyswietlacza graficznego HX8357B z interfejsem rownoleglym 16 bit ktora przygotowalem tydzien temu dla procesora Atmega32. Biblioteka spisuje sie bardzo fajnie i jestem zadowolony. Po kilku modyfiacjach tej biblioteki wyswietlacz zaczal mi dzialac na CY8CKIT-059 na ktorym siedzi CY8C5888LTI - LP097. Wszystko by bylo jak w raju tylko mam jeden klopot. Wyswietlacz wyswietla wszysto poprawnie ale bardzo wolno. Wypelnienie ekranu kolorem trwa okolo 4 sekundy.... Pomyslalem ze przegapilem cos z ustawieniami zegrara w projekcie. Wczesniej uruchamialem kilka projektow na Cyprysie z uzyciem wyswietlacza znakowego, i kilku dodatkowych rzeczy jak Quadraturowy sterownik encodera, czy transmisja po SPI do modulow zewnetrznych.. wszystko dzialalo sprawnie. Teraz uruchomilem ten nieszczesny wyswietlacz i dziala jak slimak. Na Atmedze32 dziala wysmienicie a tutaj jakas kiszka
Czy powinienem jakos inicjowac zegar przy tak prostej obsludze TFT czy moze sa inne przyczyny konfiguracyjne o ktorych nie wiem. Bawie sie Cyprysami od momentu kiedy Mirek wyemitowal swoje poradniki wiec moje doswiaczenie jest marne.
Macie jakies sugestie?
Jak wroce do domu przedstawie kod, ale nie wiele on sie rozni od tego ktory pokazalem tutaj dla AVR http://forum.atnel.pl/topic19932.html Pokaze tez film z pracy tego wyswietlacza.. praca w naprawde zwolnionym tempie. (a przeciez steruje magistrala 16bit rownolegle)
Tak to wygląda na żywo
funkcje czyszczenia ekranu kolorem czarnym, jeszcze raz kolorem niebieskim i kolejno funkcje wywalające stringi... bez delayów i innych spowalniaczy.
Teraz fragmenty kodu Funkcje wysyłania komendy i danych:
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
No nie wiele się różnią te funkcje od tych dla AVRów.. a jednak jak widać na filmie, coś pominąłem bawiłem się ustawieniami zegara w projekcie ale to nie ma żadnego wpływu na działanie wyświetlacza. Zmieniałem też porty, ale efekt zawsze ten sam.
Szukam i szukam i nie znajduję a moja stara głowa już domaga się relaksu
Widzę, że są 8-bitowe; ale wysyłasz do funkcji "writedata" daną 8-bitową, następnie zerujesz ją (dat>>8), wpisujesz do "górnego" portu, wpisujesz daną dat do "dolnego" portu i wysyłasz oba portu do sterownika. Jaki jest sens tej operacji : PORTA_Write (dat>>8) , jeżeli i tak zawsze argument będzie zerem ?
Co do "hx8357d_fillRect" , szybsza będzie pojedyncza pętla np.
for (uint16_t i=0; i<w*h; i++) {...} gdzie w*h liczba pikseli do zapisu ( być może trzeba dodać: w*h+1)
ps. można także spróbować wyprowadzić sygnały CS_L/CS_H odpowiednio przed i za pętlę-powinno działać szybciej.
Zarówno analizator jak i oscyloskop są zgodne co do tego że mój CYCKIT pracuje za wolno
1,7MHz jest raczej dalekie od spodziewanych 24MHz... nie bardzo wiem jak w kreatorze mogę się do tego dobrać. Próbowałem bawić się w ustawieniach z zakładki "Cloks" ale bez względu na to co tam ustawię, układ zachowuje się tak samo.
No i rozgryzłem orzeszka Tak jak pokazałem w poprzednim poście, pomiary czasów na banglowanym pinie trochę mnie zaniepokoiły. Cały czas byłem przekonany że mój problem powolnej pracy wyświetlacza jest związany raczej z hardwarem a dokładnie z konfiguracją zegara. Ponieważ męczyłem się z ustawieniami zegara na wszystkie sposoby i nie uzyskałem niemal żadnej poprawy, zacząłem przewalać dostępne w internecie informacje udostępniane przez CYPRESS a dotyczące właśnie użycia i konfiguracji GPIO oraz zegara i w ogóle czasów... W jednym z takich not znalazłem cenne informacje na których oparłem dalsze prace. http://www.cypress.com/file/45381/download Po pierwsze przekonałem się że narzędzie PSoC Creator jest ok ale nie do końca należy się na nim opierać. Przykład: Po wybraniu Digital Output Pin z Katalogu Komponentów i wygenerowaniu dla niego API czyli plików .c oraz .h zawierając makra pomocne przy obsłudze każdego komponentu. Jednak należy być ostrożnym przy używaniu zdefiniowanych przez kreator makr. Jeżeli potrzebuje w moim projekcie banglować jakimś pinem, ma do dyspozycji proste makro:
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
No i super ale uwaga mamy też do dyspozycji bezpośredni dostęp do rejestru tego pinu (sposób przedstawiony przez Mirka w jego poradniku) i wtedy to samo banglowanie będzie wyglądać tak
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Porównanie działania obu makr jest po prostu powalające, otóż pin balglowany makrem _Write w moim układzie generował cztery razy wolniejszy przebieg od banglowania makrem dostępu do rejestru _DR. Tak tak różnica jest aż tak duża. Pewnie dla Tych z Was którzy obeznani jesteście w tych procesorach to nic nowego, dla mnie jednak to nauczka która pomogła mi opanować problem " slimaczej pracy". Po tym doświadczeniu przewaliłem całą bibliotekę i pozmieniałem wszystkie makra... Mój projekt zaczął chodzić jak rakieta. Jednak pojawił się nowy problem Po uzyskaniu wysokiej szybkości pracy mojej przeportowanej biblioteki, pojawiły się problemy z kolorami... czasami każdy font w stringu miał inny kolor albo pojawiały się dziwne echa.. Znowu zacząłem przyglądać się zawartości funkcji rysujących na wyświetlaczu i zacząłem wstawiać opóźnienia. Wszystko zaczęło działać prawidłowo po wstawieniu zwłoki 40uS w makro WR_STB. ale wtedy znowu wyświetlacz pracował w tempie ślimaczym Wpadłem na pomysł przetestowania wyświetlacza na moim zestawie ATB 1.05 z zainstalowanym CYPRESS SHIELD na którym wlutowałem sobie CY8C5267AXI - LP051. No i biblioteka pracuje po prostu MEGA SZYBKO !!!! wywaliłem wszystkie delaye i testowałem na wiele sposobów i wszystko działa wręcz idealnie. Ok co zatem jest nie tak z CY8CKIT-059 PSoC® 5LP Prototyping Kit ????? No problem okazał się banalny, to znaczy kondensatory które są umieszczone na niektórych pinach w tym module. Niestety ja potrzebowałem dwóch portów całych do sterowania wyświetlaczem i jeszcze czterech pinów do obsługi. Mimo iż testowałem wyświetlacz na trzech różnych portach, to zawsze trafiałem na jakieś piny na których siedział 1uF i który przy wyższych prędkościach powodował problemy. (Piny P0.2, P0.3, P0.4, P3.2 na tych pinach umieszczone są kondensatory 1uF) Dzielę się z Wami tym bo zapłaciłem za moją głupotę 3 dni !! a przecież na opisówce CYCKITu jest gwiazdeczka z opisem do których pinów dolutowano kondensatory.
a tak działa znowu na CYCKIT po wylutowaniu kondensatorów 1uF - C9, C12, C13 na porcie P0 oraz C7 na P3.2. Właśnie tych portów P0 i P3 używałem do transferu danych do wyświetlacza.
No to super, że udało się Tobie odnaleźć źródło problemu. To prawda, że API jest wygodne, ale wolne w porównaniu do bezpośredniego sterowania pinami. Na szczęście można sobie to uprościć korzystając z #define i wtedy portować można całą bibliotekę, jeśli tylko była dobrze napisana (np. Mirka do LCD).
P. S. W Arduino podobnie - też jest digital write ale szybsze jest bezpośrednie sterowanie portami.
ale uwaga mamy też do dyspozycji bezpośredni dostęp do rejestru tego pinu (sposób przedstawiony przez Mirka w jego poradniku) i wtedy to samo banglowanie będzie wyglądać tak Składnia: [ Pobierz ] [ Ukryj ]
Teraz już wiesz dlaczego ja wolę taki, że tak powiem "nasz bezpośredni" dostęp a nie przez jakieś kocie generowane makra ?
Czy to jest wyświetlacz 3.2'' 320 x 480 ? Czemu link w pierwszym poście do przykładu na AVR jest niedostępny ? Gdzie kupiłeś ten wyświetlacz ?
Tak to jest taki wyświetlacz
Wątek który umieściłem wcześniej, a który dotyczył zastosowania tego wyświetlacza z AVR skasowałem w przypływie sceptycyzmu. To jest wyświetlacz który posiada wyłącznie magistralę 16bit i zastosowanie go z AVRem to chyba tylko w wersji na SPI i to minimum na Atmega32 (i raczej dla desperatów). Poza tym, ten kod dla CYCKITA nie wiele różni się od AVR, tam są tylko kwestie zmiany niektórych ustawień i w przypadku AVR przywrócenia Progmem. Cała biblioteka dla AVR po SPI jest dostępna w wątku kolegi Intre. Takie wyświetlacze nabyłem już jakiś czas temu (wiosna ubiegłego roku) na jednym takim portalu aukcyjnym za jakieś 58zł sztuka.
Mirku ja jestem jeszcze programowym niemowlakiem, moje używanie języka C sprowadza się do lizania .... ale już nawet te zabawy pokazują że to czego nauczyłem się z Twoich książek i poradników w zastosowaniu do AVRów, to wiedza niebywale pomocna w poszerzaniu horyzontów. Wsiąkłem teraz w te CYCKI i wygrzebać się nie mogę, a większość problemów rozgryzam najpierw na AVR a potem przewalam to na Cypressa fajna zabawa, no po prostu bajka.
Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 0 gości
Nie możesz rozpoczynać nowych wątków Nie możesz odpowiadać w wątkach Nie możesz edytować swoich postów Nie możesz usuwać swoich postów Nie możesz dodawać załączników
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
a nie przez jakieś kocie generowane makra ? 
.... ale już nawet te zabawy pokazują że to czego nauczyłem się z Twoich książek i poradników w zastosowaniu do AVRów, to wiedza niebywale pomocna w poszerzaniu horyzontów. Wsiąkłem teraz w te CYCKI i wygrzebać się nie mogę, a większość problemów rozgryzam najpierw na AVR a potem przewalam to na Cypressa