GB2471485A

GB2471485A - Software modules for interfacing between a single client interface and hardware components of a computing device.

Info

Publication number: GB2471485A
Application number: GB0911344A
Authority: GB
Inventors: Richard Fitzgerald
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2009-06-30
Filing date: 2009-06-30
Publication date: 2011-01-05
Also published as: GB0911344D0

Abstract

Disclosed is a method of abstracting a function common to a plurality of hardware components in a device is by means of software modules. Each software module implementing instructions necessary to access the function on the corresponding hardware components. A single common interface is provided so that clients may access the function on any one of the hardware components through the common interface. The function may be an input/output, interrupt and wakeup call. The hardware components may be pins for receiving and emitting signals with the modules having pin mapping and instructions for addressing a group of pins. Each type of hardware component may have its own corresponding virtual port. The interface and instruction may be implemented by a device manager using a dynamic link library. The hardware components may be a bus and other items connected to the bus.

Description

APPARATUS AND METHOD FOR FACILITATING

COMMUNICATION BETWEEN HARDWARE AND SOFTWARE

BACKGROUND

Embodiments of the invention relate to computing devices and to the facilitation of communication between software and hardware computing in computing devices.

Computing devices generally comprise a number of hardware components which provide various functionality and software components which interact with the hardware components to allow a user to utilise the functionality provided by the hardware components. The user interacts with user applications which, by way of regulation by an operating system on the computing device, provide input to, and receive output from, the hardware device. Device drivers facilitate the communication between the user application and the hardware components by providing instructions accessible by the user application by means of the operating system.

SUMMARY OF EMBODIMENTS OF THE INVENTION

An embodiment of the invention provides a method comprising: providing a plurality of software modules, wherein each software module corresponds to a hardware component in a computing device; specifying for each module a set of instructions to implement at least *:::: 20 one predetermined function for said corresponding hardware component; providing a single interface to said modules; and *** .* allowing one or more clients to access said predetermined function on *.** * : : any one of said corresponding hardware components through said interface, by means of said modules. S. ** S * I I

I

At least two of said modules may correspond to hardware components of different types The method may further comprise providing said single interface as a common application programming interface.

In an embodiment, each of a plurality of said hardware components comprises a pin for receiving andlor emitting electrical signals and, in this embodiment, modules may comprise one or more pin mappings for said pins. In particular, said modules may include instructions for addressing a group of pins.

The group of pins may be addressed by specifying a range of pin addresses or by addressing each pin individually.

In a further embodiment, at least two of said hardware devices are of different types and, in this instance, the interface includes at least two virtual ports so that each hardware device of a different type has a corresponding virtual port.

At least one of the modules may correspond to a plurality of hardware devices, each of the plurality of hardware devices being of the same type.

The predetermined function may be one or more of: input and output, interrupt or wakeup call.

If the predetermined function is input and output, the modules may include get,

set and direction specification instructions.

In an embodiment, the modules include instructions to specify one or more of: an interrupt signal generated at, or by, a pin; a signal state which will generate an interrupt instruction; and implementation of at least one interrupt.

If the predetermined function is wakeup call and, the modules may include instructions for disabling one or more interrupts.

At least one of said hardware components may comprise a bus and a first and a second hardware component connected to said device via the bus and, in this instance, the method includes providing a bus module corresponding to the bus, a first module corresponding to said first hardware component and a second module corresponding to said second hardware module and a client access to one of said fist and second hardware components comprises use of said bus module and said corresponding first or second module.

The interface and the instructions may be implemented in a dynamic link library.

Alternatively, the interface and the modules are implemented by a device manager.

The method may include the step of combining two or more modules to provide access to two or more hardware components. In this embodiment, at least one of the hardware components may be a bus.

A further embodiment of the invention provides a plurality of software modules, each software module corresponding to at least one of a plurality of hardware components in a computing device; each module comprising a set of instructions to implement at least one predetermined function for said corresponding hardware component; a single interface to said modules; and said interface and said modules being adapted to allow one or more clients to access said predetermined function on any one of said plurality of hardware components.

