Hej.
Mam pod ręką płytkę STM32F4 Discovery i chciałbym coś pokombinować i czegoś się nauczyć. Jednak nie wiem od czego zacząć. Chciałbym, żeby ktoś mnie poprowadził za rękę po tym ARM-ie jak szanowny Mirek po AVR. Pożyczyłem 2 książki do STM-a (niebieska i zielona) ale one są pod inne płytki niestety i kody nie działają pod F4. Może ktoś dysponuje jakimś poradnikiem albo pozycją papierową?
Chodzi głównie o wybór programu (CooCox, Atolic, Keil, Eclipse) i podstawowe projekty. Do szczegółów jakoś dojdę, ale muszę mieć jakieś podstawy. Z góry dzięki za wszelakie materiały.
Pozdrawiam.

Może wspomóż się tym http://sunduino.elektroda.eu/wordpress/ ?
Autor bywa na forum więc z pewnością odpowie na pytania.
Na tej stronie też trochę się znajdzie http://mikrokontroler.pl/node/7010

Witam mozesz jeszcze zobaczyc tu
http://mikrocontroller.bplaced.net/wordpress/

Tylko nie używaj idiotycznego STLa, a te książki jego używają + znakomita większość "pseudostron" o tematyce STM32. Nie wiem jakie jest Twoje doświadczenie z mikrokontrolerami, jeżeli małe to będziesz miał bardzo ciężko - nie chcę Cię zniechęcić, ale zachować Twój czas.

Najważniejszymi dokumentami do studiowania są:
- datasheet mikrokontrolera
- erraty
- programing manual
- datasheet ARM, rdzenia.

Nikt tutaj nie poprowadzi Cię za rękę, bo ARM są zdecydowanie trudniejszą architekturą i wymagają one od uczącego się, tylko i wyłącznie własnych sił do poznawania. I nie licz na kogoś, bo tutaj chodzi, abyś Ty potrafił wyciągać odpowiednie wnioski - pytaj dopiero po paru dniach walki - uwierz szukanie gotowych rozwiązań nie sprawi Cię programistą ARM. I powtarzam, unikaj STLa, dokumentacja w rękę i studiujemy dane peryferium i piszemy na nie kod, dokumentacja od ST jest o tyle fajna, że bardzo przyjaźnie napisana, praktycznie w każdym peryferium masz krótki opis co trzeba zrobić, żeby je uruchomić. Jak chcesz "pisać na ARM" bez pojęcia tak naprawdę co się dzieje w procesorze i dlaczego to tak w ogóle działa to wybieraj bibliotekę od ST, często wychwalaną przez pseudoprogramistów, a jeżeli chcesz wejść w ARM poważnie to już wskazałem Ci drogę.

Owocnych przemyśleń.


MXST4

Bo tutaj chodzi by właśnie podprowadzić za rączkę w taki sposób by zainteresowany szybciej mógł zacząć coś robić samodzielnie, a w ten sposób jak pisze kolega to właśnie marnuje i czas i zniechęca .
Skoro kolega ma takie dobre podejście do ARM i tak wyklina STD - jak większość pseudo ARMOWCÓW to może kolega
skrobnie jakiś poradnik ??

bynajmniej bez urazy kolego ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Bzdura powtarzana przez wielu pseudprogramistów - można by tak rzec. Ale prawda jest taka, że jeżeli jest ci wygodnie to korzystaj z bibliotek STM-a. To ty decydujesz, co jest dla ciebie odpowiednie i przydatne - ktoś to wymyślił, ktoś używa i jeżeli działa to dobrze. Faktem jest jednak, że STLa bardzo często używa się w trybie "idiot", czyli wstawiłem-nie działa-nie wiem czemu-płacz. A niestety datasheet to podstawa. Sam często używam STL i zdaję sobie sprawę z ograniczeń z tym związanych. Wszystko jednak zależy od wymagań aplikacji. Zresztą podobnie jest z wieloma bibliotekami jak np. super debounce, czy obsługi LCD stworzonymi np. przez Mirka - chcesz korzystasz i godzisz się z ich możliwościami/ograniczenia; nie chcesz nie korzystasz. Tyle, że nie mów, że złe. Ja np. mógłbym powiedzieć, że super debounce jest do kitu, ale czy taka jest prawda? Nie używam jej i nie będę bo mam zupełnie inne podejście w swoich programach do obsługi klawiatury i dlatego ta biblioteka jest mi nieprzydatna. Ale nie powiem nigdy, żeby z niej nie korzystać. Wręcz przeciwnie. Podobnie jest z STL. Jedno jednak ostrzeżenie: musisz się liczyć z tym, że te biblioteki są niedoskonałe i mogą zawierać błędy, które akurat w twojej aplikacji się ujawnią.

