STM32F4. Структура программы

[teplofizik]

Этот пост не относится конкретно к какой-то платформе, но примеры даны именно для stm32f4, ибо stm32 много у кого есть.

Раньше я особо не задумывался над структурой программ. Каждая программа была сделана по-разному, была весьма запутанной и со множеством очевидных и не очень связей между частями. Жуть. Между тем, использовать операционные системы не очень хотелось.
За год работы в ADL я всё же выработал для себя достаточно удобное представление кода в проекте.

Основные принципы вполне очевидны и широко используются:
- Инкапсуляция. Все модули сами по себе, они интроверты. Как и что они делают - это их личное дело. Общаемся только через предоставленные ими функции. Никаких глобальных переменных а ля extern uint8_t dmx_buffer[512];
- Не засоряем пространство имён. Всё, что не нужно остальному коду, отмечаем как static. Всякие структуры, не нужные вне модуля, объявляем в отдельных файлах, подключаемых только к нему. Опять же, никаких глобальных переменных для связи между модулями;
- Многоуровневый код. Алгоритм работает независимо от периферии и ничего о ней не знает. Общаемся только через драйвера;
- Обратные связи через callback-процедуры. Если нам надо получить извещение о наступлении какого-либо события, то скажем драйверу, какую функцию вызывать, а дальше он сам всё в нужный момент сделает. Нет причин его постоянно опрашивать.

