- I am using BLE SDK 2.10, and a Client based on soc-thermometer Client example project.
- Based on certain conditions, I need to accurately bit-bash a GPIO with small delays in microseconds to control an external device. I am using the udelay.c file for this (UDELAY_Delay). I have checked that this function is working.
- However I find that the bit-bashing is not accurate. I am suspecting that this is because something is interrupting, maybe the BLE radio?
- As a cross-check I do the same bit-bashing before getting into the gecko while(1) loop and the bit-bashing timing is perfect.
1) Is there some way to make this function atomic whenever needed? The function could take upto 1.5seconds to execute the bit-bashing.
2) Maybe some way to disable any external functionality (e.g. interrupts) for this period of time?
3) The Client may be connected or not connected to a Server, both cases have to work.
Check out the "system halt" command in the API ref.manual. You can use it to temporarily halt the radio operation.
If you halt the stack for 1-2 seconds and the connection supervision timeout is set to a longer value than this, then connections should not be dropped.
1) Do you mean gecko_cmd_system_halt(1)?
I am using it already to shut down and go to EM2 mode, when BLE operation is not needed and save battery.
I didn't realise it can be used and remain operational i.e. not in EM2. But now that you have suggested it, I realise that perhaps this function does not set EM2 but it's actually when it goes to wait for the next event in the gecko while(1) loop, that's where it goes to EM2. Right?
2) I will check about the connection supervision timeout as well. Is this the last parameter in cmd_le_gap_set_conn_parameters? It is currently 1000ms (default) and I can increase it to 3000ms to be on the safe side.
3) Is this timeout only to be increased by this API on the Client side or has to be called on the Server too?
Thanks for your help!
For my question 3) I think I have to read this carefully: https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/cannot_change_connec-JAKd
I realise that perhaps this function does not set EM2 but it's actually when it goes to wait for the next event in the gecko while(1) loop, that's where it goes to EM2. Right?
That command is used to set DEFAULT connection parameters and it is only effective on the master side. The right command to use is cmd_le_connection_set_parameters, you can use it for connections that are already established. It can be called either on the master or slave side (no need to call on both sides).
I can confirm that system_halt worked in preventing interrupts to the bit-bashing.
I used cmd_le_gap_set_conn_parameters to set the default timeout just after bootup event and cmd_le_connection_set_parameters just after connection is opened i.e. gecko_evt_le_connection_opened_id, to set the current connection timeout.