TWI844862B - Electronic device and method of operating same - Google Patents

Abstract

An electronic device and an operation method thereof are provided. The operation method of the electronic device includes the following steps: running an operating system to generate an operation command; looking up a driver command corresponding to the operation command in a look-up table according to the operation command; and executing the driver command.

Description

Electronic device and method of operating the same

The present invention relates to an electronic device, and more particularly to a device driver for the electronic device and an operating method for the electronic device.

FIG1 is a schematic diagram showing an operating system architecture of a known embedded device. The operating system includes an application layer 110, a graphic user interface library (GUI library) 120, a frame buffer framework layer 130, and a device driver layer 140. The frame buffer framework layer 130 is an interface provided by the Linux system for display devices. The frame buffer framework layer 130 abstracts the display buffer, shields the underlying differences of the image hardware, and allows the application layer 110 to read and write the display buffer directly or indirectly (for example, by calling the function of the GUI library 120) in the graphics mode. The device driver developed based on the frame buffer framework is called the frame buffer device driver.

FIG2 shows a schematic diagram of another operating system architecture of a known embedded device. The operating system includes an application layer 210, a graphical user interface library 220, and a device driver layer 230. The application layer 210 directly or indirectly (for example, by calling a function of the graphical user interface library 220) calls the device driver to control the hardware. The operating system architecture of FIG2 is applicable to a real-time operating system (RTOS).

Although the frame buffer framework layer 130 of FIG. 1 can shield the underlying differences of the image hardware, the frame buffer framework layer 130 is highly coupled with the device driver layer 140 (i.e., the device driver layer 140 is highly dependent on the data structure provided by the frame buffer framework layer 130 to communicate with the upper layer or the kernel), making it difficult to port the frame buffer device driver to a platform that does not include the frame buffer framework layer 130 (e.g., a platform using the architecture of FIG. 2 as an operating system). Similarly, because the application layer 210 directly calls the device driver layer 230 or the GUI library 220 and generally does not provide a universal interface, the device driver layer 230 is highly coupled with the application layer 210 and/or the GUI library 220, which is not conducive to porting the device driver layer 230 to a platform with a frame buffer framework layer (for example, a platform with the architecture of FIG. 1 as the operating system).

The above problem occurs not only in frame buffer device drivers, but also in other types of device drivers.

In view of the deficiencies of the prior art, one purpose of the present invention is to provide an electronic device and an operating method thereof to improve the deficiencies of the prior art.

One embodiment of the present invention provides an electronic device, comprising: a memory interface and a processor. The memory interface is used to access a memory, and the memory stores a plurality of program instructions or program codes of an operating system. The processor is used to execute the program instructions or program codes to perform the following steps: execute the operating system to generate an operation command; according to the operation command, query a driver command corresponding to the operation command from a lookup table; and execute the driver command.

Another embodiment of the present invention provides an operating method of an electronic device, comprising: executing an operating system to generate an operating command; searching a driver command corresponding to the operating command from a lookup table according to the operating command; and executing the driver command.

The technical means embodied in the embodiments of the present invention can improve at least one of the shortcomings of the previous technology. Therefore, the present invention is easier to transplant device drivers between platforms than the previous technology.

The features, implementation and effects of the present invention are described in detail below with reference to the accompanying drawings.

110,210,410: Application layer

120,220: Graphical User Interface Library

130,420: frame buffer framework layer

140,230,440:Device driver layer

300: Electronic devices

310: Processor

320: Image processing circuit

330: Graphics Engine

340: Stacked circuit

350: Image output circuit

360:Memory interface

370:Memory

375: Storage space

380:Default image

IMG_out: output image

430: Operating system adapter module

MI_FB_API_xxx: Operation commands

MI_FB_IMPL_API_xxx: driver command

APP_CMD: Application layer command

ID: identification code

602,S604,S606,S610,S612,S620,S621,S622,S623,S624,S625,S626,S630,S632,S634,S636,S640,S910,S920,S922,S924,S926: Steps

FIG. 1 shows a schematic diagram of an operating system architecture of a known embedded device; FIG. 2 shows a schematic diagram of another operating system architecture of a known embedded device; FIG. 3 shows a functional block diagram of an embodiment of the electronic device of the present invention; FIG. 4 shows a schematic diagram of an operating system architecture of the electronic device 300 of the present invention; FIG. 5 shows a schematic diagram of another operating system architecture of the electronic device 300 of the present invention; FIG. 6 shows a flow chart of an embodiment of an operating method of the electronic device of the present invention; FIG. 7 shows an embodiment of a lookup table; FIG. 8 shows a sub-step of step S620 of FIG. 6; FIG. 9 shows a flow chart of another embodiment of the operating method of the electronic device of the present invention; and FIG. 10 shows an embodiment of an operation command corresponding to a frame buffer framework.

The technical terms used in the following descriptions refer to the customary terms in this technical field. If this manual explains or defines some of the terms, the interpretation of those terms shall be based on the explanation or definition in this manual.

The disclosure of the present invention includes an electronic device and its operating method. Since some components included in the electronic device of the present invention may be known components individually, the details of the known components will be omitted in the following description without affecting the full disclosure and feasibility of the device invention. In addition, part or all of the process of the operating method of the electronic device of the present invention may be in the form of software and/or firmware, and can be executed by the electronic device of the present invention or its equivalent device. Without affecting the full disclosure and feasibility of the method invention, the following description of the method invention will focus on the step content rather than the hardware.

FIG3 shows a functional block diagram of an embodiment of the electronic device of the present invention. The electronic device 300 includes a processor 310, an image processing circuit 320, a graphics engine 330, an overlay circuit 340, an image output circuit 350, a memory interface 360, and a memory 370. The processor 310, the image processing circuit 320, the graphics engine 330, the overlay circuit 340, and the image output circuit 350 access the memory 370 through the memory interface 360. The processor 310 is coupled to the image processing circuit 320, the graphics engine 330, the overlay circuit 340, and the image output circuit 350. The memory interface 360 is coupled to the image processing circuit 320, the graphics engine 330, the superposition circuit 340 and the image output circuit 350. The processor 310 is coupled to the memory interface 360 and the memory 370.

In one embodiment, the processor 310, the image processing circuit 320, the graphics engine 330, the superposition circuit 340, the image output circuit 350 and the memory interface 360 are integrated on a first chip, and the memory 370 is disposed on a second chip; in this case, the electronic device of the present invention refers to the first chip.

The processor 310 may be a circuit or electronic component with program execution capability, such as a central processing unit, a microprocessor, a microprocessing unit, a digital signal processor, an application specific integrated circuit (ASIC), or an equivalent circuit thereof. In some embodiments, the memory 370 stores a plurality of program instructions or program codes of the operating system of the electronic device 300, and the processor 310 executes the operating system (i.e., executes the program instructions or program codes).

The image processing circuit 320 processes the image data, such as filtering, brightness adjustment, contrast adjustment, and color adjustment. The graphics engine 330 can generate a preset image 380 (such as a menu). The superposition circuit 340 is used to superpose the preset image 380 with the image processed by the image processing circuit 320 to generate a superimposed image. The image processed by the image processing circuit 320 and the superimposed image can be stored in a dedicated memory block of the memory 370. The image output circuit 350 can obtain the superimposed image (i.e., the image to be displayed) from the superimposed circuit 340 or the memory 370, and then encapsulate or convert the superimposed image to output the output image IMG_out.

FIG4 is a schematic diagram showing an operating system architecture of the electronic device 300 of the present invention. The operating system includes an application layer 410, a frame buffer framework layer 420, an operating system adapter module 430, and a device driver layer 440. FIG5 is a schematic diagram showing another operating system architecture of the electronic device 300 of the present invention. FIG5 is similar to FIG4, but the operating system of FIG5 does not include the frame buffer framework layer 420. As shown in FIG. 4 and FIG. 5 , the electronic device 300 of the present invention uses the operating system adapter module 430 as an interface between the device driver layer 440 and the frame buffer framework layer 420 or the application layer 410, so that the frame buffer device driver of the device driver layer 440 can be executed on both operating systems without requiring major modifications or even no modifications (i.e., making the porting of the frame buffer device driver easier).

As shown in FIG. 4 and FIG. 5 , the operating system adapter module 430 converts the operation command MI_FB_API_xxx into the driver command MI_FB_IMPL_API_xxx ("xxx" represents multiple commands), that is, generates the corresponding driver command MI_FB_IMPL_API_xxx according to the operation command MI_FB_API_xxx. In one embodiment, the operation command MI_FB_API_xxx is used to create a storage space 375 for displaying images in the memory 370, and the graphics engine 330 can draw a preset image 380 (such as a menu) and store it in the storage space 375, and the superposition circuit 340 can read the preset image 380 from the storage space 375 and superimpose it with other images. In the embodiment of FIG. 4 , the operation command MI_FB_API_xxx is generated by the frame buffer framework layer 420 in response to the application layer command APP_CMD. In the embodiment of FIG. 5 , the operation command MI_FB_API_xxx is generated by the application layer 410. In other words, in the embodiment of FIG. 5 , the operation command MI_FB_API_xxx can also be regarded as the application layer command APP_CMD. The application layer 410 includes an application program and a function library (including but not limited to a graphical user interface library), and the application layer command APP_CMD can be directly generated by the application program (without calling the function library) or indirectly generated by the application program (calling the function library).

