Wcześniej ARMami się nie interesowałem, ale powstał pomysł do którego AVR będzie za słaby więc trzeba się zainteresować.
Chcę zbudować analizator widma do wzmacniacza audio. Wynik byłby wyświetlany na dwóch OLEDach, oddzielnie dla każdego kanału.
Myślę o zastosowaniu algorytmu FFT dla 128 próbek więc potrzebny będzie Cortex-M3/M4.

Pytanie, którym producentem układów się zainteresować?
Ważne aby był dostępny u nas na rynku, miał tani programator i dobrą dokumentację.

_________________
Und schreien

Spring
Erlöse mich
Spring
...

Discovery w wersji F4, masz programator, masz wystarczająco dużo pamięci, prędkości napewno Ci wystarczy, a jak trzeba to wsparcie liczb zmienno przecinkowych masz. Do tego masa info w internecie,nawet są blogi strony poświęcone tylko tej płytce. Jedyniena upartego to dodać do tego zestawu jakiś lepszy prztwornik analaogowo cyfrowy i możesz szaleć.

Ja proponuję STM32 bez bibliotek, moim zdaniem pisze się wygodniej, lepsza wydajność. Oryginalny ST-Link V2 można dostać za około 120 zł, lub używać zestawów discovery jako programatora (każdy ma wbudowany ST-LINK V2 z SWD (coś a`la 3 pinowy JTAG) - wystarczy rozewrzeć 2 zworki, piny do programowania są wyprowadzone na goldpiny).

Co do środowiska to na początek CooCox, jak się trochę oswoisz to Eclipse ( Sunriver udostępnił ostatnio na swoim blogu dostosowaną wersję, ale jeszcze bez obsługi ST-LINKA)

Autor wspominał, że potrzebuje M3/M4 a LPC11xx to Cortex'y M0

_________________
sig off ;(

LPC ... podobno kiepskie, słychać tu i tam.Ale w tej kwesti SunRiver siępewnie wypowie
Aż tak tanie nie są... w stosunku do konkurencji

A ja proponuję zwrócić uwagę na układy PSoc4 lub PSoc5 od Cypressa.
Nikt, powtarzam nikt nie oferuje tak fantastycznego wsparcia pod względem IDE i dokumentacji jak Cypress.

Ich środowisko programistyczne PSoC Creator jest po prostu genialne dla początkujących.
Transformata FFT dla PSoC5 to drobnostka, nawet na PSoC4 ktoś pokazywał kod do FFT.

PSoC4 kosztuje w Farnell-u poniżej 4zł, a najprostsza płytka testowa niecałe 20zł.

Moim zdaniem na start w świecie arm-ów nie ma lepszych układów. Jak pisałem wynika to w dużej mierze z niezwykle przyjaznego i łatwego IDE.

_________________
auto gaz, serwis instalacji LPG, Instalacje LPG

obsługuje ST-Linka , ale przez pakiet ecxternal Tools z użyciem ST-link Tools ... natomiast server gdb dla ST-Linka bedzie dostepny zaraz jak przeniosę stronę , tymczasem działa tez pod openOCD

Jeśli chodzi o autora pomysł , to najpierw niech się zapozna z Discovery lub Kinetisem choćby KL25Z czy tez K64F współdziałają oba z Luną NE
Poprzez J-Link OpenSDA coi opisałem na stronie oraz z Keplerem co też na stronie opisałem.

A następnie pomyśli do tego co chce zrobić Cortex-M0+ spokojnie wystarczy.
W przypadku Kinetisów, które też mają bardzo przyjazne środowisko jest tęż literatura wprowadzająca w świat CW oraz co nieco o KDS na mojej stronie.

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

Czyli Cortex-M0+ wystarczy do tego co chcę zrobić?

_________________
Und schreien

Spring
Erlöse mich
Spring
...

tak , ale M0+ nie M0

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

Działa, ale początkujący może się mocno zniechęcić próbując to cudo skonfigurować. W moim przypadku np. debug nie działa pod oryginalnymi sterownikami ST-Linka (brak przewijania programu itp) tylko pod WinUSB (Instalowane przez Zadig) (programowanie i debug przez OpenOCD - ST-Link toolsy nie działają z WinUSB)

Komenda do programowania (może się komuś przyda):


Wystarczy zmienić to (patrz folder scripts w OpenOCD):

na np.

Jaki toolchain polecacie do płytki STM32F4 Discovery?
W broszurce są wymienione: Altium, Atollic, IAR, Keil.
Wybrałem Atollic, bo jest na Eclipse ale mam z nim problem już na dzeń dobry:

_________________
Und schreien

Spring
Erlöse mich
Spring
...

popatrz u mnie na stronie , masz keplera i LUnę oraz opis co jak ustawić , masz też darmowy CoIDE wystarczy pokopac u mnie na stronie w dziale arm

_________________
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 mam keplera od Suna i działa wszystko, łącznie z debugowaniem na openocd, choć trochę upierdliwe jest jak chce się szybko przekompilować, wgrać i wrócić do debugera.

_________________
Pozdrawiam, Adrian.

Może mo ktoś wyjaśnić skąd się biorą subtelne różnice w przykładowych kodach ARM?

Kod niedziałający


Kod działający

_________________
Und schreien

Spring
Erlöse mich
Spring
...

Chyba tego nikt nie odgadnie dlaczego. Pokaż cały kod inkludy, na jakich płytkach lub ewentualnie schemat, założyć osobny wątek.

Już znalazłem tą subtelną różnicę

pierwszy przykład wymaga biblioteki STM32F4xx_StdPeriph_Driver


drugi wymaga biblioteki CMSIS

_________________
Und schreien

Spring
Erlöse mich
Spring
...

To jest generalnie to samo, tylko aktualnie nazywa się HAL, a kiedyś było SPL-em

_________________
Pozdrawiam, Adrian.

a cóż to za herezje ??

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

Hmm, w sumie nie zaglebialem sie w to nigdy. Funkcje po nazwach wygladaly mi tak samo, to myslalem ze w srodku jest to samo. Podpowie ktoś gdzie popełniam błąd?

_________________
Pozdrawiam, Adrian.

http://ep.com.pl/files/2736.pdf

Napisane jest że SPL wykorzystuje standard CMSIS ale nie jest napisane że jest z nim zgodne, stąd te subtelne różnice.

_________________
Und schreien

Spring
Erlöse mich
Spring
...

Na początek, całkowity mogę śmiało polecić FRDM KL25Z na mbed.org
Do zapoznania z platformą starczy, potem można iść w KDSa.
ewentualnie Nucleo, bo też jest zgodne z shieldami ardunio .

Ja to wszystko wiem i rozumiem, tylko błędnie zakładałem, że funkcje zawarte w HAL-u są oparte bezpośrednio na kodzie SPL-a. Zajrzałem sobie do źródeł i widzę różnice. Wygląda na to, że wszystko zostało napisane w większości od nowa. Np w SPL-u przy inicjalizacji GPIO nie ma w ogóle konfiguracji funkcji alternatywnych, a HAL jest kompletny.

Czyli zasadniczo dzięki standaryzacji, biorąc mikrokontroler od innego producenta nazwy funkcji i struktury pozostają zawsze te same, jedynie zawartość funkcji obsługujących peryferia, która jest dostarczana przez producenta danego układu jest różna. Plusy tego rozwiązania są oczywiste - przenośność kodu. Minusy też - marnujemy czas procesora i flash. Ale przy aktualnych pojemnościach flasha i uwzględniając fakt, że inicjalizację peryferiów przeprowadza się zwykle tylko raz na początku, ma to wszystko sens. Jedynie w miejscach bardziej krytycznych czasowo można pokusić się o bezpośrednie odwołania do rejestrów. Np zamiast wywoływać funkcję:



Mogę napisać tylko:



licząc się z ewentualną dodatkową robotą przy zmianie procesora na inny.

Mam nadzieję, że teraz wszystko dobrze rozumiem?

_________________
Pozdrawiam, Adrian.

Ja u siebie mam w tym miejscu zestaw makr np. takich:


Przy czym pod te makra można sobie podpinać "wszelkie rodzaje odwołań", które pozwalają używać tego samego kodu przy różnych rodzajach i rodzinach procków (np. ARM i PIC32) - podmienia się tylko w odp. pliku lokalnym makro odwołujące się do konkretnych rejestrów.
Warstwa wyższa pozostaje ta sama.

Wtedy nie musisz szukać po całym kodzie odwołań do portów - masz wszystko w jednym miejscu i wystarczy tam podmienić.

Zainstalowałem keplera.
Po utworzeniu nowego pustego projektu typu STM32F4xx C/C++ Project, toolchain Cross ARM GCC
pojawiają się dwa pliki src:
main.c
__initialize_hardware.c

Czy w main.c trzeba includować __initialize_hardware.c, żadnego połączenia pomiedzy plikami nie widzę, ale chyba się inicjalizuje.

_________________
Und schreien

Spring
Erlöse mich
Spring
...

Nie trzeba includujesz tylko stm32f10x.h (zależy od rodziny procka)

Zawartość tego pliku jest wykonywana przed mainem, nie wiem tylko w jaki sposób jest ona wywoływana. Podejrzewam, że jest to zawarte w pliku startowym, ale przydałoby się potwierdzenie przez kogoś bardziej doświadczonego.

_________________
Pozdrawiam, Adrian.

Dokładnie, też do tego doszedłem, wystarczy w _initialize_hardware.c zaremować configure_system_clock(); i widać że układ działa na 8 MHz.
Skonfigurowany jest też SysTick, bez pustej funkcji void SysTick_Handler(void){} układ się zatrzymuje.

Pytanie, gdzie i jak on się wykonuje przed main?

_________________
Und schreien

Spring
Erlöse mich
Spring
...

Ja w ogóle nie używam tych plików, jeżeli przy tworzeniu projektu wybierzecie konfigurację pod konkretną rodzinę procesora np. STM32F1x... to eclipse wrzuca mnóstwo niepotrzebnych plików. Polecam użyć opcji Cross GCC i powrzucać tylko to co się potrzebuje

http://promikro.com.pl/wp-content/uploa ... images.pdf

Od strony 22 potem trzeba wejść w system_stm32f.....c i zakomentować/odkomentować odpowiednie definicje tak aby procek śmigał na wymaganej przez nas częstotliwości.

Potem do maina SystemCoreClockUpdate(); i powinno chodzić np, na 168 Mhz

Przyda się, bo do teraz robiłem tak, że tworzyłem projekt z szablonu a potem usuwałem wszystkie niepotrzebne rzeczy

_________________
Pozdrawiam, Adrian.

No właśnie ja też od dłuższego czasu zadaje sobie to pytanie od czego zacząć przygodę z ARM ??? . I moja konkluzja jest taka , że na rynku jest dosłownie za trzęsienie zestawów różnych firm , i..... właściwie na tym się kończy cała zabawa . Bo sam zestaw to nie wszystko , liczy się jeszcze wsparcie jakie dany zestaw posiada a z tym jest naprawdę cienko , ba nawet bardzo cienko .