Очевидно Вы не работали никогда например с протоколами передачи данных. В кадрах которых данные находятся упакованными. И объявлять такие кадры удобно структурами.
Поэтому Вам и сложно представить такое применение.
И дырок в таких кадрах нет - ну не заложили их разработчики этого протокола!

Очевидно, что с таким пакетом работал бы по байтам. Ибо все "красивые решения" в конечном итоге так и работают. Под маской продвинутости прячут простоту.

Это называется "сериализация и десериализация". Это кошерно, халяльно и по феншую, народ одобряет. Там ещё индейцы большие и малые.
Но, к примеру, в lwip сделано через структуры. Это действительно удобнее.

А в следующей версии добавят байтик в середину и все смещения нужно будет выискивать по-новой.
Или некоторые переменные станут невыровненными и т.п.

В gcc объявляю так:

А все остальное - дело компилятора.
Правда, есть еще пара ключиков, относящихся к теме

А завтра переносим Вашу реализацию на процессор, умеющий работать с невыровненными данными и получаем неэффективность из-за кучи лишней возни с байтовым доступом и склеиванием этих байт в слова хотя на данном CPU это не нужно. И всё придётся переписывать.
А если работа идёт через члены пакованных структур, то код вообще менять не нужно - компилятор сам знает, что на данном CPU можно не разбирать {u32 x = y} на байты.

Легким движением руки структура превращается... превращается...



Убедили! беру __packed.

Как минимум для DS5 это несколько сложнее и требует внимания программиста. Для упакованной структуры нет предположений о том что её начало выравнено, поэтому такая оптимизация не произойдет в общем случае. Всегда будет рассматриваться худший случай невыравненного размещения. А невыравненный доступ на абсолютном большинстве архитектур дороже выравненного, поэтому если есть возможность привести данные в выравненное состояние то этим стоит воспользоваться.

Ну так на M3/M4 код генерируемый компилятором от этого не меняется. Меняется только время доступа к таким данным. Работать будет всё равно пусть медленнее немного.

ВЫРОВНЯТЬ, -яю, -яешь; св. (нсв. также ровнять). кого-что. 1. Сделать ровным, прямым без изгибов. В. поверхность. В. дорогу. В. шеренгу, строй. 2. что. Расположить, направить по прямой линии в вертикальной или горизонтальной плоскости. В. самолёт. 3. Сделать размеренным, равномерным. В. дыхание. В. шаг.
<Выравнивать, -аю, -аешь; нсв. Выравниваться, -ается; страд. Выравнивание (см.).
http://www.gramota.ru/slovari/dic/?lop=x&a...%8F%D1%82%D1%8C


выравнять(ся), -яю(сь), -яет(ся) (к равный)
http://www.gramota.ru/slovari/dic/?word=%D...D1%8C&all=x

см. выделенное жирным
Последние два поста (начиная с этого) они конечно очень к тебе относятся.

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

Я там видимо опечатался "к теме" имел ввиду.

Внутренний перфекционист негодует когда работает медленней, наверное его пора топить.

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

Так похоже поводов нет: если предположить, что реализация (в IAR) __aeabi_uread4 аналогична __aeabi_memcpy, то оба варианта идентичны по затратам.