Ankieta: Jaki system operacyjnym preferujesz
Ankieta jest zamknięta.
Windows 60.78% 31 60.78%
Linux 31.37% 16 31.37%
MAC/OS 7.84% 4 7.84%
Inny 0% 0 0%
Razem 51 głosów 100%
*) odpowiedź wybrana przez Ciebie [Wyniki ankiety]

Odpowiedz 
 
Ocena wątku:
  • 1 Głosów - 5 Średnio
  • 1
  • 2
  • 3
  • 4
  • 5
Programowanie ARM, nauka, środowiska programistyczne IDE
SQ8MVY Offline
Paweł
****

Liczba postów: 542
Dołączył: 30-07-2011
Post: #91
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Właśnie zgłosiłem ten problem na forum Seggera. Będzie widać co odpowiedzą....

73 Paweł
15-07-2016 12:07
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
QRP73 Offline
Marek
**

Liczba postów: 90
Dołączył: 19-06-2009
Post: #92
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
A jak to testowac na pierwszej wersji DiscoveryF429 bo tam nie ma VCP. Potrzebny chyba bedzie konwert na USB i polaczenie pod zlacze modulu ?
15-07-2016 14:26
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP9FKP Offline
Piotr
*****

Liczba postów: 1,004
Dołączył: 28-06-2009
Post: #93
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
(15-07-2016 14:26)QRP73 napisał(a):  Potrzebny chyba bedzie konwert na USB i polaczenie pod zlacze modulu ?

Dokładnie, podłączony pod PA9 i PA10 modułu. USB/RS232 3.3V. Jako terminal sugeruję program Putty.
15-07-2016 14:41
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ8MVY Offline
Paweł
****

Liczba postów: 542
Dołączył: 30-07-2011
Post: #94
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Na podstawie drobnych uwag Adama SP5FCS, w załączniku kosmetycznie poprawiona wersja programowej obsługi portu szeregowego.

Zmiany:

- W pliku main.c konfiguracja SysTicka została przeniesiona za konfigurację portów sterujących diodami LED

- W pliku usart.c w funjkcji usart1_init(bautrate) została zmieniona kolejność inicjalizacji USART1 oraz została usunięta jedna niepotrzebna operacja konfigurująca nóżkę PA10 - RX

- Usunięty niepotrzebny plik usart1.c z katalogu z plikami nagłówkowymi,
przez przypadek się zaplątał przy przenoszeniu drzewa projektu

- usunięte błędy stylistyczne oraz poprawiona czytelność komentarzy. Mam nadzieje, że nie ma więcej literówek w komentarzach.... Jeśli zauważycie, piszcie, się poprawi......

Całość projektu została napisana pod EmBitz uruchomionym na Linuks Mint 17.3 W związku z tym w komentarzach mogą się pojawić krzaczki w miejscach polskich znaków.

Archiwum należy rozpakować , a następnie otworzyć pod EmBitz-em.

W zależności od tego jaki mamy w programatorze firmware ( J-Link, ST-Link) należy sobie ustawić interfejs w Debug->Interfaces, zakładka GDB server


.zip  Z002_v1.zip (Rozmiar: 529.93 KB / Pobrań: 104)

73 Paweł
(Ten post był ostatnio modyfikowany: 16-07-2016 12:20 przez SQ8MVY.)
16-07-2016 12:20
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP6IFN Offline
Rysio!
****

Liczba postów: 379
Dołączył: 23-03-2010
Post: #95
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Aby zrozumieć działanie programu Z002 przewertowałem 303 strony Datashetu en.DM00031020.pdf i wynotowałem słowa kluczowe by zrozumieć nazewnictwo, nieco inne niż przy obsłudze AVRów. Jeśli źle zrozumiałem, proszę mnie poprawić. Słowa kluczowe dotyczą głównego pliku main.c. Oto co ustaliłem:
Cytat:Zadanie Z002
Przybliżenie słów kluczowych występujących w lekcji:

RCC Register Control Clock
AHB1ENR włączenie rejestru zegara na szynie AHB1 (Enable Register)
GPIOGEN włączenie zegara rejestru wejście/wyjście portu G (Enabled)
MODER oznacza zmianę rejestru (Mode Register)
GPIOG-> MODER oznacza zmianę rejestru wejście/wyjście portu G
ODR Output Driver Register
ODR_13 stan rejestru na pin 13 ustawionym jako wyjście
MODER13_0 ustawia pin 13 jako wyjście ze stanem niskim
|= ustawia bit lub bity (OR)
^= zmienia stan bitów na przeciwny (XOR)

Być może ułatwi to zrozumienie innym "studentom" tego kursu, o co tu właściwie chodzi.
Rysio!
16-07-2016 21:24
Odwiedź stronę użytkownika Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ8MVY Offline
Paweł
****

Liczba postów: 542
Dołączył: 30-07-2011
Post: #96
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Witaj,

Aby zrozumieć, o co się w tych nazwach rozchodzi, może zobaczmy do dokumentu, który Rysio przytoczył, czyli en.DM00031020.pdf oraz do pliku stm32f429xx.h. Plik ten znajduje się w katalogu CMSIS/device/ w/w projektu. A dlaczego akurat ten plik ? Bo jest bezpośrednio powiązany z mikrokontrolerem, który znajduje się na naszej płytce Discovery. Znajdują się w nim definicje bitów rejestrów, struktury rejestrów peryferii i jeszcze innych ciekawych rzeczy.

RCC (Reset and Control Clock) to tak naprawdę jest cały zestaw rejestrów, które odpowiedzialne są za infrastrukturę zegarową.
Zaglądając do w/w pliku nagłówkowego od linii 711 znajduje się struktura RCC_TypeDef zawierająca rejestry należące do RCC. Kolejność rejestrów w strukturze też nie jest przypadkowa. Są one umieszczone w takiej kolejności, w jakiej występują w przestrzeni adresowej naszego stm-a.
Aby się nie zaplątać, nazwy rejestrów są takie same jak w w/w dokumentacji

AHB1ENR jest to nazwa jednego z wielu rejestrów należących do grupy RCC. A po czym to widać ? Bo znajduje się w strukturze RCC_TypeDef (plik stm32f429xx.h).
Porównując z dokumentacją, jego dokładny opis znajdziemy w rozdziale 6.3.10 w/w pdf-a. Skoczmy więc do tego rozdziału ! Co tam na samym początku się znajduje ? Taka fajna tabelka z opisem bitów w tym rejestrze. I jak się przyglądniemy to na pozycji bitu nr 6 mamy nasz GPIOGEN, którym włączamy/wyłączamy taktowanie całego portu G. Ale w programie nie użyliśmy nazwy GPIOEN, tylko RCC_AHB1ENR_GPIOGEN. I tu już po samej nazwie możemy wywnioskować, że ów bit GPIOEN znajduje się w rejestrzeAHB1ENR, który należy do grupy rejestrów RCC. A definicję tego naszego RCC_AHB1ENR_GPIOGEN znajdziemy w naszym pliku nagłówkowym stm32f429xx.h w linii 5785.

Nie wkleiłem tu jak wygląda struktura opisująca rejestry RCC bo za długa jest, ale pozwoliłem sobie wkleić strukturę portów. A wygląda ona tak:
Kod:
typedef struct
{
  __IO uint32_t MODER;    /*!< GPIO port mode register,               Address offset: 0x00      */
  __IO uint32_t OTYPER;   /*!< GPIO port output type register,        Address offset: 0x04      */
  __IO uint32_t OSPEEDR;  /*!< GPIO port output speed register,       Address offset: 0x08      */
  __IO uint32_t PUPDR;    /*!< GPIO port pull-up/pull-down register,  Address offset: 0x0C      */
  __IO uint32_t IDR;      /*!< GPIO port input data register,         Address offset: 0x10      */
  __IO uint32_t ODR;      /*!< GPIO port output data register,        Address offset: 0x14      */
  __IO uint32_t BSRR;     /*!< GPIO port bit set/reset register,      Address offset: 0x18      */
  __IO uint32_t LCKR;     /*!< GPIO port configuration lock register, Address offset: 0x1C      */
  __IO uint32_t AFR[2];   /*!< GPIO alternate function registers,     Address offset: 0x20-0x24 */
} GPIO_TypeDef;