Co do środowiska to proponuję na początek darmową wersje keil-a. Masz wszystko skonfigurowane, ustawione i właściwie odpalasz i działasz. Oczywiście są ograniczenia kodu, ale na początek wystarczy. Potem, gdy już trochę opanujesz STM-a to łatwiej będzie przejść ci na inne środowisko, które wymaga więcej zachodu z ustawieniami. Słyszałem jednak, że STM pracuje nad własnym IDE, ale czy to prawda i kiedy będzie nie mam pojęcia.

A teraz trochę o tym jak uczyć się programować STM. No cóż jak każdego innego mikrokontrolera Możesz tez robić tak: piszesz program (np. miganie diodami) z wykorzystaniem bibliotek STM-a, a potem to samo bez ich wykorzystania. Potem kolejny problem (np. obsługa klawisza) itd. Jak będziesz miał problemy to z pewnością uzyskasz pomoc pytając. Nie oczekuj jednak, że będzie ci podawane gotowe rozwiązanie, choć i tak może się zdarzyć. Najpierw jednak próbuj sam.

_________________
40-32:2=4!

Dzięki za tak liczny odzew. Nie chodziło mi o podanie na tacy wszystkiego ale na nakierowanie w jakim kierunku iść. Kiedyś w eclipse testowałem gotowe projekty ale niestety na 8.1 nie udało mi się skonfigurować Eclipsa pod ARM-a. No i głównym obecnie problemem jest wybór kompilatora.
Zainstalowałem tego Keila i będę próbować coś na nim działać. A biblioteki STL-a warto mieć pod ręką żeby sprawdzić czy w ogóle działa wgrywanie na płytę.

pokop u mnie na stronie , a z darmowych polecam ci na początek CoIDE

http://sunduino.elektroda.eu/wordpress/ ... covery-f4/

tu masz taki mały przykładzik w CoIde ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Nie można nazwać osobę programistą, która COŚ robi, ale tak naprawdę nie wie w jaki sposób to działa i co się dzieje w MCU.

Śmieszą mnie osoby, które korzystają z STLa, bo muszą przejrzeć dokumentację tej biblioteki, żeby wypełnić jakieś śmieszne strukturki + dokumentacje MCU, czyli po prostu marnują czas. Tak powinni robić, a z własnego dużego doświadczenia wiem, że szukają gotowca w internecie i wklejają do swojego projektu bezmyślnie. Polecam popatrzeć na forach, że większość problemów to programy z użyciem STLa, bo używają go osoby, które nie wiedzą o co chodzi, aby tylko koniecznie pójść na ARMa bo to takie cool.

Skonfigurowanie SPI to 2-3 linijki kodu, a przy użyciu tej biblioteki 10? I weź człowieku patrz jak tą strukturę wypełnić. Nie uczcie go złych nawyków.

Sunriver, napisałem mu poradnik co należy zrobić. Jeżeli jest gotowy na ARM to się odnajdzie, będzie ciężko, ale to zaowocuje w przyszłości, ja w to wierzę. Po za tym jak wyobrażasz sobie poradnik o ARM? Bo jakoś mam za mały umysł, aby to ogarnąć. Przeczytać rozdział o GPIO - pomachać sobie pinami, następnie zabrać się za SPI, I2C - pobawić się tymi transmisjami. Następnie ADC, zacząć używać DMA - po prostu poznawać cały mikrokontroler, samemu się uczyć, z biegiem czasu jak dobrze zapozna się z DSem STMa, będzie wiedział co gdzie szukać i pisanie obsługi jakieś transmisji, zajmie mu tylko czas potrzebny na zajrzenie do spisu rejestrów. Praktyka czyni mistrza.

