[Apollo 0]

Спасибо! До написания в этой теме, когда искал ответ на свой вопрос наткнулся и на указанную выше тему. Благо, что пока с iPhone связываться не по Bluetooth нет необходимости. Больше интересует в перспективе связаться с устройством под управлением Android.

Не выясненным остался пока вопрос какой же PIN-code хочет получить свежекупленный WT12 ("из коробки" так сказать). Пытался с телефона отправить и "0000" и "1234" не принимает. Думаю, конечно вылечится, когда я подключу управляющий МК или компьютер и либо выдам команду на отключение запроса PINa, либо команду на установку нового PINа. Хотя остается спортивный интерес узнать что же он требует в качестве PINа по умолчанию.

[MiklPolikov 0]

Спасибо! До написания в этой теме, когда искал ответ на свой вопрос наткнулся и на указанную выше тему. Благо, что пока с iPhone связываться не по Bluetooth нет необходимости. Больше интересует в перспективе связаться с устройством под управлением Android.

Не выясненным остался пока вопрос какой же PIN-code хочет получить свежекупленный WT12 ("из коробки" так сказать). Пытался с телефона отправить и "0000" и "1234" не принимает. Думаю, конечно вылечится, когда я подключу управляющий МК или компьютер и либо выдам команду на отключение запроса PINa, либо команду на установку нового PINа. Хотя остается спортивный интерес узнать что же он требует в качестве PINа по умолчанию.

Там наверняка есть команда по которой Вы узнаете PIN от производителя. Но какой в этом смысл ?

 

Ещё, мне не понравилось как организована установка бодрэйта UART. Бодрэйт устанавливается командой, и сохраняется после сброса питания. Если во время установки произойдёт какая-то ошибка,

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

[jcxz 242]

Полностью согласен!

По-моему - это большое неудобство в WT12 - сохранение в его flash всех настроек и невозможности их установки в дефолтные по одному простому сигналу (RESET).

Много плевался уже по этому поводу.... :((((((

 

Гораздо правильнее было сделать сохранение настроек в ОЗУ WT12, а при вкл. питания или reset-е - сброс в дефолтные настройки.

Всё равно если модуль подключен к МК, то МК должен при старте дать ему сброс, потом проверить все его текущие настройки и изменить те, которые необходимо.

У меня сейчас firmware так и делает, но перед этим приходится перебирать все битрейты UART (может оказаться на заводском bitrate, а может на уже моём установленном

ранее, а может на моём-же битрейте установленном ранее, но предыдущей версией ПО (если потребовалось изменить в новой версии битрейт)).

Плюс - ещё для каждого битрейта делаю определение режима (MUX или не MUX), определение режимов парсинга команд модулем (с эхом или без, с OK после команд или без),

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

Соответственно при старте надо определить какие в модуле текущие настройки и переключить их на необходимые, с какими скомпилено ПО.

 

Если-бы по reset всё сбрасывалось в дефолтные настройки и сохранялось только в ОЗУ модуля, это бы сильно упростило ПО.

[Apollo 0]

Спасибо за ценное предупреждения насчет настроек. Предполагаю что может возникнуть ещё и не совсем точное определение битрейта, ибо бывает что при близких скоростях UART микроконтроллера может вполне корректно воспринять короткий ответ "ОК" и подумать что эта текущая скорость и есть искомая. Как вариант нужно проанализировать ответ модуля, содержащий значение текущей скорости.

 

А вот что написано в iWRAP4_User_Guide:

 

If you enter an incorrect or invalid baud rate and can not access iWRAP any more, the only way to recover the module is via the SPI interface by deleting the value of PS-key : PSKEY_USR26. Please see chapter 9.1 PS-keys and how to change them for information how to change the PS-keys.

 

Короче надо на всякий случай, если железо дает возможность, подключиться ещё и по SPI. Это даст возможность реанимировать модуль.

 

И тут возникли траблы... Почитал поподробнее, но нашел только описание способа с применением компьютерной программы PSTool. Как добраться до регистров PS-keys через SPI пока не понятно.

 

Чем дальше в лес... Отыскал на сайте техподдержки BlueGiga ссылку на рекомендуемый переходник USB-PSI DEV-SYS-1808-1A-ND. Платить за переходник 211$ что-то не очень айс. Тем более это только малая часть того что нужно сделать. Этот переходник лишь позволит настраивать PS-keys с компьютера. Выходит, надо ещё сделать устройство для перехвата протокола, чтобы понять что передавать с МК. В общем какой-то сложный путь получается. Попробую отыскать информацию по командам SPI для модуля, если она вообще есть.

 

Народ, оказывается это уже тут обсуждал http://electronix.ru/forum/index.php?showtopic=112444

[jcxz 242]

вполне корректно воспринять короткий ответ "ОК" и подумать что эта текущая скорость и есть искомая.

Я не ОК ищу.

И даже AT/ОК не совпадёт - это же минимум 8 байт. И что значит близкие? Соседние скорости отличаются в 1.5-2 раза.

 

Короче надо на всякий случай, если железо дает возможность, подключиться ещё и по SPI. Это даст возможность реанимировать модуль.

Вот когда найдёте описание протокола, тогда и расскажете всем как подключиться ;)

[Apollo 0]

Докладываю о продвижениях.

Подопытный модуль WT12 собран на чипсете BlueCore4. Таких чипсета у CSR два и какой именно применен я ещё не разобрался. Есть чипсет BlueCore4-PC-ROM и есть BlueCore4-External.

Мне удалось скачать документы на каждый из чипсетов.

В документах есть раздел посвященный CSPI (SPI доработанный и запатентованный CSR'ом).

 

В документе на BlueCore4-PC-ROM это раздел 8.2 Serial Peripheral Interface, а на BlueCore4-External - 11.7 Serial Peripheral Interface.

 

Набор PS key

 

Разобрался. Чипсет всё же BlueCore4-External, так как и в WT12 и в BlueCore4-External есть интерфейс PCM, а в BlueCore4-PC-ROM его нет.

BlueCore4_PC_ROM.pdf

BlueCore4_Ext.pdf

PSkeys.rar

Изменено 29 декабря, 2013 пользователем Apollo

[Apollo 0]

Мозг уже закипает от вала информации, причем разрозненной и на мой взгляд неструктурированной. А главное то что важно не описано пока нигде.

Прочитав документ от CSR "CSR SPI (CSPI) Specification Issue 2" понял что все же в нашем чипсете этот протокол не используется и вот почему:

 

- во первых:

"CSPI is an extension of a basic SPI interface, with the access type determined by the following fields:

■ 8-bit command

■ 24-bit address

■ 16-bit burst length (optional)";

 

-во вторых:

"Command

Bit Function

[7] Start bit (must be 0)

[6] nRegister/Burst

[5] Write

[4] Read

[3] Reserved (must be 0)

[2:0] Function number.

To initiate a CSPI access, command bit 7 must be 0, and one of command bits 5 and 4 (not both) must be high,

indicating a read or a write access. Any other bit combination is ignored.";

 

То есть в CSPI используется 24, а не 16 битный адрес и в байте команды биты, указывающие на то чтение это или запись другие и не могут быть одновременно "1".

 

Файл со спецификацией CSPI прилагаю

 

В документе на чипсет протокол совсем другой. Адресация 16 битная, а байт команды записи и чтения выглядят соответственно так: 00000010 и 00000011.

CSPI_Specification.pdf

[Apollo 0]

Подскажите какие команды давать при инициализации модуля и какие для установления соединения.

 

Выдаю команду на соединение как в примере в даташите,

CALL 0C:00:A0:E7:EE:3B 1101 RFCOMM

 

 

но получаю вот что:

CALL 0

 

NO CARRIER 0 ERROR 311 SDC_NO_RESPONSE_DATA

 

 

Подозрение на параметр 1101 - это номер канала, может надо какой-то другой установить? Как узнать какой нужен канал?