Add more docs

docs/api-reference/esp/input.rst

@@ -3,4 +3,41 @@
 Input module
 ============
 
+Input module is used to input received data from *ESP* device to *ESP-AT-Lib* middleware part.
+``2`` processing options are possible:
+
+* Indirect processing with :cpp:func:`esp_input` (default mode)
+* Direct processing with :cpp:func:`esp_input_process`
+
+.. tip::
+    Direct or indirect processing mode is select by setting :c:macro:`ESP_CFG_INPUT_USE_PROCESS` configuration value.
+
+Indirect processing
+^^^^^^^^^^^^^^^^^^^
+
+With indirect processing mode, every received character from *ESP* physical device is written to
+intermediate buffer between low-level driver and *processing* thread.
+
+Function :cpp:func:`esp_input` is used to write data to buffer, which is later processed
+by *processing* thread. 
+
+Indirect processing mode allows embedded systems to write received data to buffer from interrupt context (outside threads).
+As a drawback, its performance is decreased as it involves copying every receive character to intermediate buffer, 
+and may also introduce RAM memory footprint increase.
+
+Direct processing
+^^^^^^^^^^^^^^^^^
+
+Direct processing is targeting more advanced host controllers, like STM32 or WIN32 implementation use.
+It is developed with DMA support in mind, allowing low-level drivers to skip intermediate data buffer
+and process input bytes directly.
+
+.. note::
+	When using this mode, function :cpp:func:`esp_input_process` must be used and it may
+	only be called from thread context. Processing of input bytes is done in low-level
+	input thread, started by application.
+
+.. tip::
+	Check :ref:`um_porting_guide` for implementation examples.
+
 .. doxygengroup:: ESP_INPUT

docs/api-reference/port/ll.rst

@@ -3,4 +3,10 @@
 Low-Level functions
 ===================
 
+Low-level module consists of callback-only functions, which are called by middleware
+and must be implemented by final application.
+
+.. tip::
+	Check :ref:`um_porting_guide` for actual implementation
+
 .. doxygengroup:: ESP_LL

docs/api-reference/port/sys.rst

@@ -3,4 +3,18 @@
 System functions
 ================
 
+System functions are bridge between operating system system calls and middleware system calls.
+Middleware is tightly coupled with operating system features hence it is important to include OS features directly.
+
+It includes support for:
+
+* Thread management, to start/stop threads
+* Mutex management
+* Semaphore management, works only with binary semaphores
+* Message queues for thread-safe data exchange between threads
+* Core system protection for mutual exclusion to access shared resources
+
+.. tip::
+	Check :ref:`um_porting_guide` for actual implementation
+
 .. doxygengroup:: ESP_SYS

docs/user-manual/blocking-nonblocking.rst

@@ -23,7 +23,7 @@ When API function returns, application has valid response data and can react imm
 Example code:
 
 .. literalinclude:: ../examples_src/command_blocking.c
-	:language: c
+    :language: c
     :caption: Blocking command example
 
 Non-blocking mode
@@ -39,7 +39,7 @@ Response has to be processed in event callback function.
 Example code:
 
 .. literalinclude:: ../examples_src/command_nonblocking.c
-	:language: c
+    :language: c
     :caption: Non-blocking command example
 
 .. warning::
@@ -49,7 +49,7 @@ Example code:
 Example of a bad code:
 
 .. literalinclude:: ../examples_src/command_nonblocking_bad.c
-	:language: c
+    :language: c
     :caption: Example of bad usage of non-blocking command
 
 .. toctree::