Threadx操作系统源代码（1.02M）

Express Logic's ThreadX for 68332 Using the Green Hills Tools 1. Installation ThreadX for the 68332 is delivered on a single CD-ROM compatible disk. The entire distribution can be found in the sub-directory: \THREADX To install ThreadX to your hard-disk, make a THREADX\68332\GREEN directory on your hard-disk and copy all the contents of the THREADX sub-directory on the distribution disk. The following is an example MS-DOS copy command (assuming source is D: and C: is your hard-drive): D:\THREADX>XCOPY /S *.* C:\THREADX\68332\GREEN 2. Building the ThreadX run-time Library First make sure you are in the ThreadX directory you have created on your hard-drive. Also, make sure that you have setup your path and other environment variables necessary for the Green Hills development environment. At this point you may run the BUILD_TX.BAT batch file. This will build the ThreadX run-time environment in the THREADX directory. C:\THREADX\68332\GREEN> build_tx You should observe assembly and compilation of a series of ThreadX source files. At the end of the batch file, they are all combined into the run-time library file: TX.OLB. This file must be linked with your application in order to use ThreadX. 3. Demonstration System The ThreadX demonstration is designed to execute on the 68332 QUADS evaluation board and under the MULTI environment using MULTI's 68000 simulator. The instructions that follow will show you how to get the ThreadX demonstration running in these environments. Building the demonstration is easy, simply load the MULTI project file DEMO.BLD, which is located inside your ThreadX directory: C:\THREADX\68332\GREEN\DEMO.BLD You should observe the following files in the project view area: DEMO.BLD TX_ILL.68 DEMO.C DEMO.LNK README.TXT At this point, select the "Project Build" operation and observe the compilation, assembly, and linkage of the ThreadX application. After the demonstration is built, you are now ready for debugging! To run on under MULTI's 68000 simulator, select the "Remote" button from the MULTI builder (you should see "s68 68020" in the remote window). This invokes MULTI's 68020 simulator and you should observe several new windows for it. Next, select the "Debug" button from the MULTI builder. You should now observe the demonstration program in the debugger window. At this point, you are free to debug with breakpoints, data watches, etc. The demonstration system attempts to setup a 68332 periodic timer. Since the 68020 simulator does not simulate the 68332 peripherals, the timer interrupts will not work under simulation until the following commands are entered in the simulation control window: > interrupt dev1 vector 16 > interrupt dev1 priority 2 > interrupt dev1 time 10000 every 10000 > trap 16 To run on the 68332 Evaluation board, simply convert the demo output image to S-records and download it to the evaluation board. The following command can be used to do the conversion: > gsrec demo.cfe -o demo.mot 3.1 EventAnalyzer Demonstration To build a demonstration system that will also log events for the MULTI EventAnalyzer, perform the same steps as the regular demo, except build the ThreadX library with BUILD_TXE.BAT file and use the DEMO_EL.BLD build file to build the demonstration that logs all system events. 4. System Initialization The system entry point using Green Hills tools is at the label _start. This is defined within the CRT0.O file supplied by Green Hills. In addition, this is where all static and global pre-set C variable initialization processing is called from. After the Green Hills startup function returns, ThreadX initialization is is called. The 68332 specific initialization is done in the function _tx_initialize_low_level, which is located in the file TX_ILL.68. This function is responsible for setting up various system data structures, interrupt vectors, and a periodic timer interrupt source for ThreadX. In addition, _tx_initialize_low_level defines the system timer thread�s stack and determines the first available address for use by the application. By default free memory is assumed to start at the linker defined symbol __ghsbegin_freemem. The ThreadX system timer's stack is allocated here and the memory address after the timer thread's stack is passed to the application definition function, tx_application_define. 5. Assembler / Compiler / Linker Switches The following are Green Hills switches used in building the demonstration system: Compiler/Assembler Meaning Switches -G Specifies debug information -c Specifies object code output -68332 Specifies 68332 code generation There are additional linker commands inside of the file DEMO.LNK. Please use this file as a template for your application. 5.1 User defines The following defines and their associated action are as follows: Define Meaning TX_DISABLE_ERROR_CHECKING If defined before tx_api.h is included, this define causes basic ThreadX error checking to be disabled. Please see Chapter 4 in the "ThreadX User Guide" for more details. TX_DISABLE_STACK_CHECKING By default, the thread create function fills the thread's stack with a 0xEF data pattern, which is used by the MULTI debugger to calculate stack usage. This can be bypassed by compiling tx_tc.c with this define. TX_ENABLE_EVENT_LOGGING This define enables event logging for any or all of the ThreadX source code. If this option is used anywhere, the tx_ihl.c file must be compiled with it as well, since this is where the event log is initialized. TX_NO_EVENT_INFO This is a sub-option for event logging. If this is enabled, only basic information is saved in the log. TX_ENABLE_EVENT_FILTERS This is also a sub-option for event-logging. If this is enabled, run-time filtering logic is added to the event logging code. 6. Register Usage and Stack Frames The Green Hills 68K compiler assumes that registers d0-d1, and a0-a1 are scratch registers for each function. All other registers used by a C function must be preserved by the function. ThreadX takes advantage of this in situations where a context switch happens as a result of making a ThreadX service call (which is itself a C function). In such cases, the saved context of a thread is only the non-scratch registers. The following defines the saved context stack frames for context switches that occur as a result of interrupt handling or from thread-level API calls. All suspended threads have one of these two types of stack frames. The top of the suspended thread's stack is pointed to by tx_stack_ptr in the associated thread control block TX_THREAD. Offset Interrupted Stack Frame Non-Interrupt Stack Frame 0x00 1 0 0x02 d0 d2 0x06 d1 d3 0x0A d2