[jcxz 236]

2 часа назад, EdgeAligned сказал:

Даже в рассматриваемом там STM32F0 заголовочник имеет несколько тысяч строк.

Ну уж - набросили на вентилятор так набросили!!  "Несколько тысяч"... А почему не миллионов?  

С STM32F0 дел не имел, но есть довольно большой проект на STM32F103VE. Хидер с описанием регистров периферии = около 550 строк. Просто 550, а не 550тысяч!  

2 часа назад, EdgeAligned сказал:

И сколько времени уйдет на их переписывание? Учитывая, что С++ гораздо многословнее Си.

Конечно, если поставить целью, то можно и хидер в миллион строк накатать. И писать его несколько лет.

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

Конечно никакие си++ тут не нужны. И время на написание хидера на периферийный блок регистров - просто несравнимо со временем изучения этого блока. Говорить о каких-то тратах на его создание - просто смешно.

[EdgeAligned 85]

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

Идея с описанными выше переделками не нова. Я на неё наталкивался еще года три назад, а может и раньше. Сторонники этой идеи оправдываются тем, что "вот смотрите, теперь нельзя написать в GPIOA->BSRR что-то иное, чем GPIO::BSRR::BS13". Однако, в рассматриваемом примере это малоактуально, если пишешь не в "Блокноте", а в IDE, которая в процессе написания предлагает варианты автозаполнения:

тут ошибиться можно только специально, внаглую.

Ну ладно, автор хочет иметь прям железную дуракоустойчивость, не доверяя самому себе. Хорошо. Но сколько времени уйдет на переписывание заголовочников и всего связанного окружения хотябы для наиболее часто используемых автором микроконтроллеов? Ведь почему-то даже производитель ST до сих пор не переписал ни единого заголовочника, а CubeIDE использует старый сишный стиль описания. Да и ARM тоже. Да и FreeRTOS тоже! Вон сколько всего нужно переделать будет сразу, чтобы не встрять. И это при том, что С++, как ни крути, он не имеет действительно эффективного и компактного инструментария для решения поставленных задач.

[jcxz 236]

36 минут назад, Arlleex сказал:

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

Ну вот я, в вышеуказанном STM32F103VE, описал блок периферийных регистров GPIO:

//GPIO
typedef struct {
  union {
    struct {
      u32 CRL;
      u32 CRH;
    };
    u32 CR[2];
  };
  u32 IDR;
  u32 ODR;
  u32 BSRR;
  u32 BRR;
  u32 LCKR;
  u32 unuse1[249];
} HwRegsGPIO;

Заняло = 16 строк вместе с комментом. И наверное заняло около 5 минут (не засекал).

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

[EdgeAligned 85]

1 минуту назад, jcxz сказал:

Хидер с описанием регистров периферии = около 550 строк

550? Да нет, сейчас смотрю - счетчик строк переваливает за 8 тысяч. А у H743 - чето около 30 тыс строк, насколько помню

[jcxz 236]

11 минут назад, jcxz сказал:

Хидер с описанием регистров периферии = около 550 строк. Просто 550, а не 550тысяч!

Да, наврал - из этих 550 строк около 100 - описание регистров периферии ядра (NVIC, MPU, etc.). Которые конечно же не писались, а были скопированы из предыдущего проекта на подобном ядре. Т.е. - остаётся уже 450строк. Да и многие периферийные блоки - описание их регистров также скопировал из других проектов на других STM32F, а потом исправил различия.

В сумме наверное на все эти описания потратил несколько минут чистого времени (если вычесть время изучения по мануалу функций этих регистров).

[EdgeAligned 85]

6 минут назад, jcxz сказал:

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

Но зачем писать, если он уже описан? 

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

[jcxz 236]

15 минут назад, EdgeAligned сказал:

550? Да нет, сейчас смотрю - счетчик строк переваливает за 8 тысяч. А у H743 - чето около 30 тыс строк, насколько помню

Видимо вы - из тех индусов, кому платят за количество строк.  

Чего там можно на тысячи строк описывать-то???

9 минут назад, EdgeAligned сказал:

Но зачем писать, если он уже описан? 

Вы рассуждаете как большинство чайников: "Зачем читать мануал, ведь индусами уже всё прочитано и в кубе уже всё написано".  

9 минут назад, EdgeAligned сказал:

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

Вот-вот....

9 минут назад, EdgeAligned сказал:

Поскольку в том же H743 одно только перечисление регистров занимает чето тыщщи две строк, насколько щас на память помню.

Современные контроллеры они такие. Но тут никуда не деться - или умейте изучать их; или пользуйтесь мурзилками для чайников. Ардуиной например....

У меня обычный размер исходников для почти любого проекта занимает десятки тысяч строк. Описание регистров тут - капля в море. Но для чайника наверное страшно...

[EdgeAligned 85]

Так это ж НЕ Я описываю. Этот файл прилагается к микроконтроллеру при создании проекта, я его не трогаю. По-моему, это нормальная практика, когда используешь готовый файл описания. Ведь он уже написан, проверен, отлажен и скомпонован в едином стиле и откомментирован. К тому же, когда используешь какие-то сторонние пакеты, например ту же FreeRTOS, не требуется ничего подгонять.  

Либо я не понимаю, о чем вы пишите, либо вы не понимаете, про что я говорю. Мануалы я прекрасно изучаю. Я лишь говорю о том, что НЕ следует переписывать именно вот ЭТО:

 

 

[jcxz 236]

2 минуты назад, EdgeAligned сказал:

Так это ж НЕ Я описываю. Этот файл прилагается к микроконтроллеру при создании проекта, я его не трогаю. По-моему, это нормальная практика, когда используешь готовый файл описания. Ведь он уже написан, проверен, отлажен и скомпонован в едином стиле и откомментирован.

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

4 минуты назад, EdgeAligned сказал:

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

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

 

PS: Не так давно как раз разбирался с подобным "проектом" на STM32F103VE, который также был слеплен из готовых надёрганных где-то кубиков. Работа с флешкой - кубик, работа с EEPROM - другой, FatFS (с портом) - третий, а работа с UART-ами вообще - частично из третьего надёрганного куска склеена вообще с каким-то кодом, портированным с абдурины.  

Всё это перемотано скотчем и синей изолентой, и подпиралось лесом костылей. И называлось гордо: "Прошивка для 3D-принтера"!  

Там в его составе было сразу два или три РАЗНЫХ набора файлов CMSIS и HAL!!!   Этот ужас при компиляции генерил (насколько помню) - более 3тыс. варнингов!!!

 

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

[Arlleex 180]

31 минуту назад, jcxz сказал:

Ну вот я, в вышеуказанном STM32F103VE, описал блок периферийных регистров GPIO:

//GPIO
typedef struct {
  union {
    struct {
      u32 CRL;
      u32 CRH;
    };
    u32 CR[2];
  };
  u32 IDR;
  u32 ODR;
  u32 BSRR;
  u32 BRR;
  u32 LCKR;
  u32 unuse1[249];
} HwRegsGPIO;

Заняло = 16 строк вместе с комментом. И наверное заняло около 5 минут (не засекал).

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

Мы не об этом. Лично мне не очень нравится писать самому эти структуры, к тому же зоопарк разных МК в том же семействе STM32 быстро бы остудил это желание. Да и смысла я не вижу. А про километры кода - это про подходы плюсоводов, в частности автора по ссылке выше с хабра. Накромсать километры прослоек и потом по уши сидя в этих всех хитросплетениях, заявлять, что это "безопасно" и "ухх смотрите как у меня в компайл-тайме все проверяется" - имхо, не верно.

[EdgeAligned 85]

А если, а если. "Ах, мама, а если я беременна"(С) 🙂

2 минуты назад, jcxz сказал:

который также был слеплен из готовых надёрганных где-то кубиков

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

5 минут назад, jcxz сказал:

Вот к чему приводит стремление лепить код их надёрганных кубиков.

ИМЕННО! Именно таким "надерганным кубиком" и является ваши самодельные описания. Возможно, для вас это неочевидно.

[jcxz 236]

38 минут назад, EdgeAligned сказал:

550? Да нет, сейчас смотрю - счетчик строк переваливает за 8 тысяч.

Вот для интереса - глянул сколько весят файлы описания регистров периферии (все, суммарно) в том исходном проекте на мой 3D-принтер = 3354 КБ!

Мой файл описания регистров периферии (для того же самого проекта, но переписанного мной) = ~25 КБ.  Всего в ~134 раза меньше.  

4 минуты назад, Arlleex сказал:

Накромсать километры прослоек и потом по уши сидя в этих всех хитросплетениях, заявлять, что это "безопасно" и "ухх смотрите как у меня в компайл-тайме все проверяется" - имхо, не верно.

Вот с этим соглашусь. Чем более сложный и запутанный код - тем менее он безопасен. Потому как: "чёрт ногу сломит!"

И плюсы это или не плюсы - роли не играет.

[EdgeAligned 85]

2 минуты назад, Arlleex сказал:

Накромсать километры прослоек и потом по уши сидя в этих всех хитросплетениях,

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

[jcxz 236]

7 минут назад, EdgeAligned сказал:

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

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

7 минут назад, EdgeAligned сказал:

ИМЕННО! Именно таким "надерганным кубиком" и является ваши самодельные описания. Возможно, для вас это неочевидно.

С чего бы это??? Я их ниоткуда не выдёргивал. Сам писал. Да и не код это. А всего лишь заголовочный файл.

[Arlleex 180]

11 минут назад, jcxz сказал:

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

А вдруг завтра война, а я уставши? (с)

Как будто когда сам пишешь, ошибок не допускается. Ну ну.

Я баги в заголовчниках периферии встречал от силы раза два в жизни. И отлов их занимал не более 10 минут, т.к. в отладчике все прекрасно видно.