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
SQ2KLX Offline
Początkujący
**

Liczba postów: 50
Dołączył: 02-01-2013
Post: #11
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Witam serdecznie Smile
Dobry pomysł aby zacząć wspólne sofcenie na procesory z rdzeniem ARM.
Mam kilka uwag i sugesti
Na przykład zamiast STM32xx wybrać procesor ze stajni NXP LPC.
Środowisko LPCexpresso lub Eclipse i LPCopen - generalnie najlepiej aby używać Eclipse z wtyczkami dla ARM- wiele środowisk profesjonalnych np CodeWarrior lub LPC expresso bazują na Eclipse.
Eclipse działą na OSx ,Win,Linux
STM32 mają ciekawe peryferia ,a LPC mają mniej błędów i nie maja bałaganu w dokumentacji Smile

Bazowanie na bibliotekach od ST kończy się zwykle porażką w bardziej zaawansowanych zastosowaniach.

Generalnie wsparcie ze strony NXP i społeczności jest moim zdaniem nieporównywalnie lepsze.

A poza-tym można programować poprzez UART uC i prosty interface na FT232RL lub RS232 i MAX232 ( można kupić nawet gotowe programatory dla LPC lub zrobić samemu) , oraz program FlashMagic.
Można również używać LPC link2

Nowe uC od LPC Cortex M4 sa dwurdzeniowe - Cortex M4 plus Cortex M0+

O AT90SAM lepiej zapomnieć Smile tak samo jak o ARMach od Texas Instruments Smile

Jeżeli zdecydujemy się już na jakąś platformę może jakieś grupowe zakupy Smile
28-06-2016 23:26
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP5FCS Offline
Adam
*****

Liczba postów: 1,071
Dołączył: 02-02-2009
Post: #12
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Za rodziną STM32 przemawiają bardzo silne argumenty:
1/ Tanie zestawy NUCLEO i Discovery z STlinkiem na pokładzie.
2/ Możliwość zamiany softu oryginalnego STlinka na J-linka
3/ Kilka rozbudowanych projektów z dostępem do źródeł (STM32-SDR, M0NKA, Pion, STM32F429-I2PHD).

STM-y jak każda rodzina mają zalety i trochę wad ale na etapie nauki działające programy są nieocenionym źródłem wiedzy. W STM-ach mam bardzo małe doświadczenia a po zapoznaniu się z SPL-em i HAL-em "znacznie posiwiałem" i ... zacząłem uczyć się asemblera cotexów. Nie namawiam nikogo do pisania własnych funkcji matematycznych czy DSP ale stosowanie tych gotowych bibliotek do obsługi prostych zasobów procesora to totalne nieporozumienia.

73 Adam
29-06-2016 0:17
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ6DGT Offline
Robert
*

Liczba postów: 41
Dołączył: 22-05-2011
Post: #13
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Wykorzystywanie bibliotek, jakichkolwiek, zazwyczaj prowadzi do nieoptymalnego kodu. Taka jest cena wygody jaką daje warstwa abstrakcji oferowana przez bibliotekę. Tak samo z wykorzystywaniem jakiegokolwiek języka poziomu wyższego od asemblera. Moim zdaniem po to mamy więcej mocy w procesorze i więcej pamięci, żeby móc pisać w bardziej komfortowym języku czy z wykorzystaniem bibliotek. W ten sposób możemy tworzyć bardziej skomplikowane programy i jednocześnie bardziej niezawodny kod. Procesory i pamięć są nieporównywalnie tańsze niż nasz czas, którego przecież nie możemy kupić. Zdecydowanie odradzam zejście do asemblera :-) chyba, że celem jest właśnie programowanie w asemblerze lub nostalgiczne zacięcie :-)

Robert HF6ROB
29-06-2016 9:09
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP5FCS Offline
Adam
*****

Liczba postów: 1,071
Dołączył: 02-02-2009
Post: #14
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
(29-06-2016 9:09)SQ6DGT napisał(a):  Zdecydowanie odradzam zejście do asemblera :-) chyba, że celem jest właśnie programowanie w asemblerze lub nostalgiczne zacięcie :-)

