Hardware abstraction in embedded systems

Abstract

Machine-implemented method for creating a hardware abstraction for an application running in an embedded system environment, wherein the machine-implemented method comprises: Creating a platform (208, 510) for running an application (402, 508) in a managed code environment in a first application space (202, 204, 206, 300, 400, 502); and Providing a method for specifying a second application domain (202, 204, 206, 504) that abstracts a hardware device (406, 512) through the platform, such that the application can access the hardware device via a generic interface, with the application running in the managed code environment in the first application domain. the procedure further includes: Isolating the first and second application domains from other application domains by providing a software system partitioned into a multitude of independent applications with fixed public interfaces and blocking other access among the application domains.

Description

[0001] The invention relates to the field of embedded systems and in particular to the field of hardware abstraction in embedded systems.

[0002] When developing and programming a desktop or server application, a high level of abstraction from the underlying computing resources creates scalability for the desktop or server application. A platform, such as one using the .NET framework developed by Microsoft Corporation of Redmont, Washington, can be used to execute programs. A programmer using a service-based architecture and multithreading techniques can avoid worrying about which part of a system executes a program because the platform creates a high level of abstraction.

[0003] Embedded systems are prevalent in today's computer systems. Embedded systems can be developed to be implemented with custom hardware, often running in real-time environments. Examples of embedded systems include, but are not limited to, mobile phones, set-top boxes, personal digital assistants (PDAs), telecommunications switching systems, aircraft systems, and spacecraft systems.

[0004] When developing embedded systems, a high level of abstraction, as described above, can adversely affect the embedded systems, making performance unpredictable. Furthermore, specific aspects of the hardware devices can be lost in the high level of abstraction. For example, the physical connections to physical interfaces can be abstracted, but they can be reintroduced later using additional parameters in the thread control functions and I / O drivers. Furthermore, the high level of abstraction makes it impossible for a programmer to refer to a specific central processing unit (CPU) or CPU-like device without breaking the abstraction.

[0005] In systems including, but not limited to, the .NET framework, an application can communicate with a hardware component by communicating with a driver that executes proprietary code, which can then access the hardware component. Each different hardware component can use a different driver. As a result, the programmer learns how the application interfaces with each of the different drivers before programming the application to call the drivers.

[0006] US 2005 / 0289510 A1 discloses a method, system and apparatus for providing communication and enabling seamless interoperability between devices having similar or different characteristics.

[0007] US 7 073 059 B2 shows a combined hardware and software interface for a secure platform that connects operating systems and custom control programs within a computer system. The combined hardware and software interface for a secure platform uses a hardware platform that supports at least four privilege levels: non-privileged instructions, non-privileged registers, privileged instructions, privileged registers, and firmware interfaces.

[0008] The invention is therefore based on the object of creating a method and a system which do not have the above-mentioned disadvantages.

[0009] This object is achieved according to the invention by a machine-implemented method according to claim 1, a tangible machine-readable medium according to claim 9 and a system according to claim 10. Advantageous developments of the invention are specified in the dependent claims.

[0010] This summary is intended to introduce, in a simplified form, a selection of concepts that are further described below in the detailed description. This summary is neither intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0011] A system and a machine-implanted method may be created to provide the hardware abstraction. The system may include a platform that allows a user to specify one or more application domains, some of which may abstract a hardware device. The application domains are computing units capable of executing program code in a managed code environment. The application domains may be isolated from other application domains by partitioning a software system into a number of independent applications with fixed public interfaces.

[0012] In some embodiments consistent with the subject matter of this disclosure, the platform provides the ability to create application domains via programming language constructs. An application in one application domain may access a hardware device or software in another application domain via generic interfaces provided in the managed code environment. The platform may enforce managed code features, including, but not limited to, code access security, code verification, validation of non-functional constraints, and application domain isolation. Validation of non-functional constraints may include, but is not limited to, information about a maximum runtime for a function.

[0013] In some embodiments, an application executing in a first application space may download code to a hardware device in a second application space. When the hardware device executes the downloaded code, the hardware device may perform the functions defined by the downloaded code. A generic interface may be defined so that an application executing in an application space in a managed code environment may invoke one or more functions of the downloaded code executing on the hardware device.A generic interface may be defined so that an application executing in one application space in a managed code environment may also invoke software executing in another application space through a generic interface similar to a generic interface for downloading information by an application to a hardware device or similar to a generic interface for invoking functions of the hardware device from an application.