Chętnie obejrzę projekty PJS w opraciu o ARM, jakieś poważniejsze Jeżeli kogoś podnieca robienie programów bez wiedzy dlaczego działa to jego sprawa. Wszyscy moi znajomi ARMowce (ci poważniejsi) też spróbowali dotknąć STLa, ale z biegiem czasu zobaczyli jak ta biblioteka psuje życie i marnuje czas. Ale widocznie każdy musi się przejechać na własnej skórze - na poważniejszym projekcie, jeżeli takowy będzie realizował.


MXST4

Mnie natomiast śmieszą osoby które dużo mówią a nic na temat konkretnie .....

ale mniejsza ... na moje szczęście prowadzę pseudostronę i nie mam pojęcia o czym piszę
i bardzo dobrze bo nie muszę pisać że to jest złe , tamto złe ,a to jest super i nic więcej

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Pracuję w automotive i tam nikt nie wpadłby na pomysł tak głupi jak tutaj proponujecie. Już raz napisałem, jak ktoś sobie małe projekciki robi, gdzie nie potrzeba mocy ARMa to może korzystać sobie z czego chce. Ale jeżeli zamierza pracować na takim stanowisku to już mogę poinformować, że nikt nie przyjmie bez wiedzy o procesorze. Takie tam przemyślenia osoby, które dużo mówi Całe szczęście nie spotykam w pracy osób podobnie myślących jak koledzy, bo zweryfikował to czas i duży poważny projekt.


MXST4

No dokładnie. W ogóle pojęcia typu "architektura łatwa", "architektura trudna" "zła i dobra" To są raczej pojęcia względne.
Czytałem trochę o STMach i nie wydaje mi się by były jakimś koszmarem. To samo można by powiedzieć o Xmegach bo mają setki rejestrów, event system, dma itd. A w Atmegach mamy kilkanaście trybów pracy Timera1 i chyba mało kto pamięta jakie, do czego co jest TOP co jest UPDATE itd. Ale przecież nota zawsze podpowie.
Ludzie kiedyś pisali na 8051, na Z80, 6502 i jakoś dawali radę w czystym assemblerze.

ja też się cieszę że nie spotykam takich ludzi w pracy ... bo widzisz zacząłem swoją przygodę z ARM podobnie jak i PIC i AVR , m68k, z80 , 6502 od ich assemblera i nie wyobrażam sobie poważnego pisania czegokolwiek bez wstawek ... ale zauważ że to forum jest dla początkujących i amatorów
którymi jesteśmy wszyscy ... i jedyne co staramy się pokazać że nie jest tak trudno jak się wydaje , a doświadczenie przychodzi z czasem zawsze
wiec kolego jak się urodziłeś super mega doświadczony i od razu budowałeś stację mir ... zamiast migać diodami to podziel się z nami swoją wiedzą
a nie piej jacy to jesteśmy thebile w porównaniu z tobą

to przykre kolego ze tak naprawdę nic nie pomogłeś i nic nie pokazałeś tylko wszystkim wszystko wytykasz

- bo napisanie że trzeba studiować dokumentację producenta to żadna podpowiedź - wszyscy to wiedzą
tak jest to oczywista oczywistość że nie wypada wręcz o tym wspominać w każdym poście i temacie.

dobra koniec ot ...

Bo powoli wszyscy zaczynamy szkodzić koledze autorowi zamiast mu pomagać

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Pisanie bez SPL nie jest wcale trudne - w 8-bitowcach pisało się bez żadnych SPL'i i "dało się"
Po prostu trzeba sprawdzić w datasheecie co który bit oznacza i odp. go ustawić - w/g potrzeby.
Taki mały przykład - inicjalizacja SPI1 dla STMF4:

Dla ułatwienia użyłem w niektórych miejscach dostępnego w internecie makra B16(), żeby można było wygodnie ustawić sobie poszczególne bity rejestrów.
W komentarzach mam dodatkowo podane nazwy bitów na odp. im pozycjach - żeby nie trzeba było ciągle zaglądać do manuala.
Ale to już kwestia własnych przyzwyczajeń.

Da się?

