Hello!
I`am porting the host code to another platform, and will be very grateful if someone could give a little help.
In the function BluetoothConnection::tx_data before making any call huge delays of 1 millisecond are inserted.
As I understand, this code is executed mostly from interrupts and such a huge busy loops is very bad practice.
Do these delays really needed? Can I reduce them to 1 microsecond, maybe? Or its better to use timer callback instead here?
And secondly, in function BluetoothController::claim there is no freeing memory in case of pipe allocation fail:
First call ro free_Pipe() even commented out, and no freeing for the others also...
Why so?
Regards,
Vlad.
I`am porting the host code to another platform, and will be very grateful if someone could give a little help.
In the function BluetoothConnection::tx_data before making any call huge delays of 1 millisecond are inserted.
Code:
//=============================================================================
// Process tx_data and state
//=============================================================================
void BluetoothConnection::tx_data(uint8_t *data, uint16_t length)
{
#ifdef DEBUG_BT_VERBOSE
DBGPrintf("tx_data callback (bluetooth): %d : ", pending_control_tx_);
for (uint8_t i = 0; i < length; i++) DBGPrintf("%02x ", data[i]);
DBGPrintf("\n");
#endif
switch (pending_control_tx_) {
case STATE_TX_SEND_CONNECT_INT:
[B]delay(1);[/B]
connection_rxid_++;
sendl2cap_ConnectionRequest(device_connection_handle_, connection_rxid_, interrupt_dcid_, HID_INTR_PSM);
pending_control_tx_ = 0;
break;
case STATE_TX_SEND_CONECT_RSP_SUCCESS:
[B]delay(1);[/B]
// Tell the device we are ready
sendl2cap_ConnectionResponse(device_connection_handle_, connection_rxid_++, control_dcid_, control_scid_, SUCCESSFUL);
pending_control_tx_ = STATE_TX_SEND_CONFIG_REQ;
break;
case STATE_TX_SEND_CONFIG_REQ:
[B]delay(1);[/B]
sendl2cap_ConfigRequest(device_connection_handle_, connection_rxid_, control_scid_);
pending_control_tx_ = 0;
break;As I understand, this code is executed mostly from interrupts and such a huge busy loops is very bad practice.
Do these delays really needed? Can I reduce them to 1 microsecond, maybe? Or its better to use timer callback instead here?
And secondly, in function BluetoothController::claim there is no freeing memory in case of pipe allocation fail:
Code:
rxpipe_ = new_Pipe(dev, 3, rxep & 15, 1, rx_size_, rx_interval);
if (!rxpipe_) return false;
txpipe_ = new_Pipe(dev, 3, txep, 0, tx_size_, tx_interval);
if (!txpipe_)
{
[B]//free_Pipe(rxpipe_);[/B]
return false;
}
rx2pipe_ = new_Pipe(dev, 2, rx2ep & 15, 1, rx2_size_, rx2_interval);
if (!rx2pipe_)
{
[B] // Free other pipes...[/B]
return false;
}Why so?
Regards,
Vlad.