If the demonstration system does not execute properly, the following are some troubleshooting tips. It is always a good idea to first get the demonstration system running-either on actual target hardware or simulated environment. TroubleshootingĮach ThreadX port is delivered with a demonstration application. Template for Application DevelopmentĪlthough this is a simple example, it provides a good template for real application development. Tx_thread_create(&my_thread, "My Thread", Void tx_application_define(void *first_unused_memory)
The thread executes, increments a counter, then sleeps for one clock tick. The small example system in Figure 1 shows the creation of a single thread with a priority of 3. The resulting image can be downloaded to the target and executed! Examples of system resources include threads, queues, memory pools, event flags groups, mutexes, and semaphores.Ĭompile application source and link with the ThreadX run-time library tx.lib. This is where the initial system resources are created. So be sure not to place any processing or function calls after it.Ĭreate the tx_application_define function. The ThreadX entry function tx_kernel_enter does not return. FilenameĬ header file containing all system equates, data structures, and service prototypes.Ĭ header file containing all development-tool and targetspecific data definitions and structures.Ĭ file containing a small demo application.īinary version of the ThreadX C library that is distributed with the standard package. The following is a list of several important files in the repository.
Product DistributionĪzure RTOS ThreadX can be obtained from our public source code repository at. The exception vector table and interrupt priorities may also be configured in _tx_initialize_low_level. chapter3.md#application-definition-function). This address is later passed into tx_application_define (see. In function _tx_initialize_low_level, the first-available RAM address is saved in global variable _tx_initialize_unused_memory. However, none of the timer-related services are functional. ThreadX is still functional even if no periodic timer interrupt source is available. Setup and configuration of the timer interrupt is typically located in the tx_initialize_low_level assembly file in the ThreadX Otherwise, if the target processor does not have the ability to generate a periodic interrupt, the user's hardware must provide it. If the processor has this capability, it is utilized by ThreadX. It also requires another 1 to 2 KBytes of the target's Random Access Memory (RAM) for the ThreadX system stack and other global data structures.įor timer-related functions like service call time-outs, time-slicing, and application timers to function, the underlying target hardware must provide a periodic interrupt source. ThreadX requires between 2 KBytes and 20 KBytes of Read Only Memory (ROM) on the target. Both OCD and ICE connections provide robust solutions with minimal intrusion on the target residentĪs for resources used on the host, the source code for ThreadX is delivered in ASCII format and requires approximately 1 MByte of space on the host computer's hard disk. Debuggers also communicate with target hardware through In-Circuit Emulation (ICE) connections. Most development tool debuggers communicate with the target hardware via on-chip debug (OCD) connections such as JTAG (IEEE 1149.1) and Background Debug Mode (BDM).
After the download has completed, the debugger is responsible for providing target execution control (go, halt, breakpoint, etc.) as well as access to memory and processor registers. Usually the target download is done from within the development tool debugger. After the application is compiled, linked, and located on the host, it is downloaded to the target hardware for execution.
Host ConsiderationsĮmbedded software is usually developed on Windows or Linux (Unix) host computers.
This chapter contains a description of various issues related to installation, setup, and usage of the high-performance Azure RTOS ThreadX kernel.