Как вы заменяете удобство классов С++ на СИ, при программировании под МК

@Elesh_Makfa · Регистрация: 10.02.2024

Студворк — интернет-сервис помощи студентам

Всем доброго дня.
*(Хотя, кажется в этой ветке сидит одна небольшая группа людей, которые дают ответы на все мои вопросы. Спасибо вам, большое!)

-------------------------------------

В общем, ситуация такая: Начинал я программировать на с++ в arduino ide. Привык к работе с классами их удобству. Но, чтобы отстыковаться от arduino в принципе, начал изучение и потихоньку заменял ардуиовский фукнционал сишным кодом. Все получалось хорошо, пока не дошел до темы классов. До этого думал, что классы легко заменяются стурктурами и будут так же удобны в использовании, да еще и более эффективны.

Но Оказалось, что эффективность теряется, когда, в стремлении за удобством, я каждую функцию "класса" добавляю через указатель в структуру, чтобы было удобно использовать через точку

C
1
structObj.func()

. В этом случае в опертивку будут еще и помещяться указатели фукнций на каждый экземпляр структуры, а это капец жирно.

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

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

--------------------------------------

Проекты у меня большие, разбиваю их на разные файлы по ~300 строк кода, каждый файл это какой-то самостоятельный модуль и реализовывать его через класс, одно удовольствие. В проекте обучно около 10 таких отдельных модулей. Т.е. программа большая.

Но я теперь в тупике и не знаю что делать. Без классов на с++ программа станет сильно менее читаемой. А оставаясь на си, я вроде как теряю какие-то приемущества в низкоуровневости и быстродейсвии СИ на МК.

И в итоге, вопрос: как вы, опытные разработчики МК, решаете этот вопрос? Какие "парадигмы" используете при написании больших программ на СИ? Или вообще на СИ переходит нет прям какой-то необходимости? Или есть?

В общем, прошу, высказать, ваше мнение.

--------------------------------------

*Так же на вопрос "зачем мне вообще использовать классы на мк". У меня кажды программа сильно похожа на предыдущую, только меняется количство подключенной переферии. А сейчас я сделал такую модель , что есть 1 центральный контроллер, и он может общаться с любым количеством дочерних. На каждом дочернем одна программа, которая готова, по команде центрального, создать любой из нужных мне объектов и повесить на нужный пин. Такми образом я имею неограниченое число универсальных пинов, а на всех дочерних платах одинаковй код. И такая универсальность очень тесно завязана на классах. Вот именно, при мыслях о переходе с классов на структуры у меня и возникли проблемы.

@Alex1126 · 08.01.2025, 23:10

Сообщение от COKPOWEHEU

Еще как! В моих библиотеках они активно используются:

у меня самые популярные это такие:

C
1
2
3
#define   SETBIT(reg, bit)          reg |= (1<<bit)           
#define   CLRBIT(reg, bit)       reg &= (~(1<<bit))
#define   INVBIT(reg, bit)          reg ^= (1<<bit)

ну и т.д.

@Rius · 08.01.2025, 23:15

А у нас за такое по рукам бьют и pr отклоняют.

@Alex1126 · 08.01.2025, 23:18

А почему? Помоему очень повышает читаемость кода

@Rius · 08.01.2025, 23:40

Помимо этого, в аргументы можно передать всякое и компилятор не поперхнётся.
И только потом вы когда-нибудь обнаружите, что вот у того регистра такого-то бита и в помине не было, опечатка, которую никто не заметил, а компилятор не имел возможности отследить.
Или что данные разных типов были приведены для совершения операции к какому-то типу по разумению компилятора и получился нежданчик. Но не при написании, а при эксплуатации.
Это потенциальный баг.

@COKPOWEHEU · 08.01.2025, 23:43

Сообщение от Alex1126

у меня самые популярные это такие:

А с какой целью ухудшаете читаемость кода? Если уж оборачивать куда более наглядные &=,|= в макросы, то хоть там, где это имеет смысл:

C
1
PM_BITMASK(TIM3->CHCTLR1, TIM_OC1M, 0b110); //В регистре TIM3->CHCTLR1 стирает биты по маске TIM_OC1M и выставляет вместо них соответственно сдвинутые 0b110

@Alex1126 · 08.01.2025, 23:43

Ну так используя первоначальную конструкцию

