S132: Concurrent BT operations on multi connection implementation, large BT packets

[puz_md]

Hello everybody,

Does the S312 v2.0.0 handle BT operations completely independent for each BT connection? Can I read/write from/to different characteristics on different BT devices at the same time? Especially when transferring large characteristics which need multiple operations (connection intervals). Is it possible that one BT connection may blocks other BT connections, e.g. eating up all transfer buffer? Or are BT connections completely transparent to each other when it comes to software/softdevice ressources? (Of course, radio activity may have some inpact on the timing and communication stability.)

My goal is to create multiple modules/services that work on different connections. Is there anything special I have to take care of? Or can I do my implementation like each service would be the only one in the system? (Of course, I have have to ignore on_ble_evt() events that do not relate to my service and connection. But is there anything else?)

Concerning the new Bluetooth specification, it should be possible now to send characteristic values in chunks larger than 22 bytes. Is there any tutorial about how to use this new feature while keeping compatibility with older devices that only support BT 4.0?

Oh, and something else I have been wondering about for a while: Under which control flow priority do the on_ble_evt() and on_sys_evt() run? Is it possible that these functions interrupt each other? Or are the handlers invoked in a sequential/synchronized order?

Kind regards, Michael

[RK]

The softdevice handles all the details of all connections, all reads, all writes and does it all transparently. It schedules all buffer transfers into the available radio slots and ensures everything gets some radio time when it needs it, prioritising as necessary. So just use it.

Nope - 23 bytes is still the max with all the nordic softdevices. BTLE has always supported MTUs bigger than 23 bytes, but implementations are not required to do so and that is still the case with the latest BTLE spec.

If you look at the code you'll see the two handlers you mention are called from the same interrupt, or put into the scheduler queue from the same interrupt, so no they don't interrupt each other.