[0014] Further features and advantages of the invention will become clear upon reading the following description of preferred embodiments, which refers to the drawings, in which: Fig. 1 is a functional block diagram of an exemplary processing device that may be used in embodiments consistent with the subject matter of this disclosure; Fig. 2 illustrates an exemplary system consistent with the subject matter of this disclosure and including multiple application areas; Fig. 3 illustrates a field-programmable gate array-based application consistent with the subject matter of this disclosure; Fig. 4 is a functional block diagram of an exemplary application area including an application and a hardware component in an application area; Fig. 5 is a functional block diagram illustrating an application area including an application and another application area including a hardware component accessed by the application; Fig. 6 and Fig. 7 illustrate exemplary processes that may be performed with embodiments consistent with the subject matter of this disclosure.

[0015] Embodiments are discussed below. While specific implementations are discussed, it is understood that this is done for illustrative purposes only. One skilled in the relevant art will recognize that other components and configurations may be used without departing from the spirit and scope of the subject matter of this disclosure. overview

[0016] A method and system are provided whereby a platform can execute an application in a managed code environment within an application domain. The managed code environment may be enforced by the platform and may provide the application with a number of features, including, but not limited to, memory management, thread execution, code verification, code execution, code access security, validation of non-functional constraints, application-domain isolation, and resource release. An example of validation of non-functional constraints may include, but is not limited to, a maximum runtime for a function.

[0017] An application space is a computing unit capable of executing program code. The application space can also be a target of communications and external events. The creation of an application space results in the initialization of a computing unit and the locking of associated resources, after which the application space can be ready to process communications and events. An application space can be destroyed, resulting in the release of associated resources, after which the application space can no longer be available for processing communications and events.

[0018] In some embodiments consistent with the subject matter of this disclosure, an application space concept may be implemented in a .NET programming language within the .NET framework (or .NET platform) available from Microsoft Corporation of Redmont, Washington. In other embodiments, a different platform may be used. Resources, including but not limited to memory and CPU time, may be used by the application spaces. Other resources, such as hardware interfaces, may include, but are not limited to, hardware interrupts, shared memory areas, direct memory access (DMA) channels, memory-mapped I / O spaces, I / O buses, I / O pins, and shared or exclusive locks, and may be defined as the properties of an application space.

[0019] Application domains can be isolated from other application domains by partitioning a software system into a number of independent applications with fixed public interfaces defined by an application programmer. Other accesses between application domains can be blocked.

[0020] The platform may provide the ability to create application domains as a programming language construct that abstracts hardware components. Such application domains may expose hardware functions and software-implemented functions via a generic interface that can be used for management functions, including, but not limited to, both initialization and the actual hardware or software functions. An exemplary processing device

[0021] Fig. 1 is a functional block diagram of an exemplary processing device 100 that can be used to implement embodiments consistent with the subject matter of this disclosure. The processing device 100 may be a desktop personal computer (desktop PC), a notebook or laptop PC, a server, a handheld processing device, or other processing device. The processing device 100 may include a bus 110, a memory 130, a read-only memory (ROM) 140, a processor 120, and a storage device 150. The bus 110 may allow communication between the components of the processing device 100.

[0022] Processor 120 may include at least one conventional processor or microprocessor that interprets and executes instructions, as well as one or more embedded systems. Memory 130 may be random access memory (RAM) or another type of dynamic storage device that stores information and instructions for execution by processor 120. Memory 130 may store temporary variables or other intermediate information used during execution of instructions by processor 120. ROM 140 may include a conventional ROM device or another type of static storage device that stores static information and instructions for processor 120.The storage device 150 may include a hard disk and corresponding drive, a flash-based storage device, or another type of storage device or storage medium for storing data and / or instructions for the processor 120.

[0023] Processing device 100 may perform functions in response to processor 120 executing sequences of instructions contained in a tangible machine-readable medium, such as memory 130, ROM 140, storage device 150, or another medium. Such instructions may be read into memory 130 from another machine-readable medium or from a separate device via a communications interface (not shown). Example areas of application

[0024] Fig. 2 illustrates an example system 200 that may be implemented in embodiments consistent with the subject matter of this disclosure. The example system 200 may include an application domain 202, an application domain 204, and an application domain 206 executing on a platform 208. The application domain 202 may include a CPU core 210, a software library 212, and a hardware component 214. The application domain 204 may include dual CPU cores 215, a software library 216, and a hardware component 218. The application domain 206 may include a CPU core 220, a software library 222, and a hardware component 224.

[0025] The application area 202 can interface with other components via an interrupt 230 and a software application programming interface (software API) 232, and vice versa. The application area 202 can interface with the application area 204 via an I / O bus 234 and a shared memory area 236, and vice versa. The application area 202 can interface with the application area 206 via an I / O bus 238, and vice versa. The application area 204 can interface with other components via a software API 240 and memory-mapped I / O 242, and vice versa. The application area 204 can interface with the application area 206 via a software API 244, an interrupt 246, and a shared memory area 248, and vice versa.