In the operating system architecture of FIG. 4 , the operating system switching module 430 registers the operation command MI_FB_API_xxx (i.e., registers the application program interface (API)) to the frame buffer framework layer 420, so that the frame buffer framework layer 420 can call the corresponding application program interface provided by the operating system switching module 430 according to the command being executed or called. The registration method is the same as the method of registering the device driver layer 140 to the frame buffer framework layer 130 in the known method.

FIG6 shows a flow chart of an embodiment of the operation method of the electronic device of the present invention, from which the implementation details of the operating system adapter module 430 can be known. The process of FIG6 includes the following steps, which are executed by the processor 310.

Step S602: Receive the operation command MI_FB_API_xxx. The operation command MI_FB_API_xxx can be generated by the frame buffer framework layer 420 (Figure 4) or by the application layer 410 (Figure 5).

Step S604: Determine whether the electronic device 300 is currently running a Linux system or an RTOS system. The processor 310 can make the determination of step S604 based on the system parameters. The details are well known to those skilled in the art and will not be described in detail. If the electronic device 300 is currently running an RTOS system (refer to the architecture of FIG. 5 ), the processor 310 executes step S610. If the electronic device 300 is currently running a Linux system, the processor 310 executes step S606.

Step S606: Determine whether the Linux system is currently operating in user mode or kernel mode. If the Linux system is currently operating in user mode, the processor 310 executes step S620. If the Linux system is currently operating in kernel mode, the processor 310 executes step S630.

Step S610, step S620 and step S630 are respectively the driver command generation procedures in the RTOS system, Linux user mode and Linux kernel mode, which will be described in detail below. The processor 310 generates the driver command MI_FB_IMPL_API_xxx according to the operation command MI_FB_API_xxx in step S610, step S620 or step S630, and then the processor 310 executes the driver command MI_FB_IMPL_API_xxx or the corresponding command in the device driver layer 440 (step S640).

Step S610 of FIG. 6 includes sub-step S612. In sub-step S612, the processor 310 finds the driver command MI_FB_IMPL_API_xxx corresponding to the operation command MI_FB_API_xxx (or core command) or the identification code ID by looking up the table. Please refer to FIG. 7, which shows an embodiment of the lookup table. The first column of the lookup table is the operation command MI_FB_API_xxx, the second column is the identification code ID corresponding to the operation command MI_FB_API_xxx (in some embodiments, an operation command MI_FB_API_xxx has a unique identification code ID), and the third column is the driver command MI_FB_IMPL_API_xxx. For example, the processor 310 can find the corresponding driver command MI_FB_IMPL_API_oepn (MI_FB_IMPL_API_mmap or MI_FB_IMPL_API_close) according to the operation command MI_FB_API_open (MI_FB_API_mmap or MI_FB_API_close) or its identification code 0 (1 or 2). Please note that the lookup table in FIG. 7 only lists some commands as examples, and the actual lookup table may include more commands. In some embodiments, the lookup table is stored in the memory 370.

FIG8 shows the sub-steps of step S620 of FIG6, which are executed by the processor 310. The embodiment of FIG8 can correspond to the operating system architecture of FIG5. Step S621 is executed in the user mode of the Linux system, and steps S622 to S626 are executed in the kernel mode of the Linux system.

Step S621: In Linux user mode, find the corresponding user command according to the operation command MI_FB_API_xxx. User commands are commands for operating hardware or devices in Linux user mode, such as opening device files (open), input/output control (ioctl), closing device files (close), etc. In some embodiments, the operation command MI_FB_API_xxx is an application layer command APP_CMD generated by the application layer 410 (i.e., please refer to the operating system architecture of Figure 5).

Step S622: In the Linux kernel mode, a device node is established. This step is well known to those with ordinary knowledge in this technical field, so it will not be repeated here.

