STM32 новичку в ARM что к чему

[a5021]

Хорошей идеей это будет лишь в случае, когда за работу платят построчно.

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

Сделать каждый бит объектом -- это офигенная затея.

[arkhnchul]

a5021 писал(а):

О великой пользе assert-ов можно почерпнуть из исходников HAL-а

нельзя

a5021 писал(а):

Сделать каждый бит объектом -- это офигенная затея.

вообще говоря, свойством объекта. Почему нет?

по наблюдениям, это общая болезнь эмбеддеров - думать о битах, а не о том, что они означают. Не стоит ею болеть.

[Reflector]

a5021 писал(а):

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

Я сам приводил в пример LL_DMA_Init() с десятком assert-ов, это одновременно и кривой дизайн, но и без недостатков чистого С не обошлось, т.к. подставить вместо uint32_t типы перечислений можно далеко не всегда, компилятор споткнется на первой же |, которая вернет int, а в плюсах проблему можно решить за счет перегрузки этой операции для данного типа. У меня в классе Dma три функции инициализации, по одной на каждый режим, все они принимают только те параметры, которые допустимы в данном режиме, т.е. проверок там больше, а assert всего один, проверяет не активен ли сам Dma. На HAL не похоже с какой стороны не посмотри, ни по наглядности, ни по эффективности, ни по возможности совершить ошибку.

Сделать каждый бит объектом -- это офигенная затея.

Там не один бит, есть еще биты включения CSS и Bypass, бит включения прерывания и два флага, которые можно прочитать или сбросить. Всего 11 методов.

[a5021]

arkhnchul писал(а):

нельзя

Вот это "нельзя" из первого по алфавиту файла хала:

Код:

HAL_StatusTypeDef HAL_ADC_Init(ADC_HandleTypeDef* hadc)
{
  HAL_StatusTypeDef tmp_hal_status = HAL_OK;
  uint32_t tmpCFGR1 = 0U;

  /* Check ADC handle */
  if(hadc == NULL)
  {
    return HAL_ERROR;
  }
 
  /* Check the parameters */
  assert_param(IS_ADC_ALL_INSTANCE(hadc->Instance));
  assert_param(IS_ADC_CLOCKPRESCALER(hadc->Init.ClockPrescaler));
  assert_param(IS_ADC_RESOLUTION(hadc->Init.Resolution));
  assert_param(IS_ADC_DATA_ALIGN(hadc->Init.DataAlign));
  assert_param(IS_ADC_SCAN_MODE(hadc->Init.ScanConvMode));
  assert_param(IS_FUNCTIONAL_STATE(hadc->Init.ContinuousConvMode));
  assert_param(IS_FUNCTIONAL_STATE(hadc->Init.DiscontinuousConvMode));
  assert_param(IS_ADC_EXTTRIG_EDGE(hadc->Init.ExternalTrigConvEdge));   
  assert_param(IS_ADC_EXTTRIG(hadc->Init.ExternalTrigConv));   
  assert_param(IS_FUNCTIONAL_STATE(hadc->Init.DMAContinuousRequests));
  assert_param(IS_ADC_EOC_SELECTION(hadc->Init.EOCSelection));
  assert_param(IS_ADC_OVERRUN(hadc->Init.Overrun));
  assert_param(IS_FUNCTIONAL_STATE(hadc->Init.LowPowerAutoWait));
  assert_param(IS_FUNCTIONAL_STATE(hadc->Init.LowPowerAutoPowerOff));


по наблюдениям, это общая болезнь эмбеддеров - думать о битах, а не о том, что они означают. Не стоит ею болеть.

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

Код:

             
  turn_pll_on(RCC_CFGR_PLLMUL8);  /* run MCU at 32mHz */


Без методов, инкапсуляции, полиморфизма и таинственной сущности объектно-ориентированных битов.

[arkhnchul]

a5021 писал(а):

Вот это "нельзя" из первого по алфавиту файла хала

хорошо, разжую мысль: из того, что HAL от ST - тот еще кусок этого самого, ничуть не следуют ни бесполезность assert-ов, ни бесполезность/неудобство/запутанность/большие_накладные_расходы самОй широко распространенной концепции абстрагирования от конкретной железки aka hardware abstraction layer.

a5021 писал(а):

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

вот про выделенное я и говорю. Хрен с ним с уровнем железа, пусть он сидит в недрах библиотеки HAL-а (в понимании общем, а не ST).

a5021 писал(а):

Без методов, инкапсуляции, полиморфизма и таинственной сущности объектно-ориентированных битов.

объекты - это не страшно и не больно) Если угодно, воспринимайте их как один из способов структурирования кода, сойдет. В том, что приводит Рефлектор, больше фич языка, чем ооп.