A further embodiment of the invention provides a processor for a computing device connected to a memory device, said memory device storing instructions, said processor being configured to operate according to said instructions to: provide a plurality of software modules, wherein each software module corresponds to at least one of a plurality of hardware components in said computing device; specify for each module a set of instructions to implement at least one predetermined function for said corresponding hardware component; provide a single interface to said modules; and allow one or more clients to access said predetermined function on any one of said plurality of hardware components through said interface, by means of said modules.

The clients may be one or more user applications andlor system software operating on said computing device.

Embodiments of the invention abstract a function common to a plurality of hardware components in a hardware device by means of a plurality of software modules, each software module implementing instructions necessary to access the function on one or more corresponding hardware devices. A common interface is provided so that clients may access the function on any one of the hardware devices through the common interface. The function may be one or more of: input/output, interrupt and wakeup call.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are hereinafter described with reference to the accompanying diagrams where: Figure 1 is a schematic representation of a mobile computing device wherein embodiments of the invention are implemented; Figure 2 is a schematic diagram illustrating the arrangement of hardware components of the telecommunications device of Figure 1; Figure 3 is a schematic diagram illustrating the arrangement of hardware and software components of a known mobile computing device; Figure 4 is a schematic diagram illustrating the arrangement of hardware and software components of a the mobile computing device of Figure 1: Figure 5 is a schematic representation of selected hardware and software elements of the mobile computing device of Figure 1; Figure 6 is flow diagram illustrating a process according to an embodiment of the invention; and Figure 7 is a schematic representation of selected hardware and software elements of an embodiment of the invention.

DESCRIPTION OF EMBODIMENTS

A description of a number of embodiments of the invention follows, provided by way of example only.

Figure 1 is a schematic diagram of a telecommunications device 10 having a casing 12. The telecommunication device 10 forms the basis of the embodiments to be described. The casing 12 of the device 10 encapsulates a keypad 14, a display 16, a speaker 18 and a microphone 20. The device 10 further includes an antenna 22. The device 10 illustrated in Figure 1 is a mobile device in that it may be held in a user's hand and used to participate in communication sessions, in particular, telephone calls.

During such sessions the device 10 may be utilised so that the speaker 18 is held to a user's ear and the microphone 20 is situated in proximity to a user's mouth.

Figure 2 is a schematic illustration showing the arrangement of certain of the hardware components of the device 10 of Figure 1. The keypad 14, display 16, speaker 18 and microphone 20 shown in Figure 1 are connected to a peripheral bus 42. Also provided is an 12C (Inter-Integrated Circuit) bus 52 to which an analogue to digital (ADC) converter 48 and a digital to analogue converter 50 are connected.

The computing device 10 further comprises a system bus 44 to which two UARTs (universal asynchronous receiver/transmitters) 54 and 56 are connected.

Further connected to bus 44 are: an application processor 24, a baseband processor 26, a general purpose input/output (GPIO) port 58 and a memory controller 32. The memory controller 32 is, in turn, connected to a volatile memory 34 and a non-volatile memory 36.

In the embodiment illustrated, UART1 54, UART2 56, application processor 24, GPIO 58, baseband processor 26 and memory controller 32 are provided on a single integrated circuit, as illustrated by dashed box 46. System bus 44 is provided by the integrated circuit 46, and this integrated circuit is in communication with peripheral bus 42 and the 12C bus 52 The application processor 24 processes instructions related to various software components which operate on the device 10 and which provide user access to, and regulation of, the device 10, as described in greater detail below.

Memory controller 32 controls the access to, and interaction with, volatile memory 34 and non-volatile memory 36. In this manner the application processor 24 is able to communicate with the various hardware components as well as the memory controller 32 and thereby control the operation of the various hardware components according to software instructions stored on volatile memory 34 or non-volatile memory 36.

Figure 3 is a diagram illustrating various hardware and software components of a known device 10'. The computing device 10' comprises hardware components similar to those illustrated in Figures 1 and 2 and where appropriate, similar components are denoted by similar reference numbers. The software operating on the device 10' can be categorised in various ways. Certain software operates to manage the resources provided by the various hardware components and to establish an operational environment in which other software executes. This software is known as the operating system of the device and is represented in Figure 3 by a kernel 70'. The kernel interacts with the memory controller 32' which, in common with the device 10 of Figures 1 and 2, is connected to volatile memory 34' and non-volatile memory 36'. The kernel 70' is further connected to a plurality of user programs 45' each of which may access the hardware components in a manner dictated by the kernel 70'.

