[Zelepuk 0]

Задался вопросом:

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

[adnega 10]

Задался вопросом:

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

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

[Edit2007 3]

И чем же они хороши? С таким же успехом можно взять 0x10, 0x21,0x32 ...0xFE

все равно байтовое сравнение, для простоты реализуемое через switch(){}

 

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

 

[uriy 4]

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

 

[MK2 0]

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

Работая с модулями HC-05, заметил такую вещь:

при разрыве соединения с платкой, данные на UART в блютуз модуль HC все равно слались в цикле. потом при восстановлении подключения эти данные все равно доходили в правильном порядке!

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

[Tarbal 4]

Вот хорошие 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 10]

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

Согласен, это первое что мне пришло в голову когда сказали "обоснуй".

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

В итоге решил, что в BT все давным-давно сделано и лучше если команды будут наглядными для пользователя: буквы 'w' - записать,

'r' - считать, 'f' - выключить, 'o' - включить и т.п. - в терминалке отлаживать проще будет. И не стал писать)

[uriy 4]

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

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

[DpInRock 0]

При передаче одного байта через BT по SSP получить ошибку нереально.

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

со скоростью UART (скорость в эфире всегда одинакова) чуть менее мегабита.

 

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

 

Т.е. забота о целостности - это забота BT.

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

 

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

Но если передавать что-то длинное, то тут чуть сложнее.

 

[Tarbal 4]

Согласен, это первое что мне пришло в голову когда сказали "обоснуй".

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

В итоге решил, что в BT все давным-давно сделано и лучше если команды будут наглядными для пользователя: буквы 'w' - записать,

'r' - считать, 'f' - выключить, 'o' - включить и т.п. - в терминалке отлаживать проще будет. И не стал писать)

 

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

Изменено 28 февраля, 2014 пользователем Tarbal

[uriy 4]

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

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