Предыдущая публикация: «Очередная статья — STM32 для начинающих»
В предыдущей статье создали класс для работы с портами ввода-вывода, проверили. И что дальше? Зачем это все запихивать в класс?
Возьмем для примера простенький опрос кнопок:
Для этой схемы в простейшем случае опрос будет выглядеть так:
Но, если в схеме поменять порты, подсоединенные к кнопкам, то придется менять и функцию опроса. И так в каждом проекте. Это не всегда удобно. Хочется один раз написать, протестировать и пользоваться.
Перепишем эту функцию под ранее созданный класс:
Остается в главной программе инициализировать порты и передать в функцию:
А теперь представим, законились контроллеры серии f10x, но есть куча f030. По производительности и количеству выводов хватает, только надо хедер поменять для функции GetKey или воспользоваться… #ifdef. Сделать глобальный заголовочный файл, в котором прописть тип используемого контроллера (что то типа #define STM32F030) и нагородить кучу дефайнов. Нет, не для этого создавались языки высокого уровня, что бы путаться в макросах!
Пойдем другой дорогой. Создадим класс, в котором перечислим виртуальные методы, необходимые нам по жизни для работы с портами:
(те методы, которые приравнены 0, должны быть определены в производном классе!)
и будем его использовать как базовый в классе Pin:
тогда функция GetKey чуть изменится:
Теперь нам любой контроллер нипочем! Даже если это шинный расширитель, работающий по SPI или I2C. Последовательные интерфейсы рассмотрим в следующих статьях.
Дальше надо оформить класс для работы с системным таймером. Но это уже в следующей публикации.
И как этим пользоваться?
В предыдущей статье создали класс для работы с портами ввода-вывода, проверили. И что дальше? Зачем это все запихивать в класс?
Возьмем для примера простенький опрос кнопок:
Для этой схемы в простейшем случае опрос будет выглядеть так:
int GetKey()
{
volatile uint32_t* addr = reinterpret_cast<uint32_t*>(GPIOA_IDR);
uint32_t ret_val = *addr;
return ret_val & 0x0F;
}
Но, если в схеме поменять порты, подсоединенные к кнопкам, то придется менять и функцию опроса. И так в каждом проекте. Это не всегда удобно. Хочется один раз написать, протестировать и пользоваться.
Перепишем эту функцию под ранее созданный класс:
int GetKey(Pin* p0, Pin* p1, Pin* p2, Pin* p3)
{
int ret_val = p0->Get() + (p1->Get() << 1) + (p2->Get() << 2) + (p3->Get() << 3);
return ret_val;
}
Остается в главной программе инициализировать порты и передать в функцию:
...
using namespace STM32F1xx;
Pin key0('a', 0);
Pin key1('a', 1);
Pin key2('a', 2);
Pin key3('a', 3);
...
int main()
{
key0.ModeInput();
key1.ModeInput();
key2.ModeInput();
key3.ModeInput();
int key_code = GetKey(&key0, &key1, &key2, &key3);
...
return 0;
}
А где же интерфейсы?
А теперь представим, законились контроллеры серии f10x, но есть куча f030. По производительности и количеству выводов хватает, только надо хедер поменять для функции GetKey или воспользоваться… #ifdef. Сделать глобальный заголовочный файл, в котором прописть тип используемого контроллера (что то типа #define STM32F030) и нагородить кучу дефайнов. Нет, не для этого создавались языки высокого уровня, что бы путаться в макросах!
Пойдем другой дорогой. Создадим класс, в котором перечислим виртуальные методы, необходимые нам по жизни для работы с портами:
iPin.h
#pragma once
class iPin
{
public:
virtual void ModeInput() = 0;
virtual void ModeAnalogInput() = 0;
virtual void ModeInputPulled() = 0;
virtual void ModeOutput() = 0;
virtual void ModeOutputOpenDrain() = 0;
virtual void Set(bool st) = 0;
virtual bool Get() = 0;
virtual void Reverse() { Set(!Get());}
void On() { Set(true); }
void Off() { Set(false); }
};
(те методы, которые приравнены 0, должны быть определены в производном классе!)
и будем его использовать как базовый в классе Pin:
...
#include "iPin.h"
...
class Pin : public iPin
...
тогда функция GetKey чуть изменится:
int GetKey(iPin* p0, iPin* p1, iPin* p2, iPin* p3)
{
int ret_val = p0->Get() + (p1->Get() << 1) + (p2->Get() << 2) + (p3->Get() << 3);
return ret_val;
}
Теперь нам любой контроллер нипочем! Даже если это шинный расширитель, работающий по SPI или I2C. Последовательные интерфейсы рассмотрим в следующих статьях.
И что дальше?
Дальше надо оформить класс для работы с системным таймером. Но это уже в следующей публикации.