Best practices for multiple module deployment

[Mike Mascari]

Good afternoon. 

We are engaged on a project that entails the simultaneous, independent development of two separate modules capable of interacting with the BLE stack.

Q1. Is there a best practices document that gives direction / options on how to ultimately deliver the solution to the nrf5340?

Q2. Is the only approach the delivery of a unified, compile-time merged hex or is there any deployment-time support we should be aware of? 

Q3. If the former (compile-time merged hex), is there an approach towards modularization worth exploring (e.g.: time-sliced threading) that would allow for logical isolation of code? For example, if both "modules" need to register for BLE connection call-backs, is there an approach that would allow two different pieces of code to do so in an isolated manner?

Thank you!

[ovrebekk]

Hi 

If I understand you correctly the two modules you are talking about are software modules that you will run in parallel on the same nRF53 device?

If so I don't see any good way to develop these modules as separate applications with their own hex file, I believe you will have to include them as two separate libraries or source modules in the same project, and compile them together. 

All software libraries and examples for the nRF53 are based around the new nRF Connect SDK platform (NCS). 

NCS uses the Zephyr RTOS under the hood, which is an open source RTOS optimized for low power IoT applications. 

Being an RTOS Zephyr supports multi threading, and provides various OS constructs for handling synchronization between different threads, such as mutexes, semaphores and FIFO's. 

For a full overview of the Zephyr OS features, please look at the Zephyr kernel primer. 

The simplest way to do this would probably be to just wrap all the BLE calls in a mutex, but with Zephyr you should have several options depending on the application requirements. 

Best regards
Torbjørn