=============================================================================
List of generated methods in project: ProcessorExpert

THIS TEXT DESCRIPTION IS GENERATED BY THE TOOL. DO NOT MODIFY IT.
=============================================================================

Module "GPIO1"     (component GPIO_LDD)
   - GPIO1_Init -This method initializes the associated peripheral(s) and the component internal variables. The method is 
                called automatically as a part of the application initialization code.
   - GPIO1_Deinit -This method disables the device and frees the device data structure memory.
   - GPIO1_GetPortValue -This method returns the current port input data value. Only configured pins (through all of bit fields 
                in this component) are returned.
   - GPIO1_ClearPortBits -This method drives the specified bits of the port to the inactive level. Only configured pins 
                (through all of bit fields in this component) are affected.
   - GPIO1_SetPortBits -This method drives the specified bits of the port to the active level. Only configured pins (through 
                all of bit fields in this component) are affected.
   - GPIO1_TogglePortBits -This method inverts the specified bits of the port to another level. Only configured pins (through 
                all of bit fields in this component) are affected.
   - GPIO1_SetFieldValue -This method sets the output data value of the specified bit field.
   - GPIO1_GetFieldValue -This method returns the current input data of the specified field.
   - GPIO1_ClearFieldBits -This method drives the specified bits of the specified bit field to the inactive level.
   - GPIO1_SetFieldBits -This method drives the specified bits of the specified bit field to the active level.
   - GPIO1_ToggleFieldBits -This method inverts the specified bits of the specified bit field to other level.
   - GPIO1_SetFieldInputDirection -This method sets all pins of the field to the input direction.
   - GPIO1_SetFieldOutputDirection -This method sets all pins of the field to the output direction.
   - GPIO1_ConnectPin -This method reconnects the requested pin associated with the selected peripheral in this component. This 
                method is only available for CPU derivatives and peripherals that support the runtime pin sharing with other 
                internal on-chip peripherals.

Module "GPIO2"     (component GPIO_LDD)
   - GPIO2_Init -This method initializes the associated peripheral(s) and the component internal variables. The method is 
                called automatically as a part of the application initialization code.
   - GPIO2_Deinit -This method disables the device and frees the device data structure memory.
   - GPIO2_GetPortValue -This method returns the current port input data value. Only configured pins (through all of bit fields 
                in this component) are returned.
   - GPIO2_ClearPortBits -This method drives the specified bits of the port to the inactive level. Only configured pins 
                (through all of bit fields in this component) are affected.
   - GPIO2_SetPortBits -This method drives the specified bits of the port to the active level. Only configured pins (through 
                all of bit fields in this component) are affected.
   - GPIO2_TogglePortBits -This method inverts the specified bits of the port to another level. Only configured pins (through 
                all of bit fields in this component) are affected.
   - GPIO2_SetFieldValue -This method sets the output data value of the specified bit field.
   - GPIO2_GetFieldValue -This method returns the current input data of the specified field.
   - GPIO2_ClearFieldBits -This method drives the specified bits of the specified bit field to the inactive level.
   - GPIO2_SetFieldBits -This method drives the specified bits of the specified bit field to the active level.
   - GPIO2_ToggleFieldBits -This method inverts the specified bits of the specified bit field to other level.
   - GPIO2_SetFieldInputDirection -This method sets all pins of the field to the input direction.
   - GPIO2_SetFieldOutputDirection -This method sets all pins of the field to the output direction.
   - GPIO2_ConnectPin -This method reconnects the requested pin associated with the selected peripheral in this component. This 
                method is only available for CPU derivatives and peripherals that support the runtime pin sharing with other 
                internal on-chip peripherals.

Module "LEDRed"    (component LED)
   - LEDRed_On -This turns the LED on.
   - LEDRed_Off -This turns the LED off.
   - LEDRed_Neg -This negates/toggles the LED
   - LEDRed_Get -This returns logical 1 in case the LED is on, 0 otherwise.
   - LEDRed_Put -Turns the LED on or off.
   - LEDRed_Init -Performs the LED driver initialization.
   - LEDRed_Deinit -Deinitializes the driver

Module "LEDGreen"  (component LED)
   - LEDGreen_On -This turns the LED on.
   - LEDGreen_Off -This turns the LED off.
   - LEDGreen_Neg -This negates/toggles the LED
   - LEDGreen_Get -This returns logical 1 in case the LED is on, 0 otherwise.
   - LEDGreen_Put -Turns the LED on or off.
   - LEDGreen_Init -Performs the LED driver initialization.
   - LEDGreen_Deinit -Deinitializes the driver

