Programowanie ARM, nauka, środowiska programistyczne IDE

[SP6VGX]

(04-07-2016 12:04)SP5FCS napisał(a):  Ciągle mam mentalność programisty asemlerowego, który najwyżej ceni czas procesora i wielkość generowanego kodu, potem wygodę i łatwość pisania a na wygląd wcale nie zwracam uwagi. Kodu wgranego do procesora nikt nie będzie podziwiał liczy się efekt działania urządzenia.

To nie jest zle podejscie, osobiscie tez czasem przekladam ladny kod na wydajnosc - zwlaszcza ze zycie nauczylo jednego, potem w jakims projekcie zaczyna brakowac zasobow i trzeba cicac ladnie wygladajacy kod Owszem mozna czasami zmienic procesor na szybszy/wieksza iloscia flash czy ram i o ile w podejsciu amatroskim nie jest to problem dac procek nawet za 100zl wiecej bo to jednorazowy wydatek to o tyle gdy pcha sie cos do produkcji to czasami nawet 1zl ma znaczenie przy setkach sztuk.

Natomiast co do intensywnosci kursu to osobty ktore juz w miare dobrze stoja z programowaniem choc by AVR-ow w C w miare szybko poradza sobie z ARM po poznaniu podstaw o rdzeniu i peryferiach... Czyli przerobieniu wlasnie konfiguracji zegarow, systemu przerwan NVIC, uzywania DMA... czyli tego co nie ma w maluchach (choc piszac na XMega ma sie juz jakies pojecie o tych peryferiach), a jak wspomnialem nawet i o USB mozna miec jak sie uzywalo malych z tym interfejsem (choc fakt przyznam ze jak kupowalem ATmega32U4 do testow to cena byla malo atrakcyjna w stosunku do ARM-ow - cos w okolicach 35zl) - wiec ich popuilarnosc moze byc niewielka.

[SQ8MVY]

A co mi tam, przyjmę wyzwanie dotyczące Z001, zamrugam "oboma okami" na F429 Dicovery

Kod:

#include "stm32f4xx.h"

int main(void)
{

    SystemCoreClockUpdate();
    if (SysTick_Config(SystemCoreClock/2))
        {
          SysTick_Config((SystemCoreClock/8)/2);
          SysTick->CTRL  = SysTick_CTRL_TICKINT_Msk | SysTick_CTRL_ENABLE_Msk;
        }

    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOGEN;
    GPIOG->MODER |=GPIO_MODER_MODER13_0 | GPIO_MODER_MODER14_0;

    GPIOG->ODR |= GPIO_ODR_ODR_13;

    while(1)
        {

        }

}

void SysTick_Handler(void)
{

    GPIOG->ODR ^=GPIO_ODR_ODR_13 | GPIO_ODR_ODR_14;

}

Wklejony wyżej kod jest celowo bez komentarzy. Przy zainteresowaniu razem je dopiszemy......

[SP6VGX]

(04-07-2016 16:35)SQ8MVY napisał(a):  Wklejony wyżej kod jest celowo bez komentarzy. Przy zainteresowaniu razem je dopiszemy......

A ja bede troche zlosliwy

Dlaczego pomieszanie SPL-a z odwolaniem do rejestrow (GPIO).

No i brakuje jeszcze naglowkow jak decydujemy sie na SPL-a (wiem gpio w tym kodzie mozna by pominac) rcc tez systic o ile pamietam jest chyba w misc... :

Kod:

#include <misc.h>
#include <stm32f4xx_rcc.h>
#include <stm32f4xx_gpio.h>

Mozna by dodac na poczatku tez SystemInit(); no i do tego ewentualnie informacje o edycji system_stm32f4xx.c Do tego wymagane jest chyba CDEFS dla kompilatora o ile dobrze pamietam : -DUSE_STDPERIPH_DRIVER -DSTM32F429_439xx

Dlaczego o tym pisze... bo wklejony kod nie przekompiluje sie w sporej czesci srodowisk A chyba powinnismy zaczac od podstaw jak przygotowac projekt...

[SQ8MVY]

(04-07-2016 18:59)SP6VGX napisał(a):  

(04-07-2016 16:35)SQ8MVY napisał(a):  Wklejony wyżej kod jest celowo bez komentarzy. Przy zainteresowaniu razem je dopiszemy......

A ja bede troche zlosliwy

Dlaczego pomieszanie SPL-a z odwolaniem do rejestrow (GPIO).

