JP2009252194A - Data processor, hardware access method, and hardware access program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To control each hardware from an application that operates in a user mode without depending upon a combination of hardware and an operating system (OS). <P>SOLUTION: The data processor includes: a hardware abstract layer which executes OS having a kernel mode and a user mode and has a plurality of hardware processing parts, an interface operating in the kernel mode and corresponding to each of the plurality of hardware processing parts, and a common interface to a device driver corresponding to each of the plurality of hardware processing parts; and a hardware abstract layer control part for controlling the hardware abstract layer. The hardware abstract layer control part receives a control request for one of the plurality of hardware processing parts from a program that operates in a user mode, and performs control about a hardware processing part specified by a control request by using the common interface in the hardware abstract layer. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a data processing device, a hardware access method, and a hardware access program, and in particular, data for controlling each hardware from an application operating in a user mode without depending on a combination of hardware and an OS (Operating System). The present invention relates to a processing device, a hardware access method, and a hardware access program.

  In recent years, in the field of embedded systems, the integration of devices has progressed. Accordingly, combinations of devices and peripheral devices (hereinafter referred to as devices) and OSs are diversified.

  Further, there is a device driver as software that mediates between the device and the OS and bridges that the OS controls the device. In an embedded system, it is necessary to burn a device driver in a ROM (Read Only Memory) in advance, like an OS or the like. In addition, in order to introduce a new device into an embedded system, it is necessary to develop an application and a device driver corresponding to the device. At that time, it is necessary to adjust the parameter value for controlling the device and to correct the consistency between the application and the device driver each time.

However, it is easy to modify and reinstall a normal application, but the procedure for reinstalling a device driver that has a strong connection with the OS is complicated. In addition, since a normal application operates in a user mode in which the operation of a CPU (Central Processing Unit) is limited, it is not possible to directly operate a device driver that operates in a kernel mode in which the operation of the CPU is not limited. Therefore, it is difficult to correct the application and device driver for consistency. Therefore, Patent Document 1 discloses a technique of embedding a device driver in a DLL (Dynamic Link Library) that interfaces with an application in a user mode.
JP 2001-2222412 A

  However, in Patent Document 1, it is necessary to create a DLL for each hardware (device). Therefore, there is a problem that the efficiency of development and testing is low. This is because the device driver has processing depending on the hardware, so that it is affected by the change in the hardware specifications and the device driver needs to be corrected each time. Furthermore, the device driver correction in the embedded system requires a re-writing operation of the ROM, so that the test work efficiency is lowered.

  A data processing apparatus according to the present invention executes an operating system having a kernel mode and a user mode, and operates in a plurality of hardware processing units, the kernel mode, and each of the plurality of hardware processing units. A hardware abstraction layer having a common interface to a device driver corresponding to each of the plurality of hardware processing units, and a hardware abstraction layer control for controlling the hardware abstraction layer A part. The hardware abstraction layer control unit accepts a control request for any of the plurality of hardware processing units from a program operating in the user mode, and uses the common interface in the hardware abstraction layer. Then, control related to the hardware processing unit specified by the control request is performed.

  Accordingly, it is possible to provide a mechanism for controlling each hardware from an application operating in the user mode by the hardware abstraction layer control unit without depending on the combination of hardware and OS. Therefore, it is possible to improve the work efficiency of development, debugging and evaluation of embedded systems.

  A hardware access method according to the present invention includes an operating system having a kernel mode and a user mode, an interface that operates in the kernel mode and corresponds to each of a plurality of hardware processing units, and the plurality of hardware processing units And a hardware abstraction layer having a common interface with the corresponding device driver, the access processing to the plurality of hardware processing units is executed. A control request receiving step for receiving a control request for any of the plurality of hardware processing units from a program operating in the user mode, and the control request to the hardware abstraction layer via the common interface And a hardware abstraction layer calling step for executing control related to the hardware processing unit specified by.

  As a result, it is possible to provide a method of collectively receiving control requests and calling a hardware abstraction layer operating in the kernel mode.

  A hardware access program according to the present invention includes an operating system having a kernel mode and a user mode, an interface that operates in the kernel mode and corresponds to each of a plurality of hardware processing units, and the plurality of hardware processing units And a hardware abstraction layer having a common interface with the corresponding device driver, the access processing to the plurality of hardware processing units is executed. Control request accepting means for accepting a control request for any of the plurality of hardware processing units from a program operating in the user mode, and the control request via the common interface to the hardware abstraction layer Hardware abstraction layer calling means for executing control related to the hardware processing unit specified by.

  Accordingly, it is possible to provide a program that calls a hardware abstraction layer that operates in the kernel mode in response to a control request from a program that operates in the user mode.

  According to the present invention, it is possible to provide a data processing device, a hardware access method, and a hardware access program for controlling each hardware from an application operating in a user mode without depending on the combination of hardware and OS.

