WO2006085282A2

WO2006085282A2 - Architecture for writing data to non-memory addressable embedded devices

Info

Publication number: WO2006085282A2
Application number: PCT/IB2006/050434
Authority: WO
Inventors: Armin Gerritsen
Original assignee: Nxp B.V.
Priority date: 2005-02-14
Filing date: 2006-02-09
Publication date: 2006-08-17
Also published as: WO2006085282A3

Abstract

The present invention relates to a driver architecture and method for enabling an application (10) to write data to a non-memory addressable embedded device wherein at least a portion of an addressable memory is allocated to the application (10) and a content written to the addressable memory space is flushed to a memory (30) of the non-memory addressable embedded device. The driver (20) will then flush at certain moments, either determined by the driver (20) itself or initiated by the application (10), the data from the virtual video memory to the real memory (30). Thereby, drivers for non-memory addressable display adapters are enabled to actively write to a display. As a result, the adaptors can be used in combination with any popular open source architecture.

Description

Architecture for writing data to non-memory addressable embedded devices

The present invention relates to a driver architecture and method for enabling an application to write data to a non-memory addressable embedded device, for example an embedded display device.

Operating systems, sometimes referred to as a kernel, typically include an element of software code known as a device driver. The term kernel is sometimes used to refer to the lowest level of the operating system. The device driver of the kernel typically resides in the lowest level of the operating system and provides the low level interfaces between hardware elements of the computer system and the operating system to direct the operation of the hardware elements of the computer system.

The interface function of the device driver provides the advantage that application programmes of the computer system are able to interface with the hardware without the necessity of making function calls that are specific to the hardware architecture of each model of computer system. Through function calls to the operating system or kernel application programmes may request certain action by the hardware resources of the computer system, including such hardware resources as the central processing unit (CPU), storage devices, memory, and input/output devices. Once such a function call is received by the operating system, the device driver of the operating system or kernel interfaces with the hardware resources of the computer system. The operating system communicates with the device driver of the computer system to request certain functions of the hardware of the computer system.

Open source operating systems, such as Linux, have come into more common use in computer systems. Open source software is characterized by freely available source code. In the case of an open source operating system, the source code of the operating system is accessible to users of the operating system. Computer system manufacturers are now offering the option of installing open source operating systems in computer systems, including service systems. As part of the open source operating system, the computer system manufacturer will typically include in the operating system package a device driver that is specific to the computer system model or family of the computer system models of the computer system manufacturer.

In the embedded world, the Linux frame buffer architecture becomes more and more popular. It allows direct data transfers to display adaptors by directly addressing the display memory of the display device. By transferring data into that memory, the data is automatically displayed. Normal frame buffers are used for display devices which have their own memory, which is direct accessible. Therefore, the frame buffer architecture is only written for these types of devices, which include for example AGP (Accelerated Graphics Port) and PCI (Peripheral Component Interconnect) video cards as used in personal computers for which the platform Linux was first written. In these devices, the video memory is accessible by applications as any normal piece of memory in the system. For instance, in case of a PCI video card, the video memory is mapped to a certain address range, for instance "0x4000000" as on some PCs. By writing to this address, the applications therefore directly write into the video memory causing the written image to be displayed immediately. It is intended to use open source operating systems such as Linux on small- embedded devices. Such devices may comprise for example liquid crystal display (LCD) devices as used for example in mobile phones. These display devices are designed for very low cost, low resolution and low power. This however requires that the embedded devices have their own memory, wherein however all address lines are removed to safe cost and pinning. Consequently, there is no support for directly accessing the memory in these embedded devices, and they can be called non-memory addressable devices. Special commands or serial transfers have to be used to update the memory of these non-memory addressable devices.

However, the frame buffer architecture of Linux requires that applications can directly access the memory. The standard conclusion in the Linux world would therefore be not to use the frame buffer architecture. Unfortunately, it is then no longer possible to use the large variety of applications which exists for the Linux frame buffer architecture.

It is therefore an object of the present invention to provide an architecture and method, by means of which a driver requiring an addressable memory can be used for accessing non-memory addressable embedded devices.

This object is achieved by a driver architecture as claim 1, a method as claimed in claim 10, and a computer programme product as claimed in claim 15. Accordingly, by allocating a piece of normal memory and presenting this to applications as an addressable memory, e.g. a frame buffer, applications assume that they can directly write into the memory of the non-memory addressable embedded device. As a result, non-memory addressable display adaptors can be used in combination with popular open source architectures, such as the Linux frame buffer architecture.