Figure 3 illustrates a known arrangement where interaction between the user programs 45' and hardware components of the computing device are controlled and facilitated by means of device drivers. The kernel 70' is connected to UART1 54' and UART2 56' by device driver 64'; to GPIO 58' by device driver 66', to an LCD controller 54' (which forms part of the display 16' and provides, among other functions, control of the brightness of the display 16') by a collection of device drivers 74', and to the 12C bus 52' by a collection of device drivers 72'. The collections of device drivers 72' and 74' include instructions for the user programs 45' to access the LCD controller 54' and ADC 48' and DAC 50' provided on respective peripheral bus 42' and 12C bus 52'. In certain circumstances, a device driver is needed to access the bus and another to access the hardware device connected via that bus.

Only certain of the hardware components have been illustrated but, generally, the kernel 70' controls the hardware resources of the device 10' through device drivers.

Furthermore, although the device drivers have been illustrated as separate to the kernel 70', it is possible for them to be incorporated into the kernel 70'.

The software components of Figure 3 are delineated by dashed area 82'.

During operation of the device, software instructions stored in non-volatile memory 36' establish the kernel 70', the user programs 45' and the device drivers 64', 66', 72' and 74'. Through the use of the various components illustrated in Figure 3 a user is able to utilise the device 10 according to the functionality provided by the various user programs 45'. For example, a user uses the keypad 14' to communicate with the kernel 70' by means of a corresponding device driver (not shown) to cause one of the user programs 45' to access data stored on non-volatile memory 36' by means of memory controller 32'. The kernel 70' causes the data supplied by memory controller 32', together with instructions supplied by the user program, to be sent to the application processor 24' (Figure 2). The application processor 24' will generate results from the data and instructions, generally utilising volatile memory 34' in the process, and these will be returned to the user program by the kernel 70'. On further instructions from the user program, the kernel 70' will cause the results to be displayed to the user on display 16' by means of a suitable device driver (not shown). It is to be realised that device drivers are generally also software components originating from instructions stored on non-volatile memory 36'.

The computing devices 10 and 10' include hardware components additional to those illustrated in Figures ito 3, but these are well known in the art and are not further described herein.

Figure 4 is a schematic representation of the arrangement of software and hardware components in the computing device 10 according to an embodiment of the invention. It will be noted that the arrangement of the computing device 100 of Figure 4 is similar to that of Figure 3: kernel 70 is connected to user programs 45 and memory controller 32. Memory controller 32 is connected to non-volatile memory 36 and volatile memory 34.

Further connected to kernel 70 is a mapping DLL 80 which is connected to UART 1 54, UART 2 56, GPIO 58, peripheral bus device driver 38 and 12C bus device driver 62. The peripheral bus driver 38 is connected to the peripheral bus 42 which is, in turn, connected to LCD controller 54. The 12C bus device driver 62 is connected to the 12C bus 52 which is connected to the ADC 48 and the DAC 50. The arrangement of Figure 4 differs from that in Figure 3 in that mapping DLL 80 provides certain accesses and control for the user applications 45 of the computing device 10 of the hardware components.

The software components of Figure 4 are delineated by dashed area 82.

However, this distinction between software and hardware is not essential. Components depicted as software in Figure 4 may be rendered in hardware, and those depicted as hardware may be rendered as software, in certain circumstances.

In the embodiment illustrated in Figure 4, the mapping DLL 80 performs certain of the functions of controlling and interacting with the connected hardware devices which were previously performed by the device drivers. In the embodiment illustrated, the mapping DLL performs the input and output to the hardware components and provides a single interface to the user programs 45. The representation of Figure 4 relates specifically to the input and output of the illustrated hardware components. As such it is to be realised that other functionality provided by the hardware components may be accessed by the kernel 70 by means of device drivers in the form illustrated in Figure 3.

Figure 5 is a representation of selected hardware and software elements of the mobile computing device of Figure 1. Mapping DLL 80 provides an interface 100 and a translation component 102. The interface 100 provides a series of ports: port 0 110, port 1112, port2 114, port 3 116, port 4 118 and port 5 120.