Hereinafter, specific embodiments to which the present invention is applied will be described in detail with reference to the drawings. In the drawings, the same elements are denoted by the same reference numerals, and redundant description will be omitted as necessary for the sake of clarity.
Embodiment 1 of the Invention

  In the first embodiment of the present invention, the task of evaluating hardware and device setting parameters in an embedded system is targeted.

  FIG. 1 is a block diagram showing an example of a device configuration diagram of an evaluation work performed by the hardware setting parameter evaluation system 100 according to the first exemplary embodiment of the present invention. The hardware setting parameter evaluation system 100 executes an evaluation program in which the setting parameters of the hardware 2 are defined on the evaluation board 1 and operates the hardware 2 connected to the evaluation board 1 to evaluate the setting parameters. Is to do. The hardware setting parameter evaluation system 100 includes an evaluation board 1, hardware 2, a terminal 3, and a debugger device 4.

  The hardware 2 is various hardware devices used in the embedded system, such as a display and a USB (Universal Serial Bus) hard disk device.

  The evaluation board 1 is a base on which various hardware components constituting an embedded system are arranged. Specifically, the evaluation board 1 is connected to the hardware 2, the terminal 3, and the debugger device 4 to operate the hardware 2. Software such as an OS is installed. The evaluation board 1 includes a CPU 11, a device 12, a terminal 13, a memory 14, a ROM (OS) 15, a ROM (HAL) 16, a terminal 17, and an inspection terminal 18.

  The CPU 11 is a control device that executes software stored in the memory 14, the ROM (OS) 15, and the ROM (HAL) 16. Specifically, the CPU 11 accesses the device 12 and operates the hardware 2 via the terminal 13.

  The device 12 is a controller that accepts a command from the CPU 11 and operates the hardware 2 via the terminal 13. A device 12 exists for each hardware 2. The terminal 13 is connected to the hardware 2 and is a terminal for performing communication between the device 12 and the hardware 2. For example, when the hardware 2 is a display device, the terminal 13 may be a D3 terminal.

  The memory 14 is a RAM (Random Access Memory) that is a volatile storage device, and may be a DRAM (Dynamic Random Access Memory), for example. The memory 14 stores a ROM (OS) 15, a ROM (HAL) 16, or an evaluation program installed from the outside.

  The ROM (OS) 15 is a read-only storage device, has a kernel mode and a user mode, and stores a general-purpose operating system (OS) used for a plurality of embedded systems. The ROM (OS) 15 is pre-baked with the OS. The general-purpose OS is, for example, Windows (registered trademark) CE or Linux (registered trademark).

  The ROM (HAL) 16 is a read-only storage device that shares access to the HAL (Hardware Abstraction Layer), which is a software module that conceals the operation of various hardware including the hardware 2, and from the application. HAL drivers to be received are stored. The ROM (HAL) 16 stores the HAL and the HAL driver in advance. The HAL will be described later with reference to FIG. The HAL and the HAL driver will be described later with reference to FIG.

  The terminal 17 is connected to the terminal 3 and is a serial terminal used for the RS-232C communication standard, for example. The inspection terminal 18 is a terminal that is connected to the debugger device 4, detects the states of the CPU 11 and the memory 14, and register values, and outputs them to the debugger device 4. The inspection terminal 18 is, for example, a terminal used for JTAG (Joint Test Action Group) standards.

  The terminal 3 is a general-purpose computer system connected to the evaluation board 1 and the debugger device 4. The terminal 3 includes a CPU, a RAM, a ROM, and a nonvolatile storage device as configurations not shown. In the terminal 3, the CPU reads and executes an OS, a terminal emulator program, and the like stored in the RAM, ROM, or nonvolatile storage device. As a result, the terminal 3 connects to the evaluation board 1 and executes the evaluation program. Further, the terminal 3 receives and displays debug information from the debugger device 4. Thereby, the user who operates the terminal 3 can confirm the execution result of the evaluation program.

  The debugger device 4 is a debugger used when developing an embedded system. The debugger device 4 receives the state of the CPU 11 and the memory 14 from the inspection terminal 18 and the value of the register, and transmits them to the terminal 3 as debug information.

  As described above, the evaluation board 1 executes the OS, the HAL, the HAL driver, and the evaluation program read into the memory 14 by the CPU 11, and causes the device 12 to perform processing based on the setting parameters. 2 is operated, and the state of the CPU 11, memory 14, etc. at that time is acquired by the debugger device 4, so that the setting parameter can be evaluated.

  Next, the HAL according to the first embodiment of the present invention will be described. FIG. 2 is a block diagram showing a module configuration of the HAL according to the first embodiment of the present invention. The HAL module configuration shown in FIG. 2 includes a HAL 5 and devices 121 to 123. The devices 121 to 123 are equivalent to the device 12 of FIG. 1 and are devices corresponding to different hardware.

  The HAL 5 receives a control request for any of the devices 121 to 123 from the above-described HAL driver or a device driver corresponding to any of the devices 121 to 123, and accesses any of the corresponding devices 121 to 123. Thus, the hardware corresponding to any of the devices 121 to 123 (for example, the hardware 2 in FIG. 1) is operated. The HAL 5 includes an Anchor Pointer 500, a common management area 53, and HAL Device specific units 541 to 543.

  Anchor Pointer 500 is the value of the start address when the CPU 11 reads from the ROM (HAL) 16 onto the memory 14 when the HAL is initialized. Therefore, the subsequent processing can refer to the memory 14 starting from the Anchor Pointer 500.

  The HAL 5 includes a common management area 53 for storing index information for various devices, and HAL Device specific units 541 to 543 for storing unique definition information for each device.

  The common management area 53 includes a device entry 531 that is index information to the HAL Device specific unit 541, a device entry 532 that is index information to the HAL Device specific unit 542, and a device that is index information to the HAL Device specific unit 543. And an entry 533.

  The HAL Device specific parts 541 to 543 correspond to the devices 121 to 123, respectively. Hereinafter, as an example, the HAL Device specific unit 541 will be described, and the HAL Device specific unit 542 and the HAL Device specific unit 543 are the same as the HAL Device specific unit 541, and thus description thereof will be omitted.

  The HAL Device specific unit 541 includes a device block (DB) 55, a function table (FT) 56, and a HAL function 57. The device block 55 is a structure that stores HAL operation information used inside the HAL. The HAL operation information includes, for example, a device ID that is device identification information, a revision of the device, a length of Request Data (to be described later in FIG. 3), device status information, a port address, and the like. The function table 56 is a structure that is a pointer table of a HAL function in which processing for accessing various devices from the HAL 5 is defined. The HAL function 57 is various functions (functions) in which processing for accessing and operating the device 121 from the HAL 5 is defined as described above.

  Here, the device entry 531 is index information to the HAL Device specific unit 541 in which the DB Pointer 534 that is a pointer to the device block 55 and the FT Pointer 535 that is a pointer to the function table 56 are stored. Similarly, the device entry 532 and the device entry 533 are index information to the HAL Device specific unit 542 and the HAL Device specific unit 543, respectively, and thus illustration and description thereof are omitted.

  Further, the common management area 53, the device block 55, the function table 56, and the Request Data illustrated in FIG. 3 are secured in the memory 14 at the time of initialization. The HAL function 57 includes a function common to all devices and a function unique to the device. If there is a margin in the area of the memory 14, the HAL function 57 may be secured in the memory 14 at the time of initialization. Thereby, the execution speed becomes faster.

  The HAL 5 includes a device search function and a device execution function for programs that access the HAL in addition to those shown in FIG. The device search function searches the device block 55 in each HAL Device specific part with the device ID specified by the Request Data, and specifies the device and the function table that the device has. The device execution function converts the HAL function No (number) specified by the Request Data into a HAL function based on the specified function table 56. The HAL 5 accesses the device by the converted HAL function. The HAL function No is a number assigned to each HAL function. As a result, it is possible to specify the device to be controlled based on the Request Data and execute the HAL function. FIG. 9 is an example of the HAL function and the HAL function No.

  The Request Data is a structure that defines all programs that access the HAL and data structures that are commonly used by the HAL. FIG. 3 is a diagram illustrating a configuration example of the Request Data 8 according to the first embodiment of the present invention. The Request Data 8 includes HAL operation information 81 and parameter information 82.

  The HAL operation information 81 is a fixed-length parameter data area common to various devices. The HAL operation information 81 includes a device ID 811 for identifying a device to be processed, a HAL function No 812 for identifying the HAL function 57 to be executed, a return code 813 that is a return value of the HAL function to be executed, and the like. The parameter information 82 is an area of parameter data unique to various devices. For example, in the case of a device related to a display, the parameter information 82 may be an X coordinate and a Y coordinate of the display start position, a vertical size of the screen, a horizontal size, or the like.

  As described above, all functions provided by the HAL 5 can be accessed from any program that accesses the HAL.

  FIG. 4 is a block diagram showing the relationship between the HAL evaluation program, the HAL driver, the HAL, and the device according to the first embodiment of the present invention. Note that the device drivers 621 to 623 shown in FIG. 4 are device driver programs respectively corresponding to the devices 121 to 123 shown in FIG. However, the device drivers 621 to 623 are not necessarily required in the hardware setting parameter evaluation system 100.

  In FIG. 4, first, the HAL evaluation program 7 operating in the user mode sets the setting parameter for any one of the devices 121 to 123 in the Request Data 8 for the HAL driver 6 operating in the user mode and the kernel mode. Store and send a control request for that device. Next, the HAL driver 6 collectively receives various control requests from the HAL evaluation program 7 and transmits the control requests to the HAL 5. Thereafter, the HAL 5 specifies the HAL function of any of the devices 121 to 123 based on the control request from the HAL driver 6 and the Request Data 8, and executes the HAL function specified for the corresponding device. The HAL 5 receives the execution result from the device, stores it in the Request Data 8, and returns a return value to the HAL driver 6. The HAL driver 6 returns the process to the HAL evaluation program 7 based on the return value from the HAL 5.

  Here, the HAL 5 includes the common interface 50, function tables 511 to 513 corresponding to the function table 56 of FIG. 2 described above, and HAL functions 521 to 523 corresponding to the HAL function 57 of FIG. 2 described above. To do. The common interface 50 is an interface that commonly receives control requests from the HAL driver 6 and the device drivers 621 to 623. Further, the common interface 50 searches the common management area 53 from the device ID 811 and the HAL function No. 812 included in the Request Data 8, accesses the function table 511 from the FT Pointer 535 included in the corresponding device entry, for example, The HAL function 521 is specified from the table 511, and the device 121 is accessed from the specified HAL function 521.

  FIG. 5 is a diagram showing the concept of the HAL evaluation program, the HAL driver, and the HAL calling relationship according to the first embodiment of the present invention. The HAL evaluation program 7 is programmed with a HAL function call 71 and an OS I / F call 72. The HAL function call 71 is configured to make a control request to the HAL driver after setting the device ID, HAL function No, and parameters for calling the HAL function using the Request Data8. The OS I / F call 72 converts Request Data 8 and a control request set by the HAL function call 71 so as to call an OS I / F call processing unit 61 included in a HAL driver described later. The OS I / F call 72 is realized using an application programming interface (API) provided by each OS.

  The HAL driver 6 includes an OS I / F call processing unit 61 and a HAL function call processing unit 62. The OS I / F call processing unit 61 performs processing for receiving the request data 8 and the control request from the HAL evaluation program 7 via the API. The HAL function call processing unit 62 receives the request data 8 and the control request. Based on this, a device execution function of HAL5 is called to cause HAL5 to execute the HAL function.

  The HAL 5 receives a device execution function from the HAL management unit (RAM) 51 and accesses the device using the HAL function (ROM) 52 based on the request data 8 and the device execution function.

  That is, the HAL evaluation program 7 and the HAL driver 6 are implemented with a process that hides an application programming interface (API) for a device driver provided by each OS.

  Since the HAL evaluation program 7 is a program that operates in the user mode, it is not possible to program a process that directly calls a device execution function like a device driver. Therefore, in the first embodiment of the present invention, the HAL driver 6 that operates in the user mode and the kernel mode is introduced, and the HAL driver 6 implements the OS I / F call processing unit 61 and the HAL function call processing unit 62. Thus, the device execution function of HAL5 operating in the kernel mode can be called from the control request of the evaluation program operating in the user mode. Thereby, in the HAL evaluation program 7, it is possible to implement programming of the HAL function call 71 as if the device execution function was directly called.

  This makes it possible to perform detailed parameter settings from the HAL evaluation program 7 to operate the device and access the hardware.

  Conventionally, as a process for operating a device, it is necessary to describe a setting parameter and a process for calling a device execution function in a device driver program. Like the HAL5, the device driver needs to be stored in the ROM (HAL) 16 in advance, so that the ROM (HAL) 16 needs to be created again in order to make corrections.

  However, with the introduction of the HAL driver 6 that implements a process for calling a device execution function in the kernel mode, the HAL 5 and the HAL driver 6 are stored in the ROM (HAL) 16, and the setting parameters are described in the HAL evaluation that operates in the user mode. It is possible to go out to the program 7. Therefore, when the parameter setting described in the HAL evaluation program 7 is changed, for example, the HAL evaluation program 7 is corrected on the terminal 3, compiled, and loaded into the memory 14 via the terminal 17. It becomes possible to confirm the change of the setting. Therefore, the efficiency of hardware setting parameter evaluation work is improved. Alternatively, when the evaluation board 1 includes a USB terminal and the HAL evaluation program 7 is stored in a USB memory device that is external hardware, the evaluation board 1 can be connected to the USB terminal by connecting the USB memory device to the USB terminal. The HAL evaluation program 7 can be executed. In this case, it is not necessary to load the HAL evaluation program 7 from the terminal 3 via the terminal 17, and the efficiency of the hardware setting parameter evaluation work is further improved.

  In addition, since the portion depending on the OS can be absorbed by the OS I / F call 72, the HAL function call 71 can be configured not to depend on the OS. By diverting the description similar to the HAL function call 71 to another OS or a program executed in another kernel mode, it becomes easy to create and test a program for performing operations on various devices. . In addition, since the processing whose operation has been confirmed by the HAL evaluation program 7 in advance is mounted in another program, the quality of software is improved.

  Subsequently, the flow of processing of the HAL evaluation program 7, the HAL driver 6, and the HAL 5 according to the first embodiment of the present invention will be described with reference to FIGS. FIG. 6 is a flowchart showing the flow of the HAL evaluation process of the HAL evaluation program 7. A programming example of the HAL evaluation program 7 and the HAL driver 6 is shown in FIG. Note that FIG. 10 is merely an example for explanation and is not necessarily accurate.

  First, the HAL evaluation program 7 sets Request Data 8 (S101). Specifically, in the HAL function call 71 of the HAL evaluation program 7, the device ID and various parameter values for the device to be processed are stored in the Request Data 8. In FIG. 10, pREQ is a structure corresponding to Request Data8.

  Next, the HAL evaluation program 7 sets a HAL function (S102). Specifically, in the HAL function call 71, the HAL function No to be processed for the device to be processed is stored in the Request Data 8. In FIG. 10, a code group in which a function of pREQ is set, for example, a code 711 corresponds to this.

  Thereafter, the HAL evaluation program 7 calls the HAL function (S103). Specifically, in the HAL function call 71, a device execution function is called. In FIG. 10, the code 712 calling _DevHelp corresponds to this.

  Then, the HAL evaluation program 7 calls the HAL driver 6 (S104). Specifically, in response to the call of the HAL function call 71, the OS I / F call 72 converts it to the OS API, calls the OS I / F, and the OS calls the HAL driver 6. At this time, a reference to the Request Data 8 is also passed to the HAL driver 6.

  Thereafter, the HAL evaluation program 7 determines whether or not the ReturnCode is Success (S105). Specifically, the Request Data 8 including the execution result from the HAL driver 6 is received by the HAL function call 71 via the OS I / F call 72, and the content of the Return Code included in the Request Data 8 is determined.

  If ReturnCode is Success, the HAL evaluation program 7 performs post-processing (S106). If ReturnCode is other than Success, the HAL evaluation program 7 performs error processing (S107). Thereby, the HAL evaluation process by the HAL evaluation program 7 is completed.

  Next, the processing flow of the HAL driver 6 will be described with reference to the flowchart of FIG. First, the HAL driver 6 acquires Request Data 8 (S111). Specifically, the OS I / F call processing unit 61 of the HAL driver 6 receives a call from the above-described API and receives a reference to the Request Data 8.

  Next, the HAL driver 6 calls the HAL function (S112). Specifically, the HAL function of HAL5 is called by calling the device execution function based on the Request Data 8 received by the OS I / F call processing unit 61. In FIG. 10, the code 620 calling DevHelp corresponds to this.

  Thereafter, the HAL driver 6 receives the execution result from the HAL 5 and the Return Code (S113). Specifically, the HAL function call processing unit 62 receives a reference to the Request Data 8.

  Then, the HAL driver 6 returns the received Request Data 8 to the HAL evaluation program 7 and ends the process.

  Next, the processing flow of HAL5 will be described using the flowchart of FIG. First, the HAL 5 acquires Request Data 8 (S121). Specifically, the HAL management unit (RAM) 51 receives a reference to the Request Data 8.

  Next, the HAL 5 specifies the HAL function based on the device ID and the HAL function No (S122). Specifically, the HAL management unit (RAM) 51 refers to the common management area 53 from the device ID stored in the Request Data 8 and the HAL function No, and identifies the target HAL function.

  The HAL 5 executes the specified HAL function (S123). Subsequently, the HAL 5 stores the execution result and the return code Return Code in the Request Data 8 (S124), and returns it to the HAL driver 6. At this time, if the processing of the device is not completed, the fact is stored in the Request Data 8 as a Return Code, and the HAL 5 ends the processing. For example, in the case of waiting for an interrupt, the HAL 5 and the HAL driver 6 return “waiting for interrupt” stored in the Return Code as they are, and the HAL evaluation program 7 confirms the received Return Code and makes a processing request again. You can do it.

  As described above, in the first embodiment of the present invention, means for controlling a hardware abstraction layer called HAL5 and a hardware abstraction layer called HAL driver 6 for each device corresponding to a plurality of hardware is provided. Provided. In addition, by implementing a process for converting the API of the OS in the HAL driver 6, the OS-dependent process is hidden from the HAL evaluation program 7, and can be called from the HAL evaluation program 7 that originally operates in the user mode. A process for calling the HAL5 that cannot be performed can be implemented in the HAL evaluation program 7, and parameters for operating the hardware can be set.

