Removal of unnecessary lines and correction of Index numbers of Listings and Examples (#74)

* Update ch02.md

Removing Lines after Listing

* Update ch03.md

removing unnecessary lines

* Update ch04.md

updates for removing extra lines

* Update ch04.md

formatting made consistent

* Update ch04.md

* Update ch04.md

* Update ch05.md

* Update ch06.md

* Update ch07.md

* Update ch08.md

* Update ch08.md

* Update ch08.md

* Update ch09.md

* Update ch10.md

* Update ch11.md

* Update ch12.md

* Update ch13.md

* Update ch04.md

* Update ch05.md

* Update ch06.md

* Update ch07.md

* Update ch08.md

* Update ch08.md

* Update ch09.md

* Update ch10.md

* Update toc.md

* Update toc.md

* Update ch04.md

corrected Figure Heading format

* Update ch04.md

Author: sirnish

ch02.md

@@ -122,7 +122,7 @@ FreeRTOS-Plus
 │
 └─Demo      Contains demo projects for other FreeRTOS and ecosystem libraries
 ```
-*Figure 2.1 Top level directories within the FreeRTOS distribution*
+***Figure 2.1*** *Top level directories within the FreeRTOS distribution*
 * * *
 
 The distribution only contains one copy of the FreeRTOS kernel source
@@ -188,7 +188,7 @@ FreeRTOS
     ├─stream_buffer.c FreeRTOS source file - optional
     └─croutine.c      FreeRTOS source file – optional and no longer maintained
 ```
-*Figure 2.2 Core FreeRTOS source files within the FreeRTOS directory tree*
+***Figure 2.2*** *Core FreeRTOS source files within the FreeRTOS directory tree*
 * * *
 
 It is recognized that the file names used in the zip file distribution
@@ -248,7 +248,7 @@ FreeRTOS
             ├─[architecture 2] Contains files for the compiler 2 architecture 2 port
             └─[etc.]
 ```
-*Figure 2.3 Port specific source files within the FreeRTOS directory tree*
+***Figure 2.3*** *Port specific source files within the FreeRTOS directory tree*
 * * *
 
 ### 2.2.8 Include Paths
@@ -374,7 +374,7 @@ FreeRTOS source files, but does not define any functionality.
 
 <a name="list2.1" title="Listing 2.1 The template for a new main() function"></a>
 
-* * *
+
 ```c
 int main( void )
 {
@@ -392,8 +392,8 @@ int main( void )
     return 0;
 }
 ```
-*Listing 2.1 The template for a new main() function*
-* * *
+***Listing 2.1*** *The template for a new main() function*
+
 
 
 ### 2.4.2 Creating a New Project from Scratch
@@ -442,7 +442,7 @@ procedure to create a new project:
 | All C and assembler files       | FreeRTOS/Source/portable/\[compiler\]/\[architecture\] |
 | heap\_n.c                       | FreeRTOS/Source/portable/MemMang, where n is either 1, 2, 3, 4 or 5 |
 
-*Table 1 FreeRTOS source files to include in the project*
+***Table 1*** *FreeRTOS source files to include in the project*
 * * *
 
 **Note on heap memory:**
@@ -498,7 +498,7 @@ typedef used and the actual type:
    | TICK\_TYPE\_WIDTH\_32_BITS | uint32\_t	| uint32\_t	| uint32\_t	| N/A |
    | TICK\_TYPE\_WIDTH\_64_BITS | N/A | N/A | uint64\_t | uint64\_t |
 
-   *Table 2. TickType_t data type and the configTICK_TYPE_WIDTH_IN_BITS configuration*
+   ***Table 2*** *TickType_t data type and the configTICK_TYPE_WIDTH_IN_BITS configuration*
    * * *
 
 - `BaseType_t`
@@ -562,7 +562,7 @@ list of prefixes.
 | config (for example, `configUSE_PREEMPTION`) | `FreeRTOSConfig.h`             |
 | err (for example, `errQUEUE_FULL`)           | `projdefs.h`                   |
 
-*Table 3 Macro prefixes*
+***Table 3*** *Macro prefixes*
 * * *
 
 Note that the semaphore API is written almost entirely as a set of
@@ -581,7 +581,7 @@ The macros defined in Table 4 are used throughout the FreeRTOS source code.
 | `pdPASS`     | 1     |
 | `pdFAIL`     | 0     |
 
-*Table 4 Common macro definitions*
+***Table 4*** *Common macro definitions*
 * * *
 
 

ch03.md

@@ -145,7 +145,7 @@ Referring to Figure 3.1:
 
 * * *
 ![](media/image05.png)   
-*Figure 3.1 RAM being allocated from the heap\_1 array each time a task is created*
+***Figure 3.1*** *RAM being allocated from the heap\_1 array each time a task is created*
 * * *
 
 
@@ -189,7 +189,7 @@ subsequently freed blocks are always the same size.
 
 * * *
 ![](media/image06.png)   
-*Figure 3.2 RAM being allocated and freed from the heap\_2 array as tasks are created and deleted*
+***Figure 3.2*** *RAM being allocated and freed from the heap\_2 array as tasks are created and deleted*
 * * *
 
 Figure 3.2 demonstrates how the best-fit algorithm works when a task is
@@ -276,7 +276,7 @@ RAM.
 
 * * *
 ![](media/image07.png)   
-*Figure 3.3 RAM being allocated and freed from the heap\_4 array*
+***Figure 3.3*** *RAM being allocated and freed from the heap\_4 array*
 * * * 
 
 Figure 3.3 demonstrates how the heap\_4 first-fit algorithm with memory
@@ -350,12 +350,12 @@ the call to `vPortDefineHeapRegions()`.
 
 <a name="list3.1" title="Listing 3.1 The vPortDefineHeapRegions() API function prototype"></a>
 
-* * *
+
 ```c
 void vPortDefineHeapRegions( const HeapRegion_t * const pxHeapRegions );
 ```
-*Listing 3.1 The vPortDefineHeapRegions() API function prototype*
-* * *
+***Listing 3.1*** *The vPortDefineHeapRegions() API function prototype*
+
 
 `vPortDefineHeapRegions()` takes an array of `HeapRegion_t` structures as
 its only parameter. Each structure defines the start address and size of
@@ -365,7 +365,7 @@ structures defines the entire heap space.
 
 <a name="list3.2" title="Listing 3.2 The HeapRegion\_t structure"></a>
 
-* * *
+
 ```c
 typedef struct HeapRegion
 {
@@ -377,8 +377,8 @@ typedef struct HeapRegion
 
 } HeapRegion_t;
 ```
-*Listing 3.2 The HeapRegion\_t structure*
-* * *
+***Listing 3.2*** *The HeapRegion\_t structure*
+
 
 **Parameters:**
 
@@ -407,7 +407,7 @@ which is not shown.
 
 * * *
 ![](media/image08.png)   
-*Figure 3.4 Memory Map*
+***Figure 3.4*** *Memory Map*
 * * *
 
 Listing 3.3 shows an array of `HeapRegion_t` structures that together
@@ -416,7 +416,7 @@ describe the three blocks of RAM in their entirety.
 
 <a name="list3.3" title="Listing 3.3 An array of HeapRegion\_t structures that together describe the 3 regions of RAM in their entirety"></a>
 
-* * *
+
 ```c
 /* Define the start address and size of the three RAM regions. */
 #define RAM1_START_ADDRESS ( ( uint8_t * ) 0x00010000 )
@@ -449,8 +449,8 @@ int main( void )
     /* Add application code here. */
 }
 ```
-*Listing 3.3 An array of HeapRegion\_t structures that together describe the 3 regions of RAM in their entirety*
-* * *
+***Listing 3.3*** *An array of HeapRegion\_t structures that together describe the 3 regions of RAM in their entirety*
+
 
 Although Listing 3.3 correctly describes the RAM, it does not demonstrate a
 usable example because it allocates all the RAM to the heap, leaving no
@@ -494,7 +494,6 @@ linker consumes all of RAM1, as shown in Figure 3.4 **C**.
 
 <a name="list3.4" title="Listing 3.4 An array of HeapRegion\_t structures that describe all of RAM2, all of RAM3, but only part of RAM1"></a>
 
-* * *
 ```c
 /* Define the start address and size of the two RAM regions not used by
    the linker. */