C
1
reg |= (1<<bit)

так же подставить всякое и так же потом только обнаружить что у этого регистра такого бита не было никогда...

@COKPOWEHEU · 08.01.2025, 23:45

Сообщение от Rius

И только потом вы когда-нибудь обнаружите, что вот у того регистра такого-то бита и в помине не было

От этого по большому счету не застрахуешься. Разве что весь заголовочный файл переписывать.

@Rius · 08.01.2025, 23:47

Исходные операции тоже, да.
В этом месте и рулит c++.

@Alex1126 · 08.01.2025, 23:49

Сообщение от COKPOWEHEU

А с какой целью ухудшаете читаемость кода?

Как правило при настройке перефирии я не использую эти макросы, там я пишу полностью

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    // Установка скорости обмена
    UBRRH = (F_CPU/(16*UART_BAUD)-1) >> 8;
    UBRRL = (F_CPU/(16*UART_BAUD)-1);
 
    UCSRB = 
        (1<<RXCIE) |    //RXCIE-разрешение прерывания по завершению приёма
        (1<<TXCIE) |    //TXCIE-разрешение прерывания по завершению передачи
        (0<<UDRIE) |    //UDRIE-разрешение прерывания при очистке регистра данных UDR
        (1<<RXEN) |     //RXEN-разрешение приёма
        (1<<TXEN) |     //TXEN-разрешение передачи
        (0<<UCSZ2) |    //UCSZ2-формат посылки (совместно с UCSZ1-UCSZ0 "0"-8 бит данных, "1"-9 бит данных)
        0;
    UCSRC =                 //Режим UART, 1 стоп-бит, 8 бит кадр, без паритета
        //(1<<UMSEL01) |    //UMSEL=0- асинхронный режим работы USART
        //(1<<UMSEL00) |
        //(1<<UPM01) |      //UPM1-UPM0=00 без контроля чётн/нечётн
        //(1<<UPM00) |
        //(1<<USBS0) |      //USBS0=0 - 1 стоп-бит
        //(1<<UCSZ02) |
        (1<<UCSZ1) |    //формат посылки UCSZ2-UCSZ0=0b011 - 8 бит в кадре
        (1<<UCSZ0) |
        (0<<UCPOL) |    //UCPOL - для асинхронного режима ДОЛЖЕН быть сброшен в 0
        0;

а вот когда работаю с пинами то там да (и то стараюсь обернуть в более понятные косструкции):

C
1
2
3
4
#define CLK_ON  SETBIT(RG_PORT,CLK)
#define CLK_OFF CLRBIT(RG_PORT,CLK)
#define ZD_ON   SETBIT(RG_PORT,ZD)
#define ZD_OFF  CLRBIT(RG_PORT,ZD)

@COKPOWEHEU · 08.01.2025, 23:50

И как же он рулит? Вот есть запись RCC->APB1PCENR |= RCC_IOPAEN;. Как ваш хваленый С++ узнает, что IOPAEN относится не к APB1, а к APB2? В хедерах он описан просто как #define RCC_IOPAEN ((uint32_t)0x00000004). Предлагаете переписать 5000 строк однообразных дефайнов? Вот уж удобство так удобство.

@Rius · 08.01.2025, 23:56

Предлагаете переписать 5000 строк однообразных дефайнов? Вот уж удобство так удобство

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

@COKPOWEHEU · 08.01.2025, 23:57

Сообщение от Alex1126

а вот когда работаю с пинами то там да (и то стараюсь обернуть в более понятные косструкции):

А теперь представьте, что один светодиод у вас висит на PA3, второй на PB7, третий на PC1. А на другой отладочной плате их было удобнее развести на PB0, PB4, PB2. Не обеспечивают ваши макросы должной гибкости.

Сообщение от COKPOWEHEU

Вот есть запись RCC->APB1PCENR |= RCC_IOPAEN;

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

@Rius · 08.01.2025, 23:59

Компания нанавистников cube, hal и прочих библиотек, во главе с эдди, чтоб ему вечно в бане сидеть, годами втирает, что тысячи строк готового кода от производителя - отстой. Так что всё в русле.

@COKPOWEHEU · 09.01.2025, 00:04

Сообщение от Rius

Ну у вас же есть файлы описания регистров от производителя чипа? Парсите их и генерите код.