Wszystko się da .... wystarczy konkretny przykład prawda
i to możemy nazwać pomocą w odróżnieniu od tego co nam tu pisał kol MXST4
teraz autor ma wybór ... sam zdecyduje na początek wystarczy mu std_l potem wyjdzie poza nie jak bedzie potrzebował

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Ja myślę że kolega MXST4 ma dobre intencje i jeśli ma doświdczenie w temacie to chce dobrze nakierować,
po to aby jak już się uczyć to poprawnie, bo na pewno się to kiedyś zemści.
A przykład kolegi Jado jest właśnie pokazaniem tego że wcale konfiguracja bezpośrednia rejestrów
nie jest trudna.

Nie jest trudna jak wiesz jak to robić.
Nic nie jest trudne jak już wiesz, albo przynajmniej masz podstawy.
Tylko właśnie pokażcie mi jedną chociaż książkę, która by wprowadzała w świat programowania ARMów nie na STLu.

Tutaj jest ciekawa wypowiedź jednej z osób początkowo używającej SPL: "Osobiście także używam do ustawienia mikrokontrolera tylko rejestrów, bo całkowicie nie rozumiałem tej biblioteki, które i w jakiej kolejności funkcje mam wywoływać. Wszystko było fajnie jak się korzystało z książki Paprockiego, ale gdy chciałem przetwornik ADC ustawić według swojej potrzeby to nie ogarniałem jak do tego dojść przy użyciu SPL. "
Tak więc różne bywają przypadki - a wyjście poza książkę czasami może nie być takie łatwe Pisanie "po rejestrach" jest uniwersalne dla wszystkich procków, SPL jest tylko dla STM'ow.

Pytanie : "co nas bardziej kręci"

I tu się zgadzam z kol. Jado ...
Kwestia w sporna z SPL dla STM32 , ale głównie zauważyłem że psioczą na nie osoby które nie umieją z nich korzystać.
Dużo piszę na STM32 uważam je za lepsze od LPC np ...bo miałem możliwość bezpośredniego porównania aplikacji
pracującej na Cortexie-M3 zarówno LPC jak i STM32. Często przy prostych aplikacjach sięgam po SPL ale często tez ryje
w asm .. , który jest dla ARM trochę nie ludzki ... ale jak mus to mus.

Oczywiście wiadomo że te libsy nie są idealne, ale osoba obeznana .. szybko wyłowi co jej potrzeba, a nie będzie piac jakie to do d...

Obecnie się wiele zmienia w podejściu do stm32 , za sprawą mikro.framewora czy CMSIS ...
ale z punktu widzenia początkującego na tą chwilę szybki start z SPL będzie wygodny ...

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Zdaje się, że powyższa dyskusja a propos SPL już staje się powoli nieaktualna.
Teraz trendy jest STM32Cube i HAL

A to cytat z pdf'a od Cube'a:
"The STM32Cube HAL Layer is the replacement of the Standard Peripheral Library.
The HAL APIs offer a higher abstraction level compared to the standard peripheral APIs.
HAL focuses on peripheral common functionalities rather than hardware. The higher
abstraction level allows to define a set of user friendly APIs that can be easily ported from
one product to another.
Customers currently using Standard Peripheral Libraries will be helped through Migration
guides. Existing Standard Peripheral Libraries will be supported, but not recommended for
new designs."

Dotychczasowa literatura o STM chyba pójdzie na przemiał (bo cała opiera się o SPL).
Qrcze - jak to szybko wszystko się zmienia...pamiętam, że książke Parpockiego kupowałem w 2011 roku jako absolutną nowość...

Tutaj jest to dobrze opisane http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf
oraz tutaj https://www.google.com/url?sa=t&source=web&rct=j&ei=OiuwU4WlDujlsASm64Bg&url=http://en.radzio.dxp.pl/stm32vldiscovery/&cd=1&ved=0CBwQFjAA&usg=AFQjCNHlT_366Gtc8lQZU30K3ESo7CiTtw&sig2=9H3BLDBaO9ATzokwcT36EA niestety nie jestem w stanie zweryfikowac tej drugiej strony czy dziala ew mam ja w wersji off line jak bd ww polsce to moge sie podzielic

dosyć rzadko piszę ale coś skrobnę.

