Порядок передачи бинарного числа по USART.

Собственно, на что ориентироваться.

Имеется бинарное 32-разрядное число, например 0x12345678 unsigned int/32
В памяти (стандарт Intel) оно расположено

. . . 0x78 0x56 0x34 0x12 . . . .

Как это число передать по каналу связи в составе пакета:
---------------------------------------
(1) . . . 0x78 0x56 0x34 0x12 . . . .
или
(2) . . . 0x12 0x34 0x56 0x78 . . . .
---------------------------------------

(?) Есть ли какой либо стандарт, правило, обычай, традиция итд итп
как правильно (1) или (2) ?

Разницы никакой нет, главное, чтобы принимающая сторона таким же образом собрать правильное 32-битное число. То есть всё будет определяться протоколом, который вы придумаете.
А вот над чем действительно надо думать - что будет с потоком байт, если какой-то из байтов будет искажен или потерян. В этом случае принимающая сторона не сможет собрать 32-битное число, а также все последующие (если не предпринять соотв. мер), и т. д.

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

Если "все свое", то да. Главное, чтобы было однозначное преобразование при передаче в канл и при приеме.
Но может есть какая-то стандартизация, например как MODBUS-RTU укладывает. (надо там посмотреть будет)

Мне удобнее было бы передавать данные так, как они уложены в памяти. И принимать в том же порядке.
Но если одно и тоже ПО, передача с PC, а прием на MAC - будет фонарь.

С "потоком байт" проблем нет, если изначально отказаться от потока, а работать с фреймами/кадрам.
Отсечка пакета производится по межпакетной паузе (во многих контроллерах сделано аппаратно)

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

Вот только Винды о хитрости с паузами не знают. и при передаче из РС они могут сделать какую угодно паузу...И в каком угодно месте...

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

Используйте функции преобразования: http://www.intuit.ru/studies/courses/2249/...ure/1567?page=5

Там у них (виндузный драйвер) 3 настройки таймаута - можно юзать их. Я по крайней мере их пользую.





Ok
Спасибо за инф.
Сетевой порядок посмотрю.
--------------------------

Думаю таки более правильно передавать в "Motorola" - порядке (т.е. сперва передаются старшие разряды ),
так как при подсчете CRC пакета, и наличии в конце его CRC16, которая расположена как <CRC_Hi> <CRC_Lo>
мы должны получить CRC == 0

А поскольку для этого CRC должна передаваться как <CRC_Hi> <CRC_Lo>, то и все остальные числа передаются
аналогично.

---- Посмотрел. Все ясно -----------
. . . .
Как известно, порядок байт в целых числах, представление которых занимает более одного байта, может быть для различных компьютеров неодинаковым. Есть вычислительные системы, в которых старший байт числа имеет меньший адрес, чем младший байт (big-endian byte order), а есть вычислительные системы, в которых старший байт числа имеет больший адрес, чем младший байт (little-endian byte order). При передаче целой числовой информации от машины, имеющей один порядок байт, к машине с другим порядком байт мы можем неправильно истолковать принятую информацию. Для того чтобы этого не произошло, было введено понятие сетевого порядка байт, т.е. порядка байт, в котором должна представляться целая числовая информация в процессе передачи ее по сети (на самом деле – это big-endian byte order). Целые числовые данные из представления, принятого на компьютере-отправителе, переводятся пользовательским процессом в сетевой порядок байт, в таком виде путешествуют по сети и переводятся в нужный порядок байт на машине-получателе процессом, которому они предназначены.
. . . . .

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

Да! Да! Враг не пройдет, паузы наружу не вылезут умирая в "нормальном FIFO". В этом же "нормальном FIFO" сгинут и нужные Вам паузы по которым собрались что то там "отсекать". Сюрпиз!

А вот и не сюрприз!
Есть событие EV_TXEMPTY и WaitCommEvent функция, которые позволяют разблокировать передающий поток по завершении передачи данных. Также есть таймеры, отсчитывающие нужную паузу (см. CreateWaitableTimer).
И вообще - при грамотном использовании виндовых механизмов (потоки, события и overlapped-структуры) последовательный порт работает вполне себе неплохо.

Я собственно, в смысле настройки драйвера.
Значения 123 456 789

"Функции" моут быть декларированы любые. Суть в том, что для начала просто НЕТ в железе сигнала, который сообщит хоть "драйверу", хоть "функции", что передача данных завершена в части разгрузки Shift регистра, а не только FIFO.

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

не сочтите за наглость, но позвольте вас расстроить. вернее - чтобы это было более убедительным - удостоверьтесь самостоятельно
http://www.tahapaksu.com/crc/

а если ещё и всякой чудо используется в виде инверсии )))

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

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

т.о.:
- где необходима переносимость и многоплатформенность - рулит моторола и сетевой порядок.
для стыковки своего девайса и девайсов других производителей по какомулибо стандартному протоколу
вроде 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

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