C++ для микроконтроллеров

[dm37]

Хочу поделиться наработками по программированию микроконтроллеров на языке C++.

Внутри:
- пример с динамической индикацией (исходники + proteus)
- пример с LCD на HD44780 (исходники + proteus)
- небольшое описание

Микроконтроллеры ATtiny2313 и ATmega32, компилятор IAR

Всё находится здесь
https://ru.files.fm/u/a2sfccuf#/list/,файлuC_cpp.7z

[pyzhman]

Ахтунг! "Небезопасный источник."

[dm37]

Чем заходите?
Касперский определяет как "Безопасный веб-сайт (по данным Kaspersky Security Network)"

Файл прикрепил к сообщению

Вложения

uC_cpp.7z

(662.08 KiB) Скачиваний: 288

[arkhnchul]

не очень понятно пока, зачем. Классы со сплошь public static inline void методами - имхо маленько не то, ради чего стоит использовать плюсы.

[Reflector]

arkhnchul писал(а):

не очень понятно пока, зачем. Классы со сплошь public static inline void методами - имхо маленько не то, ради чего стоит использовать плюсы.

На самом деле все не так плохо, в эмбедде большинство методов и должны быть static и часто inline, хотя непонятно зачем автор при помощи #pragma явно заставляет компилятор инлайнить методы там, где они и так будут инлайниться согласно правилам языка. Вот если бы тут все методы были статические и не использовались шаблоны, тогда да, можно было бы спокойно заменить классы неймспейсами ничего особо не потеряв...

[dm37]

>> имхо маленько не то, ради чего стоит использовать плюсы
К сожалению C++ для ПК и для микроконтроллеров отличается. Нельзя многое из ПК использовать в микроконтроллерах - микроконтроллер не справиться, ну и стиль программирования для микроконтроллера не имеет смысла для ПК.
>> непонятно зачем автор при помощи #pragma явно заставляет компилятор инлайнить методы
наличие ключевого слова inline не означает, что компилятор обязательно будет инлайнить метод (по крайней мере в IAR), для принудительного "инлайнинга" необходимо использовать #pragma. Во многих местах можно #pragma убрать и ничего не измениться, но не везде (можете по экспериментировать). Для себя решил, что если метод должен инлайнится, то наличие #pragma обязательно (в основном это касается прерываний).

[Reflector]

dm37 писал(а):

наличие ключевого слова inline не означает, что компилятор обязательно будет инлайнить метод (по крайней мере в IAR), для принудительного "инлайнинга" необходимо использовать #pragma. Во многих местах можно #pragma убрать и ничего не измениться, но не везде (можете по экспериментировать). Для себя решил, что если метод должен инлайнится, то наличие #pragma обязательно (в основном это касается прерываний).

А речь не про наличие inline, а про случаи типа таких:

Код:

class TCounter
{
public:
        #pragma inline = forced
        static inline void Init(void)
        {
            Recount = VALUE;
            FCounter::Reset();
        }
...
};

Тут не нужен ни inline, ни #pragma inline, в стандарте по этому поводу говорится следующее: A member function may be defined in its class definition, in which case it is an inline member function, or it may be defined outside of its class definition if it has already been declared but not defined in its class definition.

И почему этот метод принимает void?

[dm37]

начну с "почему void".
Для определения переменной Recount необходимо указать тип. Тип для Recount определяется на стадии компиляции в шаблоне в зависимости от значения (у меня это 1000, т.е тип будет uint16_t).

Код:

typedef STATIC_TYPE_UNSIGNED_VALUE(Value) T;
static volatile T Recount;

Мне (по условию) не требовалось менять значение инициализации (Если алгоритм требует, то конечно можно и передать значение). Тогда будет так:

Код:

static inline void Init(T value )
{
    Recount = value;
    FCounter::Reset();
}

но тогда входное значение будет (должно) иметь тоже тип uint16_t. Если сразу задать тип для Recount, то придётся делать класс под каждый тип, что не целесообразно.

Ну и отсюда почему inline. Т.к. это шаблонный класс, и инициализация предполагалась только один раз поэтому код решил инлайнить, чтобы компилятор не оформил это в вызов метода.

Добавлено after 13 minutes 7 seconds:
вообще всё что связано с inline появилось после того как начал заниматься прерываниями в C++.

[Reflector]

Dm37, я говорю совершенно о другом В С было так:

Код:

void func(void);

В С++ стало так:

Код:

void func();

Ты пишешь на С++, но местами как будто на С. Очень часто когда я вижу подобный код с ним в комплекте еще идут typedef struct и прочие пережитки чистого С.

Ну и отсюда почему inline. Т.к. это шаблонный класс, и инициализация предполагалась только один раз поэтому код решил инлайнить, чтобы компилятор не оформил это в вызов метода.

Еще раз повторяю, любой метод определенный в теле класса неявно является встроенным, т.е. инлайнится согласно правилам самого языка. Конечно можно явно прописать и inline со всякими прагмами, но это не имеет никакого значения.

[dm37]

>> В С++ стало так:
я это знаю, это не нарушает синтаксис

>> struct
в любом учебнике по C++ struct показан как public класс

по поводу inline, C++ не работает с прерываниями, это надстройка embedded. Поэтому корректной работы от компилятора ждать не приходится, надо ему помочь (ещё раз повторюсь, что сначала не было inline, он появился только после работы с прерываниями, когда результат был отрицательный)

Я ждал замечаний не по поводу синтаксиса (что пока достаточно спорно), а по организации программы, ошибкам, рекомендации

[pokk]

Добрый день, с С++ совсем не знаком по этому и пишу, подскажите в нем есть более удобные способы/методы распараллеливания задач(на конечных автоматах), ну скажем вот в функции инициализации LCD,

Код:

        static void Init(void)
        {
            InitPorts();
            DELAY_MS(15);
            SetModeCmd();
            WriteCfg(0x30);
            DELAY_MS(4.1);
            WriteCfg(0x30);
            DELAY_US(100);
            WriteCfg(0x30);
            DELAY_US(100);
            WriteCfg(0x20);
            DELAY_US(100);
            Write(0x28);
            DELAY_US(40);
            Write(0x08);
            DELAY_US(40);
            Write(0x0C);
            DELAY_US(40);
            Write(0x01);
            DELAY_MS(1.6);
            Write(0x06);
      }

Что бы вместо DELAY_MS происходил выход в майн, и проход по всем остальным задачам.
В общем есть ли там более удобное использование switch case ?

[Ivanoff-iv]

да ради бога, заходи по прерыванию таймера, а там уже свитч-кейсом выбирай какую часть кода выполнять.

[ARV]

Что бы вместо DELAY_MS происходил выход в майн, и проход по всем остальным задачам

как велико ваше желание выстрелить себе в ногу? какие-такие задачи требуют от вас этого самого "распараллеливания"? вы на 100% уверены, что это необходимо?

самый лучший совет, который я могу вам дать, повторяет суть принципа бритвы Оккама: не делай то, без чего можно обойтись.

[Ivanoff-iv]

DELAY_US нет смысла переделывать, а вот DELAY_MS особо если с большими цифрами, да работающий внутри прерывания вполне может придать контроллеру некоторую ... туповатовть. (динам. индикация может подвисать, нажатие кнопки (не на INTе) может оказаться пропущенным, "собака" не кормлена...

[pokk]

Да на все 100% уверен что надо, даже функцию инициализацию надо так как, весь маин состоит из параллельных частей, а индикатор может повисать,из за внешних помех, так что приходится его передергивать(пере инициализировать).