Впечатления о WT12 Опции

[jcxz]

Интересно: есть тут люди, кто реально в серьёзных проектах пользуется Bluegiga WT12?
Не поиграть и попробовать, а для заказчика, профессионально.
С какими проблемами в ней сталкивались? Какое мнение о ней?

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

[goodwin]

Под Новый Год интенсивно возился с WT11. Это то же самое, только с усилителем мощности (класс 1).
Версия iwrap довольно стаарая, т.к. приобретал давно.
И сам модуль, и iwrap оставили только положительные эмоции, ибо до него вошкался с "китайцем за 5$".
Сначала пытал headset профиль (хотел пробросить PCM) - работает.
Потом решил обойтись SPP.
Беспроблемное соединение, связь, режимы энергосбережения и настройки по-умолчанию посредством AT команд.
Никаких косяков не обнаружил.
В общем, модуль стОит того, что за него просят. Качество с "китайцами" не сранить, хотя железо то же самое.

PS: Проект не в тему топика - "несерьезный - Новогодний"
http://www.youtube.com/watch?v=_EPVk6mKlM8

ЗЗЫ: Да, модуль во время экпериментирования вел себя аналогично - ответы "перемешивались".
Но так, как мне нужен только SPP, отключаю вообще эхо после инициализации.

[jcxz]

ЗЗЫ: Да, модуль во время экпериментирования вел себя аналогично - ответы "перемешивались".
Но так, как мне нужен только SPP, отключаю вообще эхо после инициализации.

Это мало помогает, только снижает вероятность.
При нормальной работе эта проблема чаще всего проявляется если сделать коннект и сразу дисконнект.
Коннект у меня с авторизацией и всякими LIST и прочими для контроля и корректировки режимов соединения (SNIFF и т.п.) и
получается что сообщение о дисконнекте NO CARRIER 0 ERROR 0 перемешивается с обрабатываемыми в этот момент командами.
Или наоборот - если после дисконнекта хост сразу снова делает попытку коннекта (а в этот момент к WT12 от МК идёт поток команд после
завершения соединения: LIST и т.п.).
А если ещё учесть что приложение на хосте не знает что делает в данный момент встроенное ПО и может попытаться коннектиться в момент когда
встроенное ПО выполняет сброс и инициализацию WT12 (с кучей команд и ответов на них), то вообще труба. Хоть это и очень редко бывает.

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

Да, и ещё есть эти потери символов в ответах на команды.
Хотя случается это довольно редко (при вкл. эхе команд ~ 1 раз на 1000 коннектов; при выкл. эхе ~1раз на 2000 коннектов).
Но когда случается, приносит много проблем - прошивка МК не распознаёт ответ на команду и соотв. пересбрасывает WT12 по ошибке.
В результате - виндовое приложение на хосте зависает на попытке открытия COM-порта примерно на минуту и только после этого вываливается с ошибкой.
Принудительно закрыть раньше чем через минуту невозможно ((((