Module "LEDYellow" (component LED)
   - LEDYellow_On -This turns the LED on.
   - LEDYellow_Off -This turns the LED off.
   - LEDYellow_Neg -This negates/toggles the LED
   - LEDYellow_Get -This returns logical 1 in case the LED is on, 0 otherwise.
   - LEDYellow_Put -Turns the LED on or off.
   - LEDYellow_Init -Performs the LED driver initialization.
   - LEDYellow_Deinit -Deinitializes the driver

Module "TU1"       (component TimerUnit_LDD)
   - TU1_Init -Initializes the device. Allocates memory for the device data structure, allocates interrupt vectors and sets 
                interrupt priority, sets pin routing, sets timing, etc. If the property <"Enable in init. code"> is set to 
                "yes" value then the device is also enabled (see the description of the <Enable> method). In this case the 
                <Enable> method is not necessary and needn't to be generated. This method can be called only once. Before the 
                second call of Init the <Deinit> must be called first.
   - TU1_Deinit -Deinitializes the device. Switches off the device, frees the device data structure memory, interrupts vectors, 
                etc.

Module "SM1"       (component SPIMaster_LDD)
   - SM1_Init -Initializes the device. Allocates memory for the device data structure, allocates interrupt vectors and sets 
                interrupt priority, sets pin routing, sets timing, etc.   If the "Enable in init. code" is set to "yes" value 
                then the device is also enabled(see the description of the Enable() method). In this case the Enable() method 
                is not necessary and needn't to be generated.    This method can be called only once. Before the second call of 
                Init() the Deinit() must be called first.
   - SM1_Deinit -This method deinitializes the device. It switches off the device, frees the device data structure memory, 
                interrupts vectors, etc.
   - SM1_Enable -This method enables SPI device. This method is intended to be used together with <Disable()> method to 
                temporary switch On/Off the device after the device is initialized. This method is required if the <Enabled in 
                init. code> property is set to "no" value.
   - SM1_Disable -Disables the SPI device. When the device is disabled, some component methods should not be called. If so, 
                error ERR_DISABLED may be reported. This method is intended to be used together with <Enable()> method to 
                temporary switch on/off the device after the device is initialized. This method is not required. The <Deinit()> 
                method can be used to switch off and uninstall the device.
   - SM1_SendBlock -This method sends a block of characters. The method returns ERR_BUSY when the previous block transmission 
                is not completed. The method <CancelBlockTransmission> can be used to cancel a transmit operation.
   - SM1_ReceiveBlock -This method specifies the number of data to receive. The method returns ERR_BUSY until the specified 
                number of characters is received. The method <CancelBlockReception> can be used to cancel a running receive 
                operation.
   - SM1_GetSentDataNum -Returns the number of sent characters. This method is available only if method SendBlock is enabled.
   - SM1_GetReceivedDataNum -Returns the number of received characters in the receive buffer. This method is available only if 
                the ReceiveBlock method is enabled.
   - SM1_CancelBlockTransmission -Immediately cancels running transmit process. Unsent data will never been sent. This method 
                is available only if the SendBlock method is enabled.
   - SM1_CancelBlockReception -Immediately cancels the running receive process started by the ReceiveBlock method. Characters 
                already stored in the HW buffer will be lost. This method is available only if the ReceiveBlock method is 
                enabled.
   - SM1_GetError -This method returns a set of asserted flags. The flags are accumulated in the set. After calling this method 
                the set is returned and cleared. This method is enabled when SPI device support error detect.

