[haker_fox 60]

@Forger, благодарю вас за подробное объяснение! Идея: один ресурс - один владелец очень даже правильная. Сам стал также по-возможности делать. Плюс - можно использовать MPU, если есть, и разрешить в периферию лезть только одному нотариально доверенному! Ну, а если, какая-то задача решила выше головы прыгнуть - то хардфолт на неё)

4 hours ago, ViKo said:

Для STM32 - элементарно, если для одного порта.

Я, вообще, за миниммизацию использования макросов. Си++, наверно, уже почти для всех МК поддерживается. Предпочитаю ООП использовать: все три кита. Хотя... наблюдал и явные перегибы. Один мой коллега в прерывание засунул std::vector, не стесняясь использовать прямо там push, pop методы, которые шли в менеджер кучи. В итоге всё это валилось через раз. Считаю, что пример бестящего использования ООП в scmRTOS, которую ещё в начале 2000-х успешно компилил для AVR, и памяти это не отъедало.

[haker_fox 60]

Сам, конкретно, использую с драйверами подход стека: т.е. есть некие абстрактные классы устройств: АЦП, ЦАП, порты, шины и т.д. и т.п. Их можно соединять цепочками, указывая друг дружке адрес драйвера. Например, нужно обратиться к часам. Часы могут быть встроены в МК, либо висеть снаружи на SPI, I2C. Драйвер часов для потребителей времени всегда один, но "внутри" ему указан либо адрес драйвера реальных часов внутри МК, либо драйвер часов снаружи, а тому, в свою очередь, указан адрес драйвера шины I2C, которая, кстати, тоже может быть встроенной в МК, либо висеть в виде микросхемы на чём-нибудь. Сорри. за столь длинное предложение)))

Служба часов<->драйвер часов МК STM32Fxxxx

Либо

Служба часов<->драфер DS1307<->драйвер I2C, встроенный в STM32Fxxx

Иногда фантазия зашкваливает, и хочется сделать что-то на подобии винды, plug and play, чтобы всё само по-максимуму находилось. В приборе сделал так с внешней нанд, у нас несколько разных типов есть на складе, отличаются объёмом и командами. Так вот, при загрузке, железяка сама по ID определяет, что запаяно (ну строго говоря, это нужно для более старых релизов железа), и загружает уже конкретный драйвер микрсхемы памяти. Хотя для файловой системы "хранилище" с точки зрения API всегда одно.

[Forger 17]

1 hour ago, haker_fox said:

Плюс - можно использовать MPU, если есть, и разрешить в периферию лезть только одному нотариально доверенному! Ну, а если, какая-то задача решила выше головы прыгнуть - то хардфолт на неё)

Именно!

 

1 hour ago, haker_fox said:

Я, вообще, за миниммизацию использования макросов.

У себя использую только те макросы, которые идут в CMSIS, самые популярные SET_BIT и CLEAR_BIT ))

Больше макросов нет, оданако, хватает constexpr-выражений.

 

Quote

Один мой коллега в прерывание засунул std::vector, не стесняясь использовать прямо там push, pop методы,

Конечно, это - перебор.

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

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

Quote

которые шли в менеджер кучи.

Кучу практически никогда не использую, она вообще у меня заблокирована на уровне pragma от компилятора.

 

Quote

Считаю, что пример бестящего использования ООП в scmRTOS, которую ещё в начале 2000-х успешно компилил для AVR, и памяти это не отъедало.

В 2000х - это было действительно блестяще, но нынче уже другие времена.

К слову, когда я проектировал свою обертку вокруг РТОС (любой ртос), то опирался как раз на идеи, изложенные в scmRTOS, но сделал иначе, удобнее для себя.

 

 

1 hour ago, haker_fox said:

Иногда фантазия зашкваливает, и хочется сделать что-то на подобии винды, plug and play, чтобы всё само по-максимуму находилось.

Многие фантазии развеиваются сразу, как только по-пытаетесь использовать их на практике 

[haker_fox 60]

8 hours ago, Forger said:

которые идут в CMSIS

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

8 hours ago, Forger said:

Но сама по себе std библиотека хороша

О, да! На LPC4337 + 32 Mb снаружи, не стесняясь используем std::map, std::vector, std::string и многое другое.

8 hours ago, Forger said:

Однако, в небольших проектах она слишком избыточна

Моё мнение: hal-уровень, драйвера, системные библиотеки должны быть сделаны так, чтобы их можно было собрать как для 8-биток (ну ладно, cortex-m0:) ), так и для Cortex-Mx (A? R?). Конечно, возможно потребуется регулирование параметров компиляции, и условная компиляция, чтобы что-то урезать для младших МК, и добавить для старших. Но шаблоны, наследование, инкапсуляцию, полиморфизм вполне возможно, и нужно, использовать, т.к. сами по себе они не требуют ресурсов.

8 hours ago, Forger said:

Кучу практически никогда не использую

А мы как-то рискуем) Показалось заманчивым в любой момент запросить карту распределения памяти, вроде как добавляется власти над системой. Хотя иногда есть и опасения, что дефрагментация положит всю систему. Особенно те, которые работают в режиме 24/7/365.

9 hours ago, Forger said:

уровне pragma от компилятора

