Stm32 с чего начать изучение...

[linux_rulezz]

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

[Rapra]

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

[linux_rulezz]

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

[ARV]

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

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

[tonyk]

Зачем их тащить в МК - не понимаю

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

[linux_rulezz]

[uquote="tonyk",url="/forum/viewtopic.php?p=4790278#p4790278"]Поскольку формат данных известен, то получается работать внутри этих 2К без утечек памяти.[/uquote]
А как бороться с фрагментацией и отсутствием виртуального линейного адресного пространства?

[tonyk]

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

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

[ARV]

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

[tonyk]

так?

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

Код: Выделить всё

struct имя_структуры
{
    тип1 имя_поля1 : ширина_поля1;
    тип2 имя_поля2 : ширина_поля2;
    //..............
    типi имя_поляi : ширина_поляi;
}

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

Код: Выделить всё

struct
{
	short
		a:2,
		b:3;
}
packed_structure;

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

[ARV]

[uquote="tonyk",url="/forum/viewtopic.php?p=4790298#p4790298"]

так?

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

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

Код: Выделить всё

typedef struct{
  bool fld1 : 1;
  bool fld2 : 1;
} my_struct;

// нужно чтобы sizeof(my_struct) == 2

[tonyk]

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

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

Код: Выделить всё

struct
{
   short
      a:2,
      b:3;
}
packed_structure;

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

[ARV]

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

[tonyk]

[uquote="ARV",url="/forum/viewtopic.php?p=4790321#p4790321"]хм... я ожидал, что все биты всех полей будут просуммировны и впихнуты в размер int независимо от размеров типов самих полей...[/uquote]
Такое выравнивание включают для ускорения доступа. Если этого не делать, то компилятор вставляет дополнительный код для извлечения таких данных.

[ARV]

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

[Аlex]

[uquote="ARV",url="/forum/viewtopic.php?p=4790309#p4790309"]

Код: Выделить всё

// нужно чтобы sizeof(my_struct) == 2

[/uquote]

Код: Выделить всё

#pragma pack(push, 2)

typedef struct{
  bool fld1 : 1;
  bool fld2 : 1;
} my_struct;

#pragma pack(pop)

[tonyk]

[uquote="ARV",url="/forum/viewtopic.php?p=4790328#p4790328"]То есть мой вопрос в итоге сводится к следующему: по умолчанию структура пакуется в минимальное количество байт или для этого надо какие-то опции включить?[/uquote]
Не забывайте, что ещё есть линковщик, у которого есть свои настройки по выравниванию. Ваше

// нужно чтобы sizeof(my_struct) == 2

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

[ARV]

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

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

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

[Аlex]

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

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

[ARV]

[uquote="Аlex",url="/forum/viewtopic.php?p=4790337#p4790337"]

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

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

[Аlex]

да, именно. ....

Тогда #pragma pack