[Reflector]

a5021 писал(а):

Код:

             
  turn_pll_on(RCC_CFGR_PLLMUL8);  /* run MCU at 32mHz */


Без методов, инкапсуляции, полиморфизма и таинственной сущности объектно-ориентированных битов.

Да чего ты прицепился к ООП, убираю я класс Pll, создаю namespace Pll2, переношу туда код:

Спойлер

Код:

namespace Pll2
{
   void enable()
   {
      RCC->CR |= RCC_CR_PLLON;
      while (!(RCC->CR & RCC_CR_PLLRDY)) {}
   }

   template<PllSrc pllSrc, uint32_t mul, uint32_t prediv = 1>
   void init()
   {
      static_assert(mul >= 2 && mul <= 16, "PLL mul is out of range!");
      static_assert((pllSrc == PllSrc::HseDivPrediv && prediv >= 1 && prediv <= 16) ||
         (pllSrc == PllSrc::HsiDiv2 && prediv == 1), "PLL prediv is out of range!");

      _assert_(!isEnabled());

      uint32_t cfgr = RCC->CFGR & ~(RCC_CFGR_PLLSRC | RCC_CFGR_PLLMUL | RCC_CFGR_USBPRE);
      constexpr uint32_t baseClk = (pllSrc == PllSrc::HsiDiv2) ? HsiValue / 2 : HseValue / prediv;
      if constexpr (baseClk * mul <= 50'000'000) cfgr |= RCC_CFGR_USBPRE;
      RCC->CFGR = cfgr | uint32_t(pllSrc) | ((mul - 2) << RCC_CFGR_PLLMUL_Pos);
      if constexpr (pllSrc == PllSrc::HseDivPrediv)
      {
         RCC->CFGR2 = RCC->CFGR2 & ~RCC_CFGR2_PREDIV | (prediv - 1);
      }
      enable();
   }
}


Все, нету больше классов, хотя по-прежнему можно использовать static_assert, constexpr if и шаблонные функции. Подменяем вызов на Pll2::init(), что происходит? Ничего, по коду даже нельзя понять с классом идет работа или с namespace, а бинарник полностью идентичен и я уже говорил, что код будет как для обычной функции, но в дебаге С++ выиграет у С за счет переноса части кода на стадию компиляции.

[a5021]

arkhnchul писал(а):

из того, что HAL от ST - тот еще кусок этого самого, ничуть не следуют ни бесполезность assert-ов, ни бесполезность/неудобство/запутанность/большие_накладные_расходы самОй широко распространенной концепции абстрагирования от конкретной железки aka hardware abstraction layer.

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

В том, что приводит Рефлектор, больше фич языка, чем ооп.

То, что он приводит -- это наброски сомнительной художественной ценности. Смените компилятор и вкусите по полной.

[arkhnchul]

a5021 писал(а):

Еще как следует.

не-а. Это из - да, баянного - разряда "каждая селедка - рыба, но не каждая рыба - селедка".

a5021 писал(а):

Все упомянутые фишки -- суть придумка, как сэкономить на квалификации программистов

нет. Просто - нет, серьезно) Если надо подробнее - скажите, напишу.

a5021 писал(а):

То, что он приводит -- это наброски сомнительной художественной ценности. Смените компилятор и вкусите по полной.

вопрос компилятора вообще-то озвучивался, не? Смените его на любой, умеющий в C++17 (да, сейчас это только gcc7 - кстати, уточню, что он не является прям режущим краем капец каким новейшим, есть и gcc8, а упомянутая конструкция if constexpr была и раньше в виде нестандартного расширения gnu - но ему в затылок дышит clang, и, вероятно, появится чего-то из закрытого) - и оно соберется и будет работать.

[Ярослав555]

Мурик писал(а):

Это вовсе не

Да, еще раз извините. На работе голова забита и поделил вместо помножить.

[Reflector]

arkhnchul писал(а):

Смените его на любой, умеющий в C++17 (да, сейчас это только gcc7 - кстати, уточню, что он не является прям режущим краем капец каким новейшим, есть и gcc8, а упомянутая конструкция if constexpr была и раньше в виде нестандартного расширения gnu - но ему в затылок дышит clang, и, вероятно, появится чего-то из закрытого) - и оно соберется и будет работать.

Gcc 7 появился в VisualGDB где-то пол года назад, но еще до этого С++17 можно было попробовать в clang, в той же SES, хотя там до сих пор gcc 6. Правда они порезали С++ хедеры, сделали их общими на два компилятора, но набор самый минимальный...

[a5021]

Reflector писал(а):

Gcc 7 появился в VisualGDB где-то пол года назад, но еще до этого С++17 можно было попробовать в clang, в той же SES, хотя там до сих пор gcc 6. Правда они порезали С++ хедеры, сделали их общими на два компилятора, но набор самый минимальный...

Без всякой надежды, но еще раз попробую спустить вас с небес на землю. Тут тема новичковая, а 99% всех новичков заходят с кейла или иар-а, на худой случай. Вам же видится, что лучше начать с эклипса, к которому прикрутить девелоперскую ветку GCC. Уже с этого момента к вашим словам можно относится настороженно, но вам и этого мало. Вам надо непременно каждый бит опоясать в четыре слоя ООП-шелухой. Причем, в итоге никаких новых свойств этот бит не приобретает, код проще не становится, а объем писанины, напротив, увеличивается в разы. Вам может невдомек, но то, чем вы тут занимаетесь -- графомания в чистейшем незамутненном виде. Много слов, они звонкие и яркие, подобраны и расставлены верно. Все прекрасно. Смысла только нет.

[arkhnchul]

a5021 писал(а):

99% всех новичков заходят с кейла или иар-а, на худой случай

откуда дровишки насчет аж 99%?)

a5021 писал(а):

Вам же видится, что лучше начать с эклипса

вроде про эклипс речь не шла, или ошибаюсь?

a5021 писал(а):

к которому прикрутить девелоперскую ветку GCC

стабильный релиз gcc7 вышел год назад.

a5021 писал(а):

Вам надо непременно каждый бит опоясать в четыре слоя ООП-шелухой

вы приведенный выше показательный пример с неймспейсом вместо класса сознательно пропустили, или просто не заметили?)

[Reflector]

arkhnchul писал(а):

вроде про эклипс речь не шла, или ошибаюсь?

Не знаю ни про какой эклипс, я в VS пишу И gcc 7 никуда не прикручивал, VisualGDB его сам обновляет, да и clang в SES тоже идет из коробки.

[a5021]

arkhnchul писал(а):

откуда дровишки насчет аж 99%?)

Это можно даже в этой ветке наблюдать.

стабильный релиз gcc7 вышел год назад.

Спросим здесь, сколько человек его пользуют? Новичков.

вы приведенный выше показательный пример с неймспейсом вместо класса сознательно пропустили, или просто не заметили?)

Там было, что замечать? Он до степени смешения выглядит, как ООП, хоть ООП в чистом виде не является. Это, типа, котлеты из фальшивого зайца. Радость только для тех, кто может себя убедить силой.

[Reflector]

a5021 писал(а):

Спросим здесь, сколько человек его пользуют? Новичков.

А сколько нужно чтобы на этом основании GCC 7 можно было признать относящимся к девелоперской ветке?

Там было, что замечать? Он до степени смешения выглядит, как ООП, хоть ООП в чистом виде не является. Это, типа, котлеты из фальшивого зайца. Радость только для тех, кто может себя убедить силой.

Простые функции внутри namespace выглядят как ООП? Ладно, а что насчет такого кода:

Код:

Point p;
p.x = 10;


Это С или С++? Класс или обычная структура? А если кто-то скажет, что выглядит как ООП, то перестанешь пользоваться структурами?

[a5021]

Reflector писал(а):

А сколько нужно чтобы на этом основании GCC 7 можно было признать относящимся к девелоперской ветке?

Ваш вопрос не имеет смысла, т.к. до сей поры здесь не проявлялось ни одного пользователя gcc 7, кроме вас.

Простые функции внутри namespace выглядят как ООП? Ладно, а что насчет такого кода:

Код:

Point p;
p.x = 10;


Волшебные числа? Отлично. Это добавит перчика там, где его и без того в избытке.

Это С или С++? Класс или обычная структура? А если кто-то скажет, что выглядит как ООП, то перестанешь пользоваться структурами?

CMSIS практически сплошняком состоит из структур, но тамошним программистам не пришло в голову рядить их в OOP-like одежды. С позиций вашего подхода -- это необъяснимо.

[Reflector]

a5021 писал(а):

Ваш вопрос не имеет смысла, т.к. до сей поры здесь не проявлялось ни одного пользователя gcc 7, кроме вас.

Проблема в том, что ты пытаешься это представить как недостаток gcc 7 не имея для этого реальных оснований. На С++ тут тоже мало кто пишет, уверен это также должно означать, что язык плохой, а то и недоделанный. На С++14/17 пишут еще меньше, наверно только самые отморозки

Волшебные числа? Отлично. Это добавит перчика там, где его и без того в избытке.

Да, это волшебное число 10 которое я присваиваю координате X, видимо просто фантазии или опыта не хватает применить один из более прогрессивных подходов.

CMSIS практически сплошняком состоит из структур, но тамошним программистам не пришло в голову рядить их в OOP-like одежды. С позиций вашего подхода -- это необъяснимо.

Почему же, вполне объяснимо, - это суть придумка, как сэкономить на квалификации программистов, допуская к кодингу джуниоров-индусов, которые и С нормально освоить не могут.

[a5021]

Проблема в том, что ты пытаешься это представить как недостаток gcc 7 не имея для этого реальных оснований.

У вас наваждение такое случилось или вы и показать сможете, где я недостатки в gcc 7 вскрывал?

Почему же, вполне объяснимо, - это суть придумка, как сэкономить на квалификации программистов, допуская к кодингу джуниоров-индусов, которые и С нормально освоить не могут.

Обезъянничать у вас тоже плохо получается, т.к. вы не хуже моего знаете, что CMSIS -- это де-факто стандарт в отрасли. Нагромождения поверх -- это как раз для индусов. Пальцем в небо у вас, в общем.

Еще раз, обращаясь ко всем оппонентам в этом диспуте: ООП -- инструмент замечательный, новые правила и конструкции языка -- достижение. Только это не означает, что всем нужно подорваться строчить по три экрана кода, чтобы три бита перевернуть один раз во всей программе. Бред это.

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

[Reflector]

a5021 писал(а):

У вас наваждение такое случилось или вы и показать сможете, где я недостатки в gcc 7 вскрывал?

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

Еще раз, обращаясь ко всем оппонентам в этом диспуте: ООП -- инструмент замечательный, новые правила и конструкции языка -- достижение. Только это не означает, что всем нужно подорваться строчить по три экрана кода, чтобы три бита перевернуть один раз во всей программе. Бред это.

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

Ладно, как насчет такого примера, шлем и принимаем строку через USART при помощи DMA(TX соединен с RX):

Спойлер

Код:

static char msg_in[16] = "Hello World!";
static char msg_out[16] = {};

using usart = Usart2<>;
usart::init<PinA<2, 7>, PinA<3, 7>>(115200);
usart::initChannelTx<Dma1Ch7>(msg_in, 12);
usart::initChannelRx<Dma1Ch6>(msg_out, 12);
usart::enable(UsartCr3::DmaReceiver | UsartCr3::DmaTransmitter);

while (!Dma1Ch6::isInterruptReady(DmaFlag::TransferComplete)) {}


Я запускал на F3, но этот код будет работать и на F1, где регистры портов совсем другие, а для RX еще и нужно выбрать другой режим. И на F4 тоже работает, но там вместо каналов DMA нужно передать стримы, а вторым параметром будет номер канала. Более того, все это можно передать дальше, у меня есть класс для работы с DS18B20, он как раз принимает USART, пин и пару каналов DMA, можно одной строкой сконфигурировать его для работы с требуемой периферией, а следующей строкой,если очень нужно, сделать это для второго датчика высящего на другом пине другого усарта. Ну и чтобы по-настоящему оценить изящество этого кода хотелось бы увидеть в ответ аналогичный код на регистрах столбиком, тогда будет проще сравнить какой вариант компактнее, понятнее, устойчивее к ошибкам программирования или переносимее. То что у моего варианта будет некоторый оверхед по размеру понятно и так, но, опять же, не из-за классов и шаблонов, а из-за того, что тот же USART, например, при инициализации запросит скорость своей шины, но именно это позволяет такому коду сидеть в модуле DS18B20 и ни от чего не зависеть. А на регистрах я сам прекрасно писать умею, весь код внутри этих классов на регистрах и написан, так что в этом плане меня ничем удивить невозможно.

[Ярослав555]

Стандартный холивар об ООП Люди в упор не понимают зачем нужен ООП, при этом не писали огромных программ. Вот сейчас на столе платка размером с ATX материнку - 4 слейва на spi с опросом каждые 20 мС, архив и часы на i2c, 1-провод ключи на одном юарте и модбас на втором юарте. Остальные ноги забиты дискретными входами-выходами. А еще клиент желает логику работы на все случаи жизни. Без ООП это написать можно. Но с ООП ты долго стартуешь, зато быстро едешь (когда готовы классы - функционал перестраивается за пол часа). А с голым С поменять что-то надо неделю мозги сушить. Имел удовольствие такое наблюдать.
Вот пример - дискретный вход. Ну подумаешь - битик. Нахрена клас городить? А я в класс упаковал фильтрацию, детект фронтов, автообнуление флага фронта если его вычитали. А входов у меня 16 штук. Развернуть все экземпляры в обычные Сишные функции простыня не будет?