Easyelectronics.ru

Электроника для всех
Текущее время: 20 июн 2018, 20:09

Часовой пояс: UTC + 5 часов



    • JLCPCB - Платы прототипов всего за 2$ c бесплатной доставкой (при первом заказе)
    • 10 PCBs за $2 для 2 слоев, $15 для 4 слойной, $74 для 6 слойной платы.
    • Крупнейший китайский производитель прототипных плат. 290000+ клиентов & 8000+ заказов в день!
    • LCSC - Крупнейший китайский онлайн магазин радиодеталей.

Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 06 июн 2018, 16:44 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 1681
siarzhuk писал(а):
Динамическая память предполагает и контроль успешности выделения перед использованием, т.е. самое страшное что случится - переход в состояние ошибки.

И чем это отличается от зависания? А что делать если управляемый объект в это время в опасном состоянии?
siarzhuk писал(а):
Да и в случае отказа можно попытаться malloc_trim-ом освобождённые куски слить и попробовать ещё раз. Но, как и всё в этой области - без 100%-ной гарантии успешности.

В нормальной реализации хипа дефрагментация делается при освобождении куска памяти. Но, естественно, и это не гарантирует успешного выделения памяти.
siarzhuk писал(а):
evsi писал(а):
P.P.S. динамическое распределение памяти в эмбеде вполне применимо, но стандартные new/delete для этого подходят плохо.

VMT для объекта инициализировать можно конечно и placement new вызвать на полученном из malloc блоке памяти, но у стандартного new это получится надёжнее.

Во-первых, placement new отличается от обычного только тем, что работает по готовому куску памяти, а не по тому, который вернул malloc. То есть надежность инициализации VMT там ровно такая же. Во-вторых, зачем вам вообще VMT? Вы что, собрались иерархию типов городить?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 06 июн 2018, 18:07 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 99
evsi писал(а):
siarzhuk писал(а):
Динамическая память предполагает и контроль успешности выделения перед использованием, т.е. самое страшное что случится - переход в состояние ошибки.

И чем это отличается от зависания?

Наличием обратной связи.
evsi писал(а):
А что делать если управляемый объект в это время в опасном состоянии?

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

В newlib пришлось trim-ать.
evsi писал(а):
Во-первых, placement new отличается от обычного только тем, что работает по готовому куску памяти, а не по тому, который вернул malloc.

Атомарность создания объекта разная. Плейсменту можно подсунуть блок меньшего размера ...
evsi писал(а):
Во-вторых, зачем вам вообще VMT? Вы что, собрались иерархию типов городить?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 06 июн 2018, 18:39 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 1681
siarzhuk писал(а):
evsi писал(а):
И чем это отличается от зависания?

Наличием обратной связи.

То есть, по сути, ничем. Устройство не работает, а причина интересна только программисту.
siarzhuk писал(а):
evsi писал(а):
А что делать если управляемый объект в это время в опасном состоянии?

Получить все ресурсы до входа в транзакцию.

Чем это отличается от того, что бы не пользоваться динамическим выделением памяти? Не считая, конечно, того, что ситуация "не смогли начать транзакцию", в случае без динамического выделения памяти, в принципе невозможна.
siarzhuk писал(а):
evsi писал(а):
Во-первых, placement new отличается от обычного только тем, что работает по готовому куску памяти, а не по тому, который вернул malloc.

Атомарность создания объекта разная.

С этого места поподробнее, пожалуйста.
siarzhuk писал(а):
Плейсменту можно подсунуть блок меньшего размера ...

Сдуру можно и хер сломать. Или мы собираемся обсуждать возможные ошибки программиста в каждом случае?
siarzhuk писал(а):
evsi писал(а):
Во-вторых, зачем вам вообще VMT? Вы что, собрались иерархию типов городить?

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 07 июн 2018, 00:32 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 99
evsi писал(а):
То есть, по сути, ничем. Устройство не работает, а причина интересна только программисту.