@@ -524,8 +523,8 @@ const HeapRegion_t xHeapRegions[] =
     { NULL,               0 }           /* Marks the end of the array. */
 };
 ```
-*Listing 3.4 An array of HeapRegion\_t structures that describe all of RAM2, all of RAM3, but only part of RAM1*
-* * *
+***Listing 3.4*** *An array of HeapRegion\_t structures that describe all of RAM2, all of RAM3, but only part of RAM1*
+
 
 The advantages of the technique demonstrated in Listing 3.4 include:
 
@@ -575,22 +574,22 @@ documentation. Examples for two compilers follow:
 
 <a name="list3.5" title="Listing 3.5 Using GCC syntax to declare the array that will be used by heap\_4, and place the array in a memory section named .my\_heap"></a>
 
-* * *
+
 ```c
 uint8_t ucHeap[ configTOTAL_HEAP_SIZE ] __attribute__ ( ( section( ".my_heap" ) ) );
 ```
-*Listing 3.5 Using GCC syntax to declare the array that will be used by heap\_4, and place the array in a memory section named .my\_heap*
-* * *
+***Listing 3.5*** *Using GCC syntax to declare the array that will be used by heap\_4, and place the array in a memory section named .my\_heap*
+
 
 
 <a name="list3.6" title="Listing 3.6 Using IAR syntax to declare the array that will be used by heap\_4, and place the array at the absolute address 0x20000000"></a>
 
-* * *
+
 ```c
 uint8_t ucHeap[ configTOTAL_HEAP_SIZE ] @ 0x20000000;
 ```
-*Listing 3.6 Using IAR syntax to declare the array that will be used by heap\_4, and place the array at the absolute address 0x20000000*
-* * *
+***Listing 3.6*** *Using IAR syntax to declare the array that will be used by heap\_4, and place the array at the absolute address 0x20000000*
+
 
 
 ### 3.3.2 The xPortGetFreeHeapSize() API Function
@@ -604,12 +603,12 @@ information on heap fragmentation.
 
 <a name="list3.7" title="Listing 3.7 The xPortGetFreeHeapSize() API function prototype"></a>
 
-* * *
+
 ```c
 size_t xPortGetFreeHeapSize( void );
 ```
-*Listing 3.7 The xPortGetFreeHeapSize() API function prototype*
-* * *
+***Listing 3.7*** *The xPortGetFreeHeapSize() API function prototype*
+
 
 **Return value:**
 
@@ -639,12 +638,12 @@ after executing the code that you know has the highest heap usage,
 
 <a name="list3.8" title="Listing 3.8 The xPortGetMinimumEverFreeHeapSize() API function prototype"></a>
 
-* * *
+
 ```c
 size_t xPortGetMinimumEverFreeHeapSize( void );
 ```
-*Listing 3.8 The xPortGetMinimumEverFreeHeapSize() API function prototype*
-* * *
+***Listing 3.8*** *The xPortGetMinimumEverFreeHeapSize() API function prototype*
+
 
 **Return value:**
 
@@ -663,17 +662,17 @@ shows the `HeapStats_t` structure members.
 
 <a name="list3.9" title="Listing 3.9 The vPortGetHeapStatus() API function prototype"></a>
 
-* * *
+
 ```c
 void vPortGetHeapStats( HeapStats_t *xHeapStats );
 ```
-*Listing 3.9 The vPortGetHeapStatus() API function prototype*
-* * *
+***Listing 3.9*** *The vPortGetHeapStatus() API function prototype*
+
 
 
 <a name="list3.10" title="Listing 3.10 The HeapStatus\_t() structure"></a>
 
-* * *
+
 ```c
 /* Prototype of the vPortGetHeapStats() function. */
 void vPortGetHeapStats( HeapStats_t *xHeapStats );