То есть все-таки мартышкин труд. Производитель уже сам написал заголовочные файлы, в которых эти биты описаны. Вы же хотите эту работу повторить, но руками и на основе текстового описания, которое менее надежно. Хедер-то хотя бы тестировался, а вот ошибки в .svd ни на что не влияют, и вполне могут быть пропущены. Не говоря уж о том, что не для всех камней эти svd вообще есть.

Добавлено через 2 минуты

Сообщение от Rius

тысячи строк готового кода от производителя - отстой.

С тем, что исполняемый код у них отстой, вряд ли кто будет спорить. Но в константах-то где можно накосячить?! Хотя умудряются, да. То два независимых 32-битных регистра в одну 64-битную переменную склеят (а способов атомарного доступа не завезут), то наоборот, то половину битов описать забудут.

@Rius · 09.01.2025, 00:06

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

@Alex1126 · 09.01.2025, 00:06

Сообщение от COKPOWEHEU

А теперь представьте, что один светодиод у вас висит на PA3, второй на PB7, третий на PC1. А на другой отладочной плате их было удобнее развести на PB0, PB4, PB2. Не обеспечивают ваши макросы должной гибкости.

Ну так я же привел код. Вот более полный кусок:

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#define LOW     CHKBIT(PIND,PD2)
#define HI      CHKBIT(PIND,PD3)
 
#define LOW_BUTT    PA0
#define HI_BUTT     PA1
#define BUTT_PORT   PINA
 
#define BUTT_LOW_PRESS  CHKBIT(BUTT_PORT,LOW_BUTT)
#define BUTT_HI_PRESS   CHKBIT(BUTT_PORT,HI_BUTT)
 
#define RG_PORT PORTB
#define DT  PB2
#define CLK PB1
#define ZD  PB0
 
#define CLK_ON  SETBIT(RG_PORT,CLK)
#define CLK_OFF CLRBIT(RG_PORT,CLK)
#define ZD_ON   SETBIT(RG_PORT,ZD)
#define ZD_OFF  CLRBIT(RG_PORT,ZD)

Порты и пины меняются в одном месте под конкретный проект, конкретную плату.

@Rius · 09.01.2025, 00:06

Дубль

@Alex1126 · 09.01.2025, 00:06

Сообщение от COKPOWEHEU

А теперь представьте, что один светодиод у вас висит на PA3, второй на PB7, третий на PC1. А на другой отладочной плате их было удобнее развести на PB0, PB4, PB2. Не обеспечивают ваши макросы должной гибкости.

Ну так я же привел код. Вот более полный кусок:

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#define LOW     CHKBIT(PIND,PD2)
#define HI      CHKBIT(PIND,PD3)
 
#define LOW_BUTT    PA0
#define HI_BUTT     PA1
#define BUTT_PORT   PINA
 
#define BUTT_LOW_PRESS  CHKBIT(BUTT_PORT,LOW_BUTT)
#define BUTT_HI_PRESS   CHKBIT(BUTT_PORT,HI_BUTT)
 
#define RG_PORT PORTB
#define DT  PB2
#define CLK PB1
#define ZD  PB0
 
#define CLK_ON  SETBIT(RG_PORT,CLK)
#define CLK_OFF CLRBIT(RG_PORT,CLK)
#define ZD_ON   SETBIT(RG_PORT,ZD)
#define ZD_OFF  CLRBIT(RG_PORT,ZD)

Порты и пины меняются в одном месте под конкретный проект, конкретную плату.

@COKPOWEHEU · 09.01.2025, 00:13

Сообщение от Rius

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

А у нас - чтобы контроллер работал так, как мы хотим. Предсказуемо, просто, эффективно и читаемо.

Сообщение от Alex1126

Ну так я же привел код. Вот более полный кусок:

А теперь перенесите CLK на PC6.
Для сравнения, как я делал давным-давно, когда еще активно писал под AVR:

C
1
2
3
4
5
6
7
#define LCD_RST     D,7
#define LCD_CE      B,0
#define LCD_DC      B,4
...
DDR_1(LCD_RST); PORT_1(LCD_RST);
DDR_1(LCD_CE); PORT_1(LCD_CE);
DDR_1(LCD_DC); PORT_1(LCD_DC);

@Rius · 09.01.2025, 00:18

