nrf52832 for industrial automation

[Stas]

As I understand we have some problems with time sensitive actions while using softdevice with active ble connection. So here's my questions:

1. Are there some possible problems with hardware peripherals (in part of time accuracy) while we have active ble or hardware things absolutely independent.

2. It often needs to have more than one uart module in industrial automation, and also accuracy time operations for getting data with a lot of sensors, manage various actuators. So I think to use separate controller for that things, but with ability to OTA DFU. So my schema would be something like that:

nrf52832 (for ble all the time) <- (spi bus) -> second nrf52832 (for time sensitive operations)

So both of that controllers use softdevice, but first one all the time for ble, second one just for OTA DFU. For example second controller advertising with dfu service during 1 minute after reset and restarted by command gotten via spi bus from first controller or by user.

[endnode]

1. Surely once you run on (single MCU) ARM Cortex-M some time-sensitive process with higher interrupt priority (= BLE stack) then any other "virtual" thread may suffer. However there are methods how to "suspend" Nordic BLE stack activity for given period of time and process anything else. And because BLE is designed to keep the link alive and with 100% (or 0;) transport success rate even if there is packet loss for certain time period it can be a solution. Indeed if you will have hard requirements and you will insist on running of completely independent RTOS on top of SD (which is indeed also RTOS of its kind) then you will fail (but that's kind of evident on the first sight;). Look into Timeslot API in SoftDevice API and Specification.
2. It looks like pretty wasteful to have two BLE chips and stacks connected through (fast) SPI bus. Why you don't keep all the BLE related (and "high-level management") tasks in nRF52 and then offload all "100% real time and many wired interfaces demanding" job to other specialized chip (like some UART multiplexor with fast SPI bus or some more general MCU from STM32 or LPCxxx or other popular series)? If you design your protocols correctly it should be no problem to operate in parallel high-priority tasks (like sensor/alert/command data flow over radio between command center and your automated system) and low-priority tasks (like downloading new DFU image OTA to nRF52, storing it there and then perforiming actual bootloading at the time when it's OK = this works for both nRF52 itself as well as anything what will be connected over SPI/I2C/UART...). Surely nRF52 could be used to some extend as such "universal" MCU on "real-time" side of the system but operating two BLE stacks and two connection links to the same box looks sub-optimal to me...