Порядок передачи бинарного числа по USART, 0x1234 --> (0x12 0x34) или (0x34 0x12 ) Опции

[k155la3]

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

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

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

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

[aiwa]

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

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

Как пример.

Код

"интеловский порядок" для "интеловской" архитектуры:
typedef struct
{
// поля
}t_structA;
typedef struct
{
// поля
}t_structB;

на передающей стороне:
t_structA A;
t_structB B;

int index=0;
memcpy(buf_send[index],&A,sizeof(t_structA));
index+=sizeof(t_structA);
memcpy(buf_send[index],&B,sizeof(t_structB));
index+=sizeof(t_structB);

на принимакющей - аналогичное копирование.

Причем, если сохранять данные не нужно, а требуется лишь реакция на них, то работа прямо из приемного буфера:
t_structB& B =  (t_structB*)&buf_recieve[sizeof(t_structA)]);
if(B.поле) и так далее

При "сетевом" порядке на интеловской арихитектуре прийдется собирать лего в зависимости полей структур.

[k155la3]

. . .
[code]
. . . .
t_structB& B = (t_structB*)&buf_recieve[sizeof(t_structA)]);
. . . .

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

[zltigo]

то я бы посоветовал выбрать "интеловский" порядок байт в силу распространения такой архитектуры.

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

Тут может быть (лотерея) засада. Т.к. у компиятора "свое мнение" по поводу раскладки данных по полям структур - выравнивание.

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

[k155la3]

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

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

[Kabdim]

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

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

[aiwa]

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

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

[k155la3]

. . . . .
А корректная обработка - это уже забота не компилятора, а программиста.

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

[zltigo]

>> естественному порядку
Он естественный только потому что когда его выбрали для эзернета

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

, когда ясности какой эндианес победит не было.

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

Сейчас естественный порядок это интел. И арм пророк его.

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

[Kabdim]

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

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

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

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

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

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

[k155la3]

. . .
Если нет конкретных аргументов против такого подхода, ТС их не предоставил.
. . .

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

[zltigo]

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

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

Мое мнение удобство сейчас...

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

[Kabdim]

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

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

[zltigo]

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

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

[Kabdim]

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