Co prawda jestem początkujący, ale jak dla mnie tu nie ma ani grama SPL-a. Sam CMSIS .....

Dodano
Teraz dopiero zauważyłem, że brakuje #include "stm32f4xx.h" - źle się wkleiło - poprawione

[SP6VGX]

a sorry nie wiem co mnie wzielo patrzac na systick pomylilo mi sie z SysTick_CLKSourceConfig, chyba za dlugo dzisiaj prze kompem... Moze dlatego ze czesciej uzywam SystTick->LOAD, SysTick->VAL, SysTick-CTRL

Co nie zmiena faktu ze brakuje "stm32f4xx.h"

i podpiecia CMSIS...

W sumie bardziej mi chodzi o to aby zamieszczac wszystko od podstaw - czyli powinnismy od tego jak stworzyc projekt... Bo zrobimy zamieszanie... a jeszcze nie ustalilismy chyba wszystkiego czy idziemy w jakas biblioteke czy samo CMSIS itd.

Zwlaszcza ze musimy zapewnic aby projekty byly kompatybilne na wszystkich platformach czyli zapewne rozne srodowiska...

[SQ8MVY]

#include "stm32f4xx.h" już dodane - zginęło przy copy/paste.

Przykład ten wkleiłem w taki sposób, bo nie ma jeszcze ustalonego wspólnego środowiska....

Z rozmów jakie tu się przewijają powoli wynika, że takim może stać się EmBitz - coraz więcej kolegów się do niego przekonuje.

Jeżeli środowisko zostanie ostatecznie uzgodnione, wówczas można napisać o całej instalacji/ konfiguracji.

Przykład ten skopiowany z tematu i wklejony do pliku main.c w świeżo wygenerowanym szkielecie projektu w EmBitz bezproblemowo się kompiluje i uruchamia na płytce docelowej STM32F429I-Discovery.

[SP9FKP]

(04-07-2016 19:34)SP6VGX napisał(a):  Zwlaszcza ze musimy zapewnic aby projekty byly kompatybilne na wszystkich platformach czyli zapewne rozne srodowiska...

Otóż to!
Widzę chłopaki, że robota pali Wam się w rękach, cierpliwości. Jeszcze trzeba się porządnie przygotować aby nie było falstartu. Potem samo się napędzi. Piszę spis treści, wolno to idzie bo co rusz sprawdzam czy są jakieś ciekawe źródła, przykłady by nie powielać tych samym rzeczy a dać coś innego na ten sam temat. Zważcie, że już potrzebny jest słowniczek terminów. Kto zrobi spis skrótów, które zostały do tej pory użyte w wątku?

[SP5FCS]

(04-07-2016 19:34)SP6VGX napisał(a):  ... a jeszcze nie ustalilismy chyba wszystkiego czy idziemy w jakas biblioteke czy samo CMSIS itd.

Moim zdanie przy pierwszym zadaniu nie musimy nic ustalać, niech każdy zrobi to tak jak umie, lubi czy może w danej chwili: SPL, HAL, libopen lub rejestry. Po pierwsze pokaże to jak jesteśmy różni, jak w różny sposób piszemy programy, na jak wiele sposobów można napisać ten trywialny programik, jakie popełniamy błędy i jakie wypracować wspólne wymagania do kolejnych zadań. Po drugie zobaczymy jakie efekty dają różne podejścia, ciekawy jestem jaka będzie różnica w wielkości kodu pomiędzy HAL-em, SPL-em a rejestrami. Po trzecie powoli zaczniemy ujednolicać styl pisania programu.

Do dyskusji każdy fragment kodu jest dobry (Paweł gratulacje za szybkość i podejście rejestrowe). Dla mnie kod musi stanowić jednocześnie dokumentację projektu abym nie musiał mieć pod ręką schematu Discovery. Dlatego trzeba nazwać mrugające diody, napisać czy włączamy je stanem niskim czy wysokim itd.
Kod Pawła bez problemu się kompiluje pod EMBitz.

