Порядок передачи бинарного числа по 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-битное число, а также все последующие (если не предпринять соотв. мер), и т. д.

[k155la3]

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

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

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

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

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

[iosifk]

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

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

[gerber]

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

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

[zltigo]

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

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