Therefore, it is possible to provide a data processing device, a hardware access method, and a hardware access program that control each hardware from an application that operates in a user mode without depending on the combination of hardware and OS.
Other Embodiments of the Invention

  Note that the HAL driver 6 according to the first embodiment of the present invention can operate even when the device drivers 621 to 623 shown in FIG. 4 are being executed. This is because, in HAL5, the device drivers 621 to 623 and the HAL driver 6 are treated as independent drivers by securing the respective Request Data 8 in different areas. Therefore, it is possible to perform hardware evaluation by the HAL evaluation program 7 even for an embedded system that is actually in operation, and dynamic setting parameter evaluation or debugging can be performed. Further, during normal operation, error information can be intentionally sent by the HAL evaluation program 7 to verify the abnormal system. As an example, it is possible to finely adjust the image display position while displaying an image on the display. Even if parameters relating to fine adjustment are set in the display driver, fine adjustment is possible by changing the parameters from the HAL evaluation program 7 while operating the display driver. A code group 713 in which display parameters are set for the pREQ in FIG. 10 is an example of this.

  With the HAL driver 6 according to the first embodiment of the present invention, it is possible to call all the HAL functions in the device corresponding to the HAL 5 from the HAL evaluation program 7 in a unified manner, and the device driver for each device and each hardware. No need to change.

  According to the first embodiment of the present invention, it is not necessary to insert a debug output process for parameter evaluation into a device driver or a boot loader corresponding to each hardware in the parameter evaluation work. Further, there is no risk of degradation associated with the removal of the debug output processing or the like.

  Further, according to the first embodiment of the present invention, processing corresponding to the device drivers 621 to 623 can be realized by a program corresponding to a plurality of HAL evaluation programs 7.

  In the HAL driver 6 according to the first embodiment of the present invention, since all the HAL functions are called by one function, the versatility is high and the operation is light. This is because extra calculation processing does not occur at the time of transfer from the HAL evaluation program 7 to the HAL 5. In addition, by setting the HAL operation information 81 of the Request Data 8 to a fixed length, the HAL driver 6 and the HAL 5 only need to check the HAL operation information 81 portion, and the processing is simplified.

  In the first embodiment of the present invention, the hardware setting parameter evaluation work is targeted. However, the present invention is not limited to this. For example, in the portable information terminal equipped with the HAL 5 and the HAL driver 6 of Embodiment 1 of the present invention, the portable information terminal can be used by installing and executing a program corresponding to the HAL evaluation program 7 from the outside. Hardware operation can be controlled, adjustment of setting parameters, various verification operations, and the like can be performed.

  Furthermore, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the gist of the present invention described above.

It is a block diagram which shows the example of the apparatus block diagram of the evaluation operation | work by the hardware setting parameter evaluation system concerning Embodiment 1 of this invention. It is a block diagram which shows the module structure of HAL concerning Embodiment 1 of this invention. It is a figure which shows the structural example of Request Data concerning Embodiment 1 of this invention. It is a block diagram which shows the relationship between the HAL evaluation program, HAL driver, HAL, and device concerning Embodiment 1 of this invention. It is a figure which shows the concept of the calling relationship of the HAL evaluation program, HAL driver, and HAL concerning Embodiment 1 of this invention. It is a flowchart figure which shows the flow of the HAL evaluation process of the HAL evaluation program concerning Embodiment 1 of this invention. It is a flowchart figure which shows the flow of a process of the HAL driver concerning Embodiment 1 of this invention. It is a flowchart figure which shows the flow of a process of HAL concerning Embodiment 1 of this invention. It is a figure which shows the example of the HAL function and HAL function No concerning Embodiment 1 of this invention. It is a figure which shows the example of the evaluation program and HAL driver concerning Embodiment 1 of this invention.

Explanation of symbols

100 Hardware Setting Parameter Evaluation System 1 Evaluation Board 11 CPU
12 device 13 terminal 14 memory 15 ROM (OS)
16 ROM (HAL)
17 terminal 18 inspection terminal 2 hardware 3 terminal 4 debugger device 5 HAL
500 Anchor Pointer
53 Common Management Area 531 Device Entry 532 Device Entry 533 Device Entry 534 DB Pointer
535 FT Pointer
541 HAL Device Specific Portion 542 HAL Device Specific Portion 543 HAL Device Specific Portion 55 Device Block 56 Function Table 57 HAL Function 121 Device 122 Device 123 Device 8 Request Data
81 HAL operation information 811 Device ID
812 HAL function No.
813 Return Code
82 Parameter Information 50 Common Interface 511 Function Table 512 Function Table 513 Function Table 521 HAL Function 522 HAL Function 523 HAL Function 6 HAL Driver 621 Device Driver 622 Device Driver 623 Device Driver 7 HAL Evaluation Program 71 HAL Function Call 72 OS I / F Call 61 OS I / F call processing unit 62 HAL function call processing unit 51 HAL management unit (RAM)
52 HAL function (ROM)
711, 712, 620 code 713 code group

