+- Forum HomeMade (https://sp-hm.pl)
+-- Dział: Oprogramowanie (https://sp-hm.pl/forumdisplay.php?fid=12)
+--- Dział: Technika programowania mikroprocesorów (https://sp-hm.pl/forumdisplay.php?fid=58)
+--- Wątek: Programowanie ARM, nauka, środowiska programistyczne IDE (/showthread.php?tid=1816)
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6LUN - 17-07-2016
(17-07-2016, 18:52)SQ8MVY napisał(a):(17-07-2016, 14:08)SP6LUN napisał(a): Z002 - błędy, prawdopodobnie nieco inna składnia asemblera.
A coś jaśniej ? Z002 przenosiłeś na embed ?
Tak.
Faktycznie, wygląda na to, że tylko proste projekty da się bezproblemowo przenosić między mbed a EmBitz.
Dziękuję za wskazówki do konwersji elf na bin.
Praktycznie mam w tej chwili "uruchomione"
stm32F429 disc1 pod EmBitz i mbed
stm32mini pod EmBitz - tu procesor tylko stm32f103 ale 2x większy LCD
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 18-07-2016
(17-07-2016, 22:44)SP6LUN napisał(a): Praktycznie mam w tej chwili "uruchomione"
stm32F429 disc1 pod EmBitz i mbed
stm32mini pod EmBitz - tu procesor tylko stm32f103 ale 2x większy LCD
Więc zabawa się zaczęła....
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ5KHA - 18-07-2016
Czy sprawdzał ktoś część odbiorczą z Z002?
Dokładnie chodzi o to, że znak znajduje się w buforze RX, ale nie jest ustawiana flaga, że pojawiła się wartość w rejestrze USART1->DR.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 18-07-2016
Cześć,
Tak działa dobrze. Jak masz w programatorze firmware J-Linka to zmień do tego przykładu na ST-Linka.
J-Link ma strasznego babola, objawiającego się tym, że nie przesyła prawidłowych danych z komputera do STM-a
Cytat:znak znajduje się w buforze RX, ale nie jest ustawiana flaga, że pojawiła się wartość w rejestrze USART1->DR.
A sprawdź też pozostałe flagi dotyczące błędów np. błąd ramki FE. Jak się ustawiają, to prawdopodobnie RXNE się nie ustawi, bo wartość w rejestrze odbiorczym jest błędna.
Przy okazji zauważyłem jeszcze jedną rzecz, która prawdopodobnie mi się przestawiła jak porządkowałem kolejność ustawiania rejestrów USART1, a tyczy się przykładu w archiwum Z002v1.
W pliku usart1.c w funkcji usart1_Init jest obecnie:
Kod:
//Ustawiamy Pull-Up-a dla nóżki RX-a, aby nie wisiał w powietrzu, jak nie będzie do niczego podpięta
//Nóżka PA9 - TX jako wyjściowa domyślie jest PushPull, więc nie ma potrzeby jej konfigurować
GPIOA->PUPDR |= GPIO_PUPDR_PUPDR10_1;a powinno być:
Kod:
GPIOA->PUPDR |= GPIO_PUPDR_PUPDR10_0;Przez przypadek zamiast Pull-Up-a włączyłem Pull-Down-a. Pomimo takiej drobnostki przykład działa bezbłędnie.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ5KHA - 18-07-2016
Dzięki za odpowiedź, jeszcze popatrzę na to uważniej, wartość w rejestrze USART->DR jest taka sama jak wysłam z PC.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 18-07-2016
Tu jest jeszcze jednen problem, z odczytem wartości rejestrów USART w debuggerze.
Wspomniany bit RXNE (RX Not Empty) jest kasowany sprzętowo (programowo też można go skasować poprzez wpisanie 0 do tego rejestru) poprzez odczyt danej z rejestru DR. Więc jak debugger podaje Ci prawidłową wartość rejestru DR, to ta wartość musiała być fizycznie odczytana przez debugger. Jeśli tak, to i flaga RXNE automatycznie zostaje niezauważalnie skasowana.
Trzeba być bardzo uważnym, aby zaobserwować zmianę flagi RXNE, bo widać ją tylko przez 1 odczyt rejestrów USART-a.
Zawartość rejestru DR przez odczyt nie jest kasowana, więc widnieje cały czas w podglądzie rejestrów USART-a. Dopiero jak nadejdzie portem szeregowym nowa dana, to zostaje ona przepisana z rejestru szeregowego (niewidocznego) do rejestru DR, zastępując poptrzednią wartość...
Nadal nie podałeś nic na temat tego, czy przykład w normalnym trybie (bez debugowania) Ci działa prawidłowo, jakie firmware masz obecnie w zintegrowanym programatorze, oraz jaką wersję płytki Discovery posiadasz. Są to kluczowe informacje, bez których można tylko gdybać....
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ5KHA - 18-07-2016
Ok, dzięki za pomoc, pomęczę się jeszcze trochę sam, jak nie będzie wyników to będziemy się martwić, chodzi o to że program nie wchodzi w warunek (nie pamiętam z pamięci) funkcji usart1_getc() i return zwraca cały czas wartość zero, ale póki co się nie poddaję
.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 18-07-2016
Ok, jestem do dyspozycji ..
A tak z ciekawości, które archiwum pobrałeś ? Z002.zip, czy to poprawione Z002v1.zip..
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 20-07-2016
(06-07-2016, 11:07)SP6IFN napisał(a): A mnie dodatkowo interesuje też co jest na tej płytce ...
Krótki opis modułu STM32F429-DISCO z Elektroniki Praktycznej w załączniku.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6IFN - 20-07-2016
Dziękuję za załącznik jw.
Nikt o nic nie pyta, Nikt się nie chwali, to ja sobie pozwolę napisać. Zadanie Z002 zostało przerobione, temat zrozumiałem, program jest wgrany do płytki uruchomieniowej i prawidłowo współpracuje z terminalem PUTTY. Nie obyło się bez problemów, ale dzięki Kolegom Piotrowi i Pawłowi, wszystkie problemy zostały rozwiązane. Komunikujemy się przy wykorzystaniu komunikatora qTox, warto go zainstalować, gdyż bezpośredni kontakt w sprawie pomocy jest nieoceniony.
Rysio!