Module "I2C1"      (component I2C_LDD)
   - I2C1_Init -Initializes the device. Allocates memory for the device data structure, allocates interrupt vectors and sets 
                interrupt priority, sets pin routing, sets timing, etc.   If the "Enable in init. code" is set to "yes" value 
                then the device is also enabled(see the description of the Enable() method). In this case the Enable() method 
                is not necessary and needn't to be generated.    This method can be called only once. Before the second call of 
                Init() the Deinit() must be called first.
   - I2C1_Deinit -Deinitializes the device. Switches off the device, frees the device data structure memory, interrupts vectors,
                etc.
   - I2C1_MasterSendBlock -This method writes one (7-bit addressing) or two (10-bit addressing) slave address bytes inclusive 
                of R/W bit = 0 to the I2C bus and then writes the block of characters to the bus. The slave address must be 
                specified before, by the "SelectSlaveDevice" method or in component initialization section, "Target slave 
                address init" property. If the method returns ERR_OK, it doesn't mean that transmission was successful. The 
                state of transmission is detectable by means of events (OnMasterSendComplete or OnError). Data to be sent are 
                not copied to an internal buffer and remains in the original location. Therefore the content of the buffer 
                should not be changed until the transmission is complete. Event "OnMasterBlockSent"can be used to detect the 
                end of the transmission. This method is available only for the MASTER or MASTER - SLAVE mode.
   - I2C1_MasterReceiveBlock -This method writes one (7-bit addressing) or two (10-bit addressing) slave address bytes 
                inclusive of R/W bit = 1 to the I2C bus and then receives the block of characters from the bus. The slave 
                address must be specified before, by the "SelectSlaveDevice" method or in component initialization section, 
                "Target slave address init" property. If the method returns ERR_OK, it doesn't mean that reception was 
                successful. The state of reception is detectable by means of events (OnMasterSendComplete  or OnError). Data to 
                be received are not copied to an internal buffer and remains in the original location. Therefore the content of 
                the buffer should not be changed until the transmission is complete. Event "OnMasterBlockReceived"can be used 
                to detect the end of the reception. This method is available only for the MASTER or MASTER - SLAVE mode.
   - I2C1_SelectSlaveDevice -This method selects a new slave for communication by its 7-bit slave, 10-bit address or general 
                call value. Any send or receive method directs to or from selected device, until a new slave device is selected 
                by this method. This method is available for the MASTER mode.
   - I2C1_GetError -Returns value of error mask, e.g. LDD_I2C_ARBIT_LOST.

Module "AS1"       (component Serial_LDD)
   - AS1_Init -Initializes the device. Allocates memory for the device data structure, allocates interrupt vectors and sets 
                interrupt priority, sets pin routing, sets timing, etc. If the "Enable in init. code" is set to "yes" value 
                then the device is also enabled(see the description of the Enable() method). In this case the Enable() method 
                is not necessary and needn't to be generated.
   - AS1_Deinit -Deinitializes the device. Switches off the device, frees the device data structure memory, interrupts vectors, 
                etc.
   - AS1_SendBlock -Sends a block of characters. The method returns ERR_BUSY when the previous block transmission is not 
                completed. Method <CancelBlockTransmission> can be used to cancel a transmit operation. This method is 
                available only if the transmitter property is enabled.
   - AS1_ReceiveBlock -Specifies the number of data to receive. The method returns ERR_BUSY until the specified number of 
                characters is received. Method <CancelBlockReception> can be used to cancel a running receive operation.
   - AS1_GetSentDataNum -Returns the number of sent characters.
   - AS1_GetReceivedDataNum -Returns the number of received characters in the receive buffer.
   - AS1_GetTxCompleteStatus -Returns whether the transmitter has transmitted all characters and there are no other characters 
                in the transmitter's HW FIFO or the shift register. This method is available only if a peripheral supports this 
                feature.

Module "GPIO3"     (component GPIO_LDD)
   - GPIO3_Init -This method initializes the associated peripheral(s) and the component internal variables. The method is 
                called automatically as a part of the application initialization code.
   - GPIO3_Deinit -This method disables the device and frees the device data structure memory.
   - GPIO3_SetFieldValue -This method sets the output data value of the specified bit field.
   - GPIO3_GetFieldValue -This method returns the current input data of the specified field.
   - GPIO3_ClearFieldBits -This method drives the specified bits of the specified bit field to the inactive level.
   - GPIO3_SetFieldBits -This method drives the specified bits of the specified bit field to the active level.
   - GPIO3_ToggleFieldBits -This method inverts the specified bits of the specified bit field to other level.
   - GPIO3_SetFieldInputDirection -This method sets all pins of the field to the input direction.
   - GPIO3_SetFieldOutputDirection -This method sets all pins of the field to the output direction.
   - GPIO3_ConnectPin -This method reconnects the requested pin associated with the selected peripheral in this component. This 
                method is only available for CPU derivatives and peripherals that support the runtime pin sharing with other 
                internal on-chip peripherals.

