Da14683 Learning Log (II) - Summary of Perpherial Engineering Learning

懒猫爱飞

Da14683 Learning Log (II) - Summary of Perpherial Engineering Learning [Copy link]

This content is originally created by 懒猫爱飞, a user of EEWORLD forum. If you need to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source Da14683Learning Log (II)

-- BLE peripheral application example learning summary

Overview

This is a peripheral When studying a new BLE chip SDK, the first thing to look at is the central project and the perpherial project. This is very important for understanding the entire SDK. Generally, the perpherial project will have basic settings and operations such as the configuration of profile files, the sending of BLE data, and the setting of broadcast data. For the peripheral devices of the chip, such as timers, ADC, USB, UART, I2C, etc., these functions are basically the same as those of ordinary MCUs. Basically, if you understand the principles, you can use them. It’s just that the code style is different, the API is different, or there are some other precautions. This should be combined with the chip specification. Let’s simply learn this project. By learning this project, you should learn how to configure a new profile file and how to send and receive BLE data.

Project structure

Similar to the Central project, this project also includes the following folders

Binaries	Stores the generated elf files
Include	Includes header file paths and header files
config	Files related to project configuration and system configuration
App	Source files related to the user application layer (this was built by me later, not in the original DEMO, the main file in the original project was placed in the project directory)
misc	Some configurations about the internal address do not need to be changed
sdk	adapters	stores the driver interface source files of the system application layer, including batteries, i2c,uart, etc.
	ble	Source files related to the BLE protocol stack, generally do not need to be modified
	ble_service	stores the source code related to the Bluetooth service
	bsp_include	stores some header files related to the underlying layer
	config	It stores configuration related header files, which generally do not need to be modified
	cpm	It stores some system related application files, which generally do not need to be modified
	FreeRTOS	It stores a FreeRTOS related source file, which generally does not need to be modified
	Idscripts	Some files related to links, no need to modify
	memory	About external FLASH related source files, may need to be modified when changing external FALSH, not studied carefully yet
	osal	System related source files, generally do not need to be modified
	peripherals	Chip peripheral related drivers, call or cooperate with system calls at appropriate times
startup	Some configuration files of the chip bottom layer do not need to be modified for the time being

The project includes the following services:

? BatteryService（Multiple instance）

? CurrentTime Service

? DeviceInformation Service

? ScanParameter Service

? DialogDebug Service

? CustomUser Service application file The upper-level applications in the peripheral routines are all in the ble_peripheral_task.c source file. Regarding this source file, I will mainly talk about the following two functions: static void myservice_init(ble_service_t *include_svc) void ble_peripheral_task(void *params) file:///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image001.gif function myservice_init Although this function is simple, it can be used as a template for users to add custom services. The program uses 128-bit UUID. The source code is as follows: table [tr] [td=551]

static void myservice_init(ble_service_t *include_svc)

{

att_uuid_t uuid;

/*

* This service does absolutely nothing, it just checks that it's possible to use 128- bit

* UUIDs for services,characteristics and descriptors.

*/

// These APIs are called in ble_uuid.c

ble_uuid_from_string("91a7608d-4456 -479d-b9b1-4706e8711cf8", &uuid);

ble_gatts_add_service(&uuid, GATT_SERVICE_PRIMARY, ble_gatts_get_num_attr(1, 1, 1));

[ align=left] if (include_svc)

{

ble_gatts_add_include(include_svc->start_h, NULL);

}

ble_uuid_from_string("25047e64-657c-4856-afcf-e315048a965b", &uuid);

ble_gatts_add_characteristic(&uuid, GATT_PROP_NONE , ATT_PERM_NONE, 1, 0, NULL, NULL);

ble_uuid_from_string("6b09fe25-eed7-41fc-8da7-1ec89fab7ecb", &uuid);[/align ]

ble_gatts_add_descriptor(&uuid, ATT_PERM_NONE, 1, 0, NULL);

ble_gatts_register_service(NULL, 0);} left]Add server, add Character, add character description are all in it. These APIs are defined in the ble_uuid.c source file. How to define attributes, how to send values through UUID, how to receive data sent by the host, How to set notify and how to use indication are not given in this example. You need to learn them slowly by combining them with other examples. This function only gives a general framework and does not give a callback function for processing data. The application will be slowly summarized while learning other routines.