По вашему пересылать два килограмма кирпича через полшарика, чтобы выяснить что в нём банально выгорела UV лампа, и везти обратно с новой лампой - это эквивалентно получению по e-mail кода ошибки и высылке пострадавшему картонки с лампой. Не, уже проходили .... :)
evsi писал(а):
Чем это отличается от того, что бы не пользоваться динамическим выделением памяти?

Вопрос риторический, "Заходя в дом, подумай как будешь из него выбираться" - касается как того, кто "неожиданно" обломался в середине транзакции так и того, кто изначально протащил без нужды источник энтропии в проект.
evsi писал(а):
Или мы собираемся обсуждать возможные ошибки программиста в каждом случае?

"Ненадёжность стандартного new" вас отвратила, осмелюсь напомнить.
evsi писал(а):
Хех. Вы опираетесь на возможность и исходя из нее придумываете архитектуру.

Я опираюсь на конкретный прототип, который мне разработчики притащили для оживления, и на опыт поддержки предыдущего поколения аналогичного устройства - и шишки набитые с ним. Да и, человек у которого в руках молоток всегда весьма искушаем завернуть шуруп известным образом. И если "классики" себя уже показали хорошо - какой ленивец откажется их скопипейстить? Разве что только кто типа меня, что в известном месте играет чего-то нового попробовать. ;-)
evsi писал(а):
Но вполне удобное решение возможно и с другой архитектурой.

Бесспорно. Аз обуреваем иррациональной идеей обнулить VMT, но покамест здравый смысл убедительнее аргументирует. Типа: -"Проверку флажка тоже через диспетчеризацию пустишь?"
evsi писал(а):
Например, классы, работающие с определенными типами устройств могут сами хранить информацию о том, в каких слотах есть понятные им устройства. И, что характерно, при этом не нужно выделять память динамически и/или хранить VMT.

Класс - это методы, а данные - это объект, и от того, что в классе вместо одного набора данных будет массив наборов на все "объекты" во вселенной - да на одной индексации разорение. Не говоря о том, что работать будет в среднем 100/N % этих данных, где N - количество возможных типов модулей. А их мне обещают только больше и больше со временем.
evsi писал(а):
В добавок, весь код работы с конкретным устройством оказывается привязан к конкретному классу (или темплейту), а не размазан по иерархии.

Эдак процентов на 50 все эти "утки" "крякают" схожим образом - и. место такой общей функциональности вроде как раз в базовых классах. Размазывать по иерархии - солидарен, не приветствую, что лишнее - то лишнее, но если место общему поведению в базе - то быть посему, не понравится - отзову.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 07 июн 2018, 08:29 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 1681
siarzhuk писал(а):
evsi писал(а):
То есть, по сути, ничем. Устройство не работает, а причина интересна только программисту.

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

Такая "обратная связь" реализуема в любом варианте. Не о том речь вовсе.
siarzhuk писал(а):
evsi писал(а):
Чем это отличается от того, что бы не пользоваться динамическим выделением памяти?

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

Динамическое выделение и есть источником энтропии.

siarzhuk писал(а):
Класс - это методы, а данные - это объект, и от того, что в классе вместо одного набора данных будет массив наборов на все "объекты" во вселенной - да на одной индексации разорение. Не говоря о том, что работать будет в среднем 100/N % этих данных, где N - количество возможных типов модулей. А их мне обещают только больше и больше со временем.

Думаю вам самое время почитать об паттерне композит. А сколько их будет работать не играет никакой роли. Объем неиспользуемого в каждый момент кода будет +- одинаков при любом варианте.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 08 июн 2018, 11:07 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 99
evsi писал(а):
Такая "обратная связь" реализуема в любом варианте. Не о том речь вовсе.

Речь о том, что 0 из malloc-а - не приговор устройству. Куча - всего-лишь один из "периферийных модулей" мо́гущих временно отказать в обслуживании.
evsi писал(а):
Динамическое выделение и есть источником энтропии.