Claims (18)

A data processing apparatus that executes an operating system having a kernel mode and a user mode,
A plurality of hardware processing units;
A hardware abstraction layer that operates in the kernel mode and includes an interface corresponding to each of the plurality of hardware processing units, and a common interface for a device driver corresponding to each of the plurality of hardware processing units; ,
A hardware abstraction layer control unit for controlling the hardware abstraction layer,
The hardware abstraction layer control unit
Hardware that receives a control request for any of the plurality of hardware processing units from a program that operates in the user mode, and that is identified by the control request using the common interface in the hardware abstraction layer A data processing apparatus that performs control related to a processing unit. The hardware abstraction layer control unit
The data processing apparatus according to claim 1, wherein the control request is received via an interface of the operating system, and the hardware abstraction layer is called based on the control request. The hardware abstraction layer control unit
Request data storing device identification information for identifying the hardware processing unit, function identification information for identifying a hardware processing function for performing processing related to the hardware processing unit, and parameter values used for the hardware processing function The data processing apparatus according to claim 2, wherein the hardware abstraction layer is called by including the control request in the control request. The program that operates in the user mode is:
4. The device identification information, the function identification information, and the parameter value are stored in the request data, the request data is included in the control request, and the control request is converted into an interface of the operating system. The data processing apparatus described in 1. The program that operates in the user mode is a plurality of device drivers corresponding to the plurality of hardware processing units,
The data processing apparatus according to claim 1, wherein the hardware abstraction layer control unit receives a control request from the plurality of device drivers to the hardware processing unit. The hardware abstraction layer includes a processing function for controlling the hardware processing unit,
The data processing apparatus according to claim 1, wherein the device driver and the program operating in the user mode include a processing function call unit for calling the processing function.   The data according to claim 6, wherein the hardware abstraction layer control unit calls the processing function by converting a processing function call of a program operating in the user mode into a processing function call operating in the kernel mode. Processing equipment. An operating system having a kernel mode and a user mode, an interface operating in the kernel mode, corresponding to each of the plurality of hardware processing units, and a device driver corresponding to each of the plurality of hardware processing units A hardware access method for causing a computer including a hardware abstraction layer having an interface to execute access processing to the plurality of hardware processing units,
A control request receiving step for receiving a control request for any of the plurality of hardware processing units from a program operating in the user mode;
A hardware access method comprising: a hardware abstraction layer calling step for causing the hardware abstraction layer to execute control related to a hardware processing unit specified by the control request via the common interface.   9. The hardware access method according to claim 8, wherein the control request receiving step receives the control request via an interface of the operating system.   The hardware abstraction layer calling step includes device identification information for identifying the hardware processing unit, function identification information for identifying a hardware processing function for performing processing related to the hardware processing unit, and the hardware processing function. The hardware access method according to claim 8 or 9, wherein request data storing a parameter value to be used is included in the control request and the hardware abstraction layer is called.   The hardware according to claim 8, wherein the control request receiving step further receives a control request from a plurality of device drivers corresponding to the plurality of hardware processing units to the hardware processing unit. how to access. Operating the device driver;
The hardware information acquisition step of acquiring information on the hardware processing unit from the program operating in the user mode through the hardware abstraction layer during the operation of the device driver. 12. The hardware access method according to any one of 11 above.   The hardware according to claim 8, further comprising: a processing function calling step for calling a processing function included in the hardware abstraction layer to control the hardware processing unit from the device driver and the program operating in the user mode. Wear access method.   14. The hardware abstraction layer according to claim 13, wherein the hardware abstraction layer calling step calls the processing function by converting a processing function call of a program operating in the user mode into a processing function call operating in the kernel mode. Wear access method. An operating system having a kernel mode and a user mode, an interface operating in the kernel mode, corresponding to each of the plurality of hardware processing units, and a device driver corresponding to each of the plurality of hardware processing units A hardware access program for causing a computer including a hardware abstraction layer having an interface to execute access processing to the plurality of hardware processing units,
Control request receiving means for receiving a control request for any of the plurality of hardware processing units from a program operating in the user mode;
A hardware access program comprising: a hardware abstraction layer calling unit that causes the hardware abstraction layer to execute control related to a hardware processing unit specified by the control request via the common interface. 16. The hardware access program according to claim 15, wherein the control request accepting unit accepts the control request via an interface of the operating system.   The hardware abstraction layer calling unit includes device identification information for identifying the hardware processing unit, function identification information for identifying a hardware processing function for performing processing related to the hardware processing unit, and the hardware processing function. The hardware access program according to claim 15 or 16, wherein request data storing a parameter value to be used is included in the control request and the hardware abstraction layer is called.   The hardware according to claim 15, wherein the control request receiving unit further receives a control request from a plurality of device drivers corresponding to the plurality of hardware processing units to the hardware processing unit. Access program.

Images