-te 2 podane książki niestety nie poruszają ważnych tematów, generalnie przetłumaczenie z ang->pol not producenta, przykłady też nie są wygórowane, ale jak możesz je wypożyczyć za darmo warto przeczytać wiadomo w ojczystym języku łatwiej przyswaja się wiedzę.
-racja arm-y to nie takie hop siup, nie widzę sensu pchania się od razu w f4 są rodziny f0 RM(referece manual ma ok 600 stron napisany jest bardziej przystępnie) w rodzinie f0 jest mniej rejestrów filozofia generalnie taka sama jak w f4 tak że przesiadka nie stawowi praktycznie żadnych problemów
-co do SPL i Cube na początku się z tego śmiałem, ale mam projekt na BLE 4 i procesorze SoC gdzie komunikacja ze stosem wykonywana jest tylko przez uzupełnianie struktur i przekazywanie ich do stosu, generalnie taka sama filozofia jak w SPL , i nie ma innej możliwości bo nie ma dostępu do stosu. Proponuje nie skreślać SPL, można korzystać ale mądrze do SPL jest też dokumentacja co ciekawe nikt o niej nie mówi, generalnie piszę na rejestrach ponieważ projekt jest lżejszy np. w małych f0 ma to znaczenie żeby na starcie nie tracić połowy pamięci, ale dosyć często zaglądam do żródeł SPL jak niektóre rzeczy są zrealizowane.
-jeżeli zaczniesz pisać na rejestrach to pamiętaj o komentarzach pisz sobie stronę w RM i obszernie je opisuj, po pewnym czasie będziesz już wszystko pamiętał ale na początku jest to trochę skomplikowane
-co do środowiska na początek CooCox moim zdaniem bardzo dobre darmowe IDE stosunek cena/jakość nie do przebicia wszystko działa nic nie trzeba konfigurować działa jest rozwijany duża różnica między wersjami idzie ku lepszemu, równolegle polecam Keila ale to już jest narzędzie nieporównywalnie lepsze prędzej czy później każdy się przesiada a jak jeszcze się nie przesiadł do 99% to zrobi, nie będę pisał plusów bo nie ma sensu jedyna wada to cena ale co się dziwić to jest maszynka do robienia kasy.

uff.. koniec jak kogoś obraziłem to trudno, napisałem swoje zdanie.

Ja też nie rozumiem tego podejścia. Gdy zaczynałem uczyć się AVR-ów, też od paru osób zdążyłem usłyszeć, że podstawą jest opanowanie assemblera. Samo programowanie w C miało nie wystarczyć. Co prawda ciągle jeszcze się uczę, ale zdążyłem zrealizować kilka projektów i ani razu nie odczułem potrzeby sięgnięcia po język niskiego poziomu. Mam wręcz wrażenie, że ucząc się go "na siłę" straciłbym tylko czas, bo teraz planuję przyjrzeć się bliżej PIC-om i STM32.
Oczywiście, jeśli kiedyś pojawi się taka konieczność, zapoznam się z asm odpowiedniej rodziny MCU. Podkreślam jednak słowo "jeśli".

Poza tym prawo Moore'a robi swoje. Mamy dostęp do coraz większej mocy obliczeniowej za coraz mniejszą cenę. Dlaczego niby te zasoby nie miałyby zostać wykorzystane do ułatwienia pracy programisty? Równie dobrze można by przecież kazać komuś programować Raspberry Pi bez OS-u i bibliotek, odwołując się bezpośrednio do rejestrów. Jaka by to była oszczędność zasobów...

IMHO, zwiększone zasoby sprzętowe współczesnych mikrokontrolerów powinny zostać wykorzystane na tworzenie nowych jakościowo aplikacji/urządzeń - nowe funkcjonalności o których było nie do pomyślenia przy procesorach poprzednich generacji np. rozpoznawanie/generacja mowy, multitasking, przetwarzanie obrazów, itp....Zamiast maskować błędy programistów.

Mogę się zgodzić z tym, że dzisiaj mniej można się przejmować zajętością pamięci programu, bo nastąpiło jej znaczące powiększenie - wielkości rzędu 512kB nie są niczym nadzwyczajnym, a i tak rzadko kiedy się je czystym kodem (pomijamy tu np. tablice sampli) zapełnia. Więc walka o każdy bajt FLASH'a (czy nawet RAM'u) nie ma już takiego znaczenia jak kiedyś.

