Bluetooth: ISO: Expand defines and their text

[Thalley]

Add a few missing defines for limits used in ISO.
Add missing units and provide the value in both
hex and decimal (with units) for easier-to-read support.

[Copilot]

Pull Request Overview

This PR enhances the ISO limits in iso.h by adding missing define constants and improving comment clarity with explicit units and decimal representations.

• Added missing minimum retransmission defines (CONNECTED_RTN_MIN, BROADCAST_RTN_MIN) and standardized BROADCAST_CODE_SIZE.
• Expanded inline comments to include both hex and decimal values with units.
• Introduced new subinterval limit defines and detailed notes on interval dependencies.

Comments suppressed due to low confidence (5)

include/zephyr/bluetooth/iso.h:80

• The numeric grouping uses periods (4.000.000) which can be misread as a decimal; switch to commas (4,000,000 µs) or no separators (4000000 µs) for clarity.

/** Maximum controller delay in microseconds (4.000.000 us) */

include/zephyr/bluetooth/iso.h:88

• The comment implies 4 ms but the defined max (0x0C80 × 1.25 ms) equals 4000 ms (4 s). Update to "4,000 ms (4 s)" or simply "4 seconds" for accuracy.

/** Maximum ISO interval in units of 1.25 ms (4.000 ms) */

include/zephyr/bluetooth/iso.h:92

• Similar to the ISO interval comment, this reads as 4 ms but 0x0FA0 = 4000 ms; revise to "4,000 ms" or "4 seconds" and add a space before the closing */.

/** Maximum latency value in milliseconds (4.000 ms)*/

include/zephyr/bluetooth/iso.h:128

• The grouping and magnitude are unclear: 0x4000 × 10 ms = 163,840 ms. Change to "163,840 ms" or "163.84 s" for consistency.

/** Maximum BIG sync timeout value in units of 10 ms (163.840 ms) */

include/zephyr/bluetooth/iso.h:167

• The decimal value is incorrect: 0x00009C3F = 39999 µs. Update the comment to "39,999 µs" (or "39.999 ms") to match the define.

 */

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Thalley]

Unfortunately we don't really have a defined way for thousand separators (https://discord.com/channels/720317445772017664/884782246010175528/1393207293440426115), so went with . in this case.

[cvinayak]

Isn't this a number localization choice? Is there any guidelines documented @kartben ?

We have used 0.625 us, 1.25 ms 1250 us, 10000 microseconds etc. in public APIs.

BLUETOOTH CORE SPECIFICATION Version 6.1 | Vol 3, Part C, Appendix A Timers and Constants, mostly uses seconds and millisecond units in US English formats? (I may be wrong here on which localization that it is).

Suggested change

	/** Maximum controller delay in microseconds (4.000.000 us) */
	/** Maximum controller delay in microseconds (4000000 us) */

[Thalley]

Isn't this a number localization choice? Is there any guidelines documented @kartben ?

Asked about this on Discord as well (https://discord.com/channels/720317445772017664/884782246010175528/1393207293440426115), and there a few cases where the lack of defined formatting for large numbers can be an issue

BLUETOOTH CORE SPECIFICATION Version 6.1 | Vol 3, Part C, Appendix A Timers and Constants, mostly uses seconds and millisecond units in US English formats

They usually mix units in the HCI spec, e.g. they may give a value (in microseconds) a range of 400 ms to 4 s

Not sure if that is better or not, but I do like that when a value is in a specific unit (e.g. microseconds), then the range is also expressed in values of that unit, instead of mixing both microseconds and seconds. Some times the BT Core spec also uses 10 ms (centisecond) as the unit, but due to how rarely that unit is used, they always write "10 ms" instead, and arguably we should too, but I don't have a strong opinion here

[Thalley]

Another thing I was also considering was to the decimal, instead of hexadecimal for the #defines, so that the comment in most cases didn't have to specify the value in a human-readable format, but I also think it's nice that the values are defined the same way as they are in the BT HCI spec (in hexadecimal).

For example,

/** Maximum latency value in milliseconds (4.000 ms)*/
#define BT_ISO_LATENCY_MAX          0x0FA0

could also have been

/** Maximum latency value in milliseconds (0xFA0 ms)*/
#define BT_ISO_LATENCY_MAX          4000U