General catalogue

Construction of single chip microcomputer HLK-W801 development environment
Single chip microcomputer - HLK-W801 Bluetooth BLE function test

Yesterday, the demo ran clearly. Today, let's take a look at the LED of the development board lit by the mobile phone through Bluetooth remote control. Although this is not a typical use of low-power Bluetooth, it is a blessing to be able to quickly learn the disgusting SDK code of W801 through this means. Oh, isn't that what old Ma said.

Debugging tools

The mobile phone Bluetooth debugging tool used here is nrf connext. The app store can also search BLE and find many Bluetooth development tools. However, it will apply for various mobile phone permissions, positioning and photo albums. It can't be used if it's not allowed. It's simply a rogue behavior. This country has long said this problem, but there's no way.

But this software is very good. I don't have any permission to apply
You can use it directly. Moving.

Auto start server

In the original demo, we know that we need to make the development board run automatically as a BLE server, which requires two parts

• Turn on Bluetooth
• Run as server

The core code is these two functions

	demo_bt_enable();
	demo_ble_server_on();

However, if you want to clean copy the implementation of these two functions to your main function file, you still want to use some global variables, such as print level or adapter status.

So, you simply built a code for you, why do you want to write it yourself, just use its demo code directly, including all the header files directly, and then call these two functions.
So the main code is written like this

	demo_bt_enable();
	while(bt_adapter_state == WM_BT_STATE_OFF)
	{
		tls_os_time_delay(5000 /HZ);
	}
	tls_os_time_delay(5000 /HZ);
	demo_ble_server_on();

You can make the development board run as a server. Easy

Receive command

Here, you need to find the place where BLE server receives commands, which is in this function

static int gatt_svr_chr_demo_access_func(uint16_t conn_handle, uint16_t attr_handle,         struct ble_gatt_access_ctxt *ctxt, void *arg)
{
	int i = 0;
	struct os_mbuf *om = ctxt->om;

	switch (ctxt->op) 
	{
		case BLE_GATT_ACCESS_OP_WRITE_CHR:
		while(om) 
		{
			if(g_ble_uart_output_fptr)
			{
				g_ble_uart_output_fptr((uint8_t *)om->om_data, om->om_len);
			}
			else
			{
				print_bytes(om->om_data, om->om_len); 
			}
			om = SLIST_NEXT(om, om_next);
		}
	return 0;
	default:
	assert(0);
	return BLE_ATT_ERR_UNLIKELY;
	}
}

It indicates a logic, that is, if there is no output function pointer g_ble_uart_output_fptr, then it will be printed automatically, and it will be done when the place where the message is received is found. We can already send data or commands from the mobile phone to the development board through Bluetooth.

Message transmission

Here, in order to make our code a little independent, a message queue is used to send the commands received by Bluetooth to my main task through the queue. This part is placed in the main function file. Then we can modify the requirements here directly in the future, and there is no need to focus on the message transmission process.

Create a queue in the main function and start the monitoring receiving task

	if(tls_os_queue_create(&MyBLE_QUEUE, 32)!=TLS_OS_SUCCESS)
	{
		printf("create queue fail\n");
		return;
	}
	tls_os_task_create(NULL, NULL,
                       my_ble_msg_task,
                       NULL,
                       (void *)MyBLETaskStk,          /* task's stack start address */
                       MyBLE_TASK_SIZE * sizeof(u32), /* task's stack size, unit:byte */
                       MyBLE_TASK_PRIO,
                       0);

Message receiving task

void my_ble_msg_task(void *sdata)
{
	void *msg;

	for(;;)
	{
		tls_os_queue_receive(MyBLE_QUEUE, (void **)&msg, 0, 0);
		printf("myble revice %ld \n",(u32)msg);
	}
}

Replace the previous output print with send message. At present, we only take the first byte, which is enough to transmit information.

//print_bytes(om->om_data, om->om_len); 
if(om->om_len>0)
{
	tls_os_queue_send(MyBLE_QUEUE, (void *)(om->om_data[0]), 0);
}

In this way, after startup, the message will be automatically sent to my task, and we can only concentrate on this message.

Message processing

Here, the message is transformed into the control LED on and off, and the test effect is achieved

Here, as long as the GPIO output low level is controlled, the LED can be turned on and the output high level will be turned off.
Lighting process.

tls_gpio_cfg(MyLED1_IO, WM_GPIO_DIR_OUTPUT, WM_GPIO_ATTR_FLOATING);
tls_gpio_write(MyLED1_IO,0);	

Overall test

First run the development board and wait for the server state to start.

Then the phone opens the test tool, scans it to the development board and connects it

Then click the up arrow to send data

Send 0, you can control the led on

The development board is lit

Send 1 and the development board goes out.

It's done.

Supplementary notes

This SDK encapsulates the original contents of FreeRTOS, such as

//Message queue
 tls_os_status_t tls_os_queue_create(tls_os_queue_t **queue, u32 queue_size)
 //Task creation
 tls_os_status_t tls_os_task_create(tls_os_task_t *task,
      const char* name,
      void (*entry)(void* param),
      void* param,
      u8 *stk_start,
      u32 stk_size,
      u32 prio,
      u32 flag)
//delay
 void tls_os_time_delay(u32 ticks)

This set obviously doesn't look good. It's connected with tls encryption. In fact, it doesn't matter for half a dime

You can use it to encapsulate code, such as the message queue I used above. This can make the code appear clean, or you can use the original functions of FreeRTOS. There is no essential difference. It depends on your preference. For the usage of FreeRTOS, please refer to my articles
FreeRTOS learning - "task"
FreeRTOS learning - "message queue"
FreeRTOS learning - "semaphores"
FreeRTOS learning - "event group"
FreeRTOS learning - "timer"

Conclusion

It took three hours to make a demo and write an article, which only provided a way to solve the problem. Sometimes, you don't need to understand the functions thoroughly. As long as you can cut in and find the key points of implementation, you can make something quickly.
But of course, it doesn't mean that in-depth understanding is not good. Once there are some stable bug s, you may need to deeply understand the code.
Time is money, efficiency is life, but sometimes it's not a good thing to rush desperately. I saw a car at the peak this morning

The air bag came out and the glass broke. Hey, I hope the ambulance can help you get out more time. I hope people are all right.