Browse Prior Art Database

Methodology to Exchange Real Device Access by Device Simulation in Embedded Systems Disclosure Number: IPCOM000018954D
Original Publication Date: 2003-Aug-22
Included in the Prior Art Database: 2003-Aug-22
Document File: 4 page(s) / 18K

Publishing Venue



Accessing devices from an application creates a binding between the application and the device drivers, which makes it difficult to exchange the device driver implementation. This applies to the functional access as well as to the configuration of the device. The introduction of an Access Device Abstraction Layer separates the application from the device specifics and enables the use of different device driver versions including the support of simulated devices.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 31% of the total text.

Page 1 of 4

  Methodology to Exchange Real Device Access by Device Simulation in Embedded Systems

  An abstraction layer is disclosed which separates device access and management from the applications. This Access Device Abstraction Layer ADAL incorporates all functions necessary to configure a device and to request a device function. A device independent interface is provided to the application, which hides all device implementation details and offers only a functional view of the device. This enables the replacement of one kind of device implementation by another type or by a simulation version without affecting the application. This abstraction layer even allows some applications to use real device interfaces while others use simulated device interfaces simultaneously. This is especially useful when verifying the device hardware and it is desirable to limit the scope under test.

Application 1

Application 2

Application 3

Device 1

Device 1 Access 2

Device 1 Access 1


    If other device abstractions are provided, the Access Device Abstraction Layer is the lowest level of abstraction to hide the device interfaces and their control structures from the applications as well as the other abstraction layers. Another responsibility of the ADAL is to provide the locking mechanisms and policy for ensuring the atomic execution of a sequence of device accesses. An ADAL function uses the low-level operating services to access the device. All elements along the access path like hubs, buses, etc. are controlled within this layer. It is also responsible for handling device errors and ensures that all error data is retrieved from the device on a thread basis.

    This methodology allows the separation of the application test and verification from the availability of a working real device. It enables the developer to test the final version of the application program, because the differences in the device implementations are hidden inside the abstraction layer. This typically allows the developer to deliver better quality programs quicker, requires less time spent testing with the actual hardware and minimizes the possible constraint of availability of actual hardware.

    The Access Device Abstraction Layer provides a set of functional interfaces to the device instead of a generic control function. It is the only layer which knows

Device 2

Device 2 Access 1

Device 2 Access 2

Device 2 Access 3

Device 3

Device 3 Access 3

Device 3 Access 1

Device 2 Access 2Device 3Access 4


[This page contains 1 picture or other non-text object]

Page 2 of 4

the device name and performs the device access calls. Examples for ADAL functions might be:
read_i2c( ... )
write_uart( ... )
write_oppanel( ... )
turn_on_led( ... )
set_rpc( ... )
set_pin_high( ... )
read_jtag_reg( ... )

    The system can have multiple device paths to the same device type, e.g. a scannable chip can be attached to a JTAG device which is available in multiple chips. To distinguish between the different instances of a devic...