[MCUX-71701] Correct RPMsg-Lite documentation

Signed-off-by: Michal Princ <michal.princ@nxp.com>

CHANGELOG.md

@@ -168,7 +168,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Support of static API (without dynamic allocations).
 
 
-[unreleased]: https://github.com/nxp-mcuxpresso/rpmsg-lite/compare/v5.1.1...HEAD
+[unreleased]: https://github.com/nxp-mcuxpresso/rpmsg-lite/compare/v5.1.3...HEAD
+[5.1.3]: https://github.com/nxp-mcuxpresso/rpmsg-lite/compare/v5.1.2...v5.1.3
+[5.1.2]: https://github.com/nxp-mcuxpresso/rpmsg-lite/compare/v5.1.1...v5.1.2
 [5.1.1]: https://github.com/nxp-mcuxpresso/rpmsg-lite/compare/v5.1.0...v5.1.1
 [5.1.0]: https://github.com/nxp-mcuxpresso/rpmsg-lite/compare/v5.0.0...v5.1.0
 [5.0.0]: https://github.com/nxp-mcuxpresso/rpmsg-lite/compare/v4.0.0...v5.0.0

README.md

@@ -2,7 +2,8 @@
 [![Contributors](https://img.shields.io/github/contributors/nxp-mcuxpresso/rpmsg-lite)](https://github.com/nxp-mcuxpresso/rpmsg-lite/graphs/contributors)
 [![Issues](https://img.shields.io/github/issues/nxp-mcuxpresso/rpmsg-lite)](https://github.com/nxp-mcuxpresso/rpmsg-lite/issues)
 [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](https://github.com/nxp-mcuxpresso/rpmsg-lite/pulls)
-# RPMSG-Lite {#mainpage}
+
+# RPMSG-Lite
 
 This documentation describes the RPMsg-Lite component, which is a lightweight implementation of the Remote Processor Messaging (RPMsg) protocol. The RPMsg protocol defines a standardized binary interface used to communicate between multiple cores in a heterogeneous multicore system.
 
@@ -11,7 +12,7 @@ Compared to the RPMsg implementation of the Open Asymmetric Multi Processing (Op
 The RPMsg-Lite is an open-source component developed by NXP Semiconductors and released under the BSD-compatible license.
 
 For Further documentation, please look at doxygen documentation at: https://nxp-mcuxpresso.github.io/rpmsg-lite/
-## Motivation to create RPMsg-Lite {#motivation}
+## Motivation to create RPMsg-Lite
 
 There are multiple reasons why RPMsg-Lite was developed. One reason is the need for the small footprint of the RPMsg protocol-compatible communication component, another reason is the simplification of extensive API of OpenAMP RPMsg implementation.
 
@@ -27,7 +28,7 @@ Small MCU-based systems often do not implement dynamic memory allocation. The cr
 |RPMsg-Lite / Static API (no malloc), Release | 2926      | 352           |
 |Relative Difference [%]                      | ~52.7%    | ~77.2%        |
 
-## Implementation {#implementation}
+## Implementation
 
 The implementation of RPMsg-Lite can be divided into three sub-components, from which two are optional. The core component is situated in <i>rpmsg_lite.c</i>. Two optional components are used to implement a blocking receive API (in <i>rpmsg_queue.c</i>) and dynamic "named" endpoint creation and deletion announcement service (in <i>rpmsg_ns.c</i>).
 
@@ -37,21 +38,21 @@ The porting layer is split into two sub-layers: the environment layer and the pl
 
 ![RPMsg-Lite Architecture](./doxygen/images/rpmsg_lite_arch.png)
 
-### RPMsg-Lite core sub-component {#rpmsg_lite_core}
+### RPMsg-Lite core sub-component
 
 This subcomponent implements a blocking send API and callback-based receive API. The RPMsg protocol is part of the transport layer. This is realized by using so-called endpoints. Each endpoint can be assigned a different receive callback function. However, it is important to notice that the callback is executed in an interrupt environment in current design. Therefore, certain actions like memory allocation are discouraged to execute in the callback. The following figure shows the role of RPMsg in an ISO/OSI-like layered model:
 
 ![RPMsg ISO/OSI Layered Model](./doxygen/images/rpmsg_isoosi.png)
 
-### Queue sub-component (optional) {#rpmsg_queue}
+### Queue sub-component (optional)
 
 This subcomponent is optional and requires implementation of the env_*_queue() functions in the environment porting layer. It uses a blocking receive API, which is common in RTOS-environments. It supports both copy and nocopy blocking receive functions.
 
-### Name Service sub-component (optional) {#rpmsg_nameservice}
+### Name Service sub-component (optional)
 
 This subcomponent is a minimum implementation of the name service which is present in the Linux Kernel implementation of RPMsg. It allows the communicating node both to send announcements about "named" endpoint (in other words, channel) creation or deletion and to receive these announcement taking any user-defined action in an application callback. The endpoint address used to receive name service announcements is arbitrarily fixed to be 53 (0x35).
 
-## Usage {#usage}
+## Usage
 
 The application should put the /rpmsg_lite/lib/include directory to the include path and in the application, include either the rpmsg_lite.h header file, or optionally also include the rpmsg_queue.h and/or rpmsg_ns.h files. Both porting sublayers should be provided for you by NXP, but if you plan to use your own RTOS, all you need to do is to implement your own environment layer (in other words, rpmsg_env_myrtos.c) and to include it in the project build.
 
@@ -89,8 +90,8 @@ Another way of getting NXP MCUXpressoSDK RPMsg_Lite multicore examples is using
 mcuxsdk/examples/_<board_name>/multicore_examples 
 
 You can use the evkmimxrt1170 as the board_name for instance. Similar to MCUXpressoSDK packages the RPMsg_Lite examples use the 'rpmsg_lite_' name prefix.
-## Notes {#notes}
-### Environment layers implementation {#Environment_layers_implementation}
+## Notes
+### Environment layers implementation
 Several environment layers are provided in lib/rpmsg_lite/porting/environment folder. Not all of them are fully tested however. Here is the list of environment layers that passed testing:
 - rpmsg_env_bm.c
 - rpmsg_env_freertos.c
@@ -99,10 +100,10 @@ Several environment layers are provided in lib/rpmsg_lite/porting/environment fo
 
 The rest of environment layers has been created and used in some experimental projects, it has been running well at the time of creation but due to the lack of unit testing there is no guarantee it is still fully functional.
 
-### Shared memory configuration {#Shared_memory_configuration}
+### Shared memory configuration
 It is important to correctly initialize/configure the shared memory for data exchange in the application. The shared memory must be accessible from both the master and the remote core and it needs to be configured as Non-Cacheable memory. Dedicated shared memory section in liker file is also a good practise, it is recommended to use linker files from MCUXpressSDK packages for NXP devices based applications. It needs to be ensured no other application part/component is unintentionally accessing this part of memory. 
 
-## Configuration options {#configuration_options}
+## Configuration options
 
 The RPMsg-Lite can be configured at the compile time. The default configuration is defined in the rpmsg_default_config.h header file. This configuration can be customized by the user by including rpmsg_config.h file with custom settings. The following table summarizes all possible RPMsg-Lite configuration options.
 
@@ -122,14 +123,14 @@ The RPMsg-Lite can be configured at the compile time. The default configuration
 |RL_ALLOW_CUSTOM_SHMEM_CONFIG  | (0)           | It allows to define custom shared memory configuration and replacing the shared memory related global settings from rpmsg_config.h This is useful when multiple instances are running in parallel but different shared memory arrangement (vring size & alignment, buffers size & count) is required. The default value is 0 (all RPMsg_Lite instances use the same shared memory arrangement as defined by common config macros). |
 |RL_ASSERT                     | see rpmsg_default_config.h | Assert implementation.    |
 
-# Contributing to the rpmsg-lite project
+## Contributing to the rpmsg-lite project
 We welcome and encourage the community to submit patches directly to the rpmsg-lite project placed on github. Contributing can be managed via pull-requests. Before a pull-request is created the code should be tested and properly formatted.
 
-## How to format rpmsg-lite code
+### How to format rpmsg-lite code
 To format code, use the application developed by Google, named *clang-format*. This tool is part of the [llvm](http://llvm.org/) project. Currently, the clang-format 10.0.0 version is used for rpmsg-lite.
 The set of style settings used for clang-format is defined in the `.clang-format` file, placed in a root of the rpmsg-lite directory where Python script ``run_clang_format.py`` can be executed. 
 This script executes the application named *clang-format.exe*. You need to have the path of this application in the OS's environment path, or you need to change the script.
-## References {#references}
+## References
 [1] M. Novak, M. Cingel, Lockless Shared Memory Based Multicore Communication Protocol
 ---
 Copyright © 2016 Freescale Semiconductor, Inc.