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

[k155la3]

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

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

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

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

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

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

Сообщение отредактировал k155la3 - Jul 29 2016, 08:37

[gerber]

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

[iosifk]

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

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

[k155la3]

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

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

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

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

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

[iosifk]

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

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

[andrew_b]

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

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

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

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

[k155la3]

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

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

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

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

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). Целые числовые данные из представления, принятого на компьютере-отправителе, переводятся пользовательским процессом в сетевой порядок байт, в таком виде путешествуют по сети и переводятся в нужный порядок байт на машине-получателе процессом, которому они предназначены.
. . . . .


Сообщение отредактировал k155la3 - Jul 29 2016, 12:47

[gerber]

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

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

[zltigo]

При наличии нормального FIFO в контроллере UART эти "виндовые паузы" не должны вылезать наружу.

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

[gerber]

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

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

[k155la3]

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

Код

        HANDLE hport_Wes;
    DCB dcb1;

    COMMTIMEOUTS CommTimeOutsW;
    GetCommTimeouts(hport_Wes, &CommTimeOutsW);    

    CommTimeOutsW.ReadIntervalTimeout     = 123;
    CommTimeOutsW.ReadTotalTimeoutMultiplier = 456;
    CommTimeOutsW.ReadTotalTimeoutConstant   = 789;

    SetCommTimeouts(hport_Wes, &CommTimeOutsW);
        succ=SetCommState(hport_Wes,&dcb1);

[zltigo]

Есть событие EV_TXEMPTY и WaitCommEvent функция, которые позволяют разблокировать передающий поток по завершении передачи данных.

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

[aiwa]

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

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

[smalcom]

CRC совершенно не зависит от порядка байт.

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

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

[aiwa]

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

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

Сообщение отредактировал aiwa - Sep 20 2016, 22:36

[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]

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