А я вот с утра, пока ждал будильника, подумал: а как вы, любители ртосей, решаете проблему аллокаторов?
Ведь в "младших" ARMянах нет возможности отобразить "кусочную" память на линейную виртуальную. Соответственно, выделять можно только целыми кусками, без разрывов. А это в итоге приведет к тому, что sbrk перестанет работать, т.к. кончатся целые куски нужного размера!

Статическое распределение памяти на этапе компиляции - и никаких проблем! Требование MISRA выполняется. В этом смысле РТОС не отличается от обычной системы.

Rapra, однако, бывают и любители аллокаторов. Зачем их тащить в МК - не понимаю, но как-то ведь тащат!

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

Добавлено after 3 minutes 41 second:
По поводу аллокаторов: работа со строками стандартными libc-функциями при статическом распределении памяти порождает большой расход памяти на промежуточные буферы... И борьба с этим, порой, страшнее динамического выделения стандартными же функциями.

У меня ПЛК исполняет задачу пользователя. Априори не известно, сколько потребуется памяти для буферов запросов, например, по Модбас, которые будет делать программа пользователя. Поэтому при старте МК у ОС запрашивается, например, 2К ОЗУ, размещением данных в которых управляют мои переопределённые new/delete. Поскольку формат данных известен, то получается работать внутри этих 2К без утечек памяти.

А как бороться с фрагментацией и отсутствием виртуального линейного адресного пространства?

Я же выше написал, что формат данных известен, плюс соответствующий подход к организации хранения, поэтому не возникает утечки памяти, вызванной её фрагментацией.

а вот такой вопрос, касающийся упаковки структур.
если я описал структуру с битовыми полями, то она по умолчанию будет упакована в 32-битную ячейку памяти, так?
а если мне надо, чтобы она упаковалась в 16-битную, что надо сделать? прагма там какая-нибудь или атрибут - что?

Нет.
Открываю описание языка:

Где здесь про 4 байта?
Пишу:

У g++ нет возражений.

нигде. если я не ошибаюсь, структура с битовыми полями пакуется в размер int по умолчанию, или кратно этому размеру. если активировать packed - тут я уже путаюсь, но в опциях AVR-GCC была возможность принудительно паковать в байт.

как в 32-битных системах - не знаю. просто мне нужно описать битовые поля для 16-битного доступа МК.

А я вам что показал? Или спецификацию языка не читали?

Или не знаете размер short?

хм... я ожидал, что все биты всех полей будут просуммировны и впихнуты в размер int независимо от размеров типов самих полей...

Такое выравнивание включают для ускорения доступа. Если этого не делать, то компилятор вставляет дополнительный код для извлечения таких данных.

То есть мой вопрос в итоге сводится к следующему: по умолчанию структура пакуется в минимальное количество байт или для этого надо какие-то опции включить?

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

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

если нужны настройки - то какие именно?

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

Думаю, ARV, имеет в виду выравнивание по 16-ти битам, а не заботится о занятой памяти.

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

Тогда #pragma pack