Tani programator do ARM Cortex M0 pod Linux - jakie macie doświadczenia?

W dniu 2017-07-06 o 07:17, jacek pozniak pisze:
w systemie siła 'POPIS/EU wrote:

ja jestem głupi, nie polemizuje
ale co ty mu kurwa radzisz?
http://allegro.pl/126-st-link-stlink-v2-programator-do-stm32-stm8-fv-
i6798306430.html
No właśnie chyba coś takiego kupię (na Allegro) tylko muszę poszukać
sprzedawcy co ma taki ST-link i płytkę taką jak zapodał Sebastian. aby
jedną przesyłką ogarnąć.

jp

W sklepie Kamami dostaniesz i różne zestawy i st-link nieco drożej niż
na Allegro. Jak masz łatwy dojazd do Legionowa to i na przesyłce
zaoszczędzisz.
Niestety 200km
Oczywiście nie ma porównania z cenami Ali, ale czasem czekać 2 miesiące
na przesyłkę się nie opłaca. Chociaż czasem to ma dobroczynny wpływ na
człowieka, bo głupi pomysł zdąży mu z głowy wyparować.
A poza tym będą wakacje i przesyłka może dojść w czasie gdy nie będzie jej

Czyli, że ten ST-Link lub j-link to w zasadzie równorzędne urządzenia, tylko
j-link do większej ilości procesorów pasuje, dobrze rozumuję?

Potem ewentualnie j-link

On 7/6/2017 6:53 AM, jacek pozniak wrote:
Czyli, że ten ST-Link lub j-link to w zasadzie równorzędne urządzenia,
tylko j-link do większej ilości procesorów pasuje, dobrze rozumuję?

Bardziej jest tak:

a) J-Linka produkuje duza firma która stara się dawać dobrej jakości
oprogramowanie (prywatnie uwazam że dziadowskie, ale ja jestem dziwny).
Jest notorycznie kopiowana przez chińczyków i walczy z tym w taki sposob
że soft wykrywa podrobki i uniemożliwia ich użycie. Kupując taniego
J-Linka kupujesz podróbkę.

b) ciężko mi znaleźć zastosowanie J-Linka które nie dalo by się zastapić
*czymkolwiek* co jest interface do JTaga. Może nieco szybsze, ale nic
poza tym funkcjonalnie.

c) W przypadku STM32 zastosowanie J-Linka było kłopotliwe bo nie
obsługiwało protokołu SWD. Możliwe że już zmienili i obsluguje. Bez SWD
nie zaprogramujesz wielu płytek.

d) ludzie używają JLinka bo ciagle im się wydaje ze łatwiej jest
wyklikać niż napisać skrypt. Trudno, deewolucja.

e) ST-Link zrobi wszystko to co J-Link nie tylko dlatego że OpenOCD nie
widzi między nimi róznicy, ale rownież dlatego że producent JLinka
wypuscił upgrade softu do STLinka który emuluje JLinka dla stm32 ...

http://mikrokontroler.pl/2016/05/06/stlinkreflash-interfejs-j-link-w-
zestawach-stm32-nucleo-i-discovery/

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

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:

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ść.

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.

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

jacek pozniak <jacek.pozniak@flowservice.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

"Hello World" na LEDach zadziałał.

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ć.

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