Natomiast walka o 'czas procesora' wciąż jest jak najbardziej na miejscu - wciąż mamy do czynienia z urządzeniami czasu rzeczywistego i nie można sobie pozwolić na utratę danych z powodu "nie wyrobienia się procesora" - wskutek mało zoptymalizowanego pisania programów.
Większe moce obliczeniowe procesorów nie mogą być przyzwoleniem dla niechlujstwa programistycznego.
W każdym razie - ja - dla samego siebie - tak uważam.
Może świat idzie teraz w innym kierunku.

BTW: Kto pamięta konkursy demosceny - 1k, kiedy trzeba było zrobić najbardziej zoptymalizowany, z największą ilością efektów graficznych program-demko, którego kod musiał się zmieścić w wymaganym 1kB danych?

Można znaleźć rozsądny kompromis pomiędzy jednym i drugim, zresztą nikt nie mówi o maskowaniu błędów programistów... Jednak jaki będzie pożytek z idealnego programu napisanego w assemblerze, wykorzystującego w 100% zasoby sprzętowe, jeśli tylko kilku programistów będzie w stanie go zrozumieć? Jaki sens ma tworzenie biblioteki, której obsługi trzeba się uczyć prawie tak długo, jak programowania w nowym języku?
Prawda jest taka, że nie nauczymy wszystkim pracy niskopoziomowej. Nie każdy ma ambicję znaleźć się w wąskiej grupie najbardziej wybitnych programistów. Niektórzy po prostu chcą wziąć do ręki Arduino/Raspberry Pi/mikrokontroler na samodzielnie wykonanej płytce i stworzyć coś ciekawego (ja właśnie należę do tej grupy). Jeśli im powiesz, że powinni najpierw poświęcić mnóstwo czasu na wkuwanie nazw rejestrów i oznaczeń bitów, to z całą pewnością zniechęcić większość z nich. Czas na wyższą szkołę jazdy jeszcze przyjdzie.



Nie wszystkie projekty należą do tej grupy.




Nie mówimy o niechlujstwie. Mówimy o wykorzystywaniu narzędzia (biblioteki), które ułatwia pracę kosztem nieco gorszej optymalizacji.

Nie mówię o nie korzystaniu z bibliotek w ogóle - sam od czasu do czasu z nich korzystam - ale o SPL.
Sam producent porzucił je na rzecz nowszych - (jak podejrzewam bardziej zoptymalizowanych i napisanych lepiej) rozwiązań - po co się więc ich kurczowo trzymać?

Pisanie kodu w sposób zoptymalizowany nie koniecznie oznacza pisania ich w ASM - ja sam pisząc programy na procesory 32-bitowe przestałem używać assemblera, bo wystarcza mi C (no może poza jakimiś pojedynczymi instrukcjami).

Sam pamiętam, że zaczynając przygodę z procesorami STM32, mimo woli interesując się tematem, przeczytałem o wadach SPL na jednym z forów poświęconych mikrokontrolerom - i świadomie - zrezygnowałem z jej używania (chociaż zakupione wtedy książki o STM32 straciły sporo ze swej wartości przez to)
Teraz Wy musicie podjąć własne decyzje

Nawet nie wspominaj ... ale gdyby nie specjalne cranchery pisane pod określone demo było by ciężko w demach 1 /4K ech stare dobre czasy ..