Nawet na podstawie tak prostego programu możemy przedyskutować i określić kilka podstawowych zasad pisania następnych programów:
- nagłówek z opisem pliku (typ modułu/procesora, zegar/ biblioteka/ data/ wersja/opis przeznaczenia kodu zawartego w pliku);
- komentarze ( opis funkcji, zmiennych, definicji, fragmentów kodu, trudniejszych linii kodu;
- sposób dzielenia algorytmu na oddzielne pliki;
- sposób i miejsce konfiguracji układów peryferyjnych;
- inne (lista zapewne będzie długa).

(04-07-2016 19:53)SP9FKP napisał(a):  Kto zrobi spis skrótów, które zostały do tej pory użyte w wątku?

Piotrze, trzeba wybrać jakiś edytor do prac redakcyjnych, proponuję darmowy OpenOffice.
Jako moduł do kursu optymalny będzie DiscoveryF429I (niestety aktualnie jest dostępny tylko nowy model / droższy). Wielu kolegów już posiada te moduły.

[SQ6DGT]

(04-07-2016 19:53)SP9FKP napisał(a):  

(04-07-2016 19:34)SP6VGX napisał(a):  Zwlaszcza ze musimy zapewnic aby projekty byly kompatybilne na wszystkich platformach czyli zapewne rozne srodowiska...

Otóż to!
Widzę chłopaki, że robota pali Wam się w rękach, cierpliwości. Jeszcze trzeba się porządnie przygotować aby nie było falstartu. Potem samo się napędzi. Piszę spis treści, wolno to idzie bo co rusz sprawdzam czy są jakieś ciekawe źródła, przykłady by nie powielać tych samym rzeczy a dać coś innego na ten sam temat. Zważcie, że już potrzebny jest słowniczek terminów. Kto zrobi spis skrótów, które zostały do tej pory użyte w wątku?

Ja mogę zacząć, jakby coś nie tak proszę poprawiać:

CMSIS (ang. Cortex Microcontroller Software Interface Standard) - standardowa biblioteka (biblioteczka) interfejsu programowego do rdzeni typu ARM Cortex. Zawiera głównie definicje rejestrów i innych elementów rdzenia oraz funkcje istotne dla inicjalizacji systemu i zegara. Stopniowo, wraz z rozbudową architektury w nowszych Cortex-ach dodawane są sukcesywnie nowe definicje i funkcje, np. do DSP.

SPL (ang. Standard Peripherials Library) - standardowa biblioteka dostępu do układów peryferyjnych. Dopełnia CMSIS, zawiera definicje rejestrów peryferyjnych mikrokontrolera, stałych określających ich wartości i co najważniejsze funkcji do inicjalizacji i modyfikacji peryferiów, takich jak GPIO, TIM-ery, USART, magistrale CAN, SPI, I2C, przetworniki DAC, ADC, sterownik przerwań NVIC, moduł DMA, i inne. Zestaw funkcji jest przedmiotem krytyki jednak czyni kod dużo bardziej czytelnym ze względu na znaczące nazwy funkcji i stałych. SPL nie jest już rozwijane (o ile wiem).

HAL (ang. Hardware Abstraction Layer) - warstwa abstrakcji sprzętowej. Następca SPL-a, rozwiązanie dużo bardziej kompleksowe i z większym rozmachem, rozprowadzane jako pakiet STM32Cube. Pakiet ten zawiera graficzne środowisko do konfiguracji i generowania kodu startowego dla wybranego mikrokontrolera, itd. Z punktu widzenia kodu dosyć podobny do SPL-a.

DMA - (ang. Direct Memory Access) - moduł bezpośredniego dostępu do pamięci. Niezależnie od procesora wykonuje transfer między obszarami pamięci i/lub obszarami wejścia wyjścia. Możliwe jest konfigurowanie DMA na różne sposoby np. tak by pobierać serię próbek z przetwornika ADC i zapisywać je w ciągłym bloku pamięci o określonej długości. Transfer może być jednorazowy lub działać w pętli, itd. Transfer przez DMA jest szybszy od analogicznego przy użyciu rdzenia.

....

[SP9FKP]

(04-07-2016 22:09)SP5FCS napisał(a):  Piotrze, trzeba wybrać jakiś edytor do prac redakcyjnych, proponuję darmowy OpenOffice.
Jako moduł do kursu optymalny będzie DiscoveryF429I (niestety aktualnie jest dostępny tylko nowy model / droższy). Wielu kolegów już posiada te moduły.

Oczywiście, tylko OpenOffice wchodzi w rachubę. Co do modułu sądzę, że to najbardziej optymalny wybór. Kupując nowy mamy jeszcze VCP (Virtual Com Port) na pokładzie, będzie przydatny w wielu przykładach. Posiadacze starszych wersji STM32F429IDISCO będą musieli zaopatrzyć się w translator ponieważ nie doszukałem się informacji w jaki sposób prosto "dołożyć" do tej wersji VCP.