Module "FRTOS1"    (component FreeRTOS)
   - FRTOS1_xTaskCreate -Create a new task and add it to the list of tasks that are ready to run.
   - FRTOS1_vTaskStartScheduler -Starts the real time kernel tick processing. After calling the kernel has control over which 
                tasks are executed and when.   The idle task is created automatically when vTaskStartScheduler() is called.   
                If vTaskStartScheduler() is successful the function will not return until an executing task calls 
                vTaskEndScheduler(). The function might fail and return immediately if there is insufficient RAM available for 
                the idle task to be created.
   - FRTOS1_vTaskSuspend -Suspend any task. When suspended a task will never get any microcontroller processing time, no matter 
                what its priority. Calls to vTaskSuspend are not accumulative - i.e. calling vTaskSuspend() twice on the same 
                task still only requires one call to vTaskResume() to ready the suspended task.
   - FRTOS1_vTaskSuspendAll -Suspends all real time kernel activity while keeping interrupts (including the kernel tick) 
                enabled.   After calling vTaskSuspendAll () the calling task will continue to execute without risk of being 
                swapped out until a call to xTaskResumeAll () has been made.   API functions that have the potential to cause a 
                context switch (for example, vTaskDelayUntil(), xQueueSend(), etc.) must not be called while the scheduler is 
                suspended.
   - FRTOS1_vTaskResume -Resumes a suspended task. A task that has been suspended by one of more calls to vTaskSuspend() will 
                be made available for running again by a single call to vTaskResume().
   - FRTOS1_xTaskResumeAll -Resumes real time kernel activity following a call to vTaskSuspendAll (). After a call to 
                xTaskSuspendAll () the kernel will take control of which task is executing at any time.
   - FRTOS1_xTaskResumeFromISR -An implementation of vTaskResume() that can be called from within an ISR. A task that has been 
                suspended by one of more calls to vTaskSuspend() will be made available for running again by a single call to 
                xTaskResumeFromISR().
   - FRTOS1_taskYIELD -Macro for forcing a context switch.
   - FRTOS1_taskENTER_CRITICAL -Macro to mark the start of a critical code region. Preemptive context switches cannot occur 
                when in a critical region.      NOTE: This may alter the stack (depending on the portable implementation) so 
                must be used with care!
   - FRTOS1_taskEXIT_CRITICAL -Macro to mark the end of a critical code region. Preemptive context switches cannot occur when 
                in a critical region.      NOTE: This may alter the stack (depending on the portable implementation) so must be 
                used with care!
   - FRTOS1_taskDISABLE_INTERRUPTS -Macro to disable all maskable interrupts.
   - FRTOS1_taskENABLE_INTERRUPTS -Macro to enable microcontroller interrupts.
   - FRTOS1_vTaskDelay -Delay a task for a given number of ticks. The actual time that the task remains blocked depends on the 
                tick rate. The constant portTICK_RATE_MS can be used to calculate real time from the tick rate - with the 
                resolution of one tick period.      vTaskDelay() specifies a time at which the task wishes to unblock relative 
                to the time at which vTaskDelay() is called. For example, specifying a block period of 100 ticks will cause the 
                task to unblock 100 ticks after vTaskDelay() is called. vTaskDelay() does not therefore provide a good method 
                of controlling the frequency of a cyclical task as the path taken through the code, as well as other task and 
                interrupt activity, will effect the frequency at which vTaskDelay() gets called and therefore the time at which 
                the task next executes. See vTaskDelayUntil() for an alternative API function designed to facilitate fixed 
                frequency execution. It does this by specifying an absolute time (rather than a relative time) at which the 
                calling task should unblock.
   - FRTOS1_vTaskDelayUntil -Delay a task until a specified time. This function can be used by cyclical tasks to ensure a 
                constant execution frequency.      This function differs from vTaskDelay() in one important aspect: 
                vTaskDelay() specifies a time at which the task wishes to unblock relative to the time at which vTaskDelay() is 
                called, whereas vTaskDelayUntil() specifies an absolute time at which the task wishes to unblock.      
                vTaskDelay() will cause a task to block for the specified number of ticks from the time vTaskDelay() is called. 
                It is therefore difficult to use vTaskDelay() by itself to generate a fixed execution frequency as the time 
                between a task unblocking following a call to vTaskDelay() and that task next calling vTaskDelay() may not be 
                fixed [the task may take a different path though the code between calls, or may get interrupted or preempted a 
                different number of times each time it executes].      Whereas vTaskDelay() specifies a wake time relative to 
                the time at which the function is called, vTaskDelayUntil() specifies the absolute (exact) time at which it 
                wishes to unblock.      It should be noted that vTaskDelayUntil() will return immediately (without blocking) if 
                it is used to specify a wake time that is already in the past. Therefore a task using vTaskDelayUntil() to 
                execute periodically will have to re-calculate its required wake time if the periodic execution is halted for 
                any reason (for example, the task is temporarily placed into the Suspended state) causing the task to miss one 
                or more periodic executions. This can be detected by checking the variable passed by reference as the 
                pxPreviousWakeTime parameter against the current tick count. This is however not necessary under most usage 
                scenarios.      The constant portTICK_RATE_MS can be used to calculate real time from the tick rate - with the 
                resolution of one tick period.      This function must not be called while the scheduler has been suspended by 
                a call to vTaskSuspendAll().
   - FRTOS1_uxTaskPriorityGet -Obtain the priority of any task.
   - FRTOS1_vTaskPrioritySet -Set the priority of any task.
   - FRTOS1_xTaskGetTickCount -Return the count of ticks since vTaskStartScheduler was called.
   - FRTOS1_xSemaphoreCreateRecursiveMutex -Macro that implements a recursive mutex by using the existing queue mechanism.   
                Mutexes created using this macro can be accessed using the xSemaphoreTakeRecursive() and 
                xSemaphoreGiveRecursive() macros.  The  xSemaphoreTake() and xSemaphoreGive() macros should not be used.   A 
                mutex used recursively can be 'taken' repeatedly by the owner. The mutex doesn't become available again until 
                the owner has called xSemaphoreGiveRecursive() for each successful 'take' request.  For example, if a task 
                successfully 'takes' the same mutex 5 times then the mutex will not be available to any other task until it has 
                also  'given' the mutex back exactly five times.   This type of semaphore uses a priority inheritance mechanism 
                so a task 'taking' a semaphore MUST ALWAYS 'give' the semaphore back once the semaphore it is no longer 
                required. Mutex type semaphores cannot be used from within interrupt service routines.   See 
                vSemaphoreCreateBinary() for an alternative implementation that can be used for pure synchronisation (where one 
                task or interrupt always 'gives' the semaphore and another always 'takes' the semaphore) and from within 
                interrupt service routines.
   - FRTOS1_xSemaphoreTakeRecursive -Macro to recursively obtain, or 'take', a mutex type semaphore. The mutex must have 
                previously been created using a call to xSemaphoreCreateRecursiveMutex();   This macro must not be used on 
                mutexes created using xSemaphoreCreateMutex(). A mutex used recursively can be 'taken' repeatedly by the owner. 
                The mutex doesn't become available again until the owner has called xSemaphoreGiveRecursive() for each 
                successful 'take' request.  For example, if a task successfully 'takes' the same mutex 5 times then the mutex 
                will not be available to any other task until it has also  'given' the mutex back exactly five times.
   - FRTOS1_xSemaphoreGiveRecursive -Macro to recursively release, or 'give', a mutex type semaphore. The mutex must have 
                previously been created using a call to xSemaphoreCreateRecursiveMutex();   This macro must not be used on 
                mutexes created using xSemaphoreCreateMutex(). A mutex used recursively can be 'taken' repeatedly by the owner. 
                The mutex doesn't become available again until the owner has called xSemaphoreGiveRecursive() for each 
                successful 'take' request.  For example, if a task successfully 'takes' the same mutex 5 times then the mutex 
                will not be available to any other task until it has also  'given' the mutex back exactly five times.
   - FRTOS1_xSemaphoreCreateMutex -Macro that creates a mutex semaphore by using the existing queue mechanism.      Mutexes 
                created using this macro can be accessed using the xSemaphoreTake() and xSemaphoreGive() macros. The 
                xSemaphoreTakeRecursive() and xSemaphoreGiveRecursive() macros should not be used.      Mutexes and binary 
                semaphores are very similar but have some subtle differences: Mutexes include a priority inheritance mechanism, 
                binary semaphores do not. This makes binary semaphores the better choice for implementing synchronisation 
                (between tasks or between tasks and an interrupt), and mutexes the better choice for implementing simple mutual 
                exclusion.      The priority of a task that 'takes' a mutex can potentially be raised if another task of higher 
                priority attempts to obtain the same mutex. The task that owns the mutex 'inherits' the priority of the task 
                attempting to 'take' the same mutex. This means the mutex must always be 'given' back - otherwise the higher 
                priority task will never be able to obtain the mutex, and the lower priority task will never 'disinherit' the 
                priority. An example of a mutex being used to implement mutual exclusion is provided on the xSemaphoreTake() 
                documentation page.      A binary semaphore need not be given back once obtained, so task synchronisation can 
                be implemented by one task/interrupt continuously 'giving' the semaphore while another continuously 'takes' the 
                semaphore. This is demonstrated by the sample code on the xSemaphoreGiveFromISR() documentation page.      Both 
                mutex and binary semaphores are assigned to variables of type xSemaphoreHandle and can be used in any API 
                function that takes a parameter of this type.
   - FRTOS1_xSemaphoreTake -Macro to obtain a semaphore. The semaphore must have previously been created with a call to 
                vSemaphoreCreateBinary(), xSemaphoreCreateMutex() or xSemaphoreCreateCounting().      This macro must not be 
                called from an ISR. xQueueReceiveFromISR() can be used to take a semaphore from within an interrupt if required,
                although this would not be a normal operation. Semaphores use queues as their underlying mechanism, so 
                functions are to some extent interoperable.      xSemaphoreTake() is part of the fully featured intertask 
                communications API. xSemaphoreAltTake() is the alternative API equivalent. Both versions require the same 
                parameters and return the same values.
   - FRTOS1_xSemaphoreGive -Macro to release a semaphore. The semaphore must have previously been created with a call to 
                vSemaphoreCreateBinary(), xSemaphoreCreateMutex() or xSemaphoreCreateCounting(), and obtained using 
                sSemaphoreTake().      This must not be used from an ISR. See xSemaphoreGiveFromISR() for an alternative which 
                can be used from an ISR.      This macro must also not be used on semaphores created using 
                xSemaphoreCreateRecursiveMutex().      xSemaphoreGive() is part of the fully featured intertask communications 
                API. xSemaphoreAltGive() is the alternative API equivalent. Both versions require the same parameters and 
                return the same values.
   - FRTOS1_vSemaphoreCreateBinary -Macro that creates a semaphore by using the existing queue mechanism. The queue length is 1 
                as this is a binary semaphore. The data size is 0 as we don't want to actually store any data - we just want to 
                know if the queue is empty or full.      Binary semaphores and mutexes are very similar but have some subtle 
                differences: Mutexes include a priority inheritance mechanism, binary semaphores do not. This makes binary 
                semaphores the better choice for implementing synchronisation (between tasks or between tasks and an interrupt),
                and mutexes the better choice for implementing simple mutual exclusion.      A binary semaphore need not be 
                given back once obtained, so task synchronisation can be implemented by one task/interrupt continuously 
                'giving' the semaphore while another continuously 'takes' the semaphore. This is demonstrated by the sample 
                code on the xSemaphoreGiveFromISR() documentation page.      The priority of a task that 'takes' a mutex can 
                potentially be raised if another task of higher priority attempts to obtain the same mutex. The task that owns 
                the mutex 'inherits' the priority of the task attempting to 'take' the same mutex. This means the mutex must 
                always be 'given' back - otherwise the higher priority task will never be able to obtain the mutex, and the 
                lower priority task will never 'disinherit' the priority. An example of a mutex being used to implement mutual 
                exclusion is provided on the xSemaphoreTake() documentation page.      Both mutex and binary semaphores are 
                assigned to variables of type xSemaphoreHandle and can be used in any API function that takes a parameter of 
                this type.
   - FRTOS1_xSemaphoreCreateCounting -Macro that creates a counting semaphore by using the existing queue mechanism.      
                Counting semaphores are typically used for two things:      1. Counting events.   In this usage scenario an 
                event handler will 'give' a semaphore each time an event occurs (incrementing the semaphore count value), and a 
                handler task will 'take' a semaphore each time it processes an event (decrementing the semaphore count value). 
                The count value is therefore the difference between the number of events that have occurred and the number that 
                have been processed. In this case it is desirable for the initial count value to be zero.      2. Resource 
                management.   In this usage scenario the count value indicates the number of resources available. To obtain 
                control of a resource a task must first obtain a semaphore - decrementing the semaphore count value. When the 
                count value reaches zero there are no free resources. When a task finishes with the resource it 'gives' the 
                semaphore back - incrementing the semaphore count value. In this case it is desirable for the initial count 
                value to be equal to the maximum count value, indicating that all resources are free.
   - FRTOS1_xSemaphoreGiveFromISR -Macro to release a semaphore. The semaphore must have previously been created with a call to 
                vSemaphoreCreateBinary() or xSemaphoreCreateCounting().      Mutex type semaphores (those created using a call 
                to xSemaphoreCreateMutex()) must not be used with this macro.      This macro can be used from an ISR.
   - FRTOS1_xSemaphoreTakeFromISR -Macro to take a semaphore from an ISR. The semaphore must have previously been created with 
                a call to vSemaphoreCreateBinary() or xSemaphoreCreateCounting().      Mutex type semaphores (those created 
                using a call to xSemaphoreCreateMutex()) must not be used with this macro.      This macro can be used from an 
                ISR, however taking a semaphore from an ISR is not a common operation.  It is likely to only be useful when 
                taking a counting semaphore when an interrupt is obtaining an object from a resource pool (when the semaphore 
                count indicates the number of resources available).
   - FRTOS1_vSemaphoreDelete -Delete a semaphore.  This function must be used with care.  For example, do not delete a mutex 
                type semaphore if the mutex is held by a task.
   - FRTOS1_xSemaphoreGetMutexHolder -Returns the hlder of a mutex or semaphore. If xMutex is indeed a mutex type semaphore, 
                return the current mutex holder. If xMutex is not a mutex type semaphore, or the mutex is available (not held 
                by a task), return NULL. Note: This Is is a good way of determining if the calling task is the mutex holder, 
                but not a good way of determining the identity of the mutex holder as the holder may change between the 
                function exiting and the returned value being tested.
   - FRTOS1_vTaskList -configUSE_TRACE_FACILITY, INCLUDE_vTaskDelete and INCLUDE_vTaskSuspend must all be defined as 1 for this 
                function to be available. See the configuration section for more information.   NOTE: This function will 
                disable interrupts for its duration.  It is not intended for normal application runtime use but as a debug aid. 
                Lists all the current tasks, along with their current state and stack usage high water mark.   Tasks are 
                reported as blocked ('B'), ready ('R'), deleted ('D') or suspended ('S').
   - FRTOS1_pvPortMalloc -Allocates a memory block using the port pvPortMalloc() function
   - FRTOS1_vPortFree -Frees a memory block previously allocated with pvPortMalloc()
   - FRTOS1_xTaskGetSchedulerState -Returns the state of the scheduler
   - FRTOS1_uxTaskGetStackHighWaterMark -The stack used by a task will grow and shrink as the task executes and interrupts are 
                processed. uxTaskGetStackHighWaterMark() returns the minimum amount of remaining stack space that was available 
                to the task since the task started executing - that is the amount of stack that remained unused when the task 
                stack was at its greatest (deepest) value. This is what is referred to as the stack 'high water mark'.
   - FRTOS1_uxTaskGetNumberOfTasks -Returns the number of tasks
   - FRTOS1_xPortGetFreeHeapSize -Returns the actual free size of the heap
   - FRTOS1_xQueueCreate -Creates a queue.
   - FRTOS1_vQueueDelete -Deletes a queue that was previously created using a call to xQueueCreate(). vQueueDelete() can also 
                be used to delete a semaphore.
   - FRTOS1_xQueueSendToFront -Sends an item to the front of a queue.
   - FRTOS1_xQueueSendToFrontFromISR -Versions of xQueueSendToFront() API functions that can be called from an ISR. Unlike 
                xQueueSendToFront() these functions do not permit a block time to be specified.
   - FRTOS1_xQueueSendToBack -Sends an item to the back of a queue.
   - FRTOS1_xQueueSendToBackFromISR -Versions of xQueueSendToBack() API functions that can be called from an ISR. Unlike 
                xQueueSendToBack() these functions do not permit a block time to be specified.
   - FRTOS1_xQueueReceive -Receives an item from a queue.
   - FRTOS1_xQueueReceivefromISR -A version of xQueueReceive() that can be called from an ISR. Unlike xQueueReceive(), 
                xQueueReceiveFromISR() does not permit a block time to be specified.
   - FRTOS1_xQueuePeek -Reads an item from a queue, but does not remove the item from the queue. Therefore the same item would 
                be returned the next time xQueueReceive() or xQueuePeek() was called on the same queue.
   - FRTOS1_uxQueueMessagesWaiting -Queries the number of items that are currently held within a queue.
   - FRTOS1_uxQueueMessagesWaitingfromISR -A version of uxQueueMessagesWaiting() that can be used from inside an interrupt 
                service routine.
   - FRTOS1_xQueueReset -Reset a queue back to its original empty state.  pdPASS is returned if the queue is successfully reset.
                pdFAIL is returned if the queue could not be reset because there are tasks blocked on the queue waiting to 
                either receive from the queue or send to the queue.

