The Bluetooth Core Specification states:
> Slave latency allows a slave to use a reduced number of connection events.
> The connSlaveLatency parameter defines the number of consecutive
> connection events that the slave device is not required to listen for the master.
While optimizing throughput in a Bluetooth Loader for SBSFU I observed:
Connection Intervals too low won't let me delete flash contents (because timing protection in CPU2).
Increasing the Connection Interval results in successful operation but of course slow down the overall transfer speed.
As far as I understand the Bluetooth Specification, increasing the Slave Latency should allow for shorter Connection Intervals while giving the the controller opportunities to ignore one (or multiple for higher Slave Latency) Connection Event.
From my benchmarks a connection interval value of 20 (25ms) in combination with a Slave Latency of 1 results in the same throughput as a Connection Interval of 40 (50ms) with Slave Latency 0.
So it seems like the implementation ignores every Connection Event that is allowed to be ignored due to Slave Latency.
Is the behaviour I observed intended (read: neccessary due to other constraints)? Did I miss something?
A fix would improve the performance in scenarios where CPU1 needs to erase flash contents during a bluetooth connection.
Thank you for your support.
