nrf_rpc: Update doc with new transport layer

This updates nRF RPC documentataion with the newest
changes that add possiblity to use different transport
for each group.

Signed-off-by: Kamil Gawor <Kamil.Gawor@nordicsemi.no>

nrf_rpc/doc/architecture.rst

@@ -32,9 +32,8 @@ The following image shows an example of the command and response flow.
    nRF RPC command and response flow
 
 **Events** are intended to be used for asynchronous function calls.
-The caller sends an event to the other side and returns immediately if there is a free thread in the thread pool.
+The caller sends an event to the other side and returns immediately.
 See the :ref:`nrf_rpc_architecture_threads` section.
-Otherwise, it waits for an available thread.
 It is not possible to return anything from the remote side after receiving an event, but it is possible to send an event in the opposite direction.
 The following image shows an example of the event flow.
 
@@ -54,9 +53,7 @@ For this reason, each side of nRF RPC contains a thread pool.
 The thread pool is OS-dependent and implemented in the OS abstraction layer.
 The number of threads in a thread pool is configurable.
 
-When a caller wants to call a remote procedure, nRF RPC checks if there is a thread available in a pool.
-If there is none, then it waits until one becomes available, blocking the caller.
-After that, nRF RPC sends a packet and it is executed by an available thread from a thread pool.
+The nRF RPC sends a packet and it is executed by an available thread from a thread pool.
 In the case of a command being received, a response is sent directly to a waiting thread, so no new thread is allocated for a response.
 
 The following image presents sample command and response flows.
@@ -122,12 +119,19 @@ Transport
 ---------
 
 The main role of a transport is to transfer packets between two sides.
-You can select the transport implementation using the library configuration.
+You can implement your own transport for any nRF RPC group.
+The transport layer defines a destination remote CPU.
 
-Currently the default transport is `OpenAMP`_ on `Zephyr`_.
+The header file describing the nRF RPC transport API is :file:`include/nrf_rpc_tr.h`.
 
-The template header describing the nRF RPC transport API is :file:`template/nrf_rpc_tr_tmpl.h`.
-The header file :file:`include/rp_trans.h` is responsible for including the right transport header file based on the configuration.
+Assign your transport interface to the nRF RPC group as follows:
+
+.. code-block:: c
+
+   /* Setup this structure with your transport API and transport specific data. */
+   struct nrf_rpc_tr your_transport;
+
+   NRF_RPC_GROUP_DEFINE(math_group, "sample_math", &your_transport, NULL, NULL, NULL);
 
 Operating system abstraction
 ----------------------------

nrf_rpc/doc/usage.rst

@@ -24,9 +24,12 @@ RPC encoders
 
 RPC encoders encode commands and events into serialized packets.
 Creating an encoder is similar for all packet types.
-The first step is the allocation of a buffer using :c:macro:`NRF_RPC_ALLOC`.
-After that, you can encode parameters directly into the buffer or use the `TinyCBOR`_ library.
-In the last step, the packet is sent using one of the sending functions: :c:func:`nrf_rpc_cmd`, :c:func:`nrf_rpc_cbor_evt`, or similar.
+To create an encoder, complete the following steps:
+
+1. Allocate a buffer using :c:func:`nrf_rpc_alloc_tx_buf`.
+#. Encode parameters directly into the buffer or use the `TinyCBOR`_ library.
+
+The packet is sent using one of the sending functions: :c:func:`nrf_rpc_cmd`, :c:func:`nrf_rpc_cbor_evt`, or similar.
 
 After sending the command, a response is received, so it must be parsed.
 There are two ways to parse a response.
@@ -55,7 +58,7 @@ It returns 0 on success or a negative error code if communication with the remot
 	/* Defines a group that contains functions implemented in this
 	 * sample.
 	 */
-	NRF_RPC_GROUP_DEFINE(math_group, "sample_math", NULL, NULL, NULL);
+	NRF_RPC_GROUP_DEFINE(math_group, "sample_math", &transport, NULL, NULL, NULL);
 
 	/* Defines a helper structure to pass the results.
 	 */
@@ -70,7 +73,7 @@ It returns 0 on success or a negative error code if communication with the remot
 		struct remote_inc_result result;
 		struct nrf_rpc_cbor_ctx ctx;
 
-		NRF_RPC_CBOR_ALLOC(ctx, MAX_ENCODED_LEN);
+		NRF_RPC_CBOR_ALLOC(&math_group, ctx, MAX_ENCODED_LEN);
 
 		cbor_encode_int(&ctx.encoder, input);
 
@@ -90,7 +93,7 @@ The following code shows how this function might look.
 
 .. code-block:: c
 
-	static void remote_inc_rsp(CborValue *value, void *handler_data)
+	static void remote_inc_rsp(const struct nrf_rpc_group *group, CborValue *value, void *handler_data)
 	{
 		CborError cbor_err;
 		struct remote_inc_result *result =
@@ -126,10 +129,10 @@ A RPC decoder associated with the example above can be implemented in the follow
 	 * sample. Second parameter have to be the same in both remote
 	 * and local side.
 	 */
-	NRF_RPC_GROUP_DEFINE(math_group, "sample_math", NULL, NULL, NULL);
+	NRF_RPC_GROUP_DEFINE(math_group, "sample_math", &transport, NULL, NULL, NULL);
 
 
-	static void remote_inc_handler(CborValue *value, void* handler_data)
+	static void remote_inc_handler(const struct nrf_rpc_group *group, CborValue *value, void* handler_data)
 	{
 		int err;
 		int input = 0;
@@ -142,19 +145,19 @@ A RPC decoder associated with the example above can be implemented in the follow
 			cbor_value_get_int(value, &input);
 		}
 
-		nrf_rpc_cbor_decoding_done(value);
+		nrf_rpc_cbor_decoding_done(group, value);
 
 		/* Actual hard work is done in below line */
 
 		output = input + 1;
 
 		/* Encoding and sending the response */
 
-		NRF_RPC_CBOR_ALLOC(ctx, MAX_ENCODED_LEN);
+		NRF_RPC_CBOR_ALLOC(group, ctx, MAX_ENCODED_LEN);
 
 		cbor_encode_int(&ctx.encoder, output);
 
-		err = nrf_rpc_cbor_rsp(&ctx);
+		err = nrf_rpc_cbor_rsp(group, &ctx);
 
 		if (err < 0) {
 			fatal_error(err);