Module "UTIL1"     (component Utility)
   - UTIL1_strcpy -Same as normal strcpy, but safe as it does not write beyond the buffer.
   - UTIL1_strcat -Same as normal strcat, but safe as it does not write beyond the buffer.
   - UTIL1_chcat -Adds a single character to a zero byte terminated buffer. It cares about buffer overflow.
   - UTIL1_Num8sToStr -Converts a signed 8bit value into a string.
   - UTIL1_Num8uToStr -Converts an unsigned 8bit value into a string.
   - UTIL1_Num16sToStr -Converts a signed 16bit value into a string.
   - UTIL1_Num16uToStr -Converts a signed 16bit value into a string.
   - UTIL1_Num32uToStr -Converts an unsigned 32bit value into a string.
   - UTIL1_Num32sToStr -Converts a signed 32bit value into a string.
   - UTIL1_Num16sToStrFormatted -Converts a 16bit signed value to string.
   - UTIL1_Num16uToStrFormatted -Converts a 16bit unsigned value to string.
   - UTIL1_Num32uToStrFormatted -Converts a 32bit unsigned value to string.
   - UTIL1_Num32sToStrFormatted -Converts a 32bit signed value to string.
   - UTIL1_strcatNum8u -Appends a 8bit unsigned value to a string buffer.
   - UTIL1_strcatNum8s -Appends a 8bit signed value to a string buffer.
   - UTIL1_strcatNum16u -Appends a 16bit unsigned value to a string buffer.
   - UTIL1_strcatNum16s -Appends a 16bit signed value to a string buffer.
   - UTIL1_strcatNum32u -Appends a 32bit signed value to a string buffer.
   - UTIL1_strcatNum32s -Appends a 32bit signed value to a string buffer.
   - UTIL1_strcatNum16uFormatted -Appends a 16bit unsigned value to a string buffer in a formatted way.
   - UTIL1_strcatNum16sFormatted -Appends a 16bit signed value to a string buffer in a formatted way.
   - UTIL1_strcatNum32uFormatted -Appends a 32bit unsigned value to a string buffer in a formatted way.
   - UTIL1_strcatNum32sFormatted -Appends a 32bit signed value to a string buffer in a formatted way.
   - UTIL1_strcatNum8Hex -Appends a 8bit unsigned value to a buffer as hex number (without a 0x prefix).
   - UTIL1_strcatNum16Hex -Appends a 16bit unsigned value to a buffer as hex number (without a 0x prefix).
   - UTIL1_strcatNum24Hex -Appends a 32bit unsigned value to a buffer as hex number (without a 0x prefix). Only 24bits are used.
   - UTIL1_strcatNum32Hex -Appends a 16bit unsigned value to a buffer as hex number (without a 0x prefix).
   - UTIL1_IsLeapYear -Returns true if a given year is a leap year
   - UTIL1_WeekDay -Returns the weekday for a given date >= 1.Jan.1900
   - UTIL1_ReadEscapedName -Scans an escaped name from a string. This is useful e.g. for double quoted file names.
   - UTIL1_xatoi -Custom atoi() (ascii to int) implementation by Elm Chan
   - UTIL1_ScanDate -Scans a date in the format "dd.mm.yyyy" or "dd-mm-yyyy". For yy it will expand it to 20yy.
   - UTIL1_ScanTime -Scans a time string in the format "hh:mm:ss,hh" with the part for the ",hh" is optional.
   - UTIL1_ScanDecimal32uNumber -Scans a decimal 32bit unsigned number
   - UTIL1_ScanDecimal16uNumber -Scans a decimal 16bit unsigned number
   - UTIL1_ScanDecimal8uNumber -Scans a decimal 16bit unsigned number
   - UTIL1_strcmp -Wrapper to the standard strcmp() routine
   - UTIL1_strncmp -Wrapper to the standard strncmp() routine
   - UTIL1_strlen -Wrapper to the standard strlen() function.

Module "TU2"       (component TimerUnit_LDD)
   - TU2_Init -Initializes the device. Allocates memory for the device data structure, allocates interrupt vectors and sets 
                interrupt priority, sets pin routing, sets timing, etc. If the property <"Enable in init. code"> is set to 
                "yes" value then the device is also enabled (see the description of the <Enable> method). In this case the 
                <Enable> method is not necessary and needn't to be generated. This method can be called only once. Before the 
                second call of Init the <Deinit> must be called first.
   - TU2_Deinit -Deinitializes the device. Switches off the device, frees the device data structure memory, interrupts vectors, 
                etc.

Module "Cpu"       (component MK10DX128FM5)

===================================================================================