Step S623: Operate the device node to find a core command corresponding to the user command, for example, find the kernel mode input/output control (device_ioctl) (i.e., kernel command) corresponding to the user mode input/output control (ioctl) (i.e., user command). Because for device operations in the Linux system, user commands and kernel commands have a one-to-one correspondence, the kernel command and the operation command MI_FB_API_xxx also have a one-to-one correspondence. In other words, the first column of the lookup table in FIG. 7 can be replaced with the kernel command, or a new column "kernel command" can be added to the lookup table; the kernel command also has a one-to-one correspondence with the identification code ID.

Step S624: Determine whether the electronic device 300 includes two operating systems. In some embodiments, the electronic device 300 includes two operating systems such as a Linux system and an RTOS system (which can be executed by one core of the processor 310 or by two cores of the processor 310). If the electronic device 300 includes two operating systems, the processor 310 executes step S626; otherwise, the processor 310 executes step S625.

Step S625: Find the driver command MI_FB_IMPL_API_xxx corresponding to the core command or an identification code, for example, by querying the lookup table of Figure 7. As described above, because the core command is related to the operation command MI_FB_API_xxx, finding the driver command MI_FB_IMPL_API_xxx based on the core command is equivalent to finding the driver command MI_FB_IMPL_API_xxx based on the operation command MI_FB_API_xxx and/or its identification code ID.

Step S626: Send the core command and/or the identification code ID to the RTOS system. As described above, because the core command, the identification code ID and the operation command MI_FB_API_xxx can correspond to each other, sending the core command and/or the identification code ID is equivalent to sending the corresponding operation command MI_FB_API_xxx. When the two operating systems are executed by the same core of the processor 310, step S626 can be executed by calling a function. In one embodiment, when the two operating systems are respectively executed by two cores or the same core of the processor 310, the core command and/or the identification code ID can be sent by remote processor messaging (RPMsg) to execute step S626. Remote processing message transmission is well known to those with ordinary knowledge in this technical field, so it will not be described in detail. After the RTOS system receives the core command and/or identification code, the processor 310 executes step S612 to find the driver command MI_FB_IMPL_API_xxx.

When the electronic device 300 includes two operating systems, the device driver is usually executed in the RTOS system because the RTOS system has the advantage of fast execution speed. Therefore, step S626 sends the core command and/or identification code to the RTOS system to find the driver command MI_FB_IMPL_API_xxx in the RTOS system (i.e., step S612 in Figure 6).

FIG9 shows a flowchart of another embodiment of the operation method of the electronic device of the present invention, which is executed by the processor 310. The embodiment can correspond to the operating system architecture of FIG4, and also includes the details of step S630 of FIG6 (i.e., steps S632, S634 and S636). The process of FIG9 includes the following steps, wherein step S910 is executed in the user mode of the Linux system, and steps S920 and S630 are executed in the kernel mode of the Linux system.

Step S910: Receive application layer command APP_CMD. In some embodiments, the application layer command APP_CMD may be the user command in step S621, please refer to the description of step S621 above.

Step S920: The processor 310 executes core operations related to the frame buffer framework layer 420, including steps S922~S926.

Step S922: Establishing a device node. This step is an inherent operation of the frame buffer framework layer 420.

Step S924: Operate the device node to find a core command corresponding to the application layer command. Step S924 is similar to step S623, please refer to the above description of step S623. When the application layer command APP_CMD is equal to the user command, step S924 is the same as step S623.

Step S926: Find the operation command MI_FB_API_xxx corresponding to the core command. Please refer to Figure 4. Because the operating system adapter module 430 has registered the application program interface to the frame buffer framework layer 420 in advance (after registration, the operation command MI_FB_API_xxx corresponds one-to-one to the core command), the processor 310 can find the corresponding operation command MI_FB_API_xxx in the frame buffer framework layer 420 according to the core command.

Step S632: Determine whether the electronic device 300 includes two operating systems. This step is the same as or similar to step S624. If the electronic device 300 includes two operating systems, the processor 310 executes step S636; otherwise, the processor 310 executes step S634.

Step S634: Find the driver command corresponding to the operation command or an identification code. This step is similar to step S612.

Step S636: Send the operation command and/or identification code to the RTOS system. This step is similar to step S626.

FIG. 10 is an implementation example of the operation command MI_FB_API_xxx corresponding to the frame buffer framework. As shown in FIG. 10 , the name of the operation command MI_FB_API_xxx is similar to the name of the user interface of the frame buffer framework (i.e., user command or application layer command), which can make the operating system adapter module 430 of the present invention easier to integrate with the original Linux system. For other types of device drivers, those with ordinary knowledge in the art can also name the operation command MI_FB_API_xxx according to FIG. 10 . Please note that the naming method of FIG. 10 is only an implementation method and is not used to limit the present invention.

