RE: Programowanie ARM, nauka, środowiska programistyczne IDE - QRP73 - 05-07-2016 21:43
Witam wszystkich. Z jakim zegarem pracuje procesor w Pawla przykladzie?
Co ile ms jest przerwanie od systicka ?
Marek
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 05-07-2016 22:32
Witaj,
Przerwanie od SysTick-a jest co 0.5 sekundy, niezależnie od ustawionego zegara.
Jeżeli jest inaczej, to.......
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - QRP73 - 06-07-2016 0:11
Teoretycznie powinno byc co 1/16 lub 1/2 sekundy. Nie wiem skad tem dzielnik /8 w ustawianiu systicka ?
Cos jest nie tak z CoreClock.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 06-07-2016 8:53
Witaj,
Niech zgadnę.... Diody mrugają Ci około 3 razy za wolno ?
W tym przykładzie mają świecić naprzemiennie po 0.5 sekundy.
Jeżeli tak nie jest, to znaczy, że obliczona wartość w SystemCoreClock nie pokrywa się z rzeczywistą częstotliwością jaką jest taktowany rdzeń.
Dzieje się tak, ponieważ częstotliwość rezonatora kwarcowego zewnętrznego nie ma takiej wartości jak przypisana do HSE_VALUE w pliku stm32f4xx.h lub system_stm32f4xx.c. Domyślnie do HSE_VALUE przypisana jest wartość 25000000 (25Mhz), natomiast kwarc zewnętrzny na płytce stm32f429I Discovery ma częstotliwość 8000000 (8Mhz).
Z tego wynika, że obliczona wartość częstotliwości jest błędna, jeżeli bez wiedzy użytkownika funkcja startowa SystemInit() rozpędza zegary na maxa z użyciem zewnętrznego kwarcu.
Należy więc poprawić ręcznie wartość HSE_VALUE na taką, jaką ma zewnętrzny kwarc dołączony do STM-a
W projekcie utworzonym w EmBitz zegary domyślnie są rozpędzane na maxa w funkcji SystemInit()
Natomiast w projekcie utworzonym w SeggerStudio funkcja SystemInit() nie rusza konfiguracji zegarów, czyli rdzeń pracuje z domyślnym zegarem wewnętrznym 16Mhz.
Funkcja SystemInit() jest wywoływana w sekcji inicjalizującej procesor, jeszcze przed funkcją main()
Co do przykładu. Dlaczego jest SystemCoreClock/8.
Trzeba powiedzieć, że licznik SysTicka jest tylko 24 bitowy. Więc zmieści wartość 2^24 (16.7 mln). Jeżeli wartość SystemCoreClock/2, która jest przekazana jako parametr funkcji konfigurującej SysTicka. będzie się mieścić w liczniku SysTicka, to zostanie on skonfigurowany i funkcja zwróci 0.
Jeżeli wartość SystemCoreClock/2 będzie większa od 2^24 to funkcja konfigurująca SysTick-a zwróci wartość rózną od 0 (błąd), instrukcja warunkowa "if" pozwoli na wywołanie funkcji konfigurującej SysTick-a z parametrem SystemCoreClock/8/2, następnie zostanie włączony preskaler /8 licznika SysTicka. Więc licznik SysTicka będzie taktowany częstotliwością rdzenia podzieloną przez 8.
Dlatego też, przerwanie SysTicka bez względu na częstotliwość taktowania rdzenia będzie wykonywane co 0.5 sek , bo wartość SystemCoreClock dzielimy przez 2
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - QRP73 - 06-07-2016 9:42
Pawel dzieki za wyjasnienie sprawy systicka.
Skoro przy starcie jest wykonywana funkcja SystemInit() to poco w kodzie dajesz SystemCoreClockUpdate() ?
Funkcja SystemInit() ustawia wczesniej zegar procesora.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SQ8MVY - 06-07-2016 10:05
Aby miec pewnosć, że zmienna SystemCoreClock ma prawidłową wartość.
Funkcja SystemCoreClockUpdate() nie ustawia żadnych zegarów. Odczytuje jedynie wartości z rejestrów pll, preskalerów, mnożników i uwzględniając wartość HSE_VALUE lub HSI_VALUE, oblicza częstotliwość taktowania i zapisuje do zmiennej globalnej uint32_t SystemCoreClock.
Nie wiem (nie zwróciłem na to uwagi) czy SystemInit() po przekonfigurowaniu zegarów aktualizuje zmienną SystemCoreClock. Więc dla pewności robię to przed konfiguracją SysTick-a.
Jak wspominałem, jestem początkujący w języku C jak i ARM-ach, więc jeszcze wielu rzeczy nie wiem. Ale tym co wiem się dzielę.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6VGX - 06-07-2016 10:37
(04-07-2016 22:09)SP5FCS napisał(a): (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.
Wlasnie tak wklejony kod nic nie pokazuje... ja go przekleje do siebie w eclipse i dalej sie nie kompilije, bo trzeba recznie dolaczyc CMSIS itd. brak jest dalej mowy o pliku strartupu i linkera, ustawieniach stosu itd.
Kolejne to co wlasnie wyszlo - czyli to co wspominalem dlaczego miga tak, a nie inczczej. Czyli ustawienia zegara... do tego niektore peryferia wymagaja zegara o okreslonej czestotliwosci - wiec przykladowo w STM32F3 czasem rdzen nie moze chodzic na max.
Od takich podstaw powinno sie zaczac jak chocby schemat jak wyglada taktowanie i od tego jak to wszystko ustawic.
Wiekszosc poczatkujacych nie poradzi sobie nawet z miganiem dioda jak nie dolaczy sie gotowego projektu ktory po otwarciu w srodowisku sie kompiluje.
Natomiast zlozonosc konfiguracji zarowno w CMSIS, SPL itp. mozna zobaczyc tylko na podstawie calego projektu i pokazania gdzie i co trzeba ustawic - aby program dzialal...
Ale to jest wszystko kwestia od jakiego poziomu zaczynamy...
---
Ja sam dosc czesto takie sprawy pomijam - przez to mowie ze ze mnie nauczyciel jak z koziej d... traba, ale tutaj na razie staram sie sam siebie pilnowac aby wyjasnic wszelkie podstawy odnosnie procesorow zanim przejdzie sie do pisania nawet migania dioda. Moze i to dla niektorych bedzie banalne, ale poczatkujacy utkna pozniej bez takiej wiedzy...
Bo jak teraz zadam (pomijam osoby ktore pisza) na jakim prorytecie NVIC dziala Systick (tego priorytetu nie mozna zmienic - ale warto o nim wiedziec) to ile osob odpowie ?
Wiec dla tego mowie najpierw podstawa o STM32F4 czyli o rdzeniu, taktowaniu, systemie przerwan... srodowisko i potem mozna sie brac za pisanie kodu.
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6IFN - 06-07-2016 12:07
Cytat:Wiec dla tego mowie najpierw podstawa o STM32F4 czyli o rdzeniu, taktowaniu, systemie przerwan... srodowisko i potem mozna sie brac za pisanie kodu.
A mnie dodatkowo interesuje też co jest na tej płytce (foto poniżej), gdzie, po co i jakie kabelki się przypina, oraz co z tymi programikami które już tam są.
Rozumiem też że środowisko już zostało wybrane http://sp-hm.pl/thread-2663.html i aktualna jest instrukcja którą opisał Piotr w poście #1.
Osobiście już zainstalowałem EmBitz 0,42......no i oczekuję co będzie dalej.
Od zawsze powtarzam "nie ma głupich pytań, jest tylko brak wiedzy", proszę więc mnie nie potępiać, jestem jeszcze w zerówce.
Rysio!
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP6VGX - 06-07-2016 12:43
IMHO EmBitz moze byc jednym ze srodowisk, ale wtedy pomijamy poczatkujacych pracujacych na Linux... a widac ze jest 14 osob. Mnie z OS X w ankiecie mozna pominac (jestem w stanie odpalic sobie dowolne srodowisko).
Jednak trzeba przemyslec by bylo to wszystko kompatybilne ze soba i robic projekty tak aby nie byc ograniczonym do danego srodowiska.
Przykladowo automatyczne zalozenie projektu w Eclipse dla STM32F4 wyglada tak:
[attachment=11194]
na ile to jest kompatybilne z innymi... to hmmm
w main wygenerowany z automatu przyklad blinkled:
Kod:
//
// This file is part of the GNU ARM Eclipse distribution.
// Copyright (c) 2014 Liviu Ionescu.
//
// ----------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include "diag/Trace.h"
#include "Timer.h"
#include "BlinkLed.h"
// ----------------------------------------------------------------------------
//
// Standalone STM32F4 led blink sample (trace via DEBUG).
//
// In debug configurations, demonstrate how to print a greeting message
// on the trace device. In release configurations the message is
// simply discarded.
//
// Then demonstrates how to blink a led with 1 Hz, using a
// continuous loop and SysTick delays.
//
// Trace support is enabled by adding the TRACE macro definition.
// By default the trace messages are forwarded to the DEBUG output,
// but can be rerouted to any device or completely suppressed, by
// changing the definitions required in system/src/diag/trace_impl.c
// (currently OS_USE_TRACE_ITM, OS_USE_TRACE_SEMIHOSTING_DEBUG/_STDOUT).
//
// ----- Timing definitions -------------------------------------------------
// Keep the LED on for 2/3 of a second.
#define BLINK_ON_TICKS (TIMER_FREQUENCY_HZ * 3 / 4)
#define BLINK_OFF_TICKS (TIMER_FREQUENCY_HZ - BLINK_ON_TICKS)
// ----- main() ---------------------------------------------------------------
// Sample pragmas to cope with warnings. Please note the related line at
// the end of this function, used to pop the compiler diagnostics status.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-parameter"
#pragma GCC diagnostic ignored "-Wmissing-declarations"
#pragma GCC diagnostic ignored "-Wreturn-type"
int
main(int argc, char* argv[])
{
// Send a greeting to the trace device (skipped on Release).
trace_puts("Hello ARM World!");
// At this stage the system clock should have already been configured
// at high speed.
trace_printf("System clock: %u Hz\n", SystemCoreClock);
timer_start();
blink_led_init();
uint32_t seconds = 0;
// Infinite loop
while (1)
{
blink_led_on();
timer_sleep(seconds == 0 ? TIMER_FREQUENCY_HZ : BLINK_ON_TICKS);
blink_led_off();
timer_sleep(BLINK_OFF_TICKS);
++seconds;
// Count seconds on the trace device.
trace_printf("Second %u\n", seconds);
}
// Infinite loop, never return.
}
#pragma GCC diagnostic pop
// ----------------------------------------------------------------------------
Kod:
//
// This file is part of the GNU ARM Eclipse distribution.
// Copyright (c) 2014 Liviu Ionescu.
//
#include "Timer.h"
#include "cortexm/ExceptionHandlers.h"
// ----------------------------------------------------------------------------
#if defined(USE_HAL_DRIVER)
void HAL_IncTick(void);
#endif
// Forward declarations.
void
timer_tick (void);
// ----------------------------------------------------------------------------
volatile timer_ticks_t timer_delayCount;
// ----------------------------------------------------------------------------
void
timer_start (void)
{
// Use SysTick as reference for the delay loops.
SysTick_Config (SystemCoreClock / TIMER_FREQUENCY_HZ);
}
void
timer_sleep (timer_ticks_t ticks)
{
timer_delayCount = ticks;
// Busy wait until the SysTick decrements the counter to zero.
while (timer_delayCount != 0u)
;
}
void
timer_tick (void)
{
// Decrement to zero the counter used by the delay routine.
if (timer_delayCount != 0u)
{
--timer_delayCount;
}
}
// ----- SysTick_Handler() ----------------------------------------------------
void
SysTick_Handler (void)
{
#if defined(USE_HAL_DRIVER)
HAL_IncTick();
#endif
timer_tick ();
}
// ----------------------------------------------------------------------------
Kod:
//
// This file is part of the GNU ARM Eclipse distribution.
// Copyright (c) 2014 Liviu Ionescu.
//
#include "BlinkLed.h"
// ----------------------------------------------------------------------------
void
blink_led_init()
{
// Enable GPIO Peripheral clock
RCC->AHB1ENR |= BLINK_RCC_MASKx(BLINK_PORT_NUMBER);
GPIO_InitTypeDef GPIO_InitStructure;
// Configure pin in output push/pull mode
GPIO_InitStructure.Pin = BLINK_PIN_MASK(BLINK_PIN_NUMBER);
GPIO_InitStructure.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStructure.Speed = GPIO_SPEED_FAST;
GPIO_InitStructure.Pull = GPIO_PULLUP;
HAL_GPIO_Init(BLINK_GPIOx(BLINK_PORT_NUMBER), &GPIO_InitStructure);
// Start with led turned off
blink_led_off();
}
// ----------------------------------------------------------------------------
Kod:
//
// This file is part of the GNU ARM Eclipse distribution.
// Copyright (c) 2014 Liviu Ionescu.
//
// ----------------------------------------------------------------------------
#include "stm32f4xx.h"
#include "stm32f4xx_hal.h"
#include "stm32f4xx_hal_cortex.h"
// ----------------------------------------------------------------------------
// The external clock frequency is specified as a preprocessor definition
// passed to the compiler via a command line option (see the 'C/C++ General' ->
// 'Paths and Symbols' -> the 'Symbols' tab, if you want to change it).
// The value selected during project creation was HSE_VALUE=8000000.
//
// The code to set the clock is at the end.
//
// Note1: The default clock settings assume that the HSE_VALUE is a multiple
// of 1MHz, and try to reach the maximum speed available for the
// board. It does NOT guarantee that the required USB clock of 48MHz is
// available. If you need this, please update the settings of PLL_M, PLL_N,
// PLL_P, PLL_Q to match your needs.
//
// Note2: The external memory controllers are not enabled. If needed, you
// have to define DATA_IN_ExtSRAM or DATA_IN_ExtSDRAM and to configure
// the memory banks in system/src/cmsis/system_stm32f4xx.c to match your needs.
// ----------------------------------------------------------------------------
// Forward declarations.
void
__initialize_hardware(void);
void
SystemClock_Config(void);
// ----------------------------------------------------------------------------
// This is the application hardware initialisation routine,
// redefined to add more inits.
//
// Called early from _start(), right after data & bss init, before
// constructors.
//
// After Reset the Cortex-M processor is in Thread mode,
// priority is Privileged, and the Stack is set to Main.
//
// Warning: The HAL requires the system timer, running at 1000 Hz
// and calling HAL_IncTick().
void
__initialize_hardware(void)
{
// Initialise the HAL Library; it must be the first function
// to be executed before the call of any HAL function.
HAL_Init();
// Enable HSE Oscillator and activate PLL with HSE as source
SystemClock_Config();
// Call the CSMSIS system clock routine to store the clock frequency
// in the SystemCoreClock global RAM location.
SystemCoreClockUpdate();
}
// Disable when using RTOSes, since they have their own handler.
#if 0
// This is a sample SysTick handler, use it if you need HAL timings.
void __attribute__ ((section(".after_vectors")))
SysTick_Handler(void)
{
#if defined(USE_HAL_DRIVER)
HAL_IncTick();
#endif
}
#endif
// ----------------------------------------------------------------------------
/**
* @brief System Clock Configuration
* @param None
* @retval None
*/
void
__attribute__((weak))
SystemClock_Config(void)
{
// Enable Power Control clock
__PWR_CLK_ENABLE();
// The voltage scaling allows optimizing the power consumption when the
// device is clocked below the maximum system frequency, to update the
// voltage scaling value regarding system frequency refer to product
// datasheet.
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
#warning "Please check if the SystemClock_Config() settings match your board!"
// Comment out the warning after checking and updating.
RCC_OscInitTypeDef RCC_OscInitStruct;
#if defined(HSE_VALUE) && (HSE_VALUE != 0)
// Enable HSE Oscillator and activate PLL with HSE as source.
// This is tuned for STM32F4-DISCOVERY; update it for your board.
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
// This assumes the HSE_VALUE is a multiple of 1 MHz. If this is not
// your case, you have to recompute these PLL constants.
RCC_OscInitStruct.PLL.PLLM = (HSE_VALUE/1000000u);
#else
// Use HSI and activate PLL with HSI as source.
// This is tuned for NUCLEO-F411; update it for your board.
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_ON;
// 16 is the average calibration value, adjust for your own board.
RCC_OscInitStruct.HSICalibrationValue = 16;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI;
// This assumes the HSI_VALUE is a multiple of 1 MHz. If this is not
// your case, you have to recompute these PLL constants.
RCC_OscInitStruct.PLL.PLLM = (HSI_VALUE/1000000u);
#endif
RCC_OscInitStruct.PLL.PLLN = 336;
#if defined(STM32F401xC) || defined(STM32F401xE) || defined(STM32F411xE)
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV4; /* 84 MHz */
#elif defined(STM32F427xx) || defined(STM32F437xx) || defined(STM32F429xx) || defined(STM32F439xx)
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; /* 168 MHz */
#elif defined(STM32F405xx) || defined(STM32F415xx) || defined(STM32F407xx) || defined(STM32F417xx)
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; /* 168 MHz */
#elif defined(STM32F446xx)
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; /* 168 MHz */
#else
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV4; /* 84 MHz, conservative */
#endif
RCC_OscInitStruct.PLL.PLLQ = 7; /* To make USB work. */
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
RCC_ClkInitTypeDef RCC_ClkInitStruct;
// Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2
// clocks dividers
RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK
| RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2);
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
#if defined(STM32F401xC) || defined(STM32F401xE) || defined(STM32F411xE)
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2);
#else
// This is expected to work for most large cores.
// Check and update it for your own configuration.
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
#endif
HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
}
// ----------------------------------------------------------------------------
i tak na to patrze i hmm ja bym to wypierniczyl na sile dowala HAL i inne bzdury robiac z prostego projektu cos co raczej poczatkujacemu trudno wytlumaczyc...
do tego zwiazani jestesmy z srodowiskiem co czasem mocno utrudnia dodanie jakis gotowych blokow RTOS-y, FAT, stosy TCP/IP itd.
Ja jestem bardziej za podejsciem ze IDE pomaga, ale nie jest podstawa przy tworzeniu projektu. Z takim podejsciem to mozna stworzyc/przekompilowac/zaprogramowac uklad majac dostep tylko do konsoli z gcc,vi, openocd/jlink
RE: Programowanie ARM, nauka, środowiska programistyczne IDE - SP5FCS - 06-07-2016 12:46
(06-07-2016 10:37)SP6VGX napisał(a): Wiec dla tego mowie najpierw podstawa o STM32F4 czyli o rdzeniu, taktowaniu, systemie przerwan... srodowisko i potem mozna sie brac za pisanie kodu.
Są dwie szkoły nauczania, tradycyjna: najpierw dużo teorii a dopiero potem praktyka oraz praktyczna: konkretny przykład na którym omawiamy niezbędną w nim teorię. Ja jestem zwolennikiem drugiej metody, jest szybsza, ciekawsza i wymaga poznawania tylko tych fragmentów procesora które są nam niezbędne w danym zadaniu. Teoretyczne omówienie rdzenia, układów peryferyjnych, środowiska, kompilatora, linkera, debagera to są tysiące stron opisu i setki godzin wykładów. Kto wytrwa do końca tej teorii bez radości z uruchomienia nawet najprostszego kodu. Praktyczne ćwiczenia przyciągają czytających i zachęcają do przyłączenia się do kursu.
Pisząc pierwszy program w środowisku które posiada kreator projektu nie musimy nic wiedzieć o zegarze (ustawiony domyślnie) a tym bardziej o SysTicku i przerwaniach. Najprostsze mruganie diodą to prosta operacja na porcie i programowa pętla opóźnienia. W miarę poznawania procesora możemy modyfikować zadanie zmieniając zegar procesora czy tak jak Paweł dodać obsługę SysTicka. Na tym prostym zadaniu możemy omówić i przedyskutować wiele tematów niezbędnych do świadomego pisania własnych programów.
|