I have a program where I get a large number of bytes from BLE, then send it to another device attached to the Dialog chip via I2C
My program is based on the ble_peripheral_app sample program
The problem is that while I2C write is happening (and it takes some time to complete since I am writing a large number of bytes), if new data comes in through BLE, the BLE just gets disconnected
I am assuming that if new BLE data comes in while it is writing to the I2C port, the program tries to jump to user_catch_rest_hndl() function, which the I2C prevents from happening, and this is causing the BLE disconnection
Is it possible to stop the chip from receiving any new BLE data until all the I2C communication is complete? What I want to do is "stop BLE data reception" before I start I2C communication so that the chip ignores any new incoming BLE data, then "start BLE data reception" again, after all the I2C operations are finished.
How can this be done?
Hi mahaju,
As far as i can understand apparently you are missing BLE connection events due to the I2C activity, but i dont quite get the case with the incomming data, you mean you get disconnected when the central device sends data ? Regarding stopping incomming data from the central, there is no native way to do so, only if you have a characteristic as a flow control signal that can be notified by the peripheral and the central should check this before sending data.
还请注意,连接是重要的ained with the connection events and you should schedule those events just to maintain the connection not only to get data, so you will have to make sure that the device will be able to schedule when the time for connection event comes and not execute I2C transaction. In order to achieve that you will have to make sure that the I2C transaction will not take that long and will let the scheduler to run in order to schedule the connection event, so your I2C transaction should be divided in small fractions that can be attached to the app_on_system_powered callback or app_on_ble_powered and return KEEP_POWERED as long as there is more transaction to perform, so that the device would execute the entire transaction piece by piece and without delaying the scheduler which schedules the connection events.
Thanks MT_dialog