In summary, since the operating system adapter module 430 of the present invention provides an adapter between the device driver layer 440 and the application layer 410 or the frame buffer framework layer 420, it is easier for the developer of the electronic device to port the frame buffer device driver to different platforms.

Although the above-mentioned embodiments use the frame buffer device driver as an example, this is not a limitation of the present invention. People skilled in the art can appropriately apply the present invention to other types of device drivers based on the disclosure of the present invention.

Although the embodiments of the present invention are described above, these embodiments are not intended to limit the present invention. A person with ordinary knowledge in the technical field may make changes to the technical features of the present invention according to the explicit or implicit content of the present invention. All these changes may fall within the scope of patent protection sought by the present invention. In other words, the scope of patent protection of the present invention shall be subject to the scope of the patent application defined in this specification.

S602, S604, S606, S610, S612, S620, S630, S640: Steps

Claims (18)

An electronic device includes: a memory interface for accessing a memory storing a plurality of program instructions or program codes of an operating system; and a processor coupled to the memory interface for executing the program instructions or program codes to perform the following steps: (A) executing the operating system to generate an operation command; (B) searching a lookup table for a driver command corresponding to the operation command according to the operation command; and (C) executing the driver command. An electronic device as claimed in claim 1, wherein the operation command is generated by an application layer of the operating system. An electronic device as claimed in claim 2, wherein the operating system is a real-time operating system. As in claim 1, the operating system includes a frame buffer framework layer and an application layer, and the frame buffer framework layer generates the operation command in response to an application layer command generated by the application layer. The electronic device of claim 1, wherein when the operating system is a Linux system, the processor further executes the following steps: (D) receiving an application layer command; (E) establishing a device node; (F) operating the device node to find a core command corresponding to the application layer command; and (G) finding the operation command corresponding to the core command. An electronic device as claimed in claim 5, wherein the core command is a command of a frame buffer frame layer. The electronic device of claim 1, wherein, when the operating system is a Linux system and the processor further executes a real-time operating system, the processor further executes the following steps: transmitting the operation command or an identification code corresponding to the operation command to the real-time operating system, wherein the step (B) is executed in the real-time operating system. The electronic device of claim 1, wherein when the operating system is a Linux system, the step (B) includes: finding a user command corresponding to the operation command; establishing a device node; operating the device node to find a core command corresponding to the user command; and finding the driver command according to the core command. As in claim 1, the operation command is related to establishing a storage space in the memory, and the electronic device further comprises: a graphics engine coupled to the processor and the memory interface, generating an image and storing the image in the storage space corresponding to the operation command; and a superposition circuit coupled to the processor and the memory interface, reading the image from the storage space and superimposing the image with another image. A method for operating an electronic device comprises: (A) executing an operating system to generate an operating command; (B) searching a driver command corresponding to the operating command from a lookup table according to the operating command; and (C) executing the driver command. The method of claim 10, wherein the operation command is generated by an application layer of the operating system. As in the method of claim 11, wherein the operating system is a real-time operating system. As in the method of claim 10, the operating system includes a frame buffer framework layer and an application layer, and the frame buffer framework layer generates the operation command in response to an application layer command generated by the application layer. The method of claim 10, wherein when the operating system is a Linux system, the method further comprises: (D) receiving an application layer command; (E) establishing a device node; (F) operating the device node to find a core command corresponding to the application layer command; and (G) finding the operation command corresponding to the core command. The method of claim 14, wherein the core command is a command of a frame buffer frame layer. The method of claim 10, wherein, when the operating system is a Linux system and the electronic device further executes a real-time operating system, the method further comprises: transmitting the operation command or an identification code corresponding to the operation command to the real-time operating system, wherein the step (B) is executed in the real-time operating system. The method of claim 10, wherein when the operating system is a Linux system, the step (B) includes: finding a user command corresponding to the operation command; establishing a device node; operating the device node to find a core command corresponding to the user command; and finding the driver command according to the core command. As in the method of claim 10, wherein the operation command is related to establishing a storage space in a memory, the method further comprises: generating an image using a graphics engine, and storing the image in the storage space corresponding to the operation command; and reading the image from the storage space using a superposition circuit, and superimposing the image with another image.