Не поделитесь строкой?)

9 hours ago, Forger said:

Многие фантазии развеиваются сразу, как только по-пытаетесь использовать их на практике 

О таааа! Здесь согласен!!!!

[Forger 17]

4 hours ago, haker_fox said:

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

Из CMSIS я использую лишь h-файлы: "привязка" к компилятору и ядру, в частности cmsis_armclang.h, cmsis_compiler.h, core_cm*.h, cmsis_version.h.

Вся работа с периферией только через регистры (подключаю соотв h-файлы от самих процов, где уже "вбиты" адреса регистров, их битовые поля и структуры).

 

 

Quote

Моё мнение: hal-уровень, драйвера, системные библиотеки должны быть сделаны так, чтобы их можно было собрать как для 8-биток (ну ладно, cortex-m0:) ),

У меня одинаковый интерфейс библиотеки для всех cortex-m. Разве что для крохотных проектов есть сборка без встроенной ртос.

 

Quote

Не поделитесь строкой?)

У каждого компилятора она разная.

Я такие использую (ARM compiler V6):

__asm(".global __use_no_heap \n\t");
__asm(".global __use_no_heap_region \n\t"); 

В ARM компиляторе v5 у использовались соотв pragma, но его относительно недавно более не использую.

4 hours ago, haker_fox said:

А мы как-то рискуем)

Вовсе не обязательно использовать штатный менеджер кучи, вот, имхо, один из вполне годных вариантов для ее замены: https://github.com/mattconte/tlsf

[haker_fox 60]

1 hour ago, Forger said:

Вся работа с периферией только через регистры

Тоже стал к этому приходить. А в своё время руководство как-бы настояло использовать готовое, типа экономия времени. Ерудна!

1 hour ago, Forger said:

У меня одинаковый интерфейс библиотеки для всех cortex-m. Разве что для крохотных проектов есть сборка без встроенной ртос.

Т.е. у вас уже что-то типа своего фреймворка, как говорит уважаемый @AlexandrY.

1 hour ago, Forger said:

Я такие использую (ARM compiler V6):

Спасибо, не знал ничего об этом!

1 hour ago, Forger said:

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

В одном из проектов использовал менеджер, выложенный много лет назад уважаемым @zltigo. Стандартный и не позволит получить статистику, ну если речь о том, что с компилятором в библиотеках поставляется. Но у того менеджера обнаружилась проблема: очень медленная скорость при объёме озу 32 Мб.

1 hour ago, Forger said:

вот, имхо, один из вполне годных вариантов для ее замены: https://github.com/mattconte/tlsf

Ок, посмотрю! Кстати, вот ещё монумент!

[Forger 17]

39 minutes ago, haker_fox said:

Т.е. у вас уже что-то типа своего фреймворка

Ну, это уж очень громко сказано! Но в целом, наверно, все к тому и идет :)

В своем коде я ориентируюсь очень свободно. Впрочем, как и любой из нас ;)

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

 

Quote

Ок, посмотрю! Кстати, вот ещё монумент!

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

Самые простые и надежные аллокаторы построены на базе пулов (кусков равного размера). Компромиссный вариант - несколько пулов, каждый на куски своего размера. Именно на такой аллокатор я привел ссылку выше.

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

В некоторых классах я использую локально перегруженные new/delete, которые реализуют свои простейшие аллокаторы для конкретных классов. При этом глобальные new/delete не использую, т. к. соотв. malloc/free запрещены еще на уровне линкера.

До глобальных new/delete пока еще не дорос, точнее - пока нет у меня проектов, требующих глобальной кучи :)

 

39 minutes ago, haker_fox said:

А в своё время руководство как-бы настояло использовать готовое, типа экономия времени. Ерудна!

Честно говоря, это спорно - зависит от ситуации 

Например, USB библиотеки (и не только) я использую уже готовые, собранные, но с соотв. "обертками" (т. н. wrapper) под свой код. 

Это позволяет в случае смены библиотеки (в т. ч. RTOS) вообще не менять свой код в своих проектах.

Не настаиваю, но лично мне такой подход очень по душе - привязка к чужому очень минимальна и потому сопровождение РАЗНЫХ проектов на базе разных чужих библиотек значительно упрощается - мой код везде построен одинаково, чужое скрыто в недрах и нечего туда лазить :)

 

 

[one_eight_seven 3]

2 hours ago, Forger said:

Вся работа с периферией только через регистры (подключаю соотв h-файлы от самих процов, где уже "вбиты" адреса регистров, их битовые поля и структуры).

В смысле, никаких уровней абстракции, и прямо до приложения биты и поля тащите?

[Forger 17]

2 hours ago, one_eight_seven said:

В смысле, никаких уровней абстракции, и прямо до приложения биты и поля тащите?

Под моей фразой "Вся работа с периферией только через регистры" означает, что такая работа низкоуровневая работа с железом производится ТОЛЬКО внутри соотв. библиотек, но ни в коем случае НЕ конечных приложений!

 

Сами приложения (на базе соотв. класса AbstractAplication) работает через только через соотв. библиотеки (OS, Pin, Memory, RCC, Timer, USART, CAN и т. д.). Все эти библиотеки у меня построены на C++11.