[0026] In some embodiments consistent with the subject matter of this application, platform 208 may be implemented in a Common Language Runtime (CLR), which is a virtual machine component of the .NET framework created by Microsoft Corporation of Redmont, Washington. In other embodiments, platform 208 may be implemented via other means.

[0027] System 200 is only an example. Other systems may cover more or fewer areas of application with components other than those described in Fig. 2 components shown.

[0028] The above-mentioned hardware components can each be a programmable device. The programmable device can be a processor for special applications, including, but is not limited to, a digital signal processor or a graphics processor. In other systems, the hardware components specified to be within the application areas can be, but are not limited to, a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0029] Fig. 3 is a diagram illustrating an exemplary FPGA-based application domain 300 executing on a platform. The FPGA-based application domain 300 may include a hardware component 304, which may be an FPGA. Because an FPGA may not have a software library, no software library is shown in the FPGA-based application domain 300. The FPGA-based application domain 300 may communicate with other components outside the application domain via a software API 306, an interrupt 308, an I / O bus 310, and a memory-mapped area 312.

[0030] The FPGA-based application area 300 is only exemplary. In other embodiments, an FPGA-based application area may have other types of interfaces than those described in Fig. 3, communicate with other components.

[0031] Fig. 4 illustrates a functional block diagram of an example application domain 400 executing on a platform. The platform may provide a programming language construct for specifying an abstracted hardware component 406. A class for accessing the hardware component 406 may be defined in a software library 403. An application 402 may create an instance of the class for accessing the hardware component 406. The instance of the class may provide a generic interface and may include one or more methods for transferring information to or from the hardware component 406.In other application areas, an instance may be created for a class for interfacing with a software component, and this class for interfacing with a software component may create a generic interface containing one or more methods for communicating with a software component.

[0032] The one or more methods for accessing the hardware component 406 may include proprietary code provided by the manufacturer of the hardware component 406 or a developer. The one or more methods may further include information, including, but not limited to, configuration information for the hardware component 406.

[0033] The code may be downloaded to the hardware component 406 using the generic interface 404. The code may include code for implementing functions in the hardware component 406. A developer of the code may create a class containing methods for calling the functions in the hardware component 406. The class containing the methods for calling the functions may be instantiated by the application 402, thereby creating a generic interface for calling the functions. As an example, the hardware component 406 may be a digital signal processor (DSP), and the downloaded code may include instructions for the DSP to operate as a video decoder.In this example, application 402 may call one function to forward encoded video to hardware component 406, and may call a second function to receive a decoded video image from hardware component 406.

[0034] Fig. 5 illustrates a functional block diagram including application space 502 and application space 504 executing on a platform 510. Application space 502 may include a software library 506, which may include one or more defined classes containing methods for accessing one or more hardware components. Application 508 may create an instance of a class from software library 506 for communicating with hardware component 512 specified to be located in application space 504. As a result of creating an instance of the class from software library 506 for communicating with hardware component 512, an instance of a generic interface, which in this example may include a proxy object 514, for communicating with hardware component 512 may be created in application space 504.Proxy object 514 may include methods, which may be stub functions, to provide a mechanism for invoking functions of hardware component 512 in application scope 504. The stub functions may invoke methods of an object or instance of a class in application scope 504 to communicate with hardware component 512 and cause a function to be executed. In this way, an application executing in one application scope may cause a function to be executed with respect to a hardware component defined as residing in another application scope. Example processes

[0035] Fig. 6 illustrates an exemplary process for specifying an application domain having an abstracted hardware component and accessing the hardware component. First, an application domain may be specified for an application on a platform using a programming language construct (step 602). The hardware interfaces to other application domains may be defined as properties of the application domain, as previously discussed (step 604). A class for accessing a hardware component may be specified (step 606). The class may, in some embodiments, be included in a software library. The application may create an instance of the class (step 608). The instance of the class may include methods for accessing the hardware component.The application can use the methods of the instanced class to communicate with or access the hardware component (step 610). If the hardware component is in the same application scope as the application, then the application can use the methods as previously described with reference to . Fig. 4. If the hardware component is located in a different application domain than the application, then the application can use the methods via a proxy object, as previously described with reference to Fig. 5 has been described.

[0036] Fig. 7 illustrates another example process for specifying an application domain having an abstracted hardware component, initializing the hardware component from the application, calling functions of the hardware component from the application, and deinitializing the hardware component from the application.