I widzimy jak na dłoni, jakie rejestry są w grupie rejestrów portów. Mamy między innymi wspomniany przez Ciebie Rysio rejestr MODER, za pomocą którego konfigurujemy jaką funkcję przybierze dany pin - wejście, wyjście, funkcja alternatywna, bądź tryb analogowy. Każdy pin portu w tym rejestrze ma przypisane po dwa bity.
I tu dochodzimy do naszego MODER13_0. Dokładnie w programie użyte zostało GPIO_MODER_MODER13_0, które po samej nazwie już mówi, że bity odnoszą się do pinu 13, leżą w rejestrze MODER, należącym do grupy GPIO.
No dobrze, a co oznacza ta końcówka _0 ? Zobaczmy więc do dokumentacji (rozdział 8.4.1) oraz do naszego przytaczanego pliku nagłówkowego (w okolicach linii 4906)....
GPIO_MODER_MODER13_0 - 01 :General purpose output mode
GPIO_MODER_MODER13_1 - 10 :Alternate function mode
GPIO_MODER_MODER13 - 11 : Analog mode
Definicji dla dwóch bitów o wartości 00 nie ma. Raz, że jest to wartość domyślna po resecie, a dwa, że możemy to zrobić np. tak:
Kod:
&= ~GPIO_MODER_MODER13

Zostało to magiczne GPIOG-> MODER Jak to się je ?? W tym miejscu należy się zapoznać ze strukturami oraz wskaźnikami w języku C.
Zaglądnijmy więc do naszego pliku nagłówkowego - stm32f429xx.h.
Struktura opisująca rejestry portów nazywa się GPIO_TypeDef Ale jak to, struktura jest jedna, a portów jest kilka, i każdy ma swoje osobne rejestry. Jest na tyle dobrze, że rejestrów dla danego portu jest tyle samo, ułożonych w takiej samej kolejności...
Grzebiąc dalej w naszym pliku nagłówkowym widzimy takie cudo:
Kod:
#define GPIOG_BASE            (AHB1PERIPH_BASE + 0x1800U)
Tu już widać przy okazji, że GPIOG wisi na szynie zegarowej AHB1,
oraz
Kod:
#define GPIOG               ((GPIO_TypeDef *) GPIOG_BASE)
Oczywiście taka definicja jest nie tylko dla portu GPIOG, ale również i dla pozostałych portów, różniąca się adresem bazowym w przestrzeni adresowej

No to już wiemy co to jest, to nasze GPIOG. Jest to wskaźnik na strukturę rejestrów portu GPIOG. Pisząc
Kod:
GPIOG-> MODER
mówimy, że będziemy się odnosić do rejestru MODER należącego do portu GPIOG, którego rejestry opisane są w strukturze GPIO_TypeDef.
Taka sama zasada czytania definicji dotyczy się wszystkich peryferiów, bitów, rejestrów.

Mam nadzieję, że nic nie pomieszałem. Sam się dopiero uczę, więc jeżeli są w tych wypocinach jakieś błędy i nieścisłości, proszę bardziej doświadczonych o korektę.

73 Paweł
(Ten post był ostatnio modyfikowany: 17-07-2016 0:11 przez SQ8MVY.)
16-07-2016 23:15
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP5FCS Offline
Adam
*****

Liczba postów: 1,067
Dołączył: 02-02-2009
Post: #97
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Paweł, fajne zadanie z dobrym opisem. Mam jednak obawy co kryje się pod tą "ciszą" i brakiem pytań. Już w tym zadaniu materiału jest naprawdę dużo do opanowania.

