[jcxz 184]

Интересно: есть тут люди, кто реально в серьёзных проектах пользуется Bluegiga WT12?

Не поиграть и попробовать, а для заказчика, профессионально.

С какими проблемами в ней сталкивались? Какое мнение о ней?

 

PS: Спрошу конкретней: неужто на баги в парсере команд UART-а WT12 никто не наступал?

[AlexandrY 2]

PS: Спрошу конкретней: неужто на баги в парсере команд UART-а WT12 никто не наступал?

 

Применял WT11. Система команд думаю у них одинаковая.

 

Все функции не использовал, только беспроводной COM порт.

Но настройка показалась очень простой хотя она и не похожа на традиционный формат AT команд.

Связь держалась хорошо, остался доволен.

[jcxz 184]

Я не про систему команд, а про их реализацию.

Столкнулся с багом в парсере команд WT12:

если дать команду WT12, на которую он должен ответить каким-то ответом, то, если в этот-же момент происходит

какое-то событие, то сообщение о событии перемешивается с ответом WT12 на команду.

Например: сообщени о событии разрывает одну из строк ответа на команду и приходит внутри неё.

Разобрать потом получившуюся кашу в общем случае невозможно.

Ниже - один из таких случаев: дана команда SLEEP и в этот момент приходит RING (строки с '<<' - TX; с '>>' - RX).

(включено эхо команд и "OK." после результата команды; скорость 115200).

<<SLEEP
>>SLRING 0 00:02:72:37:68:ba 1 RFCOMM  2b4fae2
>>EEP
>>OK.

Происходит довольно часто. Для теста достаточно передавать непрерывно какую-нить команду и в этот момент к примеру попытаться сделать входящий коннект.

 

Иногда это усугубляется потерей нескольких символов из ответа на команду (думал пофиксить баг костылём с поиском асинхронных событий внутри всех ответов

на команды, но потеря символов ставит крест на таком костыле).

 

Неужто никто с таким не сталкивался????

Когда выбирал этот модуль и просматривал здесь и в других местах отзывы о нём, ничего о таком не слышал. Иначе бы вообще не выбрал WT12... :(

 

Есть ещё и другие баги, но этот самый серьёзный.

[goodwin 0]

Под Новый Год интенсивно возился с WT11. Это то же самое, только с усилителем мощности (класс 1).

Версия iwrap довольно стаарая, т.к. приобретал давно.

И сам модуль, и iwrap оставили только положительные эмоции, ибо до него вошкался с "китайцем за 5$".

Сначала пытал headset профиль (хотел пробросить PCM) - работает.

Потом решил обойтись SPP.

Беспроблемное соединение, связь, режимы энергосбережения и настройки по-умолчанию посредством AT команд.

Никаких косяков не обнаружил.

В общем, модуль стОит того, что за него просят. Качество с "китайцами" не сранить, хотя железо то же самое.

 

PS: Проект не в тему топика - "несерьезный - Новогодний" ;)

http://www.youtube.com/watch?v=_EPVk6mKlM8

 

ЗЗЫ: Да, модуль во время экпериментирования вел себя аналогично - ответы "перемешивались".

Но так, как мне нужен только SPP, отключаю вообще эхо после инициализации.

[jcxz 184]

ЗЗЫ: Да, модуль во время экпериментирования вел себя аналогично - ответы "перемешивались".

Но так, как мне нужен только SPP, отключаю вообще эхо после инициализации.

Это мало помогает, только снижает вероятность.

При нормальной работе эта проблема чаще всего проявляется если сделать коннект и сразу дисконнект.

Коннект у меня с авторизацией и всякими LIST и прочими для контроля и корректировки режимов соединения (SNIFF и т.п.) и

получается что сообщение о дисконнекте NO CARRIER 0 ERROR 0 перемешивается с обрабатываемыми в этот момент командами.

Или наоборот - если после дисконнекта хост сразу снова делает попытку коннекта (а в этот момент к WT12 от МК идёт поток команд после

завершения соединения: LIST и т.п.).

А если ещё учесть что приложение на хосте не знает что делает в данный момент встроенное ПО и может попытаться коннектиться в момент когда

встроенное ПО выполняет сброс и инициализацию WT12 (с кучей команд и ответов на них), то вообще труба. Хоть это и очень редко бывает.

 

Хорошего решения проблемы не вижу. Единственное, что смогли сделать - задали хосту временные ограничения (таймауты) между коннектами/дисконнектами.

 

Да, и ещё есть эти потери символов в ответах на команды.

Хотя случается это довольно редко (при вкл. эхе команд ~ 1 раз на 1000 коннектов; при выкл. эхе ~1раз на 2000 коннектов).

Но когда случается, приносит много проблем - прошивка МК не распознаёт ответ на команду и соотв. пересбрасывает WT12 по ошибке.

В результате - виндовое приложение на хосте зависает на попытке открытия COM-порта примерно на минуту и только после этого вываливается с ошибкой.

Принудительно закрыть раньше чем через минуту невозможно :(((((

[jcxz 184]

Хочу добавить ещё ложку дёгтя сюда в мнение о WT12. :(

Недавно выяснил, что данная проблема (наложение сообщений о событиях в модуле на текущий обмен по UART) проявляется не только в командном режиме как описывал ранее.

Оказывается сообщения о событиях в модуле (асинхронные сообщения) могут приходить даже тогда, когда модуль находится в DATA-режиме

(SPP-профиль, никаких MUX-режимов не включено)!

Т.е. - хост под виндой открыл COM-порт, начался обмен данных с моим устройством - данные идут туда и сюда, всё ок.

И тут - я пробую открыть COM-порт с другого компа (этот COM тоже сопряжён с моим устройством) и вдруг вижу в потоке символов от удалённой стороны (идущих от WT12)

строку RING .... (у меня включены уведомления о входящих коннектах).

Другие события не пробовал, но раз есть RING, то думаю будут и PAIR и др.

В этом свете теперь непонятно как вообще работать с WT12 если он так гадит прямо в данные???

В документации на WT12 явно утверждается, что в DATA-режиме я могу получать только:

1. данные от удалённой стороны;

2. "NO CARRIER X ERROR Y" (уведомление о разрыве по инициативе удалённой стороны);

3. "READY." (уведомление о разрыве по инициативе локальной стороны).

 

PS: Меня уже ничего не спасёт - проект уже в производстве и остаётся только ставить костыли, ограничивать функционал и смириться с этими граблями

(BlueGiga проблему признаёт, но исправлять firmware не собирается).

Но остальных, кто только выбирает "на чём", хотелось-бы предостеречь о данном баге.

Если-бы я в своё время нашёл где-то упоминание о таком баге, то не выбрал бы WT12. И кучу времени сэкономил-бы...

[dx40 0]

У меня был следующие проблемы. Есть некое устройство,практически постоянно, на скорости 115200 выдает данные в ком-порт. Принимать даные не надо. Подключаю настроенный WT12 и ничего толком не работает - входящие соединения то принимаются, то не принимаются, если присоединился - то данные идут нормально, но второй раз точно не соединится. Ок, не хотел это делать, но реализую анализ ответов от WT12 и передаю данные если есть Connect, перестаю передавать по разрыву. Теперь соединения проходят нормально, но за те пару мс, что проходят от разрыва соединения до того момента, как мой проц перестает слать данные - WT12 обычно успевает словить глюк.

В итоге кинул провод на ножку процессора от на PIO2 и вывел на нее статус командой SET CONTROL CD 4 1

Работает, конечно. Но осадок остался.