niema co się wypinać .... większość narzekania wynika z niewiedzy niechęci zapoznania się z kodem SPL , ale to nie jest dysputa na temat wyższości świąt panowie ... każdy używa jak chce i czego chce ... a wszystkie zamieszanie wynikło po wypowiedzi "specjalisty", który notabene nic nie miał w temacie do powiedzeni i do niego nic nie wniósł dlatego. Niemniej warto poznać procesor i możliwości różne od każdej strony
obecnie wiele się zmieniło, i już nie trzeba się kopać w asm by być cool - dostępność rozwiązań jest ogromna i stale się rozwija , elektronika tanieje , a producenci ścigają się by ugryźć kawałek kończącego się tortu ...... dynamika rozwoju technologi działa na korzyść amatorów / hobbystów , a programowanie nie jest zarezerwowane dla wybranych .... wszystko można zrobić prosto czy to na SPL czy HAL czy tez bez - ale trzeba to robić z głową ....

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Sam ostatnio próbuję zapoznać się z M0+ na początek, dwu producentów Freescale i STM, z racji posiadanych zestawów.
I powoli zaczynam wgryzać się w temat. I nie ma to jak poczytać sobie i zrozumieć Reference Manual, z wszystkimi tymi rejestrami i za co dany bit odpowiada. Co prawda nie napisałem jeszcze ani linijki zaawansowanego kodu bardziej niż miganie ledem . Tylko że czy to STL, cmsis, czy dłubanie od zera ni jak się ma do tego, że przy każdej metodzie - jak to ładnie na czacie kolega określił - wymaga od uczącego się ( Y )godzin, czyli po prostu czytać, czytać, czytać. Nawet na STLu trzeba poznać ich strukturę i w jaki sposób to działa.

Mały refresh. Z bólem dotarłem do końca strony (pełno kłótni) i pragnę zadać dokładnie to samo pytanie co kolega. Od czego zacząć? Ponieważ biblioteka SPL jest wątpliwej jakości jak mówicie, a nie chciałbym takowej używać, to proszę podać o nazwę biblioteki, z której NALEŻAŁOBY skorzystać. W końcu z jakichś bibliotek musicie korzystać, bo nie wyobrażam sobie odwoływania się do jakiegoś rejestru manualnie wpisując jej adres i rzutując ją na odpowiedni typ.

Może nie wiem aż tyle nt. uC i ich programowania, ale sporo programuję innego typu historie i zasada jest taka: najpierw piszemy tak, żeby było czytelnie ładnie i miło a optymalizacja jest na końcu. Oczywiście rozumiem, że aplikacje czasu rzeczywistego zachowują się zupełnie inaczej, ale to nie jest powód, żeby każdy program pisać przez pryzmat największej wydajności.

Nie chodzi tylko o wygodę programisty przy takim podejściu, ale o pieniądze... czas kosztuje, a korzystanie z bibliotek czas skraca. Poza tym... prototypowanie? Chyba o wiele lepiej w takim przypadku naskrobać na brudno coś, żeby się przekonać czy to w ogóle będzie działać mniej więcej zgodnie z oczekiwaniami, a potem przepisać aplikację w lepszy sposób (nie wiem jak w embedded, ale normalnie jest to powszechna praktyka).

Na pewno chciałbym z jakiejś biblioteki korzystać (choćby taka jak avr-libc dla AVR), bo uważam, że wpisywanie 0000 i 1111 na "pałkę" w kodzie jest ekstremalnie nieczytelnie, nawet jeśli w komentarzu jest opisane co i jak jak w kodzie powyżej to zamiast pisania tyyyle kodu komentarzy wolałbym się zdecydować na jakieś enumy i napisanie jakiegoś inline'a do generowania odpowiedniej liczby na podstawie nr bitu(zajmie mniej czasu niż komentarz + mogę ponownie wykorzystać + nie zaciemnia funkcji). Już o mieszaniu kodu C i asm bez konieczności (z powodu widzimisię programisty) nie wspomnę, ale to moje zdanie. Trzeba pamiętać, że kod poza napisaniem, trzeba utrzymać! A stare dobre czasy, o których koledzy mówią minęły i trzeba dostosowywać się do panujących trendów. AGAIN to tylko moja opinia.

Na początek najnowszy CMSIS, nie ma co się buldoczyć, czy końbinować.

Na początku i tak trzeba zapoznać sprzęt, architekturę, możliwości.

Można oczywiście rzeźbić od zera, ewentualnie można wykorzystywać biblioteki z CoIDE, Keil itd. zależnie od używanego środowiska/procesora.

Sam idę dwiema ścieżkami, raz CMSIS, a raz HAL, od zera na początku nie polecam, bo się tylko człowiek zniechęci.
By ogarnąć zasoby ARMa na poziomie bitowym trzeba znać procesor na wylot.