Давайте сделаем отдельную ветку, откуда началась дискуссия ViewTopic.PHP?f = 3&P = 15649#P15644

Я решительно не согласен с тем, что в каждом случаях следует избегать динамических распределений, это не должно становиться религиозным Bevhaviour !
Многие и многие библиотеки Arduino и даже основные классы, такие как String, используют Malloc/Realloc/Free, даже в AVR328.
Так что, пожалуйста, не бойтесь использовать их, если они управляются должным образом !

Я предлагаю всем, кто собирает свою собственную папку библиотек, чтобы выяснить, что правда !

Я решительно не согласен с тем, что в каждом случаях следует избегать динамических распределений, это не должно становиться религиозным Bevhaviour ! Конечно не в каждом случае!

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

Луча

Привет, Рэй,
Я согласен с вами на стороне Enduser, где новички строят список ссылок и забывают реализовать свободный узел ...

Но при рассмотрении основных файлов, таких как последовательные буферы, где эти буферы будут выделены в косвенной настройке () через серийный.begin () и что эти буферы живы навсегда (в этом случае нежелание Роджера по поводу фрагментации не возникнет), там не так много проблем по сравнению с струнным алоком/свободным перетасованием или библиотекой Ethernet .

Это цель этой темы: «Удаление мифов о динамических распределениях» в Embedded.

Как сказано в оригинальном посте, почему даже STM в их SPL использует Malloc/Realloc/Free в своем коде, если это «плохая практика» ?

Другими словами, «Проблемы динамического распределения во встроенного мира» - это миф или реальность ? (Для меня это «миф»)

Martinayotte написал: <...>
Другими словами, «Проблемы динамического распределения во встроенного мира» - это миф или реальность ? (Для меня это «миф»)

Просто для записи

Я искал Libmaple и не смог найти нигде, где Lefflabs использовали Malloc

Мы вообще не используем новое, потому что он входит в огромное количество дополнительных библиотек, что приводит к массовому воздуру кода.

Я посмотрел на собственного HAL и CMSIS от STM, и я не могу найти ни одной ссылки на Malloc

Я сделал то же самое на LiboPencm3 https: // github.com/libopencm3/libopencm ... 3&Q = Malloc
и не смог найти никаких ссылок на код на Malloc (только один файл Perl), то же самое относится и к новому оператору.


В случае последовательного буфера нет необходимости использовать Malloc, буферы могут быть статически распределены в сериал.begin () - хотя размер буфера также должен быть передан, так как в противном случае код не может узнать, насколько велики буферы.

Rogerclark написал:Просто для записи
<...>

Rogerclark написал: Я искал Libmaple и не смог найти нигде, где Lefflabs использовали Malloc

...
Я люблю хорошее обсуждение! Я подходит своим "WishyWashy" лично так хорошо
В школе я всегда принимал Адвокат дьявола позиция... Часто переключать роль дьявола в среднем потоке, как политик Это отличное обучение, но не стало большой популярностью для моих сверстников... люди не знают, что делать с кем -то, кого они не могут закрепить этикетку.

Очень безопасно использовать динамическое распределение с Malloc, но без свободного или Realloc.
Существуют пользовательские функции Malloc для замены раздутых полноценных версий стандартных библиотек.

Дорогой все, я бы хотел перенести эту дискуссию от теории на практику.
Вчера я отправил PR #184, чтобы применить некоторые улучшения USART в библиотеке F1.
Одним из этих улучшений является динамическое распределение буферов, которое я реализовал с помощью malloc ().
Это касается Роджера, который склонен к другому подходу, в котором пользователь должен быть в состоянии выделить буфер и передать его (вместе с его размером) на последовательное устройство.
С другой стороны, у меня есть проблемы с его подходом, который я перечислил в этом посте: ViewTopic.PHP?f = 3&t = 1189&начало = 50#p15662

Итак, я бы хотел ваше мнение о следующих пунктах:

• Как вы думаете, мое использование Malloc () (не) случай справедливого использования?
• Что вы думаете о моих опасениях по поводу подхода, предложенного Роджером?

Спасибо заранее и с уважением, e.

Ребята

Лично я бы предпочел просто повторить то, что делает AVR, и объявить статические неоперационные буферы, но я знаю, что это пожелает 4 х 64 байта барана, которые некоторые не хотят терять

@Мартин

Спасибо. Я не искал alloc. Моя ошибка.

@slammer

Хороший момент.