@@ -710,8 +709,8 @@ typedef struct xHeapStats
     size_t xNumberOfSuccessfulFrees;
 } HeapStats_t;
 ```
-*Listing 3.10 The HeapStatus\_t() structure*
-* * *
+***Listing 3.10*** *The HeapStatus\_t() structure*
+
 
 
 ### 3.3.5 Collecting Per-task Heap Usage Statistics
@@ -751,12 +750,12 @@ which should gracefully recover from allocation failures.
 
 <a name="list3.11" title="Listing 3.11 The malloc failed hook function name and prototype"></a>
 
-* * *
+
 ```c
 void vApplicationMallocFailedHook( void );
 ```
-*Listing 3.11 The malloc failed hook function name and prototype*
-* * *
+***Listing 3.11*** *The malloc failed hook function name and prototype*
+
 
 
 ### 3.3.7 Placing Task Stacks in Fast Memory
@@ -774,7 +773,7 @@ macros to call application-provided functions as shown in Listing 3.12.
 
 <a name="list3.12" title="Listing 3.12 Mapping the pvPortMallocStack() and vPortFreeStack() macros to an application defined memory allcator"></a>
 
-* * *
+
 ```c
 /* Functions provided by the application writer than allocate and free 
    memory from a fast area of RAM. */
@@ -790,8 +789,8 @@ void vPortFreeFastMemory( void *pvBlockToFree );
 
 #define vPortFreeStack( x ) vPortFreeFastMemory( x )
 ```
-*Listing 3.12 Mapping the pvPortMallocStack() and vPortFreeStack() macros to an application defined memory allcator*
-* * *
+***Listing 3.12*** *Mapping the pvPortMallocStack() and vPortFreeStack() macros to an application defined memory allcator*
+
 
 
 ## 3.4 Using Static Memory Allocation
@@ -850,7 +849,7 @@ also return the size of the timer task stack. A suggested implementation of the
 
 <a name="list3.13" title="Listing 3.13 Typical implementation of vApplicationGetTimerTaskMemory"></a>
 
-* * *
+
 ```c
 void vApplicationGetTimerTaskMemory( StaticTask_t **ppxTimerTaskTCBBuffer,
                                      StackType_t **ppxTimerTaskStackBuffer,
@@ -874,8 +873,8 @@ void vApplicationGetTimerTaskMemory( StaticTask_t **ppxTimerTaskTCBBuffer,
   *pulTimerTaskStackSize = sizeof(uxTimerTaskStack) / sizeof(*uxTimerTaskStack);
 }
 ```
-*Listing 3.13 Typical implementation of vApplicationGetTimerTaskMemory*
-* * *
+***Listing 3.13*** *Typical implementation of vApplicationGetTimerTaskMemory*
+
 
 Since there is only a single timer task in any system including SMP, a valid solution to the timer task memory problem 
 is to allocate static buffers in the `vApplicationGetTimeTaskMemory()` function and return the buffer pointers to the kernel.
@@ -894,7 +893,6 @@ variables to create the needed buffers.
 
 <a name="list3.14" title="Listing 3.14 Typical implementation of vApplicationGetIdleTaskMemory"></a>
 
-* * *
 ```c
 void vApplicationGetIdleTaskMemory( StaticTask_t **ppxIdleTaskTCBBuffer,
                                     StackType_t **ppxIdleTaskStackBuffer,
@@ -908,5 +906,5 @@ void vApplicationGetIdleTaskMemory( StaticTask_t **ppxIdleTaskTCBBuffer,
   *pulIdleTaskStackSize = configMINIMAL_STACK_SIZE;
 }
 ```
-*Listing 3.14 Typical implementation of vApplicationGetIdleTaskMemory*
-* * *
+***Listing 3.14*** *Typical implementation of vApplicationGetIdleTaskMemory*
+