Witam serdecznie
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

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ć tak samo jak o ARMach od Texas Instruments

Jeżeli zdecydujemy się już na jakąś platformę może jakieś grupowe zakupy

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.

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 :-)

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

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

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ć :-)

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

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 ?

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.

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

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