nRF5340, evaluate options for fast/reliable data transfer method between cores

Question

I have a project with real-time requirements for a medical device (see my other post about fast BLE/ESB transfer for the exact details), with the main one being that one nRF5340 ("receiver") needs to receive 10-byte packets every 1-2ms from another nRF5340 ("sender") via some wireless protocol (BLE/ESB). I'm currently interested in programming the "receiver" device to use its network core solely for the wireless comms and its application core to take said data and output it via UART. I would imagine the communication/data-transfer between the network core and application core would need to be at least as fast as my "10-bytes-per-ms requirement". 
 I have read several documentation links, forum posts, etc. The following options seem to be what's available (FYI I'm quite new to learning/working-with these libraries and protocols): 
 
 RPC - I got the Entropy sample code working, but before trying to adapt it for my project, I wanted to clarify - is the data being sent wirelessly, even in the dual-core device setup? I take it that's why it's considered "remote" but I'm not too sure. 
 IPC 
 OpenAMP - Seems to be based off shared memory ( see here ) 
 Bluetooth HCI - Seems quite popular but, if it's Bluetooth-based, I'm skeptical about its feasibility. So far, my experiments with getting fast BLE transfer show that BLE isn't fast enough for my project, but ESB most likely will work. 
 Shared SRAM - I would imagine this is the "fastest" option as it's "wired", but I only found some forum posts with unofficial solutions like here . I was wondering if there was official sample code for this, especially ones that can handle race conditions via semaphores/mutexes and the like. 
 
 All in all, I'm hoping to get some advice/feedback on what options are out there, when to use this and that, and which ones I should put my efforts into first. Thanks in advance! 
 --------------- --------------- --------------- --------------- --------------- --------------- 
 Development Setup: 
 
 Board: nRF5340-DK 
 Development Environment: VS Code 
 SDK: nRF Connect 2.5.0 
 OS: Windows 10

ovrebekk · Accepted Answer

Hi 
 Sorry, I forgot to answer your specific questions earlier. 
 'Remote' in RPC is not referring to wireless, no. Either it is a wired connection between two chips, or a direct internal connection between two cores like in the nRF5340. 
 afok-esmart said: Seems like most/all inter-processor comms between the nRF53 cores ultimately boil down to using shared memory space (see here ). That's all I've investigated in this regard. 
 Correct. The only way to share data between the two cores is through the use of shared memory. 
 At the lowest level you have the IPC peripheral which is essentially just a way for either core in the nRF5340 to trigger an event (and optionally an interrupt) in the other core. The ipc_service takes this one step further and allows you to send data as well, by utilizing the shared memory mentioned earlier, but is still a relatively light weight wrapper around the IPC periphal. 
 The RPC library is a bit more complex and handles things such as serialization of structures, as well as emulating function calls in a way that makes it seem you are calling a local function rather than a function running on another core. This is convenient, and allows you to implement API's that can run in a very similar way both on single core and multi core systems, but it does add some overhead compared to the ipc_service. 
 Either way it is good to hear that the ipc_service works well for you. If you are planning to send a large number of messages it makes sense to use a more light weight and streamlined interface between the two cores. 
 And in general the more you can buffer into a single transaction, rather than splitting it up into multiple transactions, the less overhead you will get. 
 Best regards Torbjørn

nRF5340, evaluate options for fast/reliable data transfer method between cores

Top Replies