+- HomeMade (http://sp-hm.pl)
+-- Dział: Oprogramowanie (/forum-84.html)
+--- Dział: Technika programowania mikroprocesorów (/forum-85.html)
+--- Wątek: Programowanie ARM, nauka, środowiska programistyczne IDE (/thread-2692.html)
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - BUBAMUBA - 08-08-2016 20:34
Witam
Pozwolę sobie włączyć się do dyskusji. Odnośnie komunikacji SPI z ILI9341 sami zauważyliście że specyfikacja mówi o prędkości do 10MHz więc wszystko ponad to to podkręcanie i nie każdemu uda się osiągnąć ten sam rezultat. Tak przy okazji zapytam czemu nie zdecydowaliście się używać interfejsu równoległego RBG lub 8080. Prędkości przesyłania są znacznie większe poprzez te interfejsy i SPI używany wyłącznie do konfiguracji. Odnośnie samego SPI. Na początek sprawdzić można konfiguracje pinów SPI czy są ustawione na co najmniej 50MHz (czy nie jest ustawiony na niższą)przy okazji radzę nie ustawiać tej wartości mocno na wyrost bo zbyt strome zbocza też nie są rzeczą dobrą. Jeśli chcecie używać SPI przy takich prędkościach jak 20M-40M i przy dużej ilości danych radziłbym używać DMA bo inaczej procek szybko się zapcha.
Co do optymalizacji, myślę że delikatną optymalizacje można włączyć. Odradzałbym tylko agresywną optymalizacje wielkości kodu. Optymalizator nie powinien ruszyć nawet bardzo szybkich funkcji szybciej się przyczepi do jakiejś pętli for która służy do opóźnienia.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 08-08-2016 21:10
(08-08-2016 20:34)BUBAMUBA napisał(a): Tak przy okazji zapytam czemu nie zdecydowaliście się używać interfejsu równoległego RBG lub 8080. Prędkości przesyłania są znacznie większe poprzez te interfejsy i SPI używany wyłącznie do konfiguracji.
Nie używamy interfejsu RGB bo ktoś go musi oprogramować, najlepiej bez SPL-a i HAL-a. Trudno w jednym przykładzie zrobić wszystko: konfigurację SPI, SDRAM, FMC i LTDC.
Do konfiguracji ILI9341 trzeba było napisać funkcje do obsługi SPI dlatego naturalnym krokiem było wykorzystanie tych funkcji do zrobienia prostej grafiki aby można było już coś wyświetlać.
Od początku kursu namawiamy do większej aktywności i współpracy w powstawaniu przykładowych programów. Może ktoś ma już rozpracowany temat równoległego starowania ILI9341 przez kontroler wbudowany w STM32F429 ?
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - BUBAMUBA - 08-08-2016 21:26
Ja jakiś czas temu rozpracowywałem ten temat, ale na jakiś czas dałem spokój. O ile sam LTDC i obsługę RAMu zewnętrznego mam opanowaną o tyle mam problemy z ustawieniem ILI aby poprawnie interpretował RGB. Ogólnie wyświetla tylko problem jest z kolorem białym bo jest lekko turkusowy zamiast białego. Oczywiście mówię o rozpracowaniu bez bibliotek SPLa. Aktualnie chyba przesiądę się na discovery z M7 bo tam sterownik wyświetlacza jest nieco "normalniejszy"
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 08-08-2016 22:05
Jeśli możesz to wrzuć na forum paczkę z kodem, wspólnymi siłami dojdziemy w czym jest problem. Jest trochę dobrze działających przykładów na ten moduł dlatego to raczej nie jest wina wyświetlacza czy kontrolera.
W tym kursie skupiamy się na procesorze STM32F429, materiału do opanowania jest wystarczająco dużo. Wszystko oczywiście zależy od potrzeb i umiejętności wykorzystania mocniejszego procesora.
------------------------------------------------------------------------------------------------------------
Kończę obsługę panela dotykowego (I2C+STMPE811).
Zdjęcie z testów w załączniku (mini paint mono).
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 08-08-2016 22:32
Witam,
Interfejsu 8080 dla wbudowanego LCD nie da się użyć ze względu na specyfikę podłączenia magistrali LCD do stm-a. Oczywiście mowa tu o płytce stm32f429I-Disc1.
Tak jak Adam pisze, najpierw trzeba opanować SDRAM a co się z tym wiąże i kontroler FMC. Bo bez sensu jest używać wbudowanej pamięci ram. Następnie nauczyć się oprogramować wbudowany kontroler LTDC itd...... Na to jest potrzebny czas.
DMA - i do tego powolutku dojdziemy... Bo dla czego nie można framebuffera mieć w RAM-ie i za pomocą DMA pchać dane przez SPI ? Można... Tylu ilu programistów, tyle jest rozwiązań....
Jak ktoś ma uwagi , propozycje na rozwiązanie danego zagadnienia niech napisze to z przykładami i wytłumaczy dlaczego to tak jest lepiej a nie inaczej....
Dla mnie, Adama i jeszcze paru innych kolegów świat ARM-ów - w tym wypadku stm32f429, jest czymś nowym. Jak na razie to z Adamem ciągniemy jakoś ten wózek.
Powoli, ale do przodu. Jak poznamy podstawową obsługę peryferiów, to wtedy można przeskoczyć poziom wyżej. Obsługa za pomocą przerwań usart-a, czy też DMA. Następnie te klocki sklejać w jakąś całość.
Jak widać w załączonych przykładach na razie wszystko jest robione prosto, tak aby dane peryferium ruszyło i było widać efekt.
Kolego BUBAMUBA
jak już wspomniałeś, że masz rozpracowane LTDC i SDRAM to fajnie by było, abyś coś więcej na ten temat napisał. Przedstawił jakiś przykład.......
Jeżeli się nie mylę, to w kontrolerze ILI9341 po zainicjowaniu przez SPI, należy przełączyć 4 piny konfiguracyjne wybierające rodzaj aktywnego interfejsu.
Dlatego też, te piny w płytce stm32f429I-Disco są podpięte pod GPIO stm-a. Stan na nich wstępnie jest ustawiony poprzez rezystory na aktywny interfejs SPI.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - BUBAMUBA - 08-08-2016 22:40
[attachment=11290]
Na razie umieszczam obsługę zewnętrznego ramu wraz z funkcjami do GPIO które używam. Co do całej paczki z kodem obsługującym LCD, muszą ją trochę przeredagować i od śmiecić przed upublicznieniem.
Oczywiście można pchać przez SPI ale przy maksymalnie podkręconym nie przepchniesz nawet 1/10 tego co przepchniesz przez RBG. A na discovery i tak masz zajęte linie do portu równoległego więc czemu ich nie wykorzystać. A DMA może przydać się do innych danych. Dla LTDC jest dedykowany DMA z wyspecjalizowanymi funkcjami. Na dodatek jak używasz LTDC masz do dyspozycji warstwy dzięki czemu możesz mieć kilka okien między którymi płynnie się przełączasz.
[attachment=11291]
Tutaj jest pokazane jak aktualnie wyświetla zdjęcie umieszczone w wewnętrznym RAMie. Barwy są zakłamane, za dużo niebieskiego.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 08-08-2016 23:05
W pełni się zgadzam.
Co do trybu równoległego - pisałem o interfejsie 8080, o którym wspomniałeś. Mieści sie na innych pinach niż równoległy RGB565 ( chyba z takim podpięty jest ILI9341).
Trzeba mieć też na uwadze, że do wszystkiego nie jest potrzebny szybki interfejs. W jednym zastosowaniu równoległe rgb, wartswy, okienka - jak najbardziej, w innym z ograniczoną liczbą pinów wystarczy SPI.
Co nie zmienia faktu, że dobrze poznać każdy z nich, aby wiedzieć coś więcej.
My, ze względów poziomu wiedzy, jaką obecnie dysponujemy zaczęliśmy od SPI.
I nie chodzi o to, czy SPI przepchnie mniej, czy rgb przepchnie więcej. Cały czas rozchodzi się o naukę.....
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 10-08-2016 16:14
Z obsługą SDRAM-u i FMC nie ma większego problemu, w pliku system_stm32f4xx.c mamy gotową funkcję SystemInit_ExtMemCtl, która zostanie dołączona po zamieszczeniu w programie definicji: DATA_IN_ExtSDRAM. Funkcja zawiera pełną konfigurację portów GPIO pod SDRAM oraz konfigurację FMC.
Najistotniejszy jest poprawna konfiguracja ILI9341, kontroler LTDC oraz proste demo łączące wszystko w jedną całość.
-----------------------------------------------------------------------------------------------------------------
Możliwości wyświetlacza i ekranu dotykowego oraz kolory możemy sprawdzić na przykładowym demo paint-a.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 12-08-2016 11:58
Witam,
Kilka dni temu na stronie SEGGER-a pojawiła się nowa wersja firmware J-Linka dla wbudowanych programatorów ST-Link.
Tu jest do pobrania nowa wersja STLinkReflash.
Jeżeli ktoś używa J-Linka na płytkach Discovery gorąco polecam aktualizacje. Poprawiono działanie wirtualnego portu VCOM. Teraz VCOM działa bezbłędnie.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - BUBAMUBA - 12-08-2016 21:18
Hey
Jakoś ostatnio mało czasu mam na hobby i nie mam czasu opakować wszystkiego w ładną całość wstawię wam to w kawałkach z instrukcją montażu. Jakiś czas temu umieściłem już na elektrodzie paczkę z plikami do obsługi LCD. Paczka ta była modyfikacją do przykładowego projektu freddiego chopina (użytkownik elektrody).
link do przykładu:
http://www.freddiechopin.info/pl/download/category/6-przyklady
Jest to przykład działający na "czystym eclipsie" bez arm plugin czy cocooxa. Dodane są tylko plugny (zylin, gdb) do debugu oraz wskazany kompilator. Jako że bazuje on na makefile myślę że niema najmniejszego problemu przenieś przykład na dowolne środowisko, ja jednak do tej pory pracuje na tym. Na jego stronie jest już troche przestarzała instrukcja jak zrobić to środowisko. Jeśli ktoś ma ochotę to mogę pomóc je złożyć.
Po zaimportowaniu tego środowiska należy rozpakować moją paczkę i podmienić/dodać pliki.
I tyle po skompilowaniu ekran będzie się świecił na biało(w moim przypadku wychodzi ten przeklęty lekki turkus).
Aby zacząć malować wystarczy dodać/skonfigurować warstwę po skonfigurowaniu LCD:
LTDC_Layer1->WHPCR = 30 | (269 <<16);
LTDC_Layer1->WVPCR = 4 | (323 <<16);
LTDC_Layer1->PFCR = 0b0;
LTDC_Layer1->CFBAR = 0xD0000000;
LTDC_Layer1->CFBLR = 963 | (960 <<16);
LTDC_Layer1->CFBLNR = 320;
LTDC_Layer1->CR |= LTDC_LxCR_LEN;
LTDC_Layer1->CACR = 0xFF;
LTDC->SRCR = LTDC_SRCR_IMR;
LTDC->GCR |= LTDC_GCR_LTDCEN;
I od tej pory ramka rozpoczyna się od adresu:
0xD0000000;
każdy piksel to 32 bity format ARGB8888.
Umieszczam to abyście mogli zacząć się temu przyglądać/wzorować się na tym. Nie wykluczam błędów. U mnie to działa ale możliwe że dokonałem modyfikacji których w tej paczce nie umieściłem. Jednak muszę znaleźć więcej czasu bo nie chce dodawać wersji która jest zlepkiem różnych eksperymentów, a tak właśnie wygląda najaktualniejszy kod źródłowy na którym pracuje. Musze zacząć od nowego projektu, poskładać to co jest potrzebne i po sprawdzeniu wam to udostępnię.