Optimizing data management between BLE and USB in 'NUS Central + CDC_ACM'

[seongmincho]

Hello!

I am programming BLE with the nRF52840-DK. [Toolchain Manager: v1.3.0, IDE: Visual Studio Code (VSCode), SDK: ncs v2.6.0, window11 pro]

I am integrating NUS Central and cdc_acm. My current goal is to send data received via Bluetooth to a PC (PuTTY) through USB. The current settings are as follows:

<Peripheral Settings>

1. Bluetooth

• MTU: 244
• Data length: 251
• PHY_2M
• Measured data throughput: about 1.41Mbps

2. USBD

• cdc_acm
• Ring buffer: 8192 bytes
• Transmission unit: 512 bytes
• Measured data throughput: about 3.60Mbps

Current Code Operation

Operates using Bluetooth receive callback and UART callback.

#define RING_BUF_SIZE 8192
#define tx_data_SIZE 512
uint8_t ring_buffer1[RING_BUF_SIZE];
uint8_t ring_buffer2[RING_BUF_SIZE];
static uint8_t buffer[tx_data_SIZE];
struct ring_buf ringbuf1, ringbuf2;
struct ring_buf *current_ringbuf;
struct ring_buf *backup_ringbuf;


static void interrupt_handler(const struct device *dev, void *user_data){
    ARG_UNUSED(user_data);
    while (uart_irq_update(dev) && uart_irq_is_pending(dev)) {
        if (uart_irq_tx_ready(dev)) {
            int rb_len = ring_buf_get(backup_ringbuf, buffer, sizeof(buffer));
            if (rb_len == 0) {
                struct ring_buf *temp = current_ringbuf;
                current_ringbuf = backup_ringbuf;
                backup_ringbuf = temp;
                rb_len = ring_buf_get(backup_ringbuf, buffer, sizeof(buffer));
            }
            
            if (rb_len > 0) {
                int send_len = uart_fifo_fill(dev, buffer, rb_len);
                if (send_len < rb_len) {
                    ring_buf_put(backup_ringbuf, buffer + send_len, rb_len - send_len);
                }
                //LOG_INF("Sent %d bytes via USB", send_len);
            } else {
                uart_irq_tx_disable(dev);
            }
        }
    }
}

static uint8_t ble_data_received(struct bt_nus_client *nus, const uint8_t *data, uint16_t len){
	ARG_UNUSED(nus);
    int rb_len = ring_buf_put(current_ringbuf, data, len);
	if (rb_len < len) {
        // 현재 버퍼가 가득 찼으면 백업 버퍼로 전환
        struct ring_buf *temp = current_ringbuf;
        current_ringbuf = backup_ringbuf;
        backup_ringbuf = temp;   
        // 남은 데이터를 새 현재 버퍼에 추가
        rb_len += ring_buf_put(current_ringbuf, data + rb_len, len - rb_len);
    }
    if (rb_len < len) {
        LOG_WRN("Both buffers full, dropped %d bytes", len - rb_len);
    }
    const struct device *dev = DEVICE_DT_GET_ONE(zephyr_cdc_acm_uart);
    uart_irq_tx_enable(dev);
    //LOG_INF("Received %d bytes via BLE, added %d to ring buffer", len, rb_len);
    return BT_GATT_ITER_CONTINUE;

}

Issue

During execution, the ring buffer quickly becomes full and does not function properly. 

In the integrated code, data is being filled via Bluetooth faster than it is being sent out via USB.

However, when running Bluetooth and USB independently, the speed of USB is faster than that of Bluetooth.

Therefore, it seems there might be an issue in the code that handles data management. (It seems especially likely that data management is lacking.)

Can you recommend any examples or tickets that might help me with this issue?

- below is debugging 

