Bardzo szybki start c.d.

Ostatnio z braku płytki musiałem nieco teoretycznie podejść do pisania pierwszego programu. Dzisiaj wreszcie mogę uruchomić prosty programik na prawdziwym mikrokontrolerze.


Czas więc szybko napisać przykład z migającą diodą. Zarówno projekt wygenerowany dla StdPeriph, jak i dla HAL Cube zawiera funkcje sterujące diodą na płytce Nucleo, napisanie programu jest zatem banalnie proste.
Na początek StdPeriph:

#include "stm32f10x.h"

#include "stm32f1xx_nucleo.h"

int main(void)

{

volatile uint32_t dly;

STM_EVAL_LEDInit(LED2);

while (1) {

STM_EVAL_LEDOn(LED2);

for (dly = 0; dly < 1000000; dly++)

;

STM_EVAL_LEDOff(LED2);

for (dly = 0; dly < 1000000; dly++)

;

}

}

Pętle opóźniające są nieco brzydkie, ale pozwalają na obserwowanie pięknie migającej diody.

Teraz dla porównania to samo w HAL Cube:

#include "stm32f1xx.h"

#include "stm32f1xx_nucleo.h"

int main(void)

{

volatile uint32_t dly;

BSP_LED_Init(LED2);

while (1) {

BSP_LED_On(LED2);

for (dly = 0; dly < 1000000; dly++)

;

BSP_LED_Off(LED2);

for (dly = 0; dly < 1000000; dly++)

;

}

}

Ten program też działa pięknie. Jednak nawet tak banalne programy kryją w sobie pierwszą niespodziankę. Częstotliwość migania diody jest widocznie różna. Myślałem, że mam problemy ze wzrokiem, postanowiłem więc podłączyć analizator - wyniki są następujące:

• StdPerip - 1.88 Hz
• Cube - 0.33 Hz

Nie znaczy to oczywiście, że któraś biblioteka jest lepsza lub gorsza. Jednak nawet tak banalny program może nas zaskoczyć. Różnica w prędkości działania to prawie 6x.

Wniosek moim zdaniem jest następujący: biblioteki są niesamowitym ułatwieniem, pozwalają na napisanie programu szybko i bez wysiłku. Jednak ich użycie wymaga sporo wiedzy i może kryć niemało niespodzianek.

Od początku planowałem dokładne poznanie STM32 , ale ten test test utwierdził mnie w moim przekonaniu, że biblioteki mogą w tym więcej przeszkodzić niż pomóc. 

Tak więc od następnej części zamiast Cube, czy StdPeriph będę używał tylko rejestrów.