file:///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image001.gif Function ble_peripheral_task

Some Bluetooth devices, service additions, and Bluetooth status callbacks are all handled in this function. Let's take a look at the source code of this function: [/ void ble_peripheral_task(void *params) { int8_t wdog_id; #if CFG_CTS ble_service_t *cts;

cts_local_time_info_t cts_lti =

{

/* Example time zone, should be taken from permanent storage or RTC */

.dst = CTS_DST_DAYLIGHT_TIME,

.time_zone = cts_get_time_zone(+3, 0), // UTC + 3 Athens[/align ]

};

#endif

ble_service_t *svc;

[/ align]

// in case services which do not use svc are all disabled, just surf -Wunused-variable

(void) svc;

file:///C:\Users\XCU\AppData\Local \Temp\msohtmlclip1\01\clip_image002.png /* register ble_peripheral task to be monitored by watchdog */

wdog_id = sys_watchdog_register(false);

[align=left ] ble_peripheral_task_handle = OS_GET_CURRENT_TASK();

srand(time(NULL));

[ /align]

ble_peripheral_start();

ble_register_app();

ble_gap_device_name_set("Dialog Peripheral", ATT_PERM_READ);

file:///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image003.png

[b ]#if CFG_DEBUG_SERVICE

/* register debug service */

dbgs = dlgdebug_init(NULL);

[ b]#endif /* CFG_DEBUG_SERVICE */

#if CFG_BAS

#if CFG_BAS_MULTIPLE

/* register BAS (1st instance) */

svc = bas_init(NULL, &bas_bat1);

#if CFG_DEBUG_SERVICE

dlgdebug_register_handler(dbgs, "bas", "set", dbg_bas_set, svc);

#endif /* CFG_DEBUG_SERVICE */

bas_set_level(svc, 90, false);

/* register BAS (2nd instance) */

svc = bas_init(NULL, &bas_bat2);

bas_set_level(svc, 60, false);

#else

file:///C :\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image004.png

/* register BAS */

svc = bas_init (NULL, NULL);

#if CFG_DEBUG_SERVICE

dlgdebug_register_handler(dbgs, "bas", "set", dbg_bas_set, svc) ;

#endif /* CFG_DEBUG_SERVICE */

bas_set_level(svc, 90, false);

#endif /* CFG_BAS_MULTIPLE */

#endif /* CFG_BAS */

#if CFG_CTS

/* register CTS */[/ align]

cts = cts_init(&cts_lti, &cts_callbacks);

#if CFG_DEBUG_SERVICE

dlgdebug_register_handler(dbgs, "cts ", "adjust", dbg_cts_adjust,cts);

#endif /* CFG_DEBUG_SERVICE */

#endif

[align =left]

#if CFG_USER_SERVICE

/* register custom service */

#if CFG_CTS

myservice_init(cts);

#else

myservice_init( NULL);

#endif

#endif

[/ align]

#if CFG_DIS

/* Add DIS */

dis_init(NULL, &dis_info);

#endif

#if CFG_SCPS

/* register ScPS */

[align= left] scps_init(&scps_callbacks);

#endif

#if[/ b] CFG_CTS

/* create timer for CTS, this will be used to update current time every second */

cts_timer = OS_TIMER_CREATE("cts", portCONVERT_MS_2_TICKS(1000), OS_TIMER_SUCCESS,

(void *) OS_GET_CURRENT_TASK(), cts_timer_cb);

OS_ASSERT(cts_timer);[/ align]

OS_TIMER_START(cts_timer, OS_TIMER_FOREVER);