Что мы делаем в сериале.end (), позвонить бесплатно () в этих буферах?


Я думаю, что мне нужно поместить это на полюс, так как мое личное мнение не так важно.
Я хочу только то, что лучше всего для ядра, но в конечном итоге это сообщество, которое является арбитром, что лучше.

Пока это не другое голосование в стиле голоса Brexit

Rogerclark написал: Пока это не другое голосование в стиле голоса Brexit

Rogerclark написал: <...>
Я думаю, что мне нужно поместить это на полюс, так как мое личное мнение не так важно.
Я хочу только то, что лучше всего для ядра, но в конечном итоге это сообщество, которое является арбитром, что лучше.
<...>

Вернемся к исходному варианту использования, серийный объект !

В 99.99% случаев, серийный объект распределяются во всем мире (но даже если они не являются следующими, все еще верно), его конструктор инициализация указателя буферов на NULL, эти указатели будут установлены во время последовательного.begin () в соответствии с запрошенным размером буфера, поскольку оригинальные указатели являются NULL, Realloc () будет вызывать malloc () (как в объекте String, упомянутом ранее). Эти буферы должны оставаться распределенными до тех пор, пока не будет назван серийный деструктор (не связанный с серийным.end () вообще).
Во всех вышеперечисленных сценарии вообще нет фрагментации кучи вообще.
Если новый сериал.begin () был вызван для существующего последовательного объекта, а затем инициализация указателя буфер.
Это единственный случай, когда может произойти фрагментация кучи !
Стоит ли подумать о нескольких серийных.Begin () поведение, даже если правильно сделано, особенно то, что это даже неизвестно на AVR ?
(У нас есть еще одна ветка о нескольких серийных.Begin () поведение, но здесь, если размеры буферов идентичны, это не будет проблемой)

Мартин

Я думаю, что есть еще одна ветка, где было отмечено, что называя сериал.Begin () снова и не называть серийный.End () сначала может не работать в любом случае.

Но если Malloc называется из серийного.begin () мы должны позвонить бесплатно в сериале.end () просто чтобы быть последовательным.

Я полагаю, в сериале.Begin () Если указатели не являются нулевыми, свободные могут быть вызваны по указателям или, возможно, realloc ()


Так. У меня есть ощущение, что, поскольку у нас было очень мало людей, комментируют, что никто не слишком сует.

Ну, за исключением того, что параметры размера буфера должны быть в конце списка аргументов

Но еще одна вещь озадачивает меня, я думал, что у Либмапла уже был буфер чтения

Разве это изменение также не сделало бы буфер чтения необязательным?

Или я что -то упускаю ?

Rogerclark написал: Я думаю, что есть еще одна ветка, где было отмечено, что называя сериал.Begin () снова и не называть серийный.End () сначала может не работать в любом случае.

Но если Malloc называется из серийного.begin () мы должны позвонить бесплатно в сериале.end () просто чтобы быть последовательным.

Я полагаю, в сериале.Begin () Если указатели не являются нулевыми, свободные могут быть вызваны по указателям или, возможно, realloc ()

Уважаемая все, мне кажется, что вы продолжаете говорить в абстрактном.
Таким образом, я думаю, что ничего не будет улучшено..

Особенности/преимущества предлагаемого, которое я предложил:

• Buffered USART TX на основе прерываний (это может значительно ускорить время отклика TX)
• Распределение буферов выполнения на единственных сериалах USART, эффективно «начинается» (буфер в любом случае эффективно выделяется с использованием Malloc () в Ring_buffer "rb_init ()", а не в сериале.начинать())
• Не нужно выделять буфер по умолчанию на неиспользуемых сериалах USART
• Deallocation ранее выделенного буфера (если есть) в случае, если RB_INIT называется более одного раза на одном и том же кольцевом буфере
• Поддержка неблокирующего TX (блокировка по умолчанию)

Возможные недостатки:

• Фрагментация кучи на случай, если один и тот же сериал начинается несколько раз с разными размерами буферов
• rb_init () Изменение интерфейса: это требует переработки кода в коде пользователей, который явно использует Ring_buffer -> Я просто думаю об этом, и я думаю, что должен сделать это обратно совместимым
• Нет повторного использования одного и того же буфера в случае, если RB_INIT вызывает на существующем кольцевом буфере с тем же размером буфера -> Легко исправить
• Не знаю, как справиться с возможными неудачами Malloc (), любое предложение?

