(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
(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
18-07-2016, 14:17 (Ten post był ostatnio modyfikowany: 18-07-2016, 14:41 przez SQ8MVY.)
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.
18-07-2016, 17:08 (Ten post był ostatnio modyfikowany: 18-07-2016, 17:09 przez SQ8MVY.)
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ć....
18-07-2016, 19:09 (Ten post był ostatnio modyfikowany: 18-07-2016, 19:09 przez SQ5KHA.)
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ę .
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!
.