These ports are provided as virtual ports through which user applications address the corresponding hardware components. Virtual ports provide a convenient address structure. In particular, where input and output are concerned, the client applications need only know the port at which the required hardware component resides. In an embodiment of the invention, the mapping DLL 80 provides a look up table so that client applications are able to discern the correct port to address.

The translation component 102 provides a series of instruction sets. Each of the instruction sets of the translation component 102 correspond to one of the ports provided by the interface 100. Therefore instruction set 122 corresponds to port 0, instruction set 124 corresponds to port 1, instruction set 126 corresponds to port 2, instruction set 128 corresponds to port 3, instruction set 130 corresponds to port 4 and instruction set 132 corresponds to port 5.

In embodiments of the invention, the instruction sets referred to above are provided as modules. A module may comprise one or more instruction sets and, during operation, the mapping DLL 80 may compile modules comprising sets of instructions which are subsets or compilations of the sets illustrated.

The translation component 102 is connected to hardware components and in this manner the mapping DLL 80 interacts with the hardware components. Each instruction set of the translation component interacts with one of the illustrated hardware components. Therefore instruction set 122 interacts with UART 1 54, instruction set 124 interacts with UART 2 56, instruction set 126 interacts with GPIO 58, instruction set 128 interacts with peripheral bus 42 and, through this bus, with the LCD controller 54. Instruction sets 130 and 132 interact with the 12C bus 52 and thereby with the ADC 48 and the DAC 50.

In this embodiment, the instructions sets of the translation component provide instructions for the user applications 45 (Figure 4) to provide input to, and receive output from, the corresponding hardware components. This is done by providing a pin mapping within the instruction set used in conjunction with a hardware component.

The port corresponding to a hardware component is addressed by the client application, the mapping DLL 80 then implements the instruction set corresponding to that port and translates the inputloutput for that hardware component according to that instructions set. This process is discussed below in greater detail below with reference to Figure 6.

Figure 6 illustrates a process 200 whereby the mapping DLL 80 deals with client requests when the client request is received, processed, passed to the correct hardware component and the response passed back to the client which initiated the request. The mapping DLL is loaded on startup of the computing device 10 and, on being loaded, loads the instructions sets for all non-removable hardware. For removable hardware, the instruction sets corresponding to the hardware component are loaded when the hardware component is installed, and unloaded when the component is removed.

The process 200 of Figure 6 is initiated at block 202 where the client request is received by the mapping DLL 80. The client request specifies the port for the hardware component being addressed and specifies a function to be performed. The interface is provided in the form of an application programming interface (API) so that each port may be addressed in a manner appropriate to the inputioutput of the corresponding hardware component. Therefore, the client request received in block 202 will only be valid if it conforms to the API of the interface 100.

Embodiments of the invention provide abstraction of functionality common to certain hardware components in a manner which is configurable as new modules (or instruction sets) may be added when new functionality is available (either through the addition of new hardware components, or by expanding the scope of the role of the mapping DLL in the regulation of existing hardware components).

Furthermore, embodiments of the invention avoid the need for duplication of software components by, inter alia, providing a common interface and modules which may be used in conjunction with one another.

At the following step 204, a determination is made as to whether the client request is properly formatted, if the corresponding hardware component is available and any other errors are processed. If a fatal error occurs, the process proceeds to block 220 where the errors are dealt with by, where appropriate, returning an error message to the requesting client or performing other error handing routines. The process will then terminate at block 218.

If no error occurs, or the error is not fatal, the process will proceed from block 204 to block 206 where the instruction set corresponding to the hardware component specified by the client request is referenced and loaded, if not previously loaded. The instruction set specifies instructions to translate the client request into a format which can be forwarded to the necessary hardware component. Therefore, in block 208 the necessary translation is performed and, at block 210, the translated request is forwarded to the specified hardware component.

At block 212, the mapping DLL 80 receives the response from the hardware component. Any necessary translation for the response is performed at block 214 and the response is forwarded to the client at 216. The process then terminates at 218.

It is to be realised that there are number of ways in which the instruction sets may be implemented. By way of example, the API of the interface 100 which treats all the ports as a number of separate pins with get, set and direction control. The required pins are then accessed by accessing the correct pin and specifying the get, set and direction control.