COKPOWEHEU, у нас тоже.
Разница в том, что с макросами вы оставляете место для будущих ошибок. Но вам можно.
А нам нельзя. Однажды обнаруженное никогда не должно повториться.

Новые блоги и статьи Все статьи Все блоги /
Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия	Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .	Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .
Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .	У нас сейчас поговорку "Опять 25" нужно переделать на "Опять +35". kumehtar 04.08.2026 С ностальгией вспоминаю времена моего детства, когда у нас и правда +25 - была максимальная температура летом. Раньше +25 °C реально казались вершиной жары, когда можно было весь день пропадать на. . .	Как ИИ начал спорить и врать (возможно почуяв опасность для себя от индустрии - уход от электроники). Hrethgir 04.08.2026 Недельный диалог, на фоне событий с НПЗ. Да, из спирта можно получать бензин, и это не сложно. Но потом в схеме я решил избавиться от насоса, при этом полностью сделав контроль подачи спирта в. . .	Термопринтер QR701 Argus19 03.08.2026 Термопринтер QR701 Купил два термопринтера QR701. На сэлф-тесте написано: Language: PC936 (GB18030). Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .

@Rius 13407 / 7860 / 1701 Регистрация: 25.05.2015 Сообщений: 23,873 Записей в блоге: 14
	08.01.2025, 23:15
	А у нас за такое по рукам бьют и pr отклоняют. 0

@Alex1126 451 / 176 / 29 Регистрация: 12.12.2020 Сообщений: 1,367
	08.01.2025, 23:18
	А почему? Помоему очень повышает читаемость кода 0

@Rius 13407 / 7860 / 1701 Регистрация: 25.05.2015 Сообщений: 23,873 Записей в блоге: 14
	08.01.2025, 23:40
	Помимо этого, в аргументы можно передать всякое и компилятор не поперхнётся. И только потом вы когда-нибудь обнаружите, что вот у того регистра такого-то бита и в помине не было, опечатка, которую никто не заметил, а компилятор не имел возможности отследить. Или что данные разных типов были приведены для совершения операции к какому-то типу по разумению компилятора и получился нежданчик. Но не при написании, а при эксплуатации. Это потенциальный баг. 0

@Rius 13407 / 7860 / 1701 Регистрация: 25.05.2015 Сообщений: 23,873 Записей в блоге: 14
	08.01.2025, 23:47
	Исходные операции тоже, да. В этом месте и рулит c++. 0

@COKPOWEHEU 4147 / 2725 / 433 Регистрация: 09.09.2017 Сообщений: 12,074
	08.01.2025, 23:50
	И как же он рулит? Вот есть запись `RCC->APB1PCENR \|= RCC_IOPAEN;`. Как ваш хваленый С++ узнает, что IOPAEN относится не к APB1, а к APB2? В хедерах он описан просто как `#define RCC_IOPAEN ((uint32_t)0x00000004)`. Предлагаете переписать 5000 строк однообразных дефайнов? Вот уж удобство так удобство. 0

@Rius 13407 / 7860 / 1701 Регистрация: 25.05.2015 Сообщений: 23,873 Записей в блоге: 14
	08.01.2025, 23:59
	Компания нанавистников cube, hal и прочих библиотек, во главе с эдди, чтоб ему вечно в бане сидеть, годами втирает, что тысячи строк готового кода от производителя - отстой. Так что всё в русле. 0

@Rius 13407 / 7860 / 1701 Регистрация: 25.05.2015 Сообщений: 23,873 Записей в блоге: 14
	09.01.2025, 00:06
	COKPOWEHEU, то есть у нас с вами всего лишь разные ценности. У нас - избежать ошибок при кодировании максимально возможной автоматизацией для минимизации ошибок от человеческого фактора. 0

@Rius 13407 / 7860 / 1701 Регистрация: 25.05.2015 Сообщений: 23,873 Записей в блоге: 14
	09.01.2025, 00:06
	Дубль 0

@Rius 13407 / 7860 / 1701 Регистрация: 25.05.2015 Сообщений: 23,873 Записей в блоге: 14
	09.01.2025, 00:18
	COKPOWEHEU, у нас тоже. Разница в том, что с макросами вы оставляете место для будущих ошибок. Но вам можно. А нам нельзя. Однажды обнаруженное никогда не должно повториться. 0