Практически любая программа может быть разделена на три уровня:
- драйвера, которые непосредственно управляют периферией (портами, таймерами, интерфейсами типа UART, SPI и т.д.);
- драйвера внешних устройств, которые работают через драйвера периферии (уже никаких #include или не допускаем) и предоставляют доступ ко всем устройствам на плате (светодиодам, кнопкам, микросхемам и т.д.), вся завязка на номера выводов и ножки именно здесь;
- пользовательская программа, реализующая конечный алгоритм через эти два уровня драйверов.

Показываю на структуре прилагаемого проекта:
./main.c - основной код, запуск инициализации в нужном порядке, главный цикл;
./drivers.c - инициализация драйверов периферии в нужном порядке (сначала базовые типа gpio и таймеров, потом более сложные типа spi и uart, которым gpio и таймеры могут быть нужны);
./bsp.c - инициализация драйверов внешних устройств, в данном случае драйвера светодиодов и кнопки;
./drivers/system.c - включение/выключение прерываний;
./drivers/systick.c - системный таймер. С заданной периодичностью может вызывать функции;
./drivers/gpio.c - драйвер портов ввода/вывода, позволяет настраивать как вход, выход, задавать альтернативную функцию (для других драйверов), задавать уровень на ножке и считывать её состояние;
./bsp/led.c - драйвер светодиодов. Работает через gpio.c и знает только, что светодиоды сидят на порту D и выводах 12-15. Его задача - предоставить доступ к светодиодам по независимым от платы номерам: от 0 до 3. Включать их и выключать по требованию основного алгоритма. При этом наличие или отсутствие отдельных светодиодов никак не повлияет на работу алгоритма в целом;
./bsp/button.c - драйвер кнопки. Периодический опрос и фиксация нажатия;
./main/test.c - тестовая программа. Моргает светодиодом с частотой 10 Гц и по нажатию на кнопку меняет текущий светодиод.

С CMSIS общаются только файлы, находящиеся в папке drivers. Остальные даже не знают, на каком контроллере они работают. И при сохранении интерфейса драйверов код можно перенести, например, на LPC23xx. Собственно, я проделал обратное. Почти все эти интерфейсы таймеров и GPIO взяты из проекта под LPC2368, а ранее из проекта под atmega1280.

В общем-то тут всё понятно. Из интересного есть только таймер. Так как множество процессов в мире микроконтроллеров являются периодическими (моргание светодиодом, опрос датчиков, перерисовка экрана, динамическая индикация) логично прийти к тому, что надо сделать механизм для периодического вызова отдельных функций.

Минимальный интерфейс имеет всего две функции:

// Запуск таймера с заданной частотой. Частота, впрочем, может быть фиксированной внутри модуля
void timer_Init(uint32_t Frequency);

// Добавление в планировщик функции, которая будет вызываться с заданной частотой
void timer_AddFunction(uint16_t Frequency, void * Handler);

Всё. Когда таймер отсчитает нужный интервал, он его сбросит для начала нового отсчёта и вызовет функцию Handler.
Раньше функция вызывалась прямо из прерывания, но я посчитал, что в большинстве случаев это нерационально: функции могут быть достаточно продолжительными, а прерывания надолго глушить не хочется. Потому в прерывании просто устанавливается флаг, а проверяется он, и вызываются обработчики в отдельной функции, которая должна быть в главном цикле:

while(1)
{
	timer_Main(); // Оттуда-то всё и вызывается
}

Такой подход ещё и исключает конфликты, связанные с порядком доступа к памяти, которые могут возникнуть, если вызывать напрямую из прерывания.
Между разными контроллерами различия только в запуске таймера и в обработчике прерывания.
Сам таймер устроен примерно так:

// Количество обработчиков максимальное
#define TIMER_HANDLERS    10

typedef struct 
{
	void  (* Handler)(void);
	uint16_t Countdown;
	uint16_t Reload;
    
	// Запущено
	bool     Run;
	// Сработало
	bool     Fired;
} THandlers;

// Функции, кои будут вызываться
THandlers Handlers[TIMER_HANDLERS];
uint32_t  TimerFrequency;

void SysTick_Handler(void)
{
    int i;
    
	for(i = 0; i < TIMER_HANDLERS; i++)
	{
		if(Handlers[i].Run)
		{
			if(--Handlers[i].Countdown == 0)
			{
				Handlers[i].Countdown = Handlers[i].Reload;
		
				// Запишем, что сработало
				Handlers[i].Fired = true;
			}
		}
	}
}

// Запуск таймера с заданной частотой
void timer_Init(uint32_t Frequency)
{
    if(!Frequency) return;
    
    // Сбросим параметры
    TimerFrequency = Frequency;
    memset(&Handlers[0], 0, sizeof(Handlers));
    
    // Настройка частоты
    // По умолчанию на SysTick Timer идёт частота, меньшая, чем системная в 8 раз
    SysTick_Config(SystemCoreClock / Frequency / 8);
    
    // Разрешение прерывания
    NVIC_EnableIRQ(SysTick_IRQn);
}

// Добавить функцию в список вызова, Handler будет вызываться с заданной частотой
void timer_AddFunction(uint16_t Frequency, void * Handler)
{
	int i;
	
	for(i = 0; i < TIMER_HANDLERS; i++)
	{
		// Найдём пустой слот
		if(!Handlers[i].Handler)
		{
			// Обработчик, частота опроса
			Handlers[i].Run       =  true;
			Handlers[i].Fired     =  false;
			Handlers[i].Handler   = (void (*)(void))Handler;
			Handlers[i].Reload    = (TimerFrequency / Frequency);
			Handlers[i].Countdown =  Handlers[i].Reload;
			
			break;
		}
	}
}

void timer_Main(void)
{
    int i;
	
	for(i = 0; i < TIMER_HANDLERS; i++)
	{
        // Если сработало - вызовем.
        if(Handlers[i].Fired)
        {
            Handlers[i].Fired = false;
            Handlers[i].Handler();
        }
    }
}

Использование тоже не отличается сложностью.
В прилагаемом примере моргает с частотой 10 Гц светодиод. При нажатии кнопки моргать будет следующий. Если кнопку не отпускать, он так и будет бегать по кругу.
Весь алгоритм работы представлен всего двумя функциями:

static bool State = false;
static int  Index = 0;

// Периодически вызываемая функция, моргание
static void test_onTimer(void)
{
    if(State)
    {
        led_On(Index);
    }
    else
    {
        led_Off(Index);
    }
    
    // Сменим состояние
    State = !State;
}

// Сменим номер светодиода по нажатию
static void test_onKey(uint8_t Button)
{
    // Погасим светодиод текущий
    led_Off(Index);
    
    // Выберем следующий номер
    Index++;
    Index &= 0x03;
    
    // Пусть и следующую итерацию он светится
    State = true;
    
    // зажгём следующий
    led_Off(Index);
}

// Запуск тестовой программы
void test_Init(void)
{
    // Функция test_onTimer будет вызываться с частотой 10 Гц
    timer_AddFunction(10, &test_onTimer);
    
    // Обработчик нажатия на кнопку
    button_SetHandler(&test_onKey);
}

Каждый модуль может запустить такие процессики для контроля своего состояния. Светодиоды могут моргать. Экран может перерисовываться. Датчики могут опрашиваться.
А остальной код и знать об этом не будет. Это не его дело, в конце-концов.

Точно так же надо делать и всё остальное. Например, кнопки. Не дело главной программы фильтровать дребезг и прочую ерунду. Она только должна сказать: при нажатии кнопки вызови этот обработчик. А драйвер кнопок уже отфильтрует дребезг, зафиксирует нажатие, и при долгом нажатии сможет периодически вызывать обработчик.
И даже если вдруг кнопки станут абсолютно другими: сенсорными, например, или появится микруха, которая эти кнопки обслуживать будет по I2C, то основная программа от этого не изменится! Изменится только сам файл button.c.

Ну и в любом случае приятно, когда алгоритм не загромождён всякими не относящимися к его задаче проверками.

Суть изоляции алгоритма от физической привязки к номерам выводов:

#define LED_COUNT 4

typedef struct
{
    TPort   Port;
    uint8_t Pin;
} TPin;

// Светодиоды сидят на порту D, выводах 12-15.
TPin Leds[LED_COUNT] = { {PORTD, 12}, {PORTD, 13}, {PORTD, 14}, {PORTD, 15} };

// Инициализация драйвера светодиодов
void led_Init(void)
{
    int i;
    
    for(i = 0; i < LED_COUNT; i++) gpio_DigitalOutput(Leds[i].Port, Leds[i].Pin);
}
    
// Включить светодиод по его номеру
void led_On(uint8_t Index)
{
    if(Index >= LED_COUNT) return;
    
    gpio_HighLevel(Leds[Index].Port, Leds[Index].Pin);
}
    
// Выключить светодиод по его номеру
void led_Off(uint8_t Index)
{
    if(Index >= LED_COUNT) return;
    
    gpio_LowLevel(Leds[Index].Port, Leds[Index].Pin);
}

Если светодиод куда-то переедет, то будет достаточно поменять всего три символа, чтобы всё снова заработало.
Да и led_On(LED_LEFT) куда как понятнее, чем gpio_HighLevel(PORTD, 12) или GPIOD->BSRR = GPIO_BSRR_BS_12.

UPD от 14.05.2013: я в итоге решил, что передавать указатель на структуру, в которой указан номер порта и вывода логичнее и нагляднее:

typedef enum { PA = 0, PB = 1, PC = 2, PD = 3, PE = 4} TPort;

typedef struct
{
    TPort   Port;
    uint8_t Pin;
} TPin;

...

static const TPin SCK = { PA, 0 };
static const TPin MOSI = { PA, 1 };

{
    // Даже писать не надо, что тут происходит
    gpio_HighLevel(&SCK);
    gpio_LowLewel(&SCK);
}

Интересные файлы:
gpio.c
systick.c
led.c
button.c
test.c

Проект целиком.

<< Предыдущее Следующее >>

@темы: arm, программизмы, электроника, stm32f4discovery, stm32

Comments

[Гость]

Есть ли привязка таймеров к портам ввода вывода на stm32?

[teplofizik]

Гость, в аком плане привязка? Если про ШИМ/энкодер/захват и подобное, то да, есть. Её в даташите поглядеть можно. В ф4 она очень удобно расписана на 50х страниах. Там по 2-3 варианта для каждого канала таймера.

[Гость]

спасибо и правда нашел)

[teplofizik]

Гость, и хорошо

[Гость]

Добрый день! Пробывал запустить на STM32F103ZE останавливается на прерывании NVIC_EnableIRQ(SysTick_IRQn);, я так понял, что в 103 нет такого прерывания? Как обойти эту проблему?

[teplofizik]

Гость, там прерывание есть, а вот NVIC такой настройки не требует.

[Гость]

Как будет выглядеть функция для 103?
// Запуск таймера с заданной частотой
void timer_Init(uint32_t Frequency)
{
if(!Frequency) return;

// Сбросим параметры
TimerFrequency = Frequency;
memset(&Handlers[0], 0, sizeof(Handlers));

// Настройка частоты
// По умолчанию на SysTick Timer идёт частота, меньшая, чем системная
SysTick_Config(SystemCoreClock / Frequency / 4);

// Разрешение прерывания
NVIC_EnableIRQ(SysTick_IRQn);
}
Я только осваиваю stm32 и С...)

[teplofizik]

Так же, но без NVIC_EnableIRQ.