Я так понял, что в этом вопросе нет "абсолютной истины", да это и хорошо, в общем.
Стандарт хорош, когда от него есть несомненная польза, а не ограничения ради "стандарта любой ценой".

т.о.:
- где необходима переносимость и многоплатформенность - рулит моторола и сетевой порядок.
для стыковки своего девайса и девайсов других производителей по какомулибо стандартному протоколу
вроде MODBUS - сетевой или настравиваемый на Intel/Moto

- для "доморощенных" и привязанных на платформу приложений - порядок "какойудобно"

Да, именно так. А учитывая, что ПК скорее всего x86, то удобней интеловский.

Как пример.

Тут может быть (лотерея) засада. Т.к. у компиятора "свое мнение" по поводу раскладки данных по полям структур - выравнивание.
К примеру, Вы "дообъявили" в проекте массив в RAM. Или изменили его размер. И ранее рабоавшая система клиент-сервер работать нормально перестала
Лучше готовить данные к передаче и разбирать по приему не из структур, а через сериализацию.
Сугубо IMHO.

Не надо выбирать интеловский, даже если в каком то случае типа PC-PC он "удобен". Все же "сетевой" порядок байт есть унифицированное решение и не надо вносить сумятицу в протколы. Лучше сразу раз и навсегда привыкайте к естественному порядку и соответственно пишите так, что бы Ваши наработки могли использоваться сразу на любой платформе без переработок и соответственно поддержки двух разных веток. Уж, поверьте сторому закоренелому протокольщику, что такой подход окупися сторицей.



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

Одобрямс.
Флеш в контроллере заполнена сейчас примерно на четверть. Будем делать настраиваемый режим.

>> естественному порядку
Он естественный только потому что когда его выбрали для эзернета, когда ясности какой эндианес победит не было. Сейчас естественный порядок это интел. И арм пророк его.
---
Правильная сериализация это конечно хорошо. Но во-первых это куча кода и сил. С учетом того что в коммерции кто первый сделал тот и папа, мама и получатель прибыли, то я бы сделал быстро грязно - интел и структуры. А если не выстрелит проект то не жалко будет что кучу времени и сил потратили на то что не взлетело. Получившееся бинарный протокол зафиксировал бы как эталон и добавил тестов на соответствие ему.

А да, мнение компилятора вполне предсказуемо. Но если сменился где-то компилятор и что-то сломалось - дорабатывай до эталона. Но случится это когда-нибудь и не факт что случится вообще. Ну и естественно при таком подходе нужно помнить где грабли лежат.
Сделать ассерты которые забьют тревогу если предположения о размерах/расположении разошлись с мнением компилятора. Включая базовые типы.
Использовать бит филды с осторожностью. Например gcc может наплевать на спецификатор типа битфилда и упаковать его в наименьший размер. Да и вообще битфилды те еще грабли, лучше их не использовать.
Размер енумов форсировать, самому.
Форсировать выравнивание. Помнить что где-нибудь на КортексМ0 невыравненное обращение - хардфолт влоб сразу. Поэтому если что-то из структуры нужно куда-то передать - лучше сразу копировать в др. буфер с нужным выравниванием.

Пример я привел лишь для иллюстрации, и "свое мнение" компилятора не имеет значения: главное как структурно оформлены данные в протоколе,
в котором и расписан порядок байтов и битов и их назначение. А корректная обработка - это уже забота не компилятора, а программиста.

Я, по ушлости характера, пытаюсь максимально переложить свои "обязаности" на компилятор и код

Мой юный друг, когда Вы узнали слово "эзернет", на белом свете существовало уже множество протоколов в том числе и МНОГО БОЛЕЕ продвинутых, чем IP c которым Вы ассоциируете слово "эзернет". Еще больше пртоколов родилось после этого слова. Так что не лезьте со своим уставом в чужой монастырь .

Не было и нет ни борьбы, ни победы. На БОЛЕЕ ПРОСТЫХ простых интелавских контроллерах более просто реализовывался определенный вариант. Вот и все.

Интел? Да ну? У меня в постоянной работе почти дюжина платформ и на большинстве из них Big-Endian. В том числе и часть ARM, всуе Вами помянутых, я использую в Big-Endian. Повнимательнее ознакомьтесь с возможностями ARM .

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

Именно. Мое мнение удобство сейчас лучше абстрактной "качественности" протокола, которая когда-нибудь может быть даст преимущество. Если нет конкретных аргументов против такого подхода, ТС их не предоставил.

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

Да выше я вродекак высказался.
-------------------
A - Если есть возможность / необходимость - сетевой порядок. Размер флеш позволяет. Быстродействие некритично.
Требуется максимальная переносимость. Клиент - на одной платформе. Сервер - на другой. итп
B - "Переключаемый" режим.
C - (экономим флеш, увеличить быстродействие, одна платформа и еще незнаючего) - свой протокол с любым нашим пожеланием.
. . . .
дописываем DEF ....

Тем, что хоть "новые", хоть "старые" пртоколы вменяемыми людьми делаются однообразно без уродливых прогибов под конкретные платформы, копиляторы... Big-Endian на самом деле есть естественный порядок и для восприятим человеком - поймете, когда, напимер, придется дампы протоколов рассматривать.

Мнение понятно, оно неправильное, что, конечно, не мешает лично Вам делать все хоть через "конскую задницу". Ну а мне соответственно указывать на прочность такого подхода.

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

Очень много пустых слов в попытке оправдать свой непрофессионализм . А суть проста, то, что для Вас кажется "проблемой" да еще требующей "бюджета, времени и денег" на самом деле для человека имеющего минимальный опыт профессиональной работы проблемой вовсе не является. Просто определенный стиль работы и ничего более. В таком стиле пишется разборка любого протокола и вообще НЕ думается о том на какой платформе все будет компилироваться. Затраты ресурсов на продумывание протокола несравнимы по заратам ресурсов на в совершенно бездумно рутинное фоновое шаблонное универсальное описание стуктур и столь-же шаблонное добавление network-to-host и host-to-network

Очень жаль что аргументов только два и они откровенно слабые: так всегда делали и читать логи проще. Для себя по топику пришел к выводу что порядок байт можно выбирать любым удобным.