ATNEL tech-forum

Re: Przejście AVR -> ARM

2018-05-25T13:08:57+01:00

Ja to mam zrobione inaczej. Debug to wiadomo gdy są problemy i grzebiemy w programie bawiąc się breakpointy.
Natomiast do wgrywania mam skrót pod F10
Mały tutorial jak to zrobić:
http://www.projekty.specteam.pl/Artykul ... NK-Utility

Statystyki: Napisane przez Samuraj — 25 maja 2018, o 13:08

Re: Przejście AVR -> ARM

2018-05-18T14:27:02+01:00

zawsze możesz kliknac debug i STOP jak wgra wracasz do perspektywy C a program działa ....
w niczym to nie przeszkadza mozna tez sobie ustawić żeby nie przełaczał perspektywy

Z armem zawsze tak to działało i jest wygodne , ciekawe co bys powiedział pracująć na keilu , gdzie jeszcze czesto zmieniam opcje uruchamiania procka z RAM
przez co program po zatrzymaniu resecie itd ulatuje z procka

Statystyki: Napisane przez SunRiver — 18 maja 2018, o 14:27

Re: Przejście AVR -> ARM

2018-05-18T10:16:27+01:00

SunRiver napisał(a):

Zealota napisał(a):

Czy potrafisz z tego środowiska wgrać bezpośrednio wsad do procka?

jak się nie da ... klikasz debug i leci , program masz wgrany do procka , niewiem w czym masz problem działa zaraz po wyjeciu z pudełka
wiec ja nie widze problemu ....

tak wiec szukanie protezy jaest nie na miejscu panie kolego -- debug zawsze wgrywa do procka czy to st-linkiem czy j-linkiem
nigdy nie było problemu

Chodzi tu o pewną filozofię i przyzwyczajenia, której często trudno się wyzbyć, szczególnie gdy pomagają w pracy.
Debug to zwykle zmiana perspektywy, gdy wrzucę debug, to zaraz mam domyślnego breakpointa, nie zawsze chcę bym on był.
Zarazem "znikają" odniesienia do systemu plików w projekcie - oczywiście perspektywę można zawsze zmodyfikować, ale taka też się przydaje, wprowadzanie dodatkowych to już niepotrzebne komplikowanie.
Czasami liczę na to by od razu mieć efekt jak ma działać program - sprzęt podłączony do mikrokontrolera, a nie przechodzić przez dodatkowe "wstrzymywacze" - jak domyślny breakpoint. Wiem, że go można wyłączyć, ale w trybie debug jest znowu przydatny
Przejście przez debug to zawsze dłuższy proces niż "zwykłe" wgranie wsadu.
Ta proteza, jak to napisałeś, okazała się dla mnie wyjątkowo użyteczna, szczególnie w połączeniu ze skrótem klawiaturowym.

Te wszystkie udogodnienia i przyzwyczajenia powodują, że jestem zawsze kilka kliknięć do przodu - dla mnie jest to istotne.

Podsumowując mam wiele powodów, by rozdzielić oba procesy wgrywania wsadu, a to że taki sposób pracy pojawia się w wielu środowiskach, też nie wzięło się z niczego.

Statystyki: Napisane przez Zealota — 18 maja 2018, o 10:16

Re: Przejście AVR -> ARM

2018-05-18T09:02:02+01:00

Zealota napisał(a):

Czy potrafisz z tego środowiska wgrać bezpośrednio wsad do procka?

Statystyki: Napisane przez SunRiver — 18 maja 2018, o 09:02

Re: Przejście AVR -> ARM

2018-05-17T20:05:55+01:00

Atomowy napisał(a):

"automat" do konwersji wbudowany jako plugin w takiego np eclipsa

Atollic true studio to tak naprawdę eclipse przystosowany automatycznie do STMów. Nwm jak w przypadku twoich płytek, ale do Nucleo (poprzez USB) i innych projektów (za pomocą np. SWD) bez problemu się wgrywa jednym kliknięciem (wciskając Debug)

Pozdrawiam

Statystyki: Napisane przez Makowka — 17 maja 2018, o 20:05

Re: Przejście AVR -> ARM