*** Booting nRF Connect SDK v3.5.99-ncs1 ***
[00:00:00.004,577] <inf> usb_cdc_acm: Device suspended
[00:00:00.102,355] <inf> usb_cdc_acm: Device resumed
[00:00:00.335,632] <inf> usb_cdc_acm: Device configured
[00:00:04.703,704] <inf> cho: DTR set
[00:00:04.814,392] <inf> cho: Baudrate set to 115200
[00:00:04.814,514] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
                                            36 f0 e5 0e 87 68 48 fb  02 fd 9f 82 cc 32 e5 7b |6....hH. .....2.{
                                            91 b1 5c ed                                      |..\.             
[00:00:04.816,528] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:04.816,558] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:04.816,589] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 54.58864 Build 1214809870
[00:00:04.817,687] <inf> bt_hci_core: Identity: C2:82:F6:94:03:85 (random)
[00:00:04.817,718] <inf> bt_hci_core: HCI: version 5.4 (0x0d) revision 0x118f, manufacturer 0x0059
[00:00:04.817,749] <inf> bt_hci_core: LMP: version 5.4 (0x0d) subver 0x118f
[00:00:04.817,779] <inf> cho: bt_nus_client_init >>> err:0
[00:00:04.818,481] <inf> cho: Scanning successfully started
[00:00:12.117,492] <inf> cho: Filters matched. Address: C1:7B:8C:FE:EB:35 (random) connectable: 0 
[00:00:12.118,316] <inf> cho: <<< scan_connecting >>>>
[00:00:12.331,298] <inf> cho: connected - GET_INFO >>> err:0
[00:00:12.331,329] <inf> cho: connected - Connected as central
[00:00:12.331,329] <inf> cho: connected - Conn. interval is 40 units
[00:00:12.331,542] <inf> cho: connected - Set_Security >>> err:0
[00:00:12.331,756] <inf> cho: connected - bt_conn_le_param_update (err 0)
[00:00:12.332,061] <inf> cho: connected - PHY >>> err:0
[00:00:12.332,275] <inf> cho: connected - data_length >>> err:0
[00:00:12.332,275] <inf> cho: connected - SCAN_STOP (err -120)
[00:00:12.332,305] <inf> cho: connected - GET_INFO >>> err:0
[00:00:12.332,305] <inf> cho: connected - Conn. interval is 40 units
[00:00:12.382,781] <err> bt_smp: pairing failed (peer reason 0x3)
[00:00:12.382,812] <inf> cho: CALLBACK - Security change failed: 4
[00:00:12.382,904] <inf> cho: gatt_discover - GATT_dm_start: 0
[00:00:12.383,087] <inf> cho: CALLBACK - Pairing failed conn: C1:7B:8C:FE:EB:35 (random), reason 4
[00:00:12.632,781] <inf> cho: CALLBACK - Connection parameters updated. >> interval: 80, latency: 0, timeout: 400
[00:00:13.282,714] <inf> cho: CALLBACK - LE data len updated: TX (len: 251 time: 2120) RX (len: 251 time: 2120)
[00:00:14.182,739] <inf> cho: CALLBACK - Service discovery completed
[00:00:14.182,922] <inf> cho: discovery_complete - MTU exchange pending
[00:00:14.282,226] <inf> cho: CALLBACK - LE PHY updated: TX PHY LE 2M, RX PHY LE 2M
[00:00:14.582,611] <inf> cho: CALLBACK - MTU exchange done
[00:00:15.796,112] <wrn> cho: Both buffers full, dropped 192 bytes
[00:00:15.797,515] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.798,889] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.800,292] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.801,696] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.803,070] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.804,473] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.805,877] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.807,250] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.808,654] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.810,058] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.811,431] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.812,835] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.814,239] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.815,612] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.817,016] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.818,389] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.932,373] <wrn> cho: Both buffers full, dropped 8 bytes
[00:00:15.933,715] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.935,119] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.936,523] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.937,896] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.939,300] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.940,704] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.942,077] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.943,481] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.944,885] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.946,258] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.947,662] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.949,035] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.950,439] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.951,843] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.953,216] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.954,620] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.956,024] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.987,792] <wrn> cho: Both buffers full, dropped 4 bytes
[00:00:15.989,166] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.990,539] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.991,943] <wrn> cho: Both buffers full, dropped 244 bytes
[00:00:15.993,316] <wrn> cho: Both buffers full, dropped 244 bytes

[Simonr]

Hi

I don't think we have a sample explaining this exactly, but the Ring buffers documentation available here should be useful for seeing how the buffers should be handled in the Zephyr RTOS. 

Best regards,

Simon

[seongmincho]

thank you for your attention. 
I apologize for my lack of clarity. The key point I want to address is how to manage incoming data at a speed of 1.4Mbps. I am curious about how others generally solve this issue, for example, by using double buffering, message queues, etc(High-speed data streaming real-time processing and transmission challenge)
.