I am using a PAN1315 module. The goal is to support multiple SCO channels (well, up to the maximum of 2 supported by the chip) over the I2S bus. There doesn't appear to be any command or event that specifies which I2S channel a particular connection is on. Therefore, I'm hoping there is a reliable means of determining which channel a connection is on. How does the chip internally decide which channel to put a connection on, at what point does it decide, and does it remain constant for the lifetime of that SCO connection?
Each SCO gets assigned one channel. The first connection gets the first channel (which stays with it for the remaineder of the connection life time), and the second connection gets the second I2S channel (again, which stays with it for the remainder of the connection time).
There is not event that will tell you which I2S channel a particular connection has been assigned.
In reply to Arild Kolsrud:
Is it safe then to say that when I get an HCI_Connection_Request_Event of type SCO/eSCO I can count that link as having a channel allocated and when I get a HCI_Disconnection_Complete_Event on that handle the channel allocation is removed? And there is no possible way I would get interleaved events such that a channel was allocated for one handle but an event sent on another before the event for the allocation occurred (and similar for channel de-allocation)?
In reply to Mike Brudevold:
We've noticed that the connection handle for the first SCO connection is something like 0x0101 and the second SCO connection is like 0x0202 (where the least significant byte corresponds to the device handle, so we could see 0x0101 or 0x0102 depending on which device opens the first SCO). Is this intentional? Can we parse the least significant bits of the most significant byte and accurately obtain which I2S channel a particular device is on?
The connection handle ordering that you mentioned is true for ACL handles. SCO connections are created on top of ACL connection(radio level). So SCO handle will take on its corresponding ACL handle. So as long each ACL/SCO connections at the radio level is made in order, your parsing should be correct.
Check out the CC26xx/CC254x BLE Main Wiki page: http://ti.com/ble-wiki
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.