Ogólna znajomość assemblera wykorzystywanego procesora jest bardzo przydatna z zupełnie innego powodu niż nostalgia czy chęć pokazania że się da w tym pisać.
Przed powstaniem softu musimy wybrać środowisko, kompilator, zestaw bibliotek. Jak ocenić efektywność pracy kompilatora czy użytej funkcji bibliotecznej kiedy nie mamy pojęcia jakie instrukcje wykona procesor ? Proponuję pooglądać pliki *.asm lub *.elf. Narzuty w rozbudowanych funkcjach typu DSP są pomijalne. Niestety proste funkcje biblioteczne mają kilka razy więcej kodu niż trzeba. Część wynika ze standardu języka C a część z filozofii danej biblioteki np. HAL-a. Tam gdzie nie zależy nam zbytnio na czasie może tak zostać. W miejscach gdzie wymagania czasowe są większe trzeba zadbać o bardziej optymalny kod, okroić funkcję biblioteczną, napisać własną lub wstawić "łatę a asm".
Możemy pisać oprogramowanie w oderwaniu od sprzętu tylko trzeba mieć świadomość jakim kosztem obciążenia procesora.

Konkluzja: dbałość o jakoś kodu ma zapobiec sytuacji kiedy mamy: język C + lib-y, 32 bity, 168Mhz a efekt jak dla procesora 8-bitowego.

73 Adam
29-06-2016 10:33
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP9FKP Offline
Piotr
*****

Liczba postów: 1,248
Dołączył: 28-06-2009
Post: #15
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
(29-06-2016 9:09)SQ6DGT napisał(a):  Wykorzystywanie bibliotek, jakichkolwiek, zazwyczaj prowadzi do nieoptymalnego kodu. Taka jest cena wygody jaką daje warstwa abstrakcji oferowana przez bibliotekę.

Zgadzam się z tym poglądem, zwłaszcza na początku, gdy nie wiadomo "co z czym się je". Ponadto można dołączać bibliotekę wstępnie prekompilowaną, by wykluczyć błędy kompilacji różnymi wersjami kompilatorów. Zresztą to kwestia umowy i dlatego powinniśmy się umówić co do szczegółów, w tym rozmieszczania kodu na dysku by przenośność była maksymalna.
Dodam jeszcze jeden argument za modułami od ST. Po wymianie programu debugera na Jlink (co jest operacją odwracalną i nie grozi żadnymi konsekwencjami) utrzymujemy dodatkową funkcjonalność jaką jest VCP czyli wirtualny port szeregowy. Dzięki temu mamy bezpośredni kontakt z procesorem i z programem tym samym łączem USB zanim uruchomimy jakiekolwiek zasoby.
İmage İmage
(Ten post był ostatnio modyfikowany: 29-06-2016 11:06 przez SP9FKP.)
29-06-2016 10:58
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ6DGT Offline
Robert
*

Liczba postów: 41
Dołączył: 22-05-2011
Post: #16
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Generalnie się zgadzam, faktycznie tak jest, że można napisać kod bardziej zwarty i szybki przy wykorzystaniu asemblera i bez bibliotek. Problem zaczyna się wtedy, kiedy kod staje się duży, skomplikowany, trzeba go utrzymywać i/lub dzielić się pracą nad nim z większą grupą. Wtedy zysk z niskopoziomowego pisania zostaje skonfrontowany ze stratą spowodowaną nieczytelnością kodu, brakiem określonej architektury (co jest częste przy niskopoziomowym pisaniu) i ogólną podatnością na błędy przy nawet małych modyfikacjach. Dawno temu jak pisałem pod C64 na Motorolę 6502 pisałem w czystym asemblerze, wykorzystanie choćby C wydawało mi się koszmarnym marnotrawstwem. Napisanie np. sortowania dynamicznie tworzonej mapy czy innych struktur danych, które są potrzebne przy bardziej skomplikowanych zagadnieniach, to było nie lada wyzwanie. Niemal szczyt możliwości. W językach wyższego poziomu, z bibliotekami, to rutyna.

To jest oczywiście moje zdanie, ale asembler jest ważny tylko tam gdzie jest absolutnie kluczowy i inaczej się nie da. Tak jest pewnie w algorytmach DSP na gołe STM32, choć i tu nie dam głowy czy nie są pisane w C. W 99% przypadków zwykłe C jest już wystarczająco niskopoziomowe.