Именно это я и имел ввиду. ;-)
evsi писал(а):
Думаю вам самое время почитать об паттерне композит.

Сдаётся мне, что схожесть терминов играет тут злую шутку. Composite pattern как один из 23-ёх (?), своими деревьями и кучкованием, к моему контексту не приклеивается даже волшебной синей изолентой, а имели вы в виду composition АКА агрегацию АКА [банальное] включение - всем известная альтернатива наследованию. Так?
evsi писал(а):
А сколько их будет работать не играет никакой роли. Объем неиспользуемого в каждый момент кода будет +- одинаков при любом варианте.

Вопрос не в коде - вопрос в данных, используемых для каждого физического модуля, - и при отказе от динамики резервировать место надо по максимуму каждого типа - то бишь нужна "матрица" 6 х N в и к тому же заведомо разреженная - так как работать одновременно могут лишь 1 - 6 блоков.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 08 июн 2018, 12:32 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 1681
siarzhuk писал(а):
Речь о том, что 0 из malloc-а - не приговор устройству. Куча - всего-лишь один из "периферийных модулей" мо́гущих временно отказать в обслуживании.

0 из malloc-а значит, что вы не можете начать "транзакцию", следовательно устройство не может выполнять свои функции. Что это как не приговор устройству?
siarzhuk писал(а):
evsi писал(а):
Думаю вам самое время почитать об паттерне композит.

Сдаётся мне, что схожесть терминов играет тут злую шутку. Composite pattern как один из 23-ёх (?), своими деревьями и кучкованием, к моему контексту не приклеивается даже волшебной синей изолентой, а имели вы в виду composition АКА агрегацию АКА [банальное] включение - всем известная альтернатива наследованию. Так?

Нет. Речь шла именно о композите. Думаю, вдумчивое прочтение первых четырех предложений из вики вам поможет понять о чем идет речь.
siarzhuk писал(а):
evsi писал(а):
А сколько их будет работать не играет никакой роли. Объем неиспользуемого в каждый момент кода будет +- одинаков при любом варианте.

Вопрос не в коде - вопрос в данных, используемых для каждого физического модуля, - и при отказе от динамики резервировать место надо по максимуму каждого типа - то бишь нужна "матрица" 6 х N в и к тому же заведомо разреженная - так как работать одновременно могут лишь 1 - 6 блоков.

О да, выделить один байт (в котором каждый бит соответствует одному слоту) это офигенный оверхед. А вот динамически создавать объект и ложить в массив/контейнер слотов указатель на этот объект - аххеренная экономия ресурсов (в том числе памяти).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 09 июн 2018, 08:41 
Старожил
Аватара пользователя

Зарегистрирован: 26 окт 2013, 07:58
Сообщения: 1795
Создал шаблончик.
Может "академически" неправильно - извиняйте, только учусь.
Segger+FreeRTOS10+SPL+потокобезопасный new/delete
FreeRTOS работает с системной кучей.
https://yadi.sk/d/Dj18xB-W3XXUUh

Камень - stm32f103ret6


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: STM32+SEGGER+FreeRTOS+C++
СообщениеДобавлено: 10 июн 2018, 00:37 
Заглядывает иногда

Зарегистрирован: 15 ноя 2015, 12:11
Сообщения: 99
evsi писал(а):
0 из malloc-а значит, что вы не можете начать "транзакцию", следовательно устройство не может выполнять свои функции.

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

Задача несколько изощрённе, чем "возможность управления группой как одним объектом", и беглый взгляд на типовую реализацию паттерна, предлагающую interface прошибает на смешок: -"Привет VMT, <тут слова с простыми корнями>".
evsi писал(а):
О да, выделить один байт (в котором каждый бит соответствует одному слоту) это офигенный оверхед.

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: Eddy_Em, goreprogrammist, mChel


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

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB