передача данных по одному байту по блютус, нужен ли протокол? Опции

[Zelepuk]

Задался вопросом:
если я хочу передавать простые команды по 1 байту от телефона в моё устройство (микроконтроллер+блютус модуль), нужен ли протокол с контролем целосности данных? или можно просто так слать/принимать. Данные по 1 байту и всего возможно всего 10 различных байт (10 команд)

[adnega]

Задался вопросом:
если я хочу передавать простые команды по 1 байту от телефона в моё устройство (микроконтроллер+блютус модуль), нужен ли протокол с контролем целосности данных? или можно просто так слать/принимать. Данные по 1 байту и всего возможно всего 10 различных байт (10 команд)

Вот хорошие 14 команд с контролем целостности: 0x11, 0x22, 0x33... 0xEE.

[редактор]

И чем же они хороши? С таким же успехом можно взять 0x10, 0x21,0x32 ...0xFE
все равно байтовое сравнение, для простоты реализуемое через switch(){}

Формально протокол можно не делать.Но Рано или поздно возникнет вопрос:Что делать если команда не распозналась?" Ну не попадает она в список объявленных? Логичный ответ, запросить повтор - а это уже зачатки протокола. Да и передающее устройство никогда не знает принята его команда или нет. Оно конечно можно слать команду постоянно, раз в N-цать мс если мощности батареи не жалко. Это уж как пожелаете.

[uriy]

В блютуз в SPP протоколе данные не будут повреждены. Они либо придут либо нет.

[MK2]

В блютуз в SPP протоколе данные не будут повреждены. Они либо придут либо нет.

Работая с модулями HC-05, заметил такую вещь:
при разрыве соединения с платкой, данные на UART в блютуз модуль HC все равно слались в цикле. потом при восстановлении подключения эти данные все равно доходили в правильном порядке!
Т.е. достоверность приема так же есть в протоколе BlueTooth? или так просто реализован стэк в этом модуле?

[Tarbal]

Вот хорошие 14 команд с контролем целостности: 0x11, 0x22, 0x33... 0xEE.

Надо брать команды с максимальным расстоянием Хемминга.
http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%...%BD%D0%B3%D0%B0

Работая с модулями HC-05, заметил такую вещь:
при разрыве соединения с платкой, данные на UART в блютуз модуль HC все равно слались в цикле. потом при восстановлении подключения эти данные все равно доходили в правильном порядке!
Т.е. достоверность приема так же есть в протоколе BlueTooth? или так просто реализован стэк в этом модуле?

Блутуз имеет два вида соединения один надежный SCO (connection oriented) и используется для передачи данных, а другой ACL (connection less) используется для потоковых соединений как например аудио или видео. Точно как TCP и UDP.
Имея возможность программировать апликацию внутру чипа CSR вы можете выбрать любой из них для соединения.

[adnega]

Надо брать команды с максимальным расстоянием Хемминга.

Согласен, это первое что мне пришло в голову когда сказали "обоснуй".
Потом подумал, решил что в последовательном канале нужно скорее защищать от сдвига байна на один бит из-за рассинхронизации.
В итоге решил, что в BT все давным-давно сделано и лучше если команды будут наглядными для пользователя: буквы 'w' - записать,
'r' - считать, 'f' - выключить, 'o' - включить и т.п. - в терминалке отлаживать проще будет. И не стал писать)

[uriy]

Т.е. достоверность приема так же есть в протоколе BlueTooth? или так просто реализован стэк в этом модуле?

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

[DpInRock]

При передаче одного байта через BT по SSP получить ошибку нереально.
Если отойти от теории, то совсем недавно проверял конструкцию, в которой данные гонялись в обоих направлениях
со скоростью UART (скорость в эфире всегда одинакова) чуть менее мегабита.

Данные либо приходят верные, либо не приходят вообще. Так как гонял по SSP кодированный звук, то контролировал еще и на слух.

Т.е. забота о целостности - это забота BT.
А вот забота о самом соединении - вовремя делать реконнект, или НЕ делать реконнект, когда этого делать не надо - это забота внешняя.

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

[Tarbal]

Согласен, это первое что мне пришло в голову когда сказали "обоснуй".
Потом подумал, решил что в последовательном канале нужно скорее защищать от сдвига байна на один бит из-за рассинхронизации.
В итоге решил, что в BT все давным-давно сделано и лучше если команды будут наглядными для пользователя: буквы 'w' - записать,
'r' - считать, 'f' - выключить, 'o' - включить и т.п. - в терминалке отлаживать проще будет. И не стал писать)

Если вы используете SCO, а вы его будете использовать поскольку UART профайл использует его, то вы получите все свои байты в целости и сохранности. В таком случае забейте на расстояния хемминга. Никаких ошибок связи у вас не будет.

Сообщение отредактировал Tarbal - Feb 28 2014, 13:25

[uriy]

Если вы используете SCO, а вы его будете использовать поскольку UART профайл использует его

Ошибочка! UART не использует SCO. SCO для звука используется