W dniu 2017-07-06 o 19:25, jacek pozniak pisze:

> Na razie staram się ogarnąć arm-none-eabi-gcc; kompiluje coś tam (prymitywne
> przykłady z /usr/share/doc/gcc-arm...), ale potrzebuję chyba nagłówki do
> poszczególnych procesorów, z definicjami peryferiów i takie tam.
> Sciąga się je skąś czy jak?
>
> Po zainstalowaniu arm-gcc nie mam żadnych plików w rodzaju *stm*.h
>
> jp
>
Ja zaczynałem od tego:
http://wydawnictwo.btc.pl/index.php?productID=187337
Na dole strony masz link do ćwiczeń. Powinny ci rozjaśnić co nieco.

do góry

Sebastian Biały wrote:

> On 7/6/2017 7:25 PM, jacek pozniak wrote:
>> Na razie staram się ogarnąć arm-none-eabi-gcc; kompiluje coś tam
>> (prymitywne
>> przykłady z /usr/share/doc/gcc-arm...), ale potrzebuję chyba nagłówki do
>> poszczególnych procesorów, z definicjami peryferiów i takie tam.
>> Sciąga się je skąś czy jak?
>
> Pobierz example do płytek Discovery jako dobry start na początek.
>
> Problem z STM32 jest taki że ST promuje własne środowisko i zgodnie z
> tym konceptem powinieneś je w zasadzie zassać:
>
> http://www.st.com/en/development-tools/sw4stm32.html
>
> Nagłówki z definicjami rejestrów i najwazniejsze - skryptem linkera,
> powinny być w komplecie. Nie używam i tu niewiele pomogę, ja składam
> firmware ręcznie, używając make i ukradzionych z jakiegos exampla
> nagłowkow.
Też muszę skąś ukraść.

W zasadzie po przeczytaniu krótkiego readme.txt, który się zainstalował
razem z kompilatorem, wygląda na to że w skrypcie dla linkera muszę podać
zakresy ROM/RAM i właśnie wydaje mi się że kilkunastu kilobajtów z
opisem/adresami rejestrów mi tylko brakuje.

Cytat z tego readme:
"...
The makefile is configured to build for Cortex-M0 by default. To build for
M3 or M4, pass CORTEX_M=3/4 respectively:
$ make CORTEX_M=3

* Porting *
These samples are written in a way that easily porting to variant Cortex-M
boards. Usually there are only two files you need modify for your boards.

ldscripts/mem.ld defines address ranges for flash and RAM. Modify them to
reflect start address and length of flash/RAM banks in your board, by
following the embedded comments.
..."


>

> Jak się upierasz ssać ręcznie, to tu masz punkt startowy do poszukiwań:
>
> https://developer.arm.com/embedded/cmsis
>
OK, będę kopał aż znajdę.

>> Po zainstalowaniu arm-gcc nie mam żadnych plików w rodzaju *stm*.h
>
> Bo armów jest miliard i kazdy ma inny nagłowek pertyferiów. Ściąga się
> je od producenta.

do góry

jacek pozniak <j...@f...pl> wrote:
>
> Na razie staram si? ogarn?? arm-none-eabi-gcc; kompiluje co? tam (prymitywne
> przyk?ady z /usr/share/doc/gcc-arm...), ale potrzebuj? chyba nag??wki do
> poszczeg?lnych procesor?w, z definicjami peryferi?w i takie tam.
> Sci?ga si? je sk?? czy jak?
>
> Po zainstalowaniu arm-gcc nie mam ?adnych plik?w w rodzaju *stm*.h

Potrzebujesz oddzielne pliki nalowkowe do procesora i byc moze
bilioteki. Wiekszosc ludzi uzywa plikow naglowkowych i
bibliotek dotarczanych przez STM (mozna sciagnac ze stron STM,
choc ostatnio probuja wrzucic paczke zawierajaca IDE Windowsowe
i reszte). Jesli interesujesz sie alternatywami to jedna
z mozliwoci jest libopecm3. Pare przykladow dla znajdziesz pod:

http://math.uni.wroc.pl/~p-wyk4/embed2016/pr/f0
http://math.uni.wroc.pl/~p-wyk4/embed2016/pr/f1
http://math.uni.wroc.pl/~p-wyk4/embed2016/pr/f4

(wiekszosc jest dla F0). Uwaga: te przyklady wrzucaja kod
do RAM. Potrzebna jest dosc oczywista modyfikacja jak
chcesz kod we flashu.

A propo: wiekszosc prockow STM i wiele prockow innych producentow
pozwala programowac flash przez port szeregowy, tak ze do programowania
wystarcza interfejs USB-serial 3.3V.

--
Waldek Hebisch

do góry

a...@m...uni.wroc.pl wrote:

> jacek pozniak <j...@f...pl> wrote:
>>
>> Na razie staram si? ogarn?? arm-none-eabi-gcc; kompiluje co? tam
>> (prymitywne
>> przyk?ady z /usr/share/doc/gcc-arm...), ale potrzebuj? chyba nag??wki do
>> poszczeg?lnych procesor?w, z definicjami peryferi?w i takie tam.
>> Sci?ga si? je sk?? czy jak?
>>
>> Po zainstalowaniu arm-gcc nie mam ?adnych plik?w w rodzaju *stm*.h
>
> Potrzebujesz oddzielne pliki nalowkowe do procesora i byc moze
> bilioteki. Wiekszosc ludzi uzywa plikow naglowkowych i
> bibliotek dotarczanych przez STM (mozna sciagnac ze stron STM,
> choc ostatnio probuja wrzucic paczke zawierajaca IDE Windowsowe
> i reszte). Jesli interesujesz sie alternatywami to jedna
> z mozliwoci jest libopecm3. Pare przykladow dla znajdziesz pod:
>
> http://math.uni.wroc.pl/~p-wyk4/embed2016/pr/f0
> http://math.uni.wroc.pl/~p-wyk4/embed2016/pr/f1
> http://math.uni.wroc.pl/~p-wyk4/embed2016/pr/f4
>
> (wiekszosc jest dla F0). Uwaga: te przyklady wrzucaja kod
> do RAM. Potrzebna jest dosc oczywista modyfikacja jak
> chcesz kod we flashu.
>
> A propo: wiekszosc prockow STM i wiele prockow innych producentow
> pozwala programowac flash przez port szeregowy, tak ze do programowania
> wystarcza interfejs USB-serial 3.3V.
>
Ogarnąłem już trochę openOCD i st-link. Działa, tzn łaczę się z procesorem
(via telnet).

Teraz przyszedł czas na jakiś wsad.

Pewnie powyciągam nagłówki z tego libopencm3 bo widzę, że w prostej formie
są zapodane.

jp

do góry

Dziękuję za pomoc wszystkim udzielającym się w tym wątku.

"Hello World" na LEDach zadziałał.



jp

do góry

On 7/8/2017 12:36 AM, jacek pozniak wrote:
> "Hello World" na LEDach zadziałał.

Jeszcze taka uwaga: jesli z jakiegos powodu ST-Link nie będzie uzyteczny
w innych zastosowaniach wymagających JTAG to zamiast kupować wypasiony
programator idź na ali i poszukal "ALtera ByteBlaster" za $2. Załatwia
on pozostałe przypadki jakie napotkałem.

Niestety im bardziej drogie i wypasione środowisko do programowania
czegoś tym bardziej będzie wymagać jakiegoś konkretnego hardware bez
powodu. Ale przynajmniej w przypadku zadań dla OpenOCD, ST-Link i
ByteBlaster są ok.

do góry

Sebastian Biały wrote:

> On 7/8/2017 12:36 AM, jacek pozniak wrote:
>> "Hello World" na LEDach zadziałał.
>
> Jeszcze taka uwaga: jesli z jakiegos powodu ST-Link nie będzie uzyteczny
> w innych zastosowaniach wymagających JTAG to zamiast kupować wypasiony
> programator idź na ali i poszukal "ALtera ByteBlaster" za $2. Załatwia
> on pozostałe przypadki jakie napotkałem.
OK
>
> Niestety im bardziej drogie i wypasione środowisko do programowania
> czegoś tym bardziej będzie wymagać jakiegoś konkretnego hardware bez
> powodu. Ale przynajmniej w przypadku zadań dla OpenOCD, ST-Link i
> ByteBlaster są ok.
No cóż na czymś muszą zarabiać.
Mi wystarczy openocd i stlink.
Teraz trza poznać troche architekturę tych STM i popróbować różne rzeczy
przeportować na tego arma.

jp

do góry

oczywiście to tylko prośba
jakbyś chciał się może Kolegom odwdzięczyć,
to możesz napisać mały tutorialek na temat debugowania tym zestawem -
tak, na moją stronę wwww...

do góry

wół, wół roboczy, wół dojno roboczo obronny 'POPIS/EU wrote:

> oczywiście to tylko prośba
> jakbyś chciał się może Kolegom odwdzięczyć,
> to możesz napisać mały tutorialek na temat debugowania tym zestawem -
> tak, na moją stronę wwww...
Niestety, nie debuguję, nie korzystam z opcji debugowania różnych stlinków
czy pickitów. :)
Wszystkie peryferia docelowej platformy staram się zamodelować na PC i
przetestować poprawność programu.
Potem przenoszę na platformę docelową i usuwam ewentualne niedopatrzenia, na
tym etapie zwykle nie ma tego wiele.

W związku z tym nie pomogę zbyt wiele, korzystam tylko, w przypadku ST-
linka, z następującego polecenia (które zresztą sciągnąłem z jakiejś strony
o bare-programming, i poprawiłem aders startowy ładowania flasha):

openocd -f ${OPENOCD_CFG} -c init -c "reset halt" -c "flash write_image
erase ${BIN_IMAGE} 0x08000000" -c "verify_image ${BIN_IMAGE}" -c reset -c
shutdown



i w zasadzie to wszystko co mam na ten temat do powiedzenia.

jp

do góry