#endif

file: ///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image005.png

ble_gap_adv_data_set(sizeof(adv_data), adv_data, 0, NULL);

ble_gap_adv_start(GAP_CONN_MODE_UNDIRECTED);

for[/ b] (;;)

{

OS_BASE_TYPE ret;

uint32_t notif;

[ /align]

/* notify watchdog on each loop */

sys_watchdog_notify(wdog_id);

/ * suspend watchdog while blocking on OS_TASK_NOTIFY_WAIT() */

sys_watchdog_suspend(wdog_id);

/*

* Wait on any of the notification bits, then clear them all

*/[ /align]

ret = OS_TASK_NOTIFY_WAIT(0,

OS_TASK_NOTIFY_ALL_BITS,

if,

OS_TASK_NOTIFY_FOREVER);[ /align]

/* Blocks forever waiting for task notification.The return value must be OS_OK */

OS_ASSERT(ret == OS_OK);

/* resume watchdog */[ /align]

sys_watchdog_notify_and_resume(wdog_id);

/* notified from BLE manager, can get event */

if (notif & BLE_APP_NOTIFY_MASK)

{

file:///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image006.png ble_evt_hdr_t *hdr;

hdr = ble_get_event(false);

if (!hdr)

[align=left ] {

goto no_event;

}

if (ble_service_handle_event(hdr))

{

goto handled;

[align= left] }

switch (hdr->evt_code)

{

case BLE_EVT_GAP_CONNECTED:

{

handle_evt_gap_connected((ble_evt_gap_connected_t *) hdr);

} break;

case BLE_EVT_GAP_ADV_COMPLETED:

{

handle_evt_gap_adv_completed((ble_evt_gap_adv_completed_t *) hdr);

} break;

case BLE_EVT_GAP_DISCONNECTED:

{

handle_evt_gap_disconnected((ble_evt_gap_disconnected_t *) hdr);

} break;

case BLE_EVT_GAP_PAIR_REQ:

{

ble_evt_gap_pair_req_t *evt = (ble_evt_gap_pair_req_t *) hdr;

ble_gap_pair_reply(evt->conn_idx, true,evt->bond);

break;

}

[align= left] default:

{

ble_handle_event_default(hdr);

}break[ /b];

}

handled:

OS_FREE(hdr);[/ align]

no_event:

// notify again if there are more events to process in queue

[ b]if (ble_has_event())

{

OS_TASK_NOTIFY(OS_GET_CURRENT_TASK(), BLE_APP_NOTIFY_MASK, eSetBits);

}

}[/ align]

file:///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image007.png#if CFG_CTS

if (notif & CTS_SET_TIME_NOTIF)

{

cts_notify_time_all(cts, &cts_time);[ /align]

}

#endif } } } } } } } } }

The above code mainly does the following things:

• The orange box is to start BLE, register APP and set the device name [* ]
• The green box is for adding various services
• The red box is for setting broadcast Data, start broadcast operation
• The gray box is to obtain BLE related events and process them
• [font= The Bluetooth color box is used to handle other notify events

(A note here: I used Word to edit and pasted it over, but the website's paste function is not powerful, and most of my formatting was removed, so,

If you need, you can download the PDF format of the second floor for viewing, thank you! Hereby declare! )

[ As for other operations, such as flashing when broadcasting, always on when connected, etc., readers need to add them by themselves. They can be added to BLE events or Use messages to complete a task, which needs to be done in combination with freertos. The use of freertos will be gradually involved in subsequent learning.

Other instructions[/b ]

The overall architecture of DA14683 SDK is relatively clear and easy to call, but some parts can be further subdivided, such as the definition of device information service and device information, which can be completely defined in The device information service source file (source file dis.c), but not in the ble_peripheral_task.c file, perhaps for the user to more convenient settings.

Another point is that the global The variable will be defined in the middle of the source code. This may be based on the principle of proximity. The variable is called from the place closest to the call. This may seem more practical at the time, but it will cause unnecessary confusion to other people who read the code. This is a matter of personal opinion. Finally, I remember that there was a period of time when I often wrote study diaries, and after each diary I would shout a slogan to encourage myself. Yes, it is time, it is necessary to shout again the slogans of the past. The slogan is:

Make a little progress every day, and be happier^_^

[ /align]

{

ble_handle_event_default(hdr);

}break;

[align= left] }

handled:

OS_FREE(hdr);

no_event:

// notify again if there are more events to process in queue

if (ble_has_event() )

{

OS_TASK_NOTIFY(OS_GET_CURRENT_TASK(), BLE_APP_NOTIFY_MASK, eSetBits);

}

}

file:///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\ 01\clip_image007.png#if CFG_CTS

if (notif & CTS_SET_TIME_NOTIF)

{

cts_notify_time_all(cts, &cts_time);

}

#endif

[ align=left] }

}

