caxapa.ru :: ИМХО, никак. Обмен в радио и в проводе асинхронен, догадайтесь, что будет без буферизации. На низком уровне можно поковырять параметры QoS L2CAP(их там всего пяток). На уровне RFCOMM можно квитироваться сигналами RTS|CTS.

Хитрый Китаец (16.01.2013 17:34, просмотров: 184) ответил iizerg на Bluetooth модуль BTM-180. Прошивка профиль SPP.

ИМХО, никак. Обмен в радио и в проводе асинхронен, догадайтесь, что будет без буферизации. На низком уровне можно поковырять параметры QoS L2CAP(их там всего пяток). На уровне RFCOMM можно квитироваться сигналами RTS|CTS.

Ответить

- Не хочу догадываться, спрашиваю у тех то хочет и может объяснить в чем ошибка. iizerg(362 знак., 16.01.2013 17:46)
  - При хорошем протоколе склейка не проблема. - Vladimir Ljaschko(16.01.2013 18:21)
    - На хорошем протоколе протоколе пока остановились. - iizerg(16.01.2013 21:42)
      - Это Модбас имеется ввиду? - Vladimir Ljaschko(16.01.2013 21:55)
        
        Нет, Модбас пойдет уровнем выше. iizerg(300 знак., 16.01.2013 22:02)
        
        может проще всё-таки RTU->ASCII->Bluetooth->ASCII->RTU сделать, раз уж оверхед допускается? А там глядишь просто на ASCII перейдёте и всё, только для старых устройств преобразователь RTU/ASCII останется. Перезапросы блютузу вроде не нужны - koyodza(17.01.2013 18:51)
        
        Не совсем понимаю зачем первая часть "RTU->ASCII->Bluetooth" ? мастер может давать любой протокол. iizerg(125 знак., 17.01.2013 19:04)
        
        да, правильно. Тем более если мастеру пофиг, а пропускная способность достаточная, я бы так и делал. В мастере на всякий случай лучше иметь возможность работать хоть с ASCII, хоть с RTU - koyodza(17.01.2013 19:08 - 19:12)
        
        Не очень понимаю, Vladimir Ljaschko(170 знак., 16.01.2013 23:00)
        
        Так выглядит отправка одинарных запросов мастера и ответ на них слейвом. iizerg(35 знак., 17.01.2013 18:47)
        
        Одинарный запрос мастера 8 байт. Склеенный пакет выглядит как одна посылка длинной 16 байт. iizerg(125 знак., 17.01.2013 18:44)
        
        Не станет. Блютузный протокол сам бьёт посылку на пакеты, причём о размере пакетов стороны договариваются друг с другом в зависимости от глубины буфера. - Shura(16.01.2013 23:04)
        
        Логично. Тогда проще каждый пакет Модбаса в свою обертку и пусть все подряд склеивает - разрывает. - Vladimir Ljaschko(16.01.2013 23:42)
        
        Аффтар принял вполне логичное (ИМХО) решение - на повышенной скорости гнать всё скопом, а на приёмной стороне парсить и раздавать как положено. - Shura(16.01.2013 23:45)
  - Переделать в ДНК. Зачем вы взяли модуль с буферизацией, аппаратным контролем целостности пакетов и автоматической перепосылкой? Берите самый простой - получите абсолютный реалтайм и ебитесь дальше с ошибками сами. - Shura(16.01.2013 18:02)
    - Мы взяли - то что можно было быстро взять для старта. iizerg(372 знак., 16.01.2013 21:51)
      - Весь реалтайм регулируется QoS L2CAP, командами управления HCI Host_Buffer_Size, Set_Host_Controller_To_Host_Flow_Control, сигналы управления модемом DTR,RTS передаются по каналу управления RFCOMM. Вам придется подбирать их комбинацию под свои Хитрый Китаец(294 знак., 17.01.2013 12:38)
        
        Спасибо за объяснение. Позже появится время - будем пробовать вариант полностью через HCI. текущий момент - внешний контроллер будет выполнять реалтайм и парсинг клееных пакетов. - iizerg(17.01.2013 18:50)
      - Через HCI можно сделать практически реалтайм, но в таком случае всё равно ошибки вам придётся окучивать самостоятельно - Shura(16.01.2013 22:04)
- Так эти сигналы просто заблокируют передачу, независимо от того - передан пакет или нет - Shura(16.01.2013 17:46)

Мобильная и беспроводная связь