как плохо это должно использовать динамический datastuctures во встроенной системе?

Это зависит от того, как значение слова «встроенный», на мой взгляд, расширилось за последние 4 года.

Традиционно на встроенных устройствах были микроконтроллеры и, как правило, не было операционной системы. Без защищенной памяти и были однопоточными. Вы должны быть очень осторожны с malloced памятью, потому что ее очень легко исчерпать, когда у вас, например, доступно только 32 КБ. Так что, как правило, мы пишем наш код с буферами фиксированного размера и никогда не используем malloc или at, если бы он использовался постоянно - очень экономно.

В последние несколько лет мы наблюдаем, что по сути является одночиповым ПК или микроплатами, которые такой же мощный, как наши старые ПК Pentium. Цены на оперативную память сейчас настолько дешевы и настолько малы, что ограничения памяти совсем не такие, как раньше. Они также часто запускают встроенный Linux или wince, поэтому теперь у нас есть возможность более свободно использовать динамическую память.

Благодаря этому появилась возможность использовать гораздо более широкий спектр языков, включая Java, C ++, многие языки сценариев и другие языки, которые предоставляют защита от переполнения буфера и обработка исключений и другие языки более высокого уровня. Так что на самом деле эти старые проблемы не такие, какими были раньше.

Я подозреваю, что все это новое доступное оборудование связано с новым набором проблем.

У меня сложилось впечатление, что во встроенной системе я точно знаю, сколько памяти доступно, и мне разрешено использовать ровно 100% ее; нет необходимости оставлять немного для других (одновременно работающих) программ, но также нет доступной виртуальной памяти, чтобы дать мне 101-й процент. Итак, для очереди я могу легко вычислить, что у меня есть место для (скажем) 981 записи; поэтому я создаю массив для этих записей, и если мне когда-нибудь понадобится 982-я запись, я буду в затруднении и должен найти способ корректно завершить работу.

Что ж, многие микроконтроллеры меньшего размера не имеют ничего вроде MMU или ОС с Хорошая куча для вас, с которой можно поработать.

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

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

Я бы сказал и нехватку памяти, и проблему неудачного malloc. Последнее является более серьезной проблемой, поскольку у вас нет ОС / интерфейса, чтобы спасти систему от такого сбоя. Очень опасно использовать функцию, которая может привести всю вашу систему, которая может работать без головы, к резкой остановке (или, возможно, вызвать сброс, все еще плохо).

Нет ничего плохого в динамической памяти во встроенной среде как таковой, хотя, как правило, во встроенной среде она не приносит вам много денег.

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

Использование некоторых макросов позволяет выделять структуры переменного размера во время компиляции.

Например -

    //we exploit the fact that C doesn't check array indices to allow dynamic alloc of this struct
    typedef struct ring_buf_t {
        int element_sz,
            buffer_sz,
            head,
            tail;
        char data[0];
    } ring_buf_t;

   #define RING_BUF_ALLOC_SZ(element_sz,n_elements) (sizeof (ring_buf_t) + \
                                                      (element_sz) * (n_elements))

    char backing_buf[RING_BUF_ALLOC_SZ (sizeof(type_to_buffer), 16)];

    //ring_buf_init() casts backing buf ring_buf_t and initialises members...
    ring_buf_t *ring_buffer = ring_buf_init (element_sz, n_elemements, backing_buf);

;

Этот шаблон представляет собой буфер динамического размера с гарантированным использованием памяти. Конечно, таким же образом могут быть реализованы и другие типы структур данных (списки, очереди и т. Д.)

Динамические структуры данных во встроенных системах немного похожи на указатели в C ++. Указатели (в C ++) - зло. Но иногда это единственный вариант; иногда они меньшее зло; а иногда вполне нормально полностью их избегать. В случаях, когда является веской причиной для их использования, могут быть «хорошие» и «плохие» способы сделать это.

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

Динамически выделяемые (я имею в виду malloc () ed или аналогичные) данные также требуют накладных расходов пространства для отслеживания распределения. По крайней мере, несколько байтов на выделение - это пространство может быть очень ценным для встроенных систем!

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

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

Я не знаю о Atmel MEGA169, но MEGA168, который, как я полагаю, связан с 169-м, имеет только 1024 байта SRAM. Он также имеет только 16 Кбайт программного ПЗУ и относительно медленный по сравнению с современными компьютерами. Таким образом, он ограничен в памяти, размере программы и скорости.

По моему опыту программирования на ассемблере AVR, нужно приложить усилия, чтобы втиснуть в PIC как можно больше функций. Объем накладных расходов, необходимых для использования динамических структур данных (дополнительное использование памяти, дополнительные инструкции, необходимые для извлечения и передачи данных из SRAM, отслеживание того, какая динамическая переменная где находится, перемещение блоков памяти при удалении промежуточных переменных .. ..) просто не оправдывает достоинств.

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