haker_fox 61 5 января, 2019 Опубликовано 5 января, 2019 · Жалоба @Forger, благодарю вас за подробное объяснение! Идея: один ресурс - один владелец очень даже правильная. Сам стал также по-возможности делать. Плюс - можно использовать MPU, если есть, и разрешить в периферию лезть только одному нотариально доверенному! Ну, а если, какая-то задача решила выше головы прыгнуть - то хардфолт на неё) 4 hours ago, ViKo said: Для STM32 - элементарно, если для одного порта. Я, вообще, за миниммизацию использования макросов. Си++, наверно, уже почти для всех МК поддерживается. Предпочитаю ООП использовать: все три кита. Хотя... наблюдал и явные перегибы. Один мой коллега в прерывание засунул std::vector, не стесняясь использовать прямо там push, pop методы, которые шли в менеджер кучи. В итоге всё это валилось через раз. Считаю, что пример бестящего использования ООП в scmRTOS, которую ещё в начале 2000-х успешно компилил для AVR, и памяти это не отъедало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 5 января, 2019 Опубликовано 5 января, 2019 · Жалоба Сам, конкретно, использую с драйверами подход стека: т.е. есть некие абстрактные классы устройств: АЦП, ЦАП, порты, шины и т.д. и т.п. Их можно соединять цепочками, указывая друг дружке адрес драйвера. Например, нужно обратиться к часам. Часы могут быть встроены в МК, либо висеть снаружи на SPI, I2C. Драйвер часов для потребителей времени всегда один, но "внутри" ему указан либо адрес драйвера реальных часов внутри МК, либо драйвер часов снаружи, а тому, в свою очередь, указан адрес драйвера шины I2C, которая, кстати, тоже может быть встроенной в МК, либо висеть в виде микросхемы на чём-нибудь. Сорри. за столь длинное предложение))) Служба часов<->драйвер часов МК STM32Fxxxx Либо Служба часов<->драфер DS1307<->драйвер I2C, встроенный в STM32Fxxx Иногда фантазия зашкваливает, и хочется сделать что-то на подобии винды, plug and play, чтобы всё само по-максимуму находилось. В приборе сделал так с внешней нанд, у нас несколько разных типов есть на складе, отличаются объёмом и командами. Так вот, при загрузке, железяка сама по ID определяет, что запаяно (ну строго говоря, это нужно для более старых релизов железа), и загружает уже конкретный драйвер микрсхемы памяти. Хотя для файловой системы "хранилище" с точки зрения API всегда одно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 5 января, 2019 Опубликовано 5 января, 2019 · Жалоба 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 61 6 января, 2019 Опубликовано 6 января, 2019 · Жалоба 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 26 6 января, 2019 Опубликовано 6 января, 2019 · Жалоба 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 61 6 января, 2019 Опубликовано 6 января, 2019 · Жалоба 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 26 6 января, 2019 Опубликовано 6 января, 2019 · Жалоба 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 6 6 января, 2019 Опубликовано 6 января, 2019 · Жалоба 2 hours ago, Forger said: Вся работа с периферией только через регистры (подключаю соотв h-файлы от самих процов, где уже "вбиты" адреса регистров, их битовые поля и структуры). В смысле, никаких уровней абстракции, и прямо до приложения биты и поля тащите? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 6 января, 2019 Опубликовано 6 января, 2019 · Жалоба 2 hours ago, one_eight_seven said: В смысле, никаких уровней абстракции, и прямо до приложения биты и поля тащите? Под моей фразой "Вся работа с периферией только через регистры" означает, что такая работа низкоуровневая работа с железом производится ТОЛЬКО внутри соотв. библиотек, но ни в коем случае НЕ конечных приложений! Сами приложения (на базе соотв. класса AbstractAplication) работает через только через соотв. библиотеки (OS, Pin, Memory, RCC, Timer, USART, CAN и т. д.). Все эти библиотеки у меня построены на C++11. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться