[npu3pak13 0]

В смысле? Плата подсоединена ни к тем ножкам UARTa в БЛЕ112?

Ну надо само собой будет перепаять ножки на БЛЕ112,

получить hex прошивки, найти инструкцию, которая меняет/устанавливает выбор UART (по моему P0SEL регистр,

надо будет дизассемблировать весь код и разбиратся).

Если там вообще ремаппинг есть.

А то и добавить придется и компильнуть ассемблер.

Нет, есть плата, куда будет впаиваться BLE112 и выведен JTAG на разъем, UART разведен как положено по datasheet.

Требуется - 1. прошить модуль, задав что рабочий UART0 на Р1, подключенный к микроконтроллеру.

2. Нужно ли еще что-то прошивать внутрь модуля, или все остальное пишет программист в программе для МК?

 

Нашел примеры у блюгига - UART 114k

 

<?xml version="1.0" encoding="UTF-8" ?>

- <project>

<gatt in="gatt.xml" />

<hardware in="hardware.xml" />

<image out="BLE112.hex" />

<device type="ble112" />

<boot fw="bootuart" />

</project>

 

<?xml version="1.0" encoding="UTF-8" ?>

- <configuration>

- <service uuid="1800">

<description>Generic Access Profile</description>

- <characteristic uuid="2a00">

<properties read="true" const="true" />

<value>Bluegiga UART Demo</value>

</characteristic>

- <characteristic uuid="2a01">

<properties read="true" const="true" />

<value type="hex">00</value>

</characteristic>

</service>

</configuration>

 

<?xml version="1.0" encoding="UTF-8" ?>

- <hardware>

<sleeposc enable="true" ppm="30" />

<usb enable="false" endpoint="none" />

<txpower power="15" bias="5" />

<usart channel="1" alternate="1" baud="115200" flow="true" endpoint="api" />

<wakeup_pin enable="true" port="0" pin="0" />

<port index="0" tristatemask="0" pull="down" />

<pmux regulator_pin="7" />

</hardware>

 

<?xml version="1.0" encoding="UTF-8" ?>

- <usb>

- <device bDeviceClass="2" bcdDevice="1" iManufacturer="Bluegiga" idVendor="2458" idProduct="0001" iProduct="Low Energy Dongle" iSerialNumber="1" bcdUSB="200">

- <configuration iConfiguration="CDC" bmAttributes="80" bMaxPower="25">

- <interface bInterfaceClass="2" bInterfaceSubClass="2" bInterfaceProtocol="1" iInterface="CDC control">

- <descriptor Type="24">

<data>001001</data>

</descriptor>

- <descriptor Type="24">

<data>0202</data>

</descriptor>

- <descriptor Type="24">

<data>060001</data>

</descriptor>

- <descriptor Type="24">

<data>010301</data>

</descriptor>

<endpoint bEndpointAddress="82" bmAttributes="3" wMaxPacketSize="40" bInterval="40" />

</interface>

- <interface bInterfaceClass="A" bInterfaceSubClass="0" bInterfaceProtocol="0" iInterface="CDC data">

<endpoint bEndpointAddress="84" bmAttributes="2" wMaxPacketSize="40" bInterval="1" />

<endpoint bEndpointAddress="4" bmAttributes="2" wMaxPacketSize="40" bInterval="1" />

</interface>

</configuration>

</device>

</usb>

И какойто hex файл - этого достаточно??

И где можно посмотреть содержание файла?? И что значит часть дескрипторов

[A. Fig Lee 0]

Нет, есть плата, куда будет впаиваться BLE112 и выведен JTAG на разъем, UART разведен как положено по datasheet.

Требуется - 1. прошить модуль, задав что рабочий UART0 на Р1, подключенный к микроконтроллеру.

2. Нужно ли еще что-то прошивать внутрь модуля, или все остальное пишет программист в программе для МК?

...

БЛЕ112 не что иное, как CC2540 с прошивкой.

Кпгда я говорил про hex file, я имелл ввиду именно БЛЕ112 прошивку.

JTAG не совсем мне понятен, это надо понимать для вашего модуля, не БЛЕ.

БЛЕ использует 2 ноги: P2_2,P2_1 для записи и чтения фирмваря в него/из него.

Это тот, который надо править.

2. "По даташиту" у БЛЕ УАРТ можит быть в 2х разных позициях.

 

Если программист не меняет прошивку БЛЕ, поменять выводы УАРТ у БЛЕ, вы не сможете.

Надо сказачать содержимое БЛЕ, отрихтовать и залить.

 

Не забудьте о лицензии! Она вроде в последнем секторе блугиги лежит.

 

[npu3pak13 0]

БЛЕ112 не что иное, как CC2540 с прошивкой.

Кпгда я говорил про hex file, я имелл ввиду именно БЛЕ112 прошивку.

JTAG не совсем мне понятен, это надо понимать для вашего модуля, не БЛЕ.

БЛЕ использует 2 ноги: P2_2,P2_1 для записи и чтения фирмваря в него/из него.

Это тот, который надо править.

2. "По даташиту" у БЛЕ УАРТ можит быть в 2х разных позициях.

 

Если программист не меняет прошивку БЛЕ, поменять выводы УАРТ у БЛЕ, вы не сможете.

Надо сказачать содержимое БЛЕ, отрихтовать и залить.

 

Не забудьте о лицензии! Она вроде в последнем секторе блугиги лежит.

 

Тот файл который лежит в примерах - BLE112.hex - его достаточно или его тоже нужно создавать??

JTAG - это разъем на который подключается CCDebagger? чтобы прошить впаянный модуль

За прошивку отвечает строка <usart channel="1" alternate="1" baud="115200" flow="true" endpoint="api" />

где задаются выводы..

 

Вопрос в следующем - если я зашью в модуль эту прошивку, то программист получит доступ по UART к нему как оконечнеку моста?

[npu3pak13 0]

Вопрос судя по всему снимается - BLE112 не видится стандартным blutooth ((

[npu3pak13 0]

Начальство все же решило продолжить испытания, нужен пока минимальный совет:

Подключаю BLED112, определяется как COM12

Подскажите как поработать в ней в терминальном режиме? Пробовал PuTTY - не работает, может нужно чтото другое??

Задача - организовать мост через донгл и самодельную платку USB-BLE112 отсылать/принимать команды\данные

[npu3pak13 0]

Помогите советом: Сделал мост между BLED112 и BLE112 в режиме донгла но не могу из сконнектить, ругается

ble_rsp_gap_connect_direct result:20c ['Command requested cannot be executed because the Controller is in a state where it cannot process this command at this time.'] connection_handle: 1 (0x01)

Что не так??

 

[AlexKoblov 0]

Общение с BLE112 через RS232 с компом помощью BGLIB API наладил, приделал эти библиотеки к C++ Builder 6, с модулем общаюсь, тут все Ок.

Но сделать тоже самое на PIC18F46J50 не получается, затык в компиляторе под этот PIC18, а именно CCS C PIC Compiler 5.049. Компилятор не хочет понимать следующую строку:

typedef void (* ble_cmd_handler) (const void *);

Она используется в исходниках BGLIB API.

C++ Builder 6 эту строку воспринял нормально.

 

уже сделал простой пример, он все равно не компилится,

выдает такие ошибки:

"Expecting an identifier"

"Expecting a declaration"

 

вот и вся программа:

newmain22.c:

-----------------------------------------------------------------------------

#include <18F46J50.h>

 

typedef void (*ble_cmd_handler)(const void*);

 

void main(void) {

 

int a, b, c;

a=2;

b=2;

c=a+b;

}

-----------------------------------------------------------------------------

 

"C:\Alex\PROGRAMS\PICC5049\CCSCON.exe" out="build/default/production" newmain22.c +FH +DF +CC +Y=9 +EA +DF +LN +T +A +M +J +EA +Z -P #__18F46J50=1

C:\Alex\MPLAB_PRJ_PCC\test_struct\test_struct.X\newmain22.c:3:59: Error#28 Expecting an identifier

C:\Alex\MPLAB_PRJ_PCC\test_struct\test_struct.X\newmain22.c:3:64: Error#43 Expecting a declaration

C:\Alex\MPLAB_PRJ_PCC\test_struct\test_struct.X\newmain22.c:3:65: Error#43 Expecting a declaration

3 Errors, 0 Warnings.

Build Failed.

 

Может кто знает как этому CCS C PIC компилятору объяснить что это за строка:

typedef void (*ble_cmd_handler)(const void*);

может ее можно както записать по другому? я честно ее не пойму

 

[AlexKoblov 0]

Похоже это косяк CCS C PIC Compiler.

Установил MPLAB® XC Compiler, скомпилилось все нормально.

 

Блин так неохота перелазить с одного компилятора на другой, когда уже написанна куча кода под CCS C PIC Compiler.

[Kabdim 0]

Если компилятор не понимает столь простую конструкцию от него надо бежать как от огня, а не жалеть об этом.

ЗЫ:

typedef void (*ble_cmd_handler)(const void*);

typedef - определяем тип:

(*ble_cmd_handler) - с именем ble_cmd_handler являющийся указателем на:

(const void*) - функцию принимающую 1 аргумент, нетипизированный указатель на константную область памяти

void - и н возвращающую ничего.

 

Изменено 26 ноября, 2015 пользователем Kabdim

[AlexKoblov 0]

помогли на сайте поддержки CCS

В общем оказывается, что по умалчанию const у них используется для хранения переменных в ROM.

А что бы был обычный си нужно было написать:

 

#device ANSI //switch const meaning

 

Так, сделал и все ошибки исчезли :)

 

Вот дословный ответ c их сайта:

By default in CCS, a 'const', is a ROM type to which a pointer can't be constructed. In ANSI C, a const is a variable in RAM, that is protected (if the hardware has such protection), against being modified. If ANSI is selected CCS attempts to switch the definition (but personally it is safer just to get rid of const).

 

 

[eka1939 0]

Я разрабатываю приложение под BLE112. Спрашивайте, может чем помогу.

 

 

А такой функционал - completelykeyless.com/premium-bluetooth-keyless/ проблемно сделать?