Therefore, each client request need only specify the get, set and direction control as enumerated types and there is no requirement for the clients to be aware of the hardware specifics for each component. This provides a standardised manner in which hardware input and output may be implemented thereby reducing the complexity of implementing client requests.

Furthermore, errors in the device are minimised where enumerated types are used for the client requests there is less chance of confusion when compared, for

example, to the specification of pin numbers.

A further advantage is that the instructions sets are provided as modules and therefore the set for a particular hardware component may be combined with those of other hardware components to co-operate.

As illustrated in Figure 5, port 0 corresponds to UART 1 54 and port 1 corresponds to UART 2 56. In an alternative embodiment, a single port maps to both UARTs and, in this instance, the different UARTs may be addressed by specifying the port and a unit number, where UART 1 is assigned as unit 1 and UART 2 is assigned as unit 2. This takes advantage of the fact that the instruction set for each hardware type is the same. Any other similar hardware components may be dealt with in the same manner.

Figure 7 is a schematic representation of selected hardware and software elements of an embodiment of the invention.. The arrangement of Figure 7 is similar to that of Figure 5 and like numerals are used to denote like components. The arrangement of Figure 7 differs from that of Figure 5 in that the mapping DLL 180 includes interface 190 and translation component 192. The interface 190 includes port 4 160 and port 5 162 which provide addresses for interaction with the ADC 48 and DAC 50. The translation component 150 includes instruction set 152 corresponding to port 4 160, instruction set 154 corresponding to port 5 and 12C bus instruction set 158.

instruction set 152, instruction set 154 and 12C bus instruction set 158 are each modules which from an 12C collection 150.

As both the ADC 48 and DAC 50 are connected to the 12C bus, client requests for both of these hardware components utilise the 12C instruction set 158. Therefore, a client request addressed to port 4, intended for the ADC 48 will be translated through use of instruction set 152 corresponding to port 4, as well as the 12C instruction set 158.

Similarly, a client request addressed to port 5, intended for the DAC 50 will be translated through use of instruction set 154 corresponding to port 5, as well as the 12C instruction set 158.

In this manner the modules provided by the instruction sets of the 12C collection may be combined as required to service client requests for the ADC 48 and the DAC 50 connected to 12C bus 52. Similarly, translations for any other hardware components connected to the 12C bus 52 may be implemented in this manner.

By using a modular approach, translations may be easily performed for a variety of hardware components where the necessary modules are combined to provide the required functionality in a manner which is transparent to the user applications. This simplifies the development of the user applications.

In the aforementioned embodiments, the example of implementing input and output functionality is described. Further embodiments of the invention relate to abstracting other functions of hardware devices. It is to be realised that any functionality shared by two or more hardware components may be implemented by means of appropriate instructions sets provided in the mapping DLL 80.

In a further embodiment, the mapping DLL includes instructions to translate hardware interrupts for the hardware components. In this instance, instructions are provided for each hardware component concerned to allow translation for the interrupt signal generated by the input/output line concerned, the signal state which will generate that interrupt (e.g. high or low signal) and the implementation of the interrupt (which relates to how the interrupt signal is generated and how this is handled by software).

In a yet further embodiment, wake up calls may be abstracted in a similar manner. In this embodiment, the instruction set concerned differentiates between interrupts which are intended to change the power state of the hardware concerned and other interrupts. The other interrupts are ignored. The mapping DLL then translates wakeup calls from a user application to the correct hardware device to cause that hardware device to wake up.

For various implementations of the abstraction of hardware functionality, including those described above, the client request is translated and passed to pins on the hardware components. The manner in which this is done will depend on the functionality concerned and the hardware components concerned. In certain circumstances only a single pin on the hardware component need be addressed.

However, in other situations more than one pin on the hardware component are involved. In such circumstances a group of pins may be addressed by specifying a mask of pins or a range of pins may be referenced by specifying the start and end pins.

Alternatively, the group of pins may be addressed by having the instructions address each pin individually and then map each bit separately. This last-mentioned solution is more complex to implement but has the advantage that the translation of embodiments of the invention may be implemented for each hardware component in the device.

Furthermore, it is to be realised that in certain embodiments of the invention it is not necessary to use the virtual ports 110 to 120, specifically where all the hardware components being dealt with are of the same type.