[/td] [/tr] [/table]

The above code mainly does the following things:

• The orange box is to start BLE, register APP and set the device name [/ The grass green box is the function of adding various services
• The red box The gray box is used to obtain BLE related events and process them. ]The Bluetooth color box is used to handle other notify events

(Here is an explanation: I use It was edited in Word and pasted here, but the website's paste function is not powerful, and most of my formatting was removed, so,

If you need it, Download the PDF format of the second floor to view it, thank you! As for other operations, such as flashing lights when broadcasting, always on when connected, etc., readers need to add them by themselves. Add in

BLE events can also use messages to do a task, this should be done in conjunction with freertos. The use of freertos will be gradually involved in subsequent learning.

Other instructions[align= The overall structure of DA14683 SDK is relatively clear and easy to call. However, some parts can be further subdivided. For example, the definition of device information service and device information can be completely defined in the device information service. The source file (source file dis.c), but not in the ble_peripheral_task.c file, perhaps for the user to more convenient settings. Another point is that global variables are defined in the middle of the source code. This may be based on the principle of proximity. The variable is called from the place closest to the calling point. This may seem more practical at the time, but It will cause unnecessary confusion to other people who read the code. Of course, this is also a matter of opinion.

Finally, I remember that there was a period of time when I often wrote learning logs, and every time I finished writing I always shout a slogan in my diary to encourage myself. Yes, it is time to shout the slogan again: Make a little progress every day and be happy. A little more^_^

{

ble_handle_event_default(hdr);

}break;

[align= left] }

handled:

OS_FREE(hdr);

no_event:

// notify again if there are more events to process in queue

if (ble_has_event())

{

OS_TASK_NOTIFY(OS_GET_CURRENT_TASK(), BLE_APP_NOTIFY_MASK, eSetBits);

}

}

file:///C:\Users\XCU\AppData\Local\Temp\msohtmlclip1\ 01\clip_image007.png#if CFG_CTS

if (notif & CTS_SET_TIME_NOTIF)

{

cts_notify_time_all(cts, &cts_time);

}

#endif

}

}

[/td] [/tr] [/table]

The above code mainly does the following things:

• The orange box is to start BLE, register APP and set the device name [/ The grass green box is the function of adding various services
• The red box The gray box is used to obtain BLE related events and process them. ]The Bluetooth color box is used to handle other notify events

