Беспроводная передача данных Опции

[amiller]

Приветствую!
Возникла задача сделать канал передачи данных между основным устройством на микроконтроллере и пультом управления (тоже на микроконтроллере).
Сначала я сориентировался на блютуз модули типа НС-05 и НС-06.
Закупил несколько штук, удалось настроить канал связи достаточно легко.
Тестировал в двух вариантах:
1. COM-порт блютуза от ноутбука - НС-05 (slave) - UART микроконтроллера.
2. USB-UART - НС-05 (master) - НС-05 (slave) - UART микроконтроллера.
В принципе связь есть в обоих случаях, но с проблемами.
У меня протокол полудуплексный, спроектирован под RS485: запрос - ожидание ответа - если таймаут, то новая попытка.
А эти модули похоже отправляют данные пачками, т.е. мои запросы набиваются в буфер и при его заполнении или по таймауту (достаточно большому), происходит передача целого блока. С ответами тоже самое. При этом эффективная скорость передачи данных получается примерно на порядок меньше расчётной.
Конечно можно переделать ПО для связи, сделать отдельные очереди на передачу и прием с разбором и распределением ответов, хотя это не избавляет от задержек реакции на единичный запрос.
Но вдруг есть способ настроить эти модули (размер буфера, интервал передачи данных). Может у кого есть опыт успешного использования?
Может есть варианты перепрошивки модулей. Кстати для их прошивки я находил только реализацию программаторов на базе LPT. Может кто видел решение посовременнее?
Или предложите совсем другое решение. Цель в общем то понятна из названия.

Сообщение отредактировал amiller - Apr 12 2017, 03:37

[V_G]

1. БеСпроводная
2. Китайские модули HC05 ужасно плохо документированы (по состоянию на 5 лет назад, когда я рассматривал их применение). Было на что-то более солидное описание, где расписывались эфирные пакеты и эфирные таймауты. В первом случае (если не пользоваться механизмом таймаутов) вам просто надо забить любым мусором свой пакет от конца информационной части до конца эфирного пакета. Во втором случае надо попробовать настроить таймауты блютус-модуля, чтобы он выдавал в эфир незаполненный буфер. В любом из этих случаев в эфире будет присутствовать мусорная часть пакета. В третьем случае можно попробовать подогнать длину эфирного пакета под Вашу длину (если протокол и система команд модуля позволяют менять длину эфирного пакета)

[amiller]

2. Китайские модули HC05 ужасно плохо документированы (по состоянию на 5 лет назад, когда я рассматривал их применение). Было на что-то более солидное описание, где расписывались эфирные пакеты и эфирные таймауты. В первом случае (если не пользоваться механизмом таймаутов) вам просто надо забить любым мусором свой пакет от конца информационной части до конца эфирного пакета. Во втором случае надо попробовать настроить таймауты блютус-модуля, чтобы он выдавал в эфир незаполненный буфер. В любом из этих случаев в эфире будет присутствовать мусорная часть пакета. В третьем случае можно попробовать подогнать длину эфирного пакета под Вашу длину (если протокол и система команд модуля позволяют менять длину эфирного пакета)

С этим согласен. И интерфейс управления через AT-команды убогий. Забивать буфер мусором, при этом не зная его реального размера, тоже не очень эффективно. я надеялся, что можно простыми средствами изменить настройки модуля, но похоже не судьба. Видимо придётся переходить в реализации протокола от уровня отдельных сообщений к уровню обработки потоков данных. При этом заполнение буферов произойдёт автоматически.

Пере прошивать можно.Для реализации вашей задачи нужно создавать прошивку, но слава богу не с нуля.Качайте Bluelab 4.1, в месте с ним будет доступны примеры, интерактивная справка по структурам, функциям, перечислениям и.д. , через браузер. Там же и документация по программированию. По всей видимости на BC417 доступно только программирование на СИ, так как во всей документации я не нашел информации по MCU XAP, не смог найти и по ассемблеру, накопал только по XAP4,5,6, все что ниже как будто засекретили.В блюкор чипах уже с завода предустановлена прошивка.Программист имеет возможность создавать программу, которые взаимодействует с Виртуальной машиной и работает с уже встроенной прошивкой.Как я понял там несколько кольцевых буферов, все тонкости не знаю, сам учусь, в качестве любителя, но думаю размер буфера настроить можно.Отлаживать и запускать можно прям на Ваших платках, через SPI LPT.USB SPI для SCR bluecore продают китайцы на али.Есть решение на FTDI чипе, но у меня не вышло, так как я самостоятельно сделал платку, а чип оказался поддельный, мне кажется проще купить готовый USB to UART с FTDIRL.