@Roger: буферы (для начинающих устройств) не являются обязательными, что является необязательным только устанавливать свое измерение, которое должно быть >= 1 для буферов TX и >= 16 для буферов RX (если меньше указанного по умолчанию до минимума).

Чего я не понимаю в текущем коде, если вы не используете Serial, Serial1, Serial2 или Serial3 в вашем коде, почему компилятор не оптимизирует неиспользованные переменные и выпал кода? Флаги, кажется, там есть, что сделало бы это:

-FFUNCTION-SECTION-FDATA-сечения в Compile и -WL,-GC-сечения At Link.

Глядя на скомпилированный код, который, кажется, там, кажется, там.

-рик

Рик Кимбалл написал:Чего я не понимаю в текущем коде, если вы не используете Serial, Serial1, Serial2 или Serial3 в вашем коде, почему компилятор не оптимизирует неиспользованные переменные и выпал кода? Флаги, кажется, там есть, что сделало бы это:

-FFUNCTION-SECTION-FDATA-сечения в Compile и -WL,-GC-сечения At Link.

Глядя на скомпилированный код, который, кажется, там, кажется, там.

@Rick kimball
@devan

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

Итак, дайте вам мнение !

(Лично у меня нет никаких возражений, но эта тема должна удостовериться, что демократия сообщества соблюдается ...)

Martinayotte написал:Итак, дайте вам мнение !

В целом, я бы предпочел статическое распределение по поводу динамического распределения-проще анализировать-динамические ассигнования не будут включены в оценку первого порядка, которую вы можете получить, просто запустив Arm-None-Eabi-Size. IDE сообщает об использовании «Динамическая память», но я подозреваю.

Учитывая, что Arduino/Plink/Wirish Way - это неявно включать вещи, чтобы средний пользователь не должен был просить их, я согласен с Роджером, что мы должны просто распределить буферы по умолчанию. Я думаю, что пользователи, которые занимаются использованием всех 20 киб SRAM, достаточно осведомлены, чтобы вручную применить патчи, необходимые для того, чтобы вернуть 2-3 киб, используемый пустым эскизом.

Деван написал:Учитывая, что Arduino/Plink/Wirish Way - это неявно включать вещи, чтобы средний пользователь не должен был просить их, я согласен с Роджером, что мы должны просто распределить буферы по умолчанию. Я думаю, что пользователи, которые занимаются использованием всех 20 киб SRAM, достаточно осведомлены, чтобы вручную применить патчи, необходимые для того, чтобы вернуть 2-3 киб, используемый пустым эскизом.

Как человек, который на самом деле не использовал Arduino IDE за долгое время, я, вероятно, не представитель типичного пользователя, и у меня нет реальной ставки в решении серийного буфера (поэтому я не сделал » ТО МОЕМ МОГО ОСОБЕННО о том, пока не станут.

Эдогальдо, я думаю, что в последовательном буфере много ценности, который взаимодействует с динамическим распределением памяти. Тем не менее, мое общее ощущение в том, что менее несправедливое динамическое распределение лучше (я переопределяю Malloc и бесплатно без пространства, не сэкономив на предыдущем неардино-проекте). Конечно, использование статических буферов представляет неоправданные статические распределения, так что это действительно вопрос предпочтения.

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

В прошлом, когда я смотрел на метод sbrk () в Arm-none-ebi-gcc, он использовал для распределения больших кусков памяти, чем вы просили. Таким образом, запрос 64 байта может в конечном итоге выделить 256 байтов или более. Кажется, что полу недавние характеристики = nano.Спецификации функции инструментального оборудования для Arm-None-Eabi более эффективны. Несмотря на то, что накладных расходов не было нулевого, быстрый взгляд на вызовы в SBRK () в отладчике выявили 72 байта, используемые для запроса на 64 байта Malloc. Так что я думаю, что это смягчает мое отвращение к Маллоку.

Один комментарий о Malloc, однако, если вы собираетесь маллоку, лучше выделить и использовать и использовать одинаковые запросы Malloc, чтобы он мог легче восстановить освобожденную память. Таким образом, вместо выделения 57 байтов и 62 байтов используют 64 -байт -запрос Malloc для них обоих. Это уменьшит фрагментацию кучи.

-рик

О да, и, как Деван, я действительно не заинтересованная сторона здесь.

Деван написал:[...]
Я подозреваю, что большинство пользователей не столкнутся с какими -либо проблемами с ни одной реализацией.