[STM32][Eclipse] Sterowanie wyświetlaczem przez SSD1289

Witam,
Ostatnio dokonałem zakupu płytki prototypowej (ewaluacyjnej) z mikrokontrolerem STM32F103. Mini-STM32 -> http://arduinosolutions.com/index.php?route=product/product&product_id=90

Chciałem przenieść się z 8-bitowych AVRów na coś mocniejszego, więc padło właśnie na to. Jednak od razu natrafiłem na dosyć poważny problem. Wprawdzie dostałem kody źródłowe kilku przykładów, ale są one napisane w środowisku Keil (MDK-ARM/uVision), które jest płatne i raczej nie uśmiecha mi się w nim pisać. Preferowałbym coś darmowego, najlepiej Eclipse.

Szukałem bardzo długo i niestety nie znalazłem żadnych przykładowych kodów do obsługi LCD przez sterownik SSD1289 na STM32, z których mógłbym się uczyć.

Czy mieliście może do czynienia z tym sterownikiem? Mam wrażenie, że jest niezwykle mało popularny. Dostałem również przykładowe kody do obsługi LCD przez inny sterownik (ST7783), czy da radę w łatwy sposób je zmodyfikować do tamtego sterownika?

Będę wdzięczny za wszelkie lektury na temat i pomoc w temacie

Widzę, że procesorek ma FSMC, a wyświetlacz obsługuje interfejs i80 (8080). W związku z powyższym sterowanie nim będzie banalnie proste, gdyż FSMC będzie mu wrzucał wszystko co rozkażesz.

Wskazana lektura to datasheet tam masz wszystko opisane na temat konfiguracji FSMC podpowiem, że interesuje Cię NOR Flash/PSRAM controller. Podłączenie jest w nocie AN2790
http://www.icbase.com/hotic/html/docs/14811.pdf

Poza tym Keil do kodu nie przekraczającego 32kB pamięci jest darmowy

Dziękuje, faktycznie przez FSMC to prosta sprawa.

Jednak trafiłem na kolejny problem, siedziałem nad tym całą noc i nie mam pojęcia co robię źle.
Korzystam obecnie z nieco zmodyfikowanej biblioteki GLCD, niestety dokumentacja jest po chińsku.

Tak wygląda metoda wrzucająca na wyświetlacz bitmapę:


Tutaj jest plik nagłówkowy z bitmapą (dołączam dodatkowo jako załącznik)
http://paste.org/pastebin/view/35779

Natomiast w main, funkcję wywołuję tak:


Efekt to biały pasek po lewej stronie ekranu. Wydaje mi się, że sama metoda do wyświetlania jest zła. Co poradzić?

Nazwa tablicy w pliku załączniku jest inna, ale w kodzie jest ona poprawna.

Powodem może być niepoprawna konfiguracja rejestrów sterownika.

poza tym nie pokazałeś jak wygląda funkcja zapisu do ramu i ustawienia kursora. Ja używam takich funkcji:



W celu testowania funkcji skup się na ustawieniu tła, tzn zapisuj do ramu jeden kolor, jak to zadziała baw się we wskaźniki

Powodzenia,
Damian

Dziękuję, faktycznie ten powyższy kod sporo mi pomógł znaleźć błąd
Teraz bezproblemowo wyświetlam bitmapy z plików nagłówkowych, ale są one mocno niebieskie. Wygląda to tak, jakby patrzyło się na wyświetlacz przez niebieską folię półprzeźroczystą. Wyświetlanie tekstu poprzez funkcje biblioteki jest okej, kolory są normalne. Problem tyczy się jedynie bitmap z tablic. Podejrzewałem program do konwersji, ale przy innym miałem identyczną sytuację.

bitmapy rozumiem 24bitowe. W tym przypadku należy zastosować konwersję na kolor z 24bit na R5G6B5. Najlepiej taką bitmapę eksportować z photoshopa w tym formacie

Witam
Konfiguracja sprzętowa jak w powyższym temacie natomiast kod jak w temacie https://www.elektroda.pl/rtvforum/topic2088263.html#9923843. Mam problem z inicjalizacją wyświetlacza. Błąd występuje w momencie pierwszego zapisu do LCD funkcją LCD_WrReg(u8 reg, u16 data)
W momencie wykonania instrukcji mov.w r3, #1811939328 ; 0x6c000000
następuje skok do:
Debuger ląduje w pliku vectors.c na static void __Default_Handler(void)
{
while (1);
}

Dlaczego zapis rejestru R3 wartoscia 0x6c000000 powoduje zawieszenie wykonania programu?

Błąd powodują instrukcje poniżej:
200004b0: strh r0, [r3, #0]
200004b2: strh r1, [r3, #2]
Jest to zapis pod adres 0x6c000000, czyli że wyświetlacz musisz mieć podłaczony do FSMC, tyle że pewnie jest ono nieskonfigurowane - zapis pod nieistniejący adres wywołuje któryś tam wyjątek.

4\/3!!

Konfiguracje mam taką:

Wiec wynikalo by z tego że dla tego wyswietlacza powinna byc inna.

@lolcat1 również posiadam taka płytke
możesz wstawić poprawiony kod do wyświetlania bitmamp ??

Zestaw ten poprawnie działa przy ustawieniach (przynajmniej u mnie)


W moim przypadku DeviceCode = 0x8989
Oraz poprawnie wspolpracuje z biblioteka poniżej. Funkcje inicjacyjne można pominąć używając powyższych ustawień.

udalo sie wyswietlic bitmape ;p
u mnie wsystko ladnie pokazuje konwersje robie za pomoca image2lcd

Witam serdecznie ,

Postanowiłem się przyłączyć do tematu ponieważ mój problem jest ściśle związany z przypadkiem tu opisywanym,

W końcu znalazło się troszkę czasu żeby zabrać się za oprogramowywanie STMa ale jak to zwykle bywa początek nie był aż taki prosty..
Posiadam płytkę HY-mini z STM32F103VCT6, oraz Jtag-lock-pick kolegi Freddie'go
całość obsługiwana z poziomu eclipse przy pomocy ocd i gdb.
uruchomienie przykładów Freddiego przysporzyło mi na początku troszkę kłopotów ale chyba wynikało to głównie z mojego braku doświadczenia w obsłudze eclipse (troszkę innej wersji niż ta opisana w tutorialu) ale do rzeczy.

Postanowiłem uruchomić LCDka który znajduje się na płytce HY-mini ale pozostając przy minimalistycznym projekcie Freddiego tzn bez standardowych bibliotek. Troszkę pogrzebałem w dokumentacjach ST (swoja droga tragiczne jeśli by je porównać do dokumentacji TI - np. TMS320F28x , czy nawet Atmela) poskładałem wszystko razem to jest bibliotekę GLCD z konfiguracja "ręczna" FSMC i gpio. Niestety jak to zwykle bywa nie zadziałało. a ze oryginalnie wgrane demo uCOS działało bez zarzutów to oczywiście wina może tylko i wyłącznie leżeć po stronie softu poskładanego przeze mnie.
siedziałem pol nocy żeby na wszelkie możliwe sposoby to uruchomić ponieważ tych bibliotek konfiguracji SSD1289 są setki w internecie to było na czym się oprzeć.. choć trochę w ciemno bo hardwarowa konfiguracja tego LCDka jest chińską wiedzą tajemna ponieważ akurat kontrolera wraz z konfiguracja jego pinów nie ma na schemacie HY32D.

Przerobiłem nawet przykłady załączone na DVD do płytki tak aby można było je uruchomić z poziomu eclipse ale to tez nic nie dało .. cały czas pikny biały ekran..
aż to nad ranem niespodzianka po zasileniu płytki program działa ... hym..ale..

no wiec program działa wyświetla itd .. ale nie zawsze i tylko przez jaki czas..
wygląda to jak by był skonfigurowany do pracy synchronicznej ale częstotliwości są delikatnie różne w związku z czym po jakimś czasie rozjeżdża się wszystko na ekranie i wracamy do białego ekranu.. do czasu aż odłączymy zasilanie, pozwieramy wszystkie piny zasilające, odmówimy modlitwę do Murphy'ego itd.

tak "normalnie" po uruchomieniu na JTAGu jeszcze ani razu mi nie zadziałało.
próbowałem wielu zmian w ustawieniach "czasowych" FSMC (oczywiście również z tymi które wychodzą na podstawie obliczeń opartych na dokumentacjach SSD1289, LCD gdzieś z internetu, AN2790 itd)

żeby trochę zobrazować problem nakręciłem krotki (4min) filmik który obrazuje problem
http://www.youtube.com/watch?v=c_bt6u0L5As&list=HL1328466113&feature=mh_lolz
(uwaga muzyka dodana w tle w celach rozrywkowych - bo filmik jest jednak dosyć nudny;P jeśli ktoś nie przepada proszę od razu wyciszyć)

jakieś pomysły?

PS. na pewno pojawi się pytanie o kod oczywiście na życzenie mogę go zamieścić ale korzystałem już chyba ze wszystkiego wiec podejrzewam jakiś inny problem.

EDIT:
dodałem polskie krzaki do posta bo zupełnie o tym zapomniałem.

Zacznijmy może od tego w Twojej kompilacji:



Opis problemu sugeruje że timingi są albo na granicy albo po prostu w końcu coś rozwala Ci transmisję jakimś "impulsowym zakłóceniem". Jeśli masz sporo przerwań, to postaraj się maxymalnie je ograniczyć <:

4\/3!!

Dzięki za odzew Freddie,

Rzeczywiście w tej chwili timingi są dość wyżyłowane ale jak wspominałem nawet z nimi czasami się uruchamia i działa bardzo sympatycznie szybko. Nie mniej jednak już od początku próbowałem z "typowymi", wolnymi a nawet bardzo wolnymi ustawieniami FSMC jak i przerw przy konfiguracji SSD1289 i skutek był zawsze ten sam. Swoją drogą na filmku można zauważyć ze te ustawienia czasowe są dość wolne bo funkcja LCD_Clear(Red); ewidentnie powoli zapisuje piksel po pikselu co objawia sie płynnym przysłanianiem starego obrazu.

co do przerwań to mam jedynie SysTick'a na 1ms
no i zegary FSMC i SRAM (ale brak obsługi/wykorzystania przerwań)

w załączniku jest kod źródłowy (projekt w eclipse+open OCD+ gdb) oparty na przykładzie Freddiego

EDIT:
Polskie krzaki:)
poprawiłem kwestie nawiasów (jakiś chińczyk się nie postarał;P - funkcje wyświetlania sa prosto z GLCD) w funkcji wskazanej przez Freddiego niestety nie ma poprawy

rzuciłem jeszcze raz okiem na sygnały wychodzące do LCDka i natknąłem się na interesujące zjawiska.. mianowicie bardzo nie ładny sygnał D11 (FSMC) (NewFile0) (CH1 CS,CH2 D11) przy pierwszym wystąpieniu w czasie inicjalizacji ale mimo tego objawu inicjalizował się poprawnie..

później wysyłane dane wyglądały całkiem normalnie (NewFile1) - LCD działał poprawnie..


a jak obraz na wyświetlaczu zaczął się sypać to sygnały jak by były lekko podciągane wraz z CS = 1; nie powinno to być w zakresie tego co rozpoznaje LCD, nie mniej jednak jest to moim zdaniem dziwne dlaczego ma to związek z poprawnym/niepoprawnym działaniem LCD

Jakieś pomysły koledzy?

Witam
Mam identyczny zestaw, po skompilowaniu programu i załadowaniu do procesora (program umieściłem w pamięci RAM i uruchamiam z jtaga) nie zauważyłem żadnych nieprawidłowych objawów o których pisałeś.

o to już przynajmniej wiadomo że jest to kwestia hardware'owa (btw. nawet jak program chodził 10-15min to wszystko było w porządku?)
Jeśli tak to zostaje mi tylko jedno podejrzenie, które wcześniej wydawało mi się nie realne .. ale o tym później jak będę miał chwilkę,

Dzięki za test!

Swoją drogą mógłbyś wrzucić wersje programu którą zapisujesz do ramu? byłbym bardzo wdzięczny to oszczędziło by mi setek niepotrzebnych cykli

Pozdrawiam

Wykresy wyglądają tak jakby pin pracował czasami w trybie open-drain, więc albo problem na płytce albo uszkodzony układ.

4\/3!!

a nie jest to tak, że jak nie zapisuję do pamięci (FSMC) tzn jak CS jest podciągany do góry to szyna danych przestawia się na wejście? a następnie po jakimś czasie powstaje różnica potencjałów między masą kontrolera LCD a masą procesora i D=0 z punktu widzenia procka jest kilka set miliwoltów, a z punktu widzenia kontrolera dane z procka są ujemne lub mają za niską wartość HIGH.

Oto Twoja wersja troche przerobiona tak aby poszła z ram czyli modyfikacja main zmienilem też skrypt linekera i makefile. Ladujesz to przez
load_image C:\\ARM\\...\\flash.bin 0x20000000
a odpalasz
resume 0x20000000

Przechodzę podobne boje z wyświetlaczem HY35A na SSD1693. U mnie nie działa procedura odczytu danych z wyświetlacza.
Objaw jest taki, że procedura odczytu dany zwraca mi wartości jakie były ostatnio wpisywane (jakby pamiętała ostatni stan?).
Dziwna sprawa jest taka, że na początku miałem błąd w ustawieniach GPIO i w ogóle nie aktywowałem CS wyświetlacza
a mimo to wszystko się wyświetlało prawidłowo. Poniżej przedstawiam procedury odczytu i ich asemblerowe rozwinięcie.
Pierwsza LCD_X_Read01_16 - pojedynczy odczyt działa prawidłowo ale odczyt paczki już jest jak powyżej (nawet pierwszy odczyt jest już nieprawidłowy)





W trakcie działania programu nic nie zmienia ustawień FSMC ani GPIO a inny program który nie korzysta z odczytu pakietowego działa prawidłowo więc myślę, że podłączenia są prawidłowe.

Dzisiaj mam zamiar zobaczyć na oscyloskopie co się dzieje

thug napisał:

a nie jest to tak, że jak nie zapisuję do pamięci (FSMC) tzn jak CS jest podciągany do góry to szyna danych przestawia się na wejście? a następnie po jakimś czasie powstaje różnica potencjałów między masą kontrolera LCD a masą procesora i D=0 z punktu widzenia procka jest kilka set miliwoltów, a z punktu widzenia kontrolera dane z procka są ujemne lub mają za niską wartość HIGH.

Raczej ciężko żeby powstała taka różnica na masie, która jest połączona (jest?)... Może kilka mV, ale nie kilkaset.

4\/3!!

rzeczywiście z masą nie ma problemu - muszę przyznać, że jestem już chyba bardzo zdesperowany bo dzięki koledze sepako można stwierdzić definitywnie iż nie jest to błąd software'owy. Równocześnie pamiętam, że demo soft działał zawsze prawidłowo (tylko nie wiem jak długo bo nigdy się nim dłużej nie bawiłem, a odpaliłem go może ze 3 razy ) a hardware'owo nic nie zmieniałem (poza do lutowaniem pinhead'era - ale wykluczam to jako przyczynę bo przy takiej operacji amator nie był by nawet w stanie uszkodzić procka, a ja mam doświadczenie nawet w lutowaniu takich układów jak ten procesor)

Bez wyświetlacza wszystkie sygnały na data wyglądają dobrze ale to chyba właściwie nic nie znaczy.. :/

PS. bootowanie z RAMu działa wyśmienicie - dzięki za tipa

No to może wyświetlacz lub układ jest uszkodzony - takie rzeczy się zdarzają.

4\/3!!

Wykonałem parę obserwacji przebiegów. U mnie tak samo jak u kolegi thug przebiegi sygnałów sterujących są prawidłowe. Dane jednak mają dziwne przebiegi i tak samo zmiana CS powoduje dziwne podciągnięcia i oscylacje na bitach danych. Nigdy nie ma pełnej "1". Jak pisałem wcześniej mam tylko problem podczas odczytu - sterownik inny ale problemy podobne. Objaw na oscyloskopie jest taki jakby prądowo nie "wydalał" LCD.
Na działającym programie demo, przebiegi są bez zastrzeżeń.
Moje podejrzenia są z goła odwrotne: sprzęt OK, tylko coś skopane w programie - konkretnie to podejrzewam timing FSMC. Mam zamiar się temu przyjrzeć właśnie pod kontem wymaganych czasów. Doczytałem dokładnie pdfa dla mojego SSD1963 ..jest tam napisane drobnym druczkiem ".. pierwszy odczyt z paczki nie może być szybciej niż.." Ustawienia ściągnąłem z dema "chinczyków"... może były na granicy?
... thug na str63 pdfa dla swojego LCD masz podane czasy porównaj czy masz prawidłowe ????
// też jestem podłamany ..ze dwa tygodnie już na tym siedzę :/



mam jeszcze pytania: co jest wymuszone na liniach danych w czasie gdy FSMC z nich nie korzysta.. L, H, HiZ?
i czy można ( w jaki sposób) włączy rezystory podciągające w strukturze GPIO podczas pracy portu w trybie AF_PP?

Niestety nie mam oryginalnego wsadu demo żeby porównać to w podobny sposób jak kolega (swoją drogą możesz zmierzyć na oscyloskopie mniej więcej jakie tam są czasy dostępu) bo te w źródłach programu uCOS demo z Bootloaderem są szybsze niż wynikają z obliczeń, ale sam próbowałem we wszystkich kierunkach, w trybie SRAM jak i NOR Flash.
Co do odczytu to z tego co przeczytałem w tym pdfie do SSD1289 to przy odczycie czasy muszą być oczywiście dużo dłuższe no i przy odczycie z ramu trzeba odczytać najpierw dummy data.
Ja natomiast nie mam żadnych problemów z odczytem sygnatury kontrolera LCD.

oczywiście może to być zwyczajnie uszkodzony procek lub LCD, gdyby ktoś miał oryginalny wsad demo to mógłbym sprawdzić czy to demo rzeczywiście działało poprawnie na dłuższą metę, jak i porównać timing'i.

nie wiem jak jest z tymi alternatywnymi (bo np wypadku szyny danych one muszą być tez czasami wejściami) funkcjami ale normalnie PP (push-pull) to półmostek wiec nie trzeba nic podciągać.

Czasy które pomierzyłem:
CS - ok 175ns, WR - 80ns, RD -175ns. Posiadam też zestaw Mini z SSD1289 i demo działa bez zarzutu godzinami. Mogę Ci je podesłać, tylko w jakiej formie chciałbyś?

Najprościej zrzucić wszystko na uszkodzony sprzęt, sam sobie tak wytłumaczyłbym gdyby nie działające demo.
Obecnie mam sytuacje taką:
demo
1.rozbiegówka napisana przez producenta w StdLib
2.inicjalizacja FSMC i LCD moja własna
3.nieskończona pętla zapisu i odczytu LCD
Zapis i odczyt odbywa się prawidłowo

mój program
1.moja własna rozbiegówka napisana bez użycia StdLib
2.inicjalizacja FSMC i LCD moja własna (dokładnie taka sama j/w)
3.nieskończona pętla zapisu i odczytu LCD (j/w))
Zapis prawidłowy.
Przy odczycie objawy są takie: wyświetlacz jednak wystawia oczekiwane dane jednak nie potrafi ustawić odpowiednich poziomów na magistrali ponieważ w jakiś nie wytłumaczalny dla mnie sposób podczas odczyt pojawiają się ostatnio zapisywane. Tego jestem pewien bo robiłem też próby z wypiętym LCD. Podczas odczytu pojawiają ostatnio zapisywane dane.
Na razie nie wiem jak to możliwe i co ustawiłem źle w rozbiegówce (bo tylko tym teraz różnią się te dwa programy) ale dojdę to tego . Może masz jakiś pomysł - nawet bez sensu? ..być może jakieś inne urządzenie jednocześnie "odpowiada" tylko nie mam pojęcia jak to sprawdzić bo trochę tego wisi na magistrali?

postaram się to porównać u mnie jak będzie jakiś efekt

Co do dema to hex, bin , elf najlepiej bo to mogę bezpośrednio przez OpenOCD wrzucić

Jaką Ty masz płytkę uruchomieniową ? HY-mini tylko z wyświetlaczem HY-35A czy jeszcze coś innego np. RedBull ?
bo na mini nic nie ma poza wyświetlaczem na FSMC. Jeśli masz tego RedBull'a to wisi USB, 2xFlash, SRAM , chyba tez ethernet.. podpatrz czy przypadkiem nie wystawiasz CSa któregoś przez ten trick z dekodowaniem.. swoją drogą na tej płytce sygnał CS musi wychodzić jednocześnie z RS bo CS jest na liniach adresowych, a nie na NE wiec może tu jest jakiś problem?