The non-memory addressable embedded device may be a display device with a video memory, wherein the allocated addressable memory space may be used as a frame buffer. Thereby, the Linux frame buffer architecture can be used in connection with small non-memory addressable display devices. The flushing operation may be performed at a timing determined by the application or, alternatively, at a timing determined by the driver architecture. Thereby, applications can notify the driver architecture after decoding data that they want to supply the data to the non-memory addressable embedded device.

The allocated addressable memory space may cover a portion of the memory of the non-memory addressable embedded device, wherein the flushing means is adapted to notify the non-memory addressable embedded device about which part of the memory is updated. This provides the advantage, that it is not necessary to detect which part of the frame buffer has been updated.

As an alternative option, the allocated addressable memory space may cover the full content of the memory of the non-memory addressable embedded device. In this case, flushing can be performed automatically at certain moments and the flush contains the whole memory of the embedded device.

Additionally, processing means may be provided for processing data written into the addressable memory space. Thereby, specific processings, such as color space conversion, data rotation, data translation, and solving of endian incompatibilities, can be performed prior or at least during the flushing operation. Thereby, common problems faced in embedded devices can be solved by using the proposed flush mechanism.

The proposed driver architecture can be implemented as a software architecture provided in the kernel space of a computer system, wherein code means are adapted to produce the method steps when run on a computer device of the computer system. The computer programme product may be downloaded from a network or may be stored on a computer readable medium such as an optical or magnetical disc.

Further advantageous developments are defined in the dependent claims. The present invention will now be described based on preferred embodiments with reference to the accompanying drawings in which:

Fig. 1 shows a schematic block diagram of a conventional Linux frame buffer architecture;

Fig. 2 shows a schematic block diagram of a flushing frame buffer driver architecture according to the preferred embodiments;

Fig. 3 shows a schematic block diagram of a flushing frame buffer driver architecture according to a first preferred embodiment; and Fig. 4 shows a schematic block diagram of a flushing frame buffer architecture according to a second preferred embodiment.

The preferred embodiments will now be described in connection with a Linux frame buffer architecture as a specific example of a general driver architecture in which the present invention can be implemented.

If graphic user interfaces (GUIs) such as MiniGUI or Micro Windows are used, LCD device drivers must be implemented as Linux Frame buffer device drivers in addition to those low level operations which only deal with commands provided by LCD controllers. The frame buffer device provides an abstraction for the graphics' hardware. It represents the frame buffer of some video hardware and allows application software to access the graphics' hardware through a well-defined interface, so the software doesn't need to know anything about the low- level issues, such as hardware registers or the like.

According to the preferred embodiments, very few modifications to the driver and the applications are necessary to use a popular frame buffer architecture, such as the Linux frame buffer architecture, in combination with display adaptors of non-memory addressable display devices for embedded systems, allowing the use of all existing software which exists for this architecture. The changes involve letting the driver for the non-memory addressable adapter play an active role in writing to the display. Initially, for a better understanding of the present invention, a conventional

Linux frame buffer architecture is described in connection with Fig. 1.

Fig. 1 shows a schematic block diagram of the Linus frame buffer architecture, wherein an application 10 accesses the video RAM (Random Access Memory) of a memory addressable embedded device via a conventional driver 20, wherein the conventional frame buffer driver 20 is only required for initialization and for situations where hardware settings need to be changed, such as changing the resolution. The application 10 however, can write directly to the video memory 30. The frame buffer driver 20 merely forwards memory addresses AD supplied by the application 10 to the video memory 30, where the corresponding memory cells addressed by the memory addresses AD are accessed.

Fig. 2 shows a flushing frame buffer architecture according to the preferred embodiments, as a solution for non-memory addressable situations. Here, the driver 20 actively flushes the application's data to the display adaptor of the video memory 30.

In connection with the present description, the term "flush" is used to describe any transfer of data from a temporary storage area to a more permanent memory, where the data is finally used. The data of the temporary storage area is transferred to the more permanent memory without requiring any external address designation concerning the destination or more permanent memory. Hence, an external application writing into the temporary storage does not need to have any information about an address range of the more permanent memory.

According to Fig. 2, the application 10 which may be any kind of user-based application can address a flush mechanism 22 provided in the frame buffer driver 20 by using a memory address AD as if a memory addressable adaptor would be provided in the kernel space for accessing the video memory 30. This can be achieved by having the operating system allocate a predetermined portion of a normal memory space of the computer system to the frame buffer driver 20, so that the display data transferred from the application 10 is written to the allocated memory space of the normal memory. Then, the flush mechanism 22 acts to flush the content of the allocated memory space to the video memory 30 of the non- addressable embedded display device. In the following, two specific implementation examples for the flush mechanism 22 are described in connection with first and second preferred embodiments. Fig. 3 shows a schematic block diagram of a first preferred embodiment, wherein the allocated memory space of the normal memory of the computer system covers only a portion of the whole video memory 30. In particular, the block diagram of Fig. 3 corresponds to a software architecture of the flushing frame buffer driver according to the first preferred embodiment.

The application 10 which can be allocated to the user space 100 of the software architecture provides control information CTRL to the frame buffer driver 20 and address information AD to a partial virtual video memory (RAM) 220, so that a memory- addressable data transfer can be initiated to the partial virtual video memory 220. Then, the frame buffer driver 20 provides synchronization information SYNC to a flush operation 222, based on which the flush operation 222 flushes the content of the partial virtual video memory 220 to the real video memory (RAM) 30, using the non-memory addressable display adaptor.

The components of the frame buffer driver 20, the partial virtual video memory 220, the flush operation 222 and the display adaptor can be allocated to the kernel space of the computer system.

By allocating a piece of normal memory and presenting this to the application 10 as the frame buffer, the application interprets the system as providing a memory- addressable video memory and can directly write to the real video memory 30. The frame buffer driver 20 will then initiate flushing procedures at predetermined moments which may either be determined by the frame buffer driver itself or which may be determined or initiated by the application 10 based on the control information CTRL, so that data from the partial virtual video memory 220 is transferred to the real video memory 30. As an example of such a control operation, the application 10 may be part of an MPEG (Moving Picture Expert Group) player which notifies the frame buffer driver 20 after decoding a frame, or a picture viewer which wants to display a picture.

Virtual buffer is thus transferred or allocated to the frame buffer driver 20, wherein the application 10 notifies the frame buffer driver 20 about which part of the real video memory 30 is being updated. The notification may be implemented by using RPC (Remote Procedure Calls) or writing to a specific memory address, etc. To achieve this, corresponding adjustments may be made at the application 10 and an extra data buffer may be provided at the application 10. The data transfer may be performed by using the following subroutine in pseudo C-code:

struct sizeinfo_t sizelnfo ; unsigned char *image ;

// Get a bitmap LoadBitmapToMemory ( &image) ;

// Define position where the image need to be placed sizelnfo.x = x coordinate ; sizelnfo.y = y coordinate ; sizelnfo.size = x coordinate * y coordinate * bitsPerPixel ;

// Copy bitmap to internal buffer in the frame buffer driver memcpy ( localMelodyBuffer, image, sizeOflmage) ;

// Tell our driver it needs to flush this buffer to the specified coordinates, ioctl ( FramebufferDriver, COMMAND FLUSH, &sizelnfo) ;

Fig. 4 shows a corresponding block diagram of a second preferred embodiment, in which an output-flush mechanism is provided for automatically flushing temporarily stored display data to the video memory 30 of the non-memory addressable embedded display device. In this case, a full virtual video memory 224 is allocated from the normal memory of the computer system to the frame buffer driver 20, wherein an automatic flush operation 226 is provided for flushing the temporarily stored data to the real video memory 30. The temporarily stored data is automatically flushed to the real video memory 30 at predetermined timings. In view of the fact that the virtual video memory 224 covers the whole content of the real video memory 30, higher memory requirements are required which lead to a decreased performance. However, in this case, the virtual video memory 224 can be accessed directly or transparently through the frame buffer driver 20, similar to the conventional access function of Fig. 1, wherein however the allocated virtual video memory 224 is accessed and not the real video memory 30. This leads to an easier development of application software and prevents possible use of local intermediate buffers at the application side.

Furthermore, as it is impossible to easily detect the part of the virtual video memory 224, which has been updated, the flushing procedure should cover the whole content of the virtual frame buffer 224 and thus of the real video memory 30. Due to possible limitations of the bandwidth, the maximum frame rate will be limited, which will result in a lower update-rate. However, depending on the case of use, this may be acceptable. It could for instance be decided that for applications such as a web browser, an update of a predetermined reduced number of frames per second may be fast enough. The advantage is however that no limitations exist on the method of the data transfer between the application 10 and the frame buffer driver 20. One could in this case, for instance also use RPC calls in the frame buffer driver 20 instead of memory copies.

The automatic flushing procedure may be initiated at a fixed or programmable rate, for instance via an ioctl instruction as defined in Linux.

Using the above described flush mechanisms of the first and second preferred embodiments is also very useful as an aid in solving other problems of embedded devices. For example, data may need to be post-processed after the application 10 has written it into the virtual frame buffer, e.g. the partial or full virtual video memory 220, 224. Such a post- processing may include color space conversion, rotating or translating data and solving endian incompatibilities between the embedded system and the display adapter. These actions can be performed prior or at least during the flushing procedure.

Especially the problem of endian fixing is a serious problem in some embedded systems. Sometimes the endianess of the display adaptor is different from the rest of the system. In such cases, bytes must be swapped. The normal frame buffer architecture cannot handle this processing and thus requires serious changes to the application 10. These changes can be prevented if the endian processing can be provided by the frame buffer driver 20 in connection with the flushing procedure.

In summary, a driver architecture and method have been described for enabling an application 10 to write data to a non-memory addressable embedded device wherein at least a portion of an addressable memory is allocated to the application 10 and a content written to the addressable memory space is flushed to a memory 30 of the non- memory addressable embedded device. The driver 20 will then flush at certain moments, either determined by the driver 20 itself or initiated by the application 10, the data from the virtual video memory to the real memory 30. Thereby, drivers for non-memory addressable display adapters are enabled to actively write to a display. As a result, the adaptors can be used in combination with any popular open source architecture.

It is noted that the present invention is not restricted to the above-preferred embodiments but can be used in connection with any system where a non-memory addressable embedded device must be accessed by an application to thereby enable use of the embedded devices in combination with popular open source architectures.

Finally but yet importantly, it is noted that the term "comprising" when used in the specification including the claims is intended to specify the presence of stated features, means, steps or components, but does not exclude the presence or addition of one or more other features, means, steps, components or groups thereof. Further, the word "a" or "an" preceding an element in a claim does not exclude the presence of a plurality of such elements. Moreover, any reference sign does not limit the scope of the claims.

Claims

CLAIMS:

1. A driver architecture for enabling an application (10) to write data to a non- memory addressable embedded device, said architecture comprising: allocating means (20) for allocating at least a portion (220; 224) of an addressable memory to said application (10) as an addressable memory space; and - flushing means (22) for flushing a content written to said addressable memory space to a memory (30) of said non-memory addressable embedded device.

2. An architecture according to claim 1, wherein said allocated addressable memory space is used as a frame buffer, and said memory (30) is a video memory.

3. An architecture according to claim 1 or 2, wherein said flushing means (22) is arranged to perform said flushing at a timing determined by said application (10).

4. An architecture according to any claim 1 or 2, wherein said flushing means (22) is arranged to perform said flushing at a timing determined by said driver architecture.

5. An application according to any one of the preceding claims, wherein said allocated addressable memory space covers a portion of said memory (30) of said non- memory addressable embedded device, and wherein said flushing means (22) is adapted to notify said non-memory addressable embedded device about which part of the memory (30) is updated.

6. An architecture according to any one of claims 1 to 4, wherein said allocated addressable memory space covers the full content of said memory (30).

7. An architecture according to any one of the preceding claims, further comprising processing means for processing data written into said addressable memory space.

8. An architecture according to claim 7, wherein said processing means is arranged to perform said processing prior or at least during said flushing of said flushing means (22).

9. An architecture according to claim 7 or 8, wherein said processing comprises at least one of color space conversion, rotating data, translating data, and solving endian incompabilities.

10. A method for enabling application (10) to write data to a non-memory addressable embedded device, said method comprising the steps of: allocating at least a portion (220; 224) of an addressable memory to said application (10) as an addressable memory space; and flushing a content written to said addressable memory space to a memory (30) of said non-memory addressable embedded device.

11. A method according to claim 10, wherein said flushing step is performed at a timing determined by said application (10).

12. A method according to claim 10 or 11, wherein said flushing step is performed at a timing determined by said driver architecture.

13. A method according to any one of claims 10 to 12, further comprising the step of notifying said non-memory addressable embedded device about which part of the memory (30) is updated.

14. A method according to any one of claims 10 to 13, further comprising a step of processing data written to said addressable memory space prior or at least during said flushing step.

15. A computer programme product comprising code means adapted to produce the steps of any one of method claims 10 to 14 when run on a computer device.

16. A computer readable medium storing a computer programme product as claimed in claim 15.