Moduły programu
Nawet rozbudowany program napisany w języku C możemy umieścić w jednym pliku. Niestety wraz z przybywania kolejnych linii kodu jego czytelność jest coraz mniejsza a poruszanie się po całym kodzie trudniejsze. Nawet jeśli pogrupujemy definicje i funkcje w tematyczne bloki to odnalezienie ich w programie liczącym kilka tysięcy linii jest trudne i czasochłonne. W rozbudowanych procesorach takich jak STM32 sama ilość definicji rejestrów, bitów, stałych, funkcji obsługi rdzenia to kilkanaście tysięcy linii kodu. Aby jakoś zapanować nad tym ogromem informacji pogrupowano ją w bloki tematyczne i umieszczono w oddzielnych plikach. Poszczególne fragmenty kodu są włączane do naszego programu dyrektywą #include. Przykład: #include "stm32f4xx.h"

Od początku powstawania programu warto zadbać aby również nasz kod był podzielony na bloki tematyczne, w które zostaną pogrupowane definicje i funkcje do obsługi jednego zagadnienia np. USART, I2C, SPI, DSP, itd.
Dzięki podziałowi kodu na kilka plików:
- poruszanie się po kodzie i jego edycja jest łatwiejsza;
- tematyczne fragmenty kodu mogą być wykorzystywane w kolejnych projektach;
- możliwy jest podział realizacji dużego algorytmu na odrębne tematy i współpraca kilku programistów.

Poszczególne fragmenty kodu możemy łączyć dyrektywą #include w jeden program i kompilować całość. Takie rozwiązanie ma jednak jedną istotną wadę: cały kod musi być kompilowany przy każdej najmniejszej modyfikacji. Rozwiązaniem tej niedogodności są oddzielne moduły kodu które możemy kompilować niezależnie od innych fragmentów programu. Taki niezależny moduł zawiera wszystkie potrzebne elementy kodu: deklaracje zmiennych oraz kod funkcji do obsługi np. portu szeregowego.

Pliki nagłówkowe
Niezależnie skompilowane moduły muszą udostępniać sobie na wzajem pewien zestaw stałych, zmiennych oraz funkcji. Są jednak pewne lokalne zasoby, których muszą pozostać widoczne tylko wewnątrz danego modułu. Gdybyśmy wczytali kod modułu dyrektywą #include do głównego programu to mielibyśmy dostęp do wszystkiego co zawiera wczytany kod. Do rozwiązania tego zagadnienia służą plik nagłówkowe.

Plik nagłówkowy ( np. usart1.h dla modułu usart1.c ) musi zawierać te elementy, które mają być widoczne dla innych modułów. Jeśli jakiś moduł chce obsługiwać w swoim kodzie port USART1 to nie wczytuje źródła modułu usart1.c tylko wystarczy wczytać plik nagłówkowy usart1.h. Taki plik zawiera deklaracje (nie definicje) zmiennych i prototypy funkcji (nie ciało funkcji) z których będziemy mogli skorzystać w swoim kodzie. Zaletą oddzielnych modułów jest to, że możemy je kompilować niezależnie a po modyfikacji musimy kompilować tylko edytowany moduł co znacznie przyśpiesza kompilację całego kodu programu. Drugą zaletą jest to, że programista zajmujący się innym modułem nie musi mieć dostępu do kodu źródłowego innego modułu, wystarczy mu plik nagłówkowy i plik po kompilacji, resztę załatwi linker środowiska.

Uwagi do kodu z zadania nr. 2
Plik nagłówkowy usart1.h zawiera definicję bufora, którą moim zdaniem trzeba przenieść do kodu źródłowego modułu usart1.c bo to jest lokalna zmienna modułu usart1.c, którą będziemy udostępniali innym modułom.
Kod:
char usart_bufor_rx[bufor_size_rx];