In the aforegoing the operation of the embodiments has been described with reference to requests originating from clients described as user applications. However, the client request need not originate from user applications and embodiments of the invention are equally capable of handling requests originating from other software such as the kernel 70.

Furthermore, the implementation of the aforementioned embodiments, relies on the presence of the mapping DLL. It is to be realised that the mapping DLL may operate in conjunction with the known device driver/hardware component arrangement so that the functions of only certain of the hardware components on the device are dealt with the manner described above.

In further embodiments, a mapping DLL is not necessary and this functionality is provided by a driver manager. In this instance, the instruction sets are registered with the driver manager and the interface to which the client requests are addressed is provided by the driver manager. A driver manager has the advantage of being able to standardise all hardware communication within the device. Details of the implementation of a device driver manager which may be used in conjunction with embodiments of this invention are disclosed in co-pending application GB 0807508.7 filed 24 April 2008 in the name of Symbian Software Ltd. The illustrations of the accompanying Figures is presented merely by way of example; that known devices comprise more components than those shown.

Implementations of embodiments of the invention are not dependent on the precise arrangement and configuration of components shown in the Figures. Therefore other components with similar functionality may be substituted and further components added thereto or illustrated components omitted therefrom without affecting the operation of embodiments of the invention.

Embodiments of the invention have been described and illustrated with reference to a mobile computing device. However, further embodiments of the invention extend to computing devices which are not mobile.

Claims

Claims 1. A method comprising: providing a plurality of software modules, wherein each software module corresponds to a hardware component in a computing device; specifying for each module a set of instructions to implement at least one predetermined function for said corresponding hardware component; providing a single interface to said modules; and allowing one or more clients to access said predetermined function on any one of said corresponding hardware components through said interlace, by means of said modules.
2. The method according to claim 1 further comprising providing said single interface as a common application programming interface.
3. The method according to claim 1 or claim 2 wherein each of a plurality of said hardware components comprise a pin for receiving andlor emitting electrical signals and wherein said modules comprise one or more pin mappings for said pins.
4. The method according to claim 3 wherein said modules include instructions for addressing a group of pins.
5. The method according to any preceding claim wherein at least two of said hardware devices are of different types and wherein said interface includes at least two virtual ports so that each hardware device of a different type has a corresponding virtual port.
6. The method according to any preceding claim wherein at least one of said modules corresponds to a plurality of hardware devices, each of said plurality of hardware devices being of the same type.
7. The method according to any preceding claim wherein said predetermined function is one or more of: input and output, interrupt or wakeup call.
8. The method according to claim 7 wherein said predetermined function is input and output and wherein said modules include get. set and direction specification instructions.
9. The method according to claim 7 or claim 8 wherein said predetermined function is interrupt and wherein said modules include instructions to specify one or more of: an interrupt signal generated at, or by, a pin; a signal state which will generate an interrupt instruction; and implementation of at least one interrupt.
10. The method according to any one of claims 7 to 9 wherein said predetermined function is wakeup call and wherein said modules include instructions for disabling one or more interrupts.
11. The method according to any preceding claim wherein at least one of said hardware components comprises a bus and a first and a second hardware component connected to said device via said bus and wherein said method incEudes providing a bus module corresponding to said bus, a first module corresponding to said first hardware component and a second module corresponding to said second hardware module; and wherein a client access to one of said fist and second hardware components comprises use of said bus module and said corresponding first or second module.
12. The method according to any preceding claim wherein said interface and said instructions are implemented in a dynamic link library.
13. The method according to any one of claims 1 to 9 wherein said interface and said modules are implemented by a device manager.
14. A plurality of software modules, each software module corresponding to at least one of a plurality of hardware components in a computing device; each module comprising a set of instructions to implement at least one predetermined function for said corresponding hardware component; a single interface to said modules; and said interface and said modules being adapted to allow one or more clients to access said predetermined function on any one of said plurality of hardware components.
15. A processor for a computing device connected to a memory device, said memory device storing instructions, said processor being configured to operate according to said instructions to: provide a plurality of software modules, wherein each software module corresponds to at least one of a plurality of hardware components in said computing device; specify for each module a set of instructions to implement at least one predetermined function for said corresponding hardware component; provide a single interface to said modules; and allow one or more clients to access said predetermined function on any one of said plurality of hardware components through said interface, by means of said modules.