Projekt powoli mi się rozrasta i zastanawiam się nad przepisaniem fragmentów np. mojej biblioteczki do komunikacji przez UART na C++. Po co ? Np. bardziej podobałoby mi się stworzenie np. obiektu do komunikacji w ten sposób:

Usart rs1 = new Usart(USART1, 115200, 8, 1, 200);

gdzie argumenty to nr. USART, prędkość, bity danych, bity stopu, timeout w ms. I potem:

if(rs1.error()) { .... } czy
if(rs1.success()) { ....}
if(rs1.hasData()) {
rs1.read(&buf, 200); gdzie 200 - maks długość, a dla sprawdzenia statusu operacji:
}

i dalej w tym stylu.

Mam to teraz w C gdzie każdorazowo zmieniam sobie definicje w nagłówku dla konkretnych danych. Tutaj byłoby ładnie zamknięte w obiekcie (albo strukturze), mógłbym stworzyć kilka takich obiektów dla wielu portów na raz, itd. Trzeba by napisać kod w konstruktorze, któryby poustawiał wszystko w MCU, podłączył zegar tam gdzie trzeba itd. Może nawet remap by się przydał, byłoby trochę kodu, czasem może nie potrzebnego. Ale jaka wygoda i mała podatność na błędy! W tym stylu widziałbym np. biblioteki do obsługi np. DDS-ów, SPI, I2C itd. Składałoby się z klocków a kod dbałby o to, żeby zegary były podane do odpowiednich modułów MCU itd. Wiem, że SPL/HAL idą w tym kierunku ale IMO są dalej pisane nieco kryptologicznie. Moje podejście jest takie, że biblioteka powinna być jak towar dla programisty: ładna, zgrabna i funkcjonalna, żeby kod był mały i prosty i chciało się programować :-)

Robert HF6ROB
(Ten post był ostatnio modyfikowany: 29-06-2016 11:01 przez SQ6DGT.)
29-06-2016 11:00
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SP9FKP Offline
Piotr
*****

Liczba postów: 1,248
Dołączył: 28-06-2009
Post: #17
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
(29-06-2016 11:00)SQ6DGT napisał(a):  Mam to teraz w C gdzie każdorazowo zmieniam sobie definicje w nagłówku dla konkretnych danych. Tutaj byłoby ładnie zamknięte w obiekcie (albo strukturze), mógłbym stworzyć kilka takich obiektów dla wielu portów na raz, itd. Trzeba by napisać kod w konstruktorze, któryby poustawiał wszystko w MCU, podłączył zegar tam gdzie trzeba itd.

Tak się składa, że taki projekt już jest i nazywa się MBED. Niech za komentarz posłuży ten post. Nie sądzę, by na początek to był dobry wybór.
29-06-2016 11:25
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ6DGT Offline
Robert
*

Liczba postów: 41
Dołączył: 22-05-2011
Post: #18
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
No widzę z tego postu, że optymalny to ten MBED nie jest :-) Ale oni chyba idą inną drogą niż ja myślę. Jak przerobię USART w tym stylu jak napisałem powyżej to wrzucę gdzieś do przeglądu. Planuję nie używać SPL czy HAL wewnątrz a tylko udostępnić ładny i spójny interface na zewnątrz, zobaczymy jak się uda.

Z innej beczki... zaciekawił mnie post o ARM-ach z NXP, nigdy ich nie używałem. Czy kod jest faktycznie w pełni przenaszalny i to co mi działa na STM32 pójdzie na odpowiednim Cortex-M3 z NXP ?

Robert HF6ROB
29-06-2016 11:51
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ8MVY Offline
Paweł
****

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

W tym momencie można by powiedzieć, że w tej krótkiej dyskusji został przez kolegów wybrany programator. A jest nim...... J-Link. Jak widać, mając już w swoich zasobach jakiś zestaw startowy z programatorem na pokładzie - Nucleo, Discovery, czy wspomniany LPC link2, to praktycznie bez dodatkowych kosztów mamy dostęp do J-Linka.
Co prawda taki przebrandowany J-Link ma niewielkie ograniczenia. J-Link z ST-Linka obsługuje tylko STM-y, natomiast J-Link z LPC link2 obsługuje tylko procki od NXP.