Путь погружения в программирование блютуз модулей выглядит слишком затратным. Часть моего вопроса была ещё в том, что может быть известны другие работоспособные варианты реализации беспроводного канала связи.
Желателен конечно блютуз (из-за распространенности), но не исключены и другие технологии.
Или же, как пишет уважаемый zltigo "2)Все радиоитерфейсы ПАКЕТНЫЕ а не байтовые в отличие он UART." Следовательно при беспроводной передаче данных следует просто это учитывать.

[jcxz]

Путь погружения в программирование блютуз модулей выглядит слишком затратным. Часть моего вопроса была ещё в том, что может быть известны другие работоспособные варианты реализации беспроводного канала связи.
Желателен конечно блютуз (из-за распространенности), но не исключены и другие технологии.

Так и их вагон + маленькая тележка.
При отсутствии других требований, можно выбрать то, что попроще в реализации и предсказуемо себя ведёт: например nRF24L01 - описание простое, подробное.
BT я бы выбирал в последнюю очередь, если только нужна связь устройство - комп(телефон) без доп. устройств на стороне компа(тела) и если в этом случае нельзя почему-то использовать WiFi.
И работа с ними на МК гораздо проще чем уродским интерфейсом АТ-команд и прошлого века терминалов и пользователей.
Не понимаю - почему так народ на этом BT зациклен??? Если нужна радио-связь, то и следует выбирать радио-связь, а не левую надстройку над ней.

[amiller]

Так и их вагон + маленькая тележка.
При отсутствии других требований, можно выбрать то, что попроще в реализации и предсказуемо себя ведёт: например nRF24L01 - описание простое, подробное.
BT я бы выбирал в последнюю очередь, если только нужна связь устройство - комп(телефон) без доп. устройств на стороне компа(тела) и если в этом случае нельзя почему-то использовать WiFi.
И работа с ними на МК гораздо проще чем уродским интерфейсом АТ-команд и прошлого века терминалов и пользователей.
Не понимаю - почему так народ на этом BT зациклен??? Если нужна радио-связь, то и следует выбирать радио-связь, а не левую надстройку над ней.

nRF24L01 посмотрю, спасибо.
Почему блютуз, - я для себя так ставил задачу:
У меня в производстве достаточно много разных устройств с управлением по последовательному интерфейсу.
Хотелось иметь в качестве опции универсальное беспроводное решение.
Чтобы можно было управлять с ноутбука, с телефона, и с собственного микроконтроллерного пульта, поставив туда беспроводной адаптер.
Поэтому и выбрал такое предварительное решение. А сейчас хочу или утвердится в этом решении или сменить на другое.

[bassizlink]

nRF24L01 посмотрю, спасибо.
Почему блютуз, - я для себя так ставил задачу:
У меня в производстве достаточно много разных устройств с управлением по последовательному интерфейсу.
Хотелось иметь в качестве опции универсальное беспроводное решение.
Чтобы можно было управлять с ноутбука, с телефона, и с собственного микроконтроллерного пульта, поставив туда беспроводной адаптер.
Поэтому и выбрал такое предварительное решение. А сейчас хочу или утвердится в этом решении или сменить на другое.

Почему бы вам просто не включить аппаратное управление потоками например изменив ключ "UART configuration when under VM control"(PSKEY_UART_CONFIG_USR), в PSTool , на 0x08a8 , в ваших HC05,06, проделать что то похожее на других микроконтроллерах, добавить пару лишних проводов и гарантированная передача данных без переполнения буферов готова.

Если у вас нет LPT, то купите себе вот этот адаптер https://www.aliexpress.com/item-img/Wavesha...2728399302.html
Поставьте себе вот этот драйвер https://github.com/lorf/csr-spi-ftdi, там и распиновка есть.

Сообщение отредактировал bassizlink - Apr 12 2017, 11:23

[bassizlink]

Программно управление потоком можно задействовать так:

PioSetRts (True) //устанавливает лог 1 на контакте RTS, это говорит о готовности принимать данные, в противном случае виртуальная машина автоматически меняет лог на 0.

PioGetCts () // активизирует Cts на прием, Виртуальная машина начинает реагировать на входящий сигнал.