2018-05-13T22:36:58+01:00

To może jeszcze jedno małe pytanko posiadam chyba z 5 płytek z stm32f103 i na nich jest wyprowadzone usb. Kiedyś wgrywałem w nie wsady poprzez DFUse. Mogę je zaprogramować ze środowiska [jakiegokolwiek] - bezpośrednio [znaczy się z użyciem oczywiście botloadera] ale ta konwersja programu defuse może zostać zrealizowana w pełni przez jakiegolwiek środowisko ? Czy tradycyjny sposób program - > kompilacja -> konwersja do .dfu -> wgranie wsadu. Bo jak się nie da to strzasznie to kłopotliwe i nieporęczne Idąc dalej może popełni ktoś jakiś "automat" do konwersji wbudowany jako plugin w takiego np eclipsa

Statystyki: Napisane przez Atomowy — 13 maja 2018, o 22:36

Re: Przejście AVR -> ARM

2018-05-13T19:19:41+01:00

Makowka napisał(a):

Witam,

Do programowania polecam darmowe środowisko Atollic True Studio

Czy potrafisz z tego środowiska wgrać bezpośrednio wsad do procka?
Moje doświadczenia pokazują, że po "wyjęciu z pudełka" nie ma takiej możliwości.
Da się debugować, ale nie wgrywać, w przeciwieństwie do System Worbench, gdzie tam jest to zaraz po instalacji.
Prawdopodobnie nie umiem tego True Studio zmusić do tak prozaicznej czynności

EDIT.
Sam sobie odpowiem
Nie da się. Jest za to rozwiązanie tego problemu:
http://www.projekty.specteam.pl/Artykul ... NK-Utility

Statystyki: Napisane przez Zealota — 13 maja 2018, o 19:19

Re: Przejście AVR -> ARM

2018-05-13T17:44:00+01:00

Nic tylko pisać Więc zabieram się za robotę. Dzieki jeszcze raz

Statystyki: Napisane przez Atomowy — 13 maja 2018, o 17:44

Re: Przejście AVR -> ARM

2018-05-12T21:02:34+01:00

nawiązując do SAM ... , jeszcze są LPC z NXP , Kinetisy .... i wszystko to obsłuzy J-link
co do środowisk ...
głównie używam Keila , ale dużo tez w TrueStudio , że nie wspomnę o świetnym pluginie VisualGDB (nie jest aż tak drogi jak się wydaje)
i mozna pisać w VisualStudio ...

Statystyki: Napisane przez SunRiver — 12 maja 2018, o 21:02

Re: Przejście AVR -> ARM

2018-05-12T19:14:15+01:00

Okej dzięki bardzo koledzy

A więc się prawdopodobnie zostane przy STM - faktycznie wsparcie jest duże .

Dzieki za odpowiedzi Pozdrawiam

Statystyki: Napisane przez Atomowy — 12 maja 2018, o 19:14

Re: Przejście AVR -> ARM

2018-05-12T18:43:21+01:00

Idz w STM32. Duzo przykładów, darmowe srodowisko, duże wsparcie itd. Od razu na plytkach masz st-linka i sobie debugujesz. Znajdz sobie poradnik szczywronka jeszcze na elektrodzie. STMy nie bez przyczyny są chyba najbardziej popularnymi Cortexami M. Z resztą nie wazne jaką architekture wybierzesz, wazniejsza jest znajomosc C czy tam C++.

Statystyki: Napisane przez Nefarious19 — 12 maja 2018, o 18:43

Re: Przejście AVR -> ARM

2018-05-12T11:31:06+01:00

Witam,

Co prawda mam stosunkowo małe doświadczenie z 32-bitowcami, ale z ponad pół roku temu zacząłem swoją przygodę z STM32 od cortexu M3 na płytce startowej "Nucleo".
Do programowania polecam darmowe środowisko Atollic True Studio (zostało z resztą niedawno kupione przez STMicroelectronics, więc wszystko się bardzo przyjemnie konfiguruje ) + CubeMX - warto się zainteresować, poczytać

Tak jak kolega wyżej napisał, bardzo polecam kurs na forobocie - świetnie wprowadza w temat, pozwala poznać uniwersalne biblioteki HALowskie.

Niestety problem z PSoC-ami jest taki, że w Polsce bardzo trudno je dostać. Nie ma się też co oszukiwać - ich cena jest bardzo wysoka w porównaniu do STMów i w większości przypadków, moim zdaniem, ich wykorzystywanie jest po prostu nieopłacalne. Uważam, że są bardzo fajne do potestowana, wypróbowania (co mam już za sobą wg. poradników Mirka ), lecz ciężko mi wyobrazić sobie projekt, w którym w pełni wykorzystałbym ich potencjał.

Pozdrawiam,
Michał

Statystyki: Napisane przez Makowka — 12 maja 2018, o 11:31

Re: Przejście AVR -> ARM

2018-05-12T10:45:57+01:00

A co sądzicie o PscC/SAM ?

Statystyki: Napisane przez Atomowy — 12 maja 2018, o 10:45

Re: Przejście AVR -> ARM

2018-05-12T10:20:21+01:00

Kurs na Forbocie bardzo dobry. Sam korzystam

Oraz na Sunduino:

https://www.sunduino.pl/?s=STM32&submit=Szukaj

Statystyki: Napisane przez Jaglarz — 12 maja 2018, o 10:20

Re: Przejście AVR -> ARM

2018-05-12T10:08:13+01:00

Hej też kilka razy zaczynałem z STMem
Proponuje przejrzeć ten kurs:
https://forbot.pl/blog/kurs-stm32-f1-mi ... ci-id23580
oraz
https://forbot.pl/blog/kurs-stm32-f4-1- ... su-id14114
jeśli chcesz poznać CUBE (czyli taki graficzny konfigurator)

Statystyki: Napisane przez xamrex — 12 maja 2018, o 10:08

Przejście AVR -> ARM

2018-05-11T22:11:07+01:00

Witam

Wydaję mi się szanowni koledzy, że nadszedł już czas, żeby pokusić się o coś większego niż AVR. I stąd moje pytanie i odwieczny dylemat. Przeglądałem troszkę postów na ten temat, ale myślę, żę dodanie posta swojego bedzię lepsze

Pytanie jest proste:

PsoC5 vs STM32 vs SAM - co wybrać ? a może jeszcze coś innego

Osobiście nie skłaniam się ku STM32 - dlaczego ? - bo miałem już troszke z nimi styczność - dokładniej CoCox + defuse i powiem szczerze, żę jak wgrywanie kodu ma tak wyglądać to troche lipa, ale pewnie są jakieś fajniejsze środowiska, gdzie możęmy osiągnąc wygodę jaką prezentuje mirekk36 ?
Oczywiście z plusów to bardzo duża społeczność + wiele programów w sieci.
Nie mniej jednak jakoś mnie te stm-y nie przekonują ....

PsoC5 - z racji możliwości wyglądają naprawde nieźle - od razu milijon pomysłów na wykorzystanie Tylko społeczność mała, no i raczej znając siebie nie potrafiłbym zbytnio wykorzystać tych bloczków, natomist wałkowałbym na okrągło sprawy programowe .... po czasie pewnie by mi przeszło

SAM - hmm troche się skłaniam ku tej opcji - wydaje się wygodna i nie ma żadnych bloczków tylko taka typowa alternatywa dla stm, ponadto hmm fajnie by było zacząć znowu z Atmelem jakoś polubiłem tą firme i jej noty katalogowe, zaraz hejterzy mnie wyzwą, że to już Microchip

No i tak na koniec stosunkowo ważna sprawa:

STM - programatory spoko i łatwo dostępne - a środowiska w sumie nwm - macie coś dobrego >?

Psoc no to psoc creator, z programatorami nie tak źle - kupie sobie "lizaczka" i bede miał

SAM - troche lipa SAM-ICE, który kosztuje majątek, ale są fajne płytki z EDBG i kompatybilen z Atmel Studio

Fajnie jak mnie do czegoś przekonacie:)

Z góry dzieki i pozdrawiam wszystkich maniaków uC

Statystyki: Napisane przez Atomowy — 11 maja 2018, o 22:11