Dodatkowo pod J-Linka mamy dostęp do osobnego debuggera. Jest on przedstawiony na stronie Seggera , natomiast do pobrania jest w dziale download. Licencja mówi jasno, że do celów edukacyjnych / hobbystycznych jest w pełni darmowy.

Procki - również z tych kilku postów powoli widać, że przewagę mają STM-y

Platforma sprzętowa - Osobiście do dyspozycji mam to co na dołączonych zdjęciach. Ciekawą i całkiem niedrogą opcją jest zaprezentowana przez kolegę SP9FKP płytka Discovery F429. Nie należy również zapomnieć o......sterowniku do Tulipana, który można po swojemu oprogramować.

(29-06-2016 11:51)SQ6DGT napisał(a):  ... zaciekawił mnie post o ARM-ach z NXP, nigdy ich nie używałem. Czy kod jest faktycznie w pełni przenaszalny i to co mi działa na STM32 pójdzie na odpowiednim Cortex-M3 z NXP ?

Ale jaki kod ? Skompilowany wsad, czy przenośność jeszcze na etapie kodu źródłowego?

Z tym tak prosto nie jest, bo o ile rdzeń ARM M3, M4, M7 jest dokładnie taki sam w STM czy NXP, to już cała otoczka - czyli peryferia są całkiem inne - inaczej się je konfiguruje, rejestry konfiguracyjne leżą pod innymi adresami....

Przenośność kodu na poziomie źródłowym - te biblioteki HAL, SPL (one są od ST) miały to zapewnić, ale tylko w obrębie danego producenta. Nie mam pojęcia jak to jest rozwiązane u NXP - czy też mają takie grubaśne biblioteki - HAL-e, SPL-e.


İmage İmage

73 Paweł
(Ten post był ostatnio modyfikowany: 29-06-2016 12:16 przez SQ8MVY.)
29-06-2016 12:16
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
SQ2KLX Offline
Początkujący
**

Liczba postów: 50
Dołączył: 02-01-2013
Post: #20
RE: Programowanie ARM, nauka, środowiska programistyczne IDE
Witam,
ARM 32bit od NXP z seri LPC maja swoje korzenie w procesorach 8051, następnie z drobnymi zmianami można przenosić kod pomiędzy starymi ARM7TDMI a cortexami LPC17xx M3.
. Dodatkowo jeżeli napiszemy coś na LPC M0 a zabraknie poweru albo pamięci programu, można soft na piniowy odpowiednik z rdzeniem M3 - nie trzeba przerabiać PCB.
Dla mnie dużym plusem jest fabryczny bootloader po UART/CAN . Generalnie LPC mają mniej baboli , a jak się już jakiś znajdzie to w miarę szybko pojawiają się rozwiązania.
Jestem raczej skłonny zacząć od procesora LPC1114FBD48/302 aby (koledzy którzy jeszcze nie siedzą w ARMA-ch a na AVR mogli bezboleśnie wejść ARM-y) - jest tani widziałem na pazzegro za około 5PLN plus porto.
Zacząć od Cortexa M0 jest prościej ze względu na mniejsza liczbę peryferii co za tym idzie mniejszą liczbę rejestrów do ogarnięcia Smile
Cortexy M3 z serii LPC17xx są pinowo zgodne z Cortexami M4 LPc40xx.



LPCexpresso w wersji Free debug kodu do 256kB , ale kompiluje powyżej 256kB i soft wrzucamy Flas Magickiem. niestety tylko procki NXP ale instalacja next,next,next i działa Big Grin ewentualnie Eclipse i wtyczki od NXP.

Można by nabyć j link Segger w wersji edu ale to koszt 200 zł

Ten STM32F4 bardzo ciekawie wygląda 2MB flash 256kb RAM -do zastosowań radiowych całkiem
Ja bym zalecał coś prostszego - jak mamy lecieć od zera,jak już się opanuje podstawowe peryferia arm-ów to można potem bezboleśnie przesiąść się na na większy procek z bogatszymi peryferiami Smile

Na LPC może być mniej przykładów ale biblioteki są trochę bardziej ogarniete, ewentualnie gdzieś na elce jest kurs w formie pdf programowanie STM32 na rejestrach
29-06-2016 13:39
Znajdź wszystkie posty użytkownika Odpowiedz cytując ten post
Odpowiedz 


Skocz do:


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