[0037] First, an application domain for an application on a platform may be specified using a programming language construct (step 702). The hardware interfaces to other application domains may be defined as the properties of the application domain, as previously discussed (step 704). A class for accessing a hardware component may be specified (step 706). The class may, in some embodiments, be specified in a software library. A class for calling functions of the hardware component may be specified (step 708). The application may create an instance of the class for accessing the hardware component (step 710).The instance of the class may contain methods for accessing the hardware component if the hardware component is contained in the same application scope as the application, or stumps for accessing an object in another application scope that has methods for accessing the hardware component if the hardware component is contained in the other application scope. Next, an instance of the class may be created to invoke the functions of the hardware component (step 712). The methods of the instance of the class may contain stumps in a proxy object for transferring a function call to an instance of a class in the other application scope that contains the hardware component, or the instance of the class may contain methods for invoking functions of the hardware component if the application and the hardware component are in the same application scope.The application may initialize the hardware component using methods of the instance of the class for accessing the hardware component to download information about the hardware component. The information may include code or configuration information in a binary file or code for the hardware component to perform functions (step 714). Of course, the information may be downloaded to the hardware component at a later time, such as during runtime. The application may use the methods of the instance of the class to cause the hardware component to perform the functions (step 716). The application may then use a method to notify the hardware component, deinitialize it, and release any resources used by the hardware component (step 718).

[0038] Embodiments consistent with the subject matter of this disclosure provide a consistent method for users, such as programmers, to specify application domains, hardware components, and software components so that applications can access hardware components, invoke functions, and access software components in a consistent and well-defined manner in a managed code environment. conclusion

[0039] Although the subject matter has been described in language specific to the structural features and / or methodological steps, it is to be understood that the subject matter in the appended claims is not necessarily limited to the specific features or steps described above. Instead, the specific features and steps described above are disclosed as example forms for implementing the claims.

[0040] Although the above descriptions may include specific details, they are not to be construed as limiting the claims in any way. Other configurations of the described embodiments are within the scope of this disclosure. Furthermore, implementations consistent with the subject matter of this disclosure may include more or fewer steps than those described with respect to the Fig. 6 and Fig. 7, or they may implement the steps in a different order than that shown. Accordingly, rather than any specific examples given, the appended claims define the invention.

Claims

[1] A machine-implemented method for providing a hardware abstraction for an application executing in an embedded system environment, the machine-implemented method comprising: Creating a platform (208, 510) for executing an application (402, 508) in a managed code environment in a first application domain (202, 204, 206, 300, 400, 502); and Creating a method for specifying a second application domain (202, 204, 206, 504) abstracting a hardware device (406, 512) by the platform so that the hardware device can be accessed by the application via a generic interface, the application being executed in the managed code environment in the first application domain, the method further comprising: Isolating the first and second application areas from other application areas by providing a software system partitioned into a plurality of independent applications with fixed public interfaces and blocking other accesses among the application areas. [2] Machine-implemented method according to claim 1, characterized by that the hardware device includes a processor for special applications. [3] Machine-implemented method according to claim 1, characterized by that the hardware device comprises a digital signal processor, a graphics processing unit, a field-programmable gate array, or an application-specific integrated circuit. [4] Machine-implemented method according to claim 1, characterized by that it includes: Enforcement of managed code characteristics by the platform for the application running in the managed code environment. [5] Machine-implemented method according to claim 4, characterized by that the features of the managed code include code access security, code verification, validation of non-functional constraints, and application domain isolation. [6] Machine-implemented method according to claim 1, characterized by that it includes: Downloading a binary file to the hardware by the application running in the managed code environment. [7] Machine-implemented method according to claim 1, characterized by that it includes: Accessing the hardware device from the application running in the managed code environment. [8] Tangible machine-readable medium (130, 140, 150), characterized by that it comprises the instructions for at least one processor (120) to execute the machine-implemented method according to any one of claims 1-7. [9] System (200), which includes: a platform (208,510) for executing an application (402, 508) in a managed code environment in a first application domain (202, 204, 206, 300, 400, 502); and a second application area (202, 204, 206, 504) that abstracts a hardware device (406, 512) so that the hardware device can be accessed via a generic interface by the application executing in the managed code environment in the first application area, wherein the first and second application areas are isolated from other application areas by providing a software system partitioned into a plurality of independent applications with fixed public interfaces and blocking other accesses among the application areas. [10] System according to claim 9, characterized by , that: the first application area or the second application area contains at least one hardware interface that is specified as an application area property. [11] System according to claim 10, characterized by that the at least one hardware interface comprises at least one memory area, a hardware interrupt or an input / output bus. [12] System according to claim 9, characterized by that the hardware device contains a programmable device. [13] System according to claim 12, characterized by that the programmable device contains a digital signal processor or a graphics processing unit. [14] System according to claim 9, characterized by , that: the platform enforces managed code features for the application, and the managed code features include code access security, code verification, non-functional constraint validation, and application domain isolation.

Images