(Here is an explanation: I use It was edited in Word and pasted here, but the website's paste function is not powerful, and most of my formatting was removed, so,

If you need it, Download the PDF format of the second floor to view it, thank you! As for other operations, such as flashing lights when broadcasting, always on when connected, etc., readers need to add them by themselves. Add in

BLE events can also use messages to do a task, this should be done in conjunction with freertos. The use of freertos will be gradually involved in subsequent learning.

Other instructions[align= The overall structure of DA14683 SDK is relatively clear and easy to call. However, some parts can be further subdivided. For example, the definition of device information service and device information can be completely defined in the device information service. The source file (source file dis.c), but not in the ble_peripheral_task.c file, perhaps for the user to more convenient settings. Another point is that global variables are defined in the middle of the source code. This may be based on the principle of proximity. The variable is called from the place closest to the call point. This may seem more practical at the time, but It will cause unnecessary confusion to other people who read the code. Of course, this is also a matter of opinion.

Finally, I remember that there was a period of time when I often wrote learning logs, and every time I finished writing I always shout a slogan in my diary to encourage myself. Yes, it is time to shout the slogan again: Make a little progress every day and be happy. A little more^_^

// notify again if there are more events to process in queue

if (ble_has_event())

[align =left] {

OS_TASK_NOTIFY(OS_GET_CURRENT_TASK(), BLE_APP_NOTIFY_MASK, eSetBits);

}

}

file:///C :\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image007.png#if CFG_CTS

if (notif & CTS_SET_TIME_NOTIF){cts_notify_time_all(cts, &cts_time);} #endif

}

}

[/td] [/tr] [/table]

In the above code The main things done are as follows:

• The orange box is to start BLE, register APP and set the device name
• The green box is for adding various services
• The red box is for setting broadcast data and starting broadcast operations[/
• The gray box is for obtaining BLE related events and processing them
• The Bluetooth colored box is for processing other notify events [/list ]
  (A note here: I used Word to edit and paste it, but the website's paste function is not good, so most of my The format has been removed, so if you need it, you can download the PDF format of the second floor to view it, thank you! Special statement! ) As for other operations, such as flashing when broadcasting, always on when connected, etc., readers need to add them by themselves, which can be added in BLE You can use events, or you can use messages to do a task, which should be done in combination with freertos. The use of freertos will be gradually involved in subsequent learning.
  Other instructions[/b ]
  The overall architecture of DA14683 SDK is relatively clear and easy to call, but some parts can be further subdivided, such as the definition of device information service and device information, which can be completely defined in The device information service source file (source file dis.c), but not in the ble_peripheral_task.c file, perhaps for the user to more convenient settings.
  Another point is that the global The variable will be defined in the middle of the source code. This may be based on the principle of proximity. The variable is called from the place closest to the call. This may seem more practical at the time, but it will cause unnecessary confusion to other people who read the code. This is a matter of personal opinion. Finally, I remember that there was a time when I often wrote study diaries, and after each diary I would shout a slogan to encourage myself. Yes, it is time, it is necessary to shout again the slogans of the past. The slogan is:
  Make a little progress every day, and be happier^_^
  [ /align]
  // notify again if there are more events to process in queue
  if (ble_has_event())
  [align =left] {
  OS_TASK_NOTIFY(OS_GET_CURRENT_TASK(), BLE_APP_NOTIFY_MASK, eSetBits);
  }
  }
  file:///C :\Users\XCU\AppData\Local\Temp\msohtmlclip1\01\clip_image007.png#if CFG_CTS
  if (notif & CTS_SET_TIME_NOTIF){cts_notify_time_all(cts, &cts_time);} #endif
  }
  }
  [/td] [/tr] [/table]
  In the above code The main things done are as follows:
  • The orange box is to start BLE, register APP and set the device name
  • The green box is for adding various services
  • The red box is for setting broadcast data and starting broadcast operations[/
  • The gray box is for obtaining BLE related events and processing them
  • The Bluetooth colored box is for processing other notify events [/list ]
    (A note here: I used Word to edit and paste it, but the website's paste function is not good, so most of my The format has been removed, so if you need it, you can download the PDF format of the second floor to view it, thank you! Special statement! ) As for other operations, such as flashing when broadcasting, always on when connected, etc., readers need to add them by themselves, which can be added in BLE You can use events, or you can use messages to do a task, which should be done in combination with freertos. The use of freertos will be gradually involved in subsequent learning.
    Other instructions[/b ]
    The overall architecture of DA14683 SDK is relatively clear and easy to call, but some parts can be further subdivided, such as the definition of device information service and device information, which can be completely defined in The device information service source file (source file dis.c), but not in the ble_peripheral_task.c file, perhaps for the user to more convenient settings.
    Another point is that the global The variable will be defined in the middle of the source code. This may be based on the principle of proximity. The variable is called from the place closest to the call. This may seem more practical at the time, but it will cause unnecessary confusion to other people who read the code. This is a matter of personal opinion. Finally, I remember that there was a period of time when I often wrote study diaries, and after each diary I would shout a slogan to encourage myself. Yes, it is time, it is necessary to shout again the slogans of the past. The slogan is:
    Make a little progress every day, and be happier^_^
    [ /align]

    Register APP and set device name
  • The grass green box is the function of adding various services
  • The red box is to set broadcast data and start broadcasting
  • The gray box is to obtain BLE related events and process them
  • The Bluetooth color box is to process other notify events
  (A note here: I used the word editor and pasted it over, but the website's paste function is not powerful, so most of my formatting was removed, so,
  If you need, you can download the PDF format on the second floor to view it. Thank you! Hereby declare!)
  As for other operations, such as flashing lights during broadcasting, always on when connected, etc., readers need to add them by themselves. They can add them to
  BLE events, or use messages to do a task. This needs to be done in combination with freertos. The use of freertos will be gradually involved in subsequent learning.
  Other instructions
  The overall architecture of the DA14683 SDK is relatively clear, and it is also relatively convenient to call. However, some places can be further subdivided. For example, the definition of device information service and device information can be completely defined in the source file of the device information service (source file dis.c), and there is no need to define it in the ble_peripheral_task.c file. Perhaps it is for the convenience of users to set it up.
  Another point is that global variables are defined in the middle of the source code. This may be based on the principle of proximity. The variable is called from the place closest to the calling point. This may seem more practical at the time, but it will cause unnecessary confusion to other people who read the code. Of course, this is a matter of opinion.
  Finally, I remember that there was a period of time when I often wrote learning logs, and after each log I would shout a slogan to encourage myself. Yes, it is time to shout the slogan again:
  Make a little progress every day, and be happier^_^
  Register APP and set device name
• The grass green box is the function of adding various services
• The red box is to set broadcast data and start broadcasting
• The gray box is to obtain BLE related events and process them
• The Bluetooth color box is to process other notify events

(A note here: I used the word editor and pasted it over, but the website's paste function is not powerful, so most of my formatting was removed, so,

If you need, you can download the PDF format on the second floor to view it. Thank you! Hereby declare!)

As for other operations, such as flashing lights during broadcasting, always on when connected, etc., readers need to add them by themselves. They can add them to

BLE events, or use messages to do a task. This needs to be done in combination with freertos. The use of freertos will be gradually involved in subsequent learning.

Other instructions

The overall architecture of the DA14683 SDK is relatively clear, and it is also relatively convenient to call. However, some places can be further subdivided. For example, the definition of device information service and device information can be completely defined in the source file of the device information service (source file dis.c), and there is no need to define it in the ble_peripheral_task.c file. Perhaps it is for the convenience of users to set it up.

Another point is that global variables are defined in the middle of the source code. This may be based on the principle of proximity. The variable is called from the place closest to the calling point. This may seem more practical at the time, but it will cause unnecessary confusion to other people who read the code. Of course, this is a matter of opinion.

Finally, I remember that there was a period of time when I often wrote learning logs, and after writing each log, I would shout a slogan to encourage myself. Yes, it is time to shout the slogan again:

Make a little progress every day, and be happier^_^

懒猫爱飞

I'm taking a seat on the second floor and uploading a PDF document. If you need it, you can download the organized PDF document, or it will look more beautiful^_^ ---->>> Da14683学习日志（二） - Perpherial工程学习总结.pdf (952.73 KB, downloads: 25)

2018-8-17 15:13 上传

点击文件名下载附件

Okay, I wish you good luck, and I'll organize the next one when I have time