Chris Friedt

Yeah - everyone in the Zephyr community is kind of in crunch time right now because they're on 2.4.0-rc2 and 2.4.0 is set to be released imminently. I would assume...

I'll follow up with TI to see if they will fund the BLE driver work Otherwise, the demo is documented here: https://gist.github.com/cfriedt/f2026ed38025b30c67103088e14198d6 Nowadays, with the greybus service, it's more like...

Working on SPI next.

BLE has been demonstrated to work already. However, if you are asking what the status is of porting the Zephyr BLE stack to the cc1352r, which was outside the scope...

> Can you please document the issue with the TI BLE stack on e2e.ti.com and link here? TI's BLE5 Stack (and even the 'micro ble stack') require TI-RTOS. TI has...

https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/973763?LAUNCHXL-CC1352R1-Support-for-BLE5-Stack-on-another-RTOS

Just an aside, in Zephyr, we previously used named-registers for this. However, that caused our DT bindings to diverge from the Linux DT bindings, which caused further fragmentation.

ping?

It would be kind of great to have 1 header file for converting between zephyr time representations. Naming things is hard, but if it can be added to an existing...

I would say, the basis for POSIX time is `struct timespec` rather than a 64-bit timestamp. `struct rtctime` could be converted to a 64 bit ms counter since the epoch...