W pliku nagłówkowym usart1.h musimy zamieścić deklarację
Kod:
extern char usart_bufor_rx[bufor_size_rx];

dla kompilatora i linkera, że jest taka zmiena zewnętrzna z której możemy korzystać a adres tej zmiennej zastanie dostarczony na etapie linkowania modułów.
Definicja bufora musi być w jednym miejscu ( plik usart1.c ) aby moduły wczytujące header usart1.h nie tworzyły własnych, lokalnych kopii bufora. Deklaracja extern zabezpiecza nas przed tym problemem.

Koledzy więcej aktywności i śmiałości. Dla mnie to też są nowe rzeczy, które staram się jakoś poukładać. Jeśli są jakieś nieścisłości lub braki w opisie proszę o korektę.

73 Adam
17-07-2016 11:46
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP6LUN Offline
Andrzej
***

Liczba postów: 141
Dołączył: 01-09-2014
Post: #98
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Ćwiczę na STM32F429-DISC1.
Programy wgrywam poprzez flasha.
Moduł reaguje tylko na pliki bin z platformy mbed (przynajmniej na razie tylko tyle opanowałem).
Projekty przenoszę więc na tę platformę.
Z001 - bez problemów.
Z002 - błędy, prawdopodobnie nieco inna składnia asemblera.

edit 15:09:
Udało mi się uruchomić moduł HY-MiniSTM32V, który leżał sobie
dłuższy czas w szufladzie.

Andrzej
(Ten post był ostatnio modyfikowany: 17-07-2016 15:09 przez SP6LUN.)
17-07-2016 15:08
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ8MVY Offline
Paweł
****

Liczba postów: 542
Dołączył: 30-07-2011
Post: #99
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
(17-07-2016 15:08)SP6LUN napisał(a):  Z002 - błędy, prawdopodobnie nieco inna składnia asemblera.

A coś jaśniej ? Z002 przenosiłeś na embed ? jak tak ,to w tym środowisku jest trochę inaczej. Mbed generalnie nastawione jest na obiektowość i C++ oraz ma swój kompilator z własnymi bibliotekami, które normalnie nie są widziane w drzewie projektu. A jeżeli już się je dostawi, to mają jakieś zależności związane z platformą Embed. Trzeba się odrobinę napocić, aby bardziej rozbudowane programy chciały się poprawnie kompilować. Identyczna sytuacja jest w drugą stronę. Rozbudowany projekt przeniesiony z Mbed ciężko doprowadzić do tego, aby bez błędów się kompilował w normalnym lokalnym środowisku.

Rzeczywiście, ST-Link zintegrowany przyjmuje tylko pliki *.bin ( metoda copy/paste do katalogu programatora ST-Link). Ale nie muszą to być pliki wygenerowane przez środowisko Mbed. Równie dobrze może takie pliki generować inne środowisko. Jeżeli nie ma takiej możliwości, to plik *.bin generujemy z pliku *.elf w taki sposób:
Kod:
arm-none-eabi-objcopy -Obinary ścieżka/do/naszego/pliku.elf ścieżka/do/naszego/pliku.bin
lub do pliku hex:
Kod:
arm-none-eabi-objcopy -Oihex ścieżka/do/naszego/pliku.elf ścieżka/do/naszego/pliku.hex

Równie dobrze te komendy można umieścić w ustawieniach projektu w zakładce post-build


Do tych przykładów zalecam instalację EmBitz-a. Gwarantuję, że wówczas nie będzie żadnych kłopotów....

73 Paweł
(Ten post był ostatnio modyfikowany: 17-07-2016 19:52 przez SQ8MVY.)
17-07-2016 19:52
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP6LUN Offline
Andrzej
***

Liczba postów: 141
Dołączył: 01-09-2014
Post: #100
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
(17-07-2016 19:52)SQ8MVY napisał(a):  
(17-07-2016 15: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

Andrzej
17-07-2016 23:44
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
Odpowiedz 


Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości