+- 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 - 17-08-2016 20:34
Kod w main różni się niewiele jednak patrząc na projekt który ty umieściłeś widzę że używasz innego startupa oraz inaczej konfigurujesz zegary. Coś z czymś nie chce współgrać.
Po czym poznajesz ze procesor wisi przy próbie zapisu do sdramu. W jaki tryb wchodzi rdzeń?
Podmień jeszcze te pliki z załącznika. To są te co używam teraz może wprowadziłem jakie drobne zmiany.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 17-08-2016 21:05
(17-08-2016 17:31)QRP73 napisał(a): ...Co to jest pamiec jednokrotnego zapisu, to takie OTP jak w starych procesorach?
OTP - One-Time Programmable bytes - specjalny obszar pamięci jednokrotnego zapisu
W rodzinie F4 obszar ten rozpoczyna się od adresu 0x1FFF 7800. Zorganizowany jest w 16 bankach. Każdy bank składa się z 32 bajtów. Ostatni bank 17, jest bankiem specjalnym, składającym się z 16 bajtów. W kolejności, każdy z bajtów tego banku odpowiada za blokowanie możliwości zapisu do banków 0 do 15.
Reszta do znalezienia w User Manualu do stm32F4.
(17-08-2016 17:31)QRP73 napisał(a): ..Kilka razy juz pisalem ze procesor wisi przy probie zapisu do sdramu. Zegar ustawilem na 180mhz, targed voltage 3,3V....
Kolego, rdzeń nie wisi, nie ma takiej możliwości. Jeżeli już wystąpi nieoczekiwana sytuacja, to prawdopodobnie wskakuje do wektora HardFault_Handler i tam w nieskończonej pętli siedzi.
Ale, żeby tego się dowiedzieć, należy przeanalizować to co pokazuje wbudowany debugger w EmBitz-a, łącznie z tym co widać w okienku z wartościami zmiennych... Najlepiej wklej zrzut ekranu z debuggera....
Kolego BUBAMUBA, fajnie, że się dzielisz swoją wiedzą, ale rób to z głową. Jak wiesz, pracujemy w środowisku EmBitz, więc dobrze, aby Twój kod był jako projekt dla tego środowiska. Bo w chwili obecnej, taka zbieranina kawałków kodu, z różnych portali, jaką wklejasz, nie ma sensu. Właśnie wychodzą takie "kwiatki" jak ma QRP73. A co mają zrobić osoby, które dopiero zaczynają ? Szczerze mówiąc nawet nie miałem najmniejszej ochoty składać tego w projekt pod EmBitz i uruchamiać....
(12-08-2016 21:18)BUBAMUBA napisał(a): ....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....Proszę, wskaż gdzie w Twoim archiwum jest plik MakeFile, który umożliwi prawidłową kompilację kodu ? Pragnę również przypomnieć, że cocoox to nie jest plugin do eclipsa, lecz całe środowisko IDE bazujące na eclipse.
Nie chcę, aby z tego tematu zrobił się śmietnik, z nic nie wartymi kodami. Jeżeli już, to trzymajmy się jakiegoś standardu. Takim stał się EmBitz i CMSIS bez dodatkowych bibliotek HAL, czy SPL. Taka paczka powinna się dać bez problemu rozpakować, otworzyć w EmBitz, oraz BEZ BŁĘDÓW skompilować, a co najważniejsze uruchomić poprawnie na STM32F429I-Disc1(0)
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - QRP73 - 17-08-2016 21:49
Bez zmian, program nie wychodzi z funkcji inicjowania sdramu. Na koncu jest zerowanie ramki obrazu, kasuje kilka pikseli i tyle, stoi w miejscu. Nawet nie dochodzi do mrugania dioda. Moze problem jest w plikach stm32f4xx.h i system.
Dlaczego nie wrzuci kolega do zipa kompletu plikow ?
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6LUN - 18-08-2016 0:10
(17-08-2016 21:49)QRP73 napisał(a): Bez zmian, program nie wychodzi z funkcji inicjowania sdramu. Na koncu jest zerowanie ramki obrazu, kasuje kilka pikseli i tyle, stoi w miejscu. Nawet nie dochodzi do mrugania dioda. Moze problem jest w plikach stm32f4xx.h i system.
Dlaczego nie wrzuci kolega do zipa kompletu plikow ?
Dokładnie kasuje 16 pixeli...
Efektu jednak nie widać na ekranie.
Czy konfiguracja portów odpowiedzialnych za sygnały SDNE1 i SDCKE1
(linie 69 i 70 w sdram.c) jest wyłączona celowo?
Piny te są odpowiedzialne za wybór pamięci (~CS) i uaktywnienie zegara (CKE).
Jeżeli "wiszą" w powietrzu, stany tych sygnałów mogą zależeć od przypadkowych sprzężeń pojemnościowych.
------
Uaktywnienie tych sygnałów nie przynosi żadnego efektu.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 18-08-2016 22:23
(17-08-2016 21:05)SQ8MVY napisał(a): Nie chcę, aby z tego tematu zrobił się śmietnik, z nic nie wartymi kodami. Jeżeli już, to trzymajmy się jakiegoś standardu. Takim stał się EmBitz i CMSIS bez dodatkowych bibliotek HAL, czy SPL. Taka paczka powinna się dać bez problemu rozpakować, otworzyć w EmBitz, oraz BEZ BŁĘDÓW skompilować, a co najważniejsze uruchomić poprawnie na STM32F429I-Disc1(0)
Moim zdaniem to powinna być generalna zasada zamieszczania własnych przykładów na naszym forum. Nie przenośmy tutaj najgorszych wzorców z elektrody. Rzucamy kawałek kodu a reszta niech kombinuje co autor miał na myśli. Projekty mogą powstawać w innym środowisku ale muszą być kompletne, kompilowalne i działające bez konieczności dogrywania brakujących plików.
Krótko przeglądałem kod do inicjowania SDRAM-u. Konfiguracja pinów wydaje się poprawna natomiast ustawienie rejestrów SDCR[0], SDCR[1] jest niewłaściwe. Trzeba posiedzieć nad opisem obsługi SDRAM-u. Jest też jakiś problem z optymalizacją kodu, stąd zmienna pośrednia volatile ptr przed zapisem do rejestru.
Kod:
ptr = FMC_SDCR1_SDCLK_1 | FMC_SDCR1_RPIPE_0;
FMC_Bank5_6->SDCR[0] = ptr;
ptr = FMC_SDCR1_NR_0 | FMC_SDCR1_MWID_0 | FMC_SDCR1_NB | FMC_SDCR1_CAS |
FMC_SDCR1_SDCLK_1 | FMC_SDCR1_RPIPE_0;
FMC_Bank5_6->SDCR[1] = ptr;Po wykonaniu powyższej modyfikacji wykonuje się funkcja inicjowania SDRAM-u i poprawnie kasuje ramka obrazu.
W załączniku działająca paczka pod EmBitz (BUBAMUBA + paczka QRP73 + poprawki SP5FCS). Trzeba jeszcze poprawić konfigurację LTDC i przerobić kod na kolor formatu RGB565. Szkoda pamięci i czasu procesora na 24 bitowy kolor.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6IFN - 18-08-2016 23:03
(18-08-2016 22:23)SP5FCS napisał(a): W załączniku działająca paczka pod EmBitz (BUBAMUBA + paczka QRP73 + poprawki SP5FCS). Trzeba jeszcze poprawić konfigurację LTDC i przerobić kod na kolor formatu RGB565. Szkoda pamięci i czasu procesora na 24 bitowy kolor.Coś nie tak u mnie z wyświetlaczem się porobiło. Po wgraniu programu z załącznika rysowały się skośne linie. Ok, może tak miało być. Ale potem chciałem wgrać wcześniejsze dema Piotra i Adama, ale niestety, ekran świeci sobie jasno i nic nie wyświetla. Natomiast HEXy z lekcji Adama wgrywają się prawidłowo Jlinkiem i ekran wyświetla co trzeba. Demo Painta też działa. Ja nie wiem o co tu chodzi.
Rysio!
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - QRP73 - 19-08-2016 9:13
Pawel moze zle to okreslilem ze procesor wisi, slabo znam stma. Efekt byl taki, ze program zapetlal sie na kasowaniu ramki obrazu i nie przechdzil do dalszej czesci kodu. Teraz dziala poprawnie, rysuje biala linie i mruga zielona dioda.
Jako pocztkujacy tez uwazam ze dema musza byc kompletne i dzialajace. Duzo czasu siedzialem nad tymi kawalkami kodu fredii, radzio, buba, elektroda. Kilka razy pytalem czy to dziala, bez odpowiedzi.
Nie moglem sobie poradzic z naglowkiem pod procesor stm32f429, poniewaz EmBitz nie ma mozliwosci wybrania tego modelu a w pliku stm32f4xx brakuje deklaracji pod LTDC. Na poczatku nauki to za trudne tematy do opanowania.
W paczce jest plik do bitbandu, ogolnie wiem co to jest ale to kolejne nowe zaganienie.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 19-08-2016 11:15
Witaj,
Ja też początkujący jestem......
(19-08-2016 9:13)QRP73 napisał(a): ... w pliku stm32f4xx brakuje deklaracji pod LTDC...
Tak, obecna wersja EmBitz-a bazuje na starych wersjach bibliotek, i w przypadku nowszych STM-ów brakuje deklaracji (opisu) peryferii. Można dodać je ręcznie samemu, lub podmienić pliki na nowsze wersje. Dlatego właśnie należy wklejać kompletne archiwum projektu. W naszych przykładach, które udostępniliśmy do tej pory, brakujące definicje są dodane, ale tylko te które tyczą się użytego peryferiala np. SPI5 w przykładach obsługi LCD przez SPI.
Z ciekawości zaglądnąłem do Twojej paczki i zauważyłem, że dodałeś nowe wersje plików stm32f4xx.h oraz stm32f429xx.h zastępując te defaultowe z Embitza. Jak zauważyłes zapewne, w tym podmienionym stm32f4xx.h jest przyjęta inna zasada. To za pomocą niego inkludowane są odpowiednie pliki nagłówkowe z definicjami rejestrów - w tym przypadku jest dodatkowo dołączany stm32f429xx.h dotyczący STM-a na naszej płytce Discovery. W pliku dostarczanym przez EmBitza (stm32f4xx.h) już są zawarte takie definicje, ale "wybrakowane" -jak sam zauważyłeś.
I tu mała uwaga. Do większości Twoich plików dodawałeś na początku dyrektywę preprocesora #define STM32F429xx. Oczywiście jest ona potrzebna, aby poprzez plik nagłówkowy stm32f4xx.h został dodatkowo dołączony stm32f429xx.h.
Ale tego się tak nie robi, bo jak miałbyś w projekcie np. 500 plików żródłowych to do wszystkich byś musiał dodać to #define STM32F429xx.
A co byś zrobił, jak chciałbyś część plików z tego projektu użyć w innym projekcie z innym modelem STM-a - dla przykładu stm32f439 ? Trzeba by wszystko edytować i zmieniać na np #define STM32F439xx !!!
Te definicja dla preprocesora #define STM32F429xx musi być widziana globalnie w projekcie. Dlatego też nie umieszcza się jej w plikach źródłowych projektu, TYLKO dopisuje się do parametrów kompilatora w postaci STM32F429xx. A pole do dopisania znajduje się w Build options. Prawy klawisz na nazwie aktywnego projektu w oknie z drzewem projektów. Należy ten wpis dodać do obu profili projektu: Debug oraz Release.
[attachment=11346]
Generalnie o prawidłowe wpisy powinien zadbać kreator projektu EmBitza, ale że bazuje na starych wersjach bibliotek, nie robi tego. Nowa wersja EmBitza ma mieć już to poprawione, bo i będzie mieć nowsze biblioteki.
W innym środowisku IDE konfiguracja będzie w innym miejscu. Dla przykładu IDE CodeLite:
[attachment=11347]
(19-08-2016 9:13)QRP73 napisał(a): Nie moglem sobie poradzic z naglowkiem pod procesor stm32f429, poniewaz EmBitz nie ma mozliwosci wybrania tego modelu.......
Jestem pewien, że stm32f429 jest wspierany w kreatorze projektu EmBitz.
[attachment=11345]
Trochę z innej "beczki"...
Zauważyłem jeszcze jedną niepokojącą praktykę. Naszym językiem jest język polski, którym się na co dzień posługujemy. Jeżeli do pisanego kodu dodawane są opisy, to niech będą w naszym ojczystym języku, a nie jak można zauważyć w modzie od kolegi BUBAMUBA, jakąś łamaną angielszczyzną ! To ma być dla nas zrozumiałe...
Oczywiście uwaga ta nie dotyczy się kodu / bibliotek, które importujemy od kogoś ( cmsis, hal, spl oraz inne.....) bo szkoda czasu na tłumaczenie, tylko tych, które sami piszemy. Komentujmy nasze przykłady, programy, biblioteki, które będą zamieszczane na forum w naszym ojczystym języku.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6LUN - 19-08-2016 17:07
Dzisiaj analizowałem ustawienia korekcji gamma w module ILI9341.
W kodzie wygląda to tak:
LCD_WriteCommand(LCD_PGAMMA);
LCD_WriteData(0x0F);
......
Upps.. przypadkowo wysłałem posta na forum i nie mogę go skasować.
Zapytam więc tylko czy są zainteresowani ustawieniami gamma dla LCD.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 19-08-2016 17:28
Witaj,
Ustawienia GAMMA do czego służą w ILI9341 ?
Przeźroczystość, nasycenie kolorów, czy coś innego ? Nie analizowałem tych ustawień tak dokładnie. W naszych przykładach, ustawienia defaultowe działają dobrze, więc nie było potrzeby zmieniać. Ale jeżeli ma być lepiej, to jak najbardziej taka wiedza się przyda.... , więc opisuj śmiało.
Jedyne co zmieniałem to częstotliwość odświeżania LCD i różnicę było widać gołym okiem. Ale to wszystko w przypadku, gdy ILI9341 pracował tylko po magistrali SPI. Przy pracy magistralą LTDC (RGB) liczba klatek jest zależna od częstotliwości sygnału PIXEL_CLK.
Natomiast jak LCD będzie pracował na magistrali LTDC RGB, to wówczas cały sprzętowy mechanizm w stm-ie zajmuje się obróbką danych, składaniem warstw ( są 2 warstwy obrazu dostępne oraz tło), przenikaniami obrazu między warstwami i wieloma ciekawymi bajerami...