Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction

The VictoR Core Library will provide a standardized, user-friendly set of interfaces for interacting with the various services within an FN VictoR device without needing to reference an ICD to figure out the low-level details required for those interactions. To facilitate the development of those interfaces, a common Base Service Interface will be created with the intent of providing a common set of methods that utilize the device communication interfaces as well as any common data to be shared among any service interfaces that inherit from this base interface.

Requirements

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#4.-Device-Information-Service

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#5.-Device-Configuration-Service

https://unity3d.atlassian.net/wiki/spaces/FNUPEXT/pages/1584529409/Software+Requirements#6.-Object-Transfer-Service

Constraints

Performance

Read/Write calls to a VictoR device are time intensive I/O operations. The Service Interfaces should not block and force the end-user to wait for the operations to complete.

OS Abstraction

End-users should not have to directly interact with OS-specific APIs to communicate with a VictoR device. The Base Service Interface, and by extension all Derived Service Interfaces, should abstract away the OS-specific implementation details and only provide the end-user with the data that they are interested in.

Ease of Use

End-users should not have to operate on data in binary form. The Derived Service Interfaces should provide ordered, human-readable data structures that they will serialize into binary data when sending to a device, and deserialize binary data from when receiving from a device.

Detailed Design

The Service Interface will provide the common data required by all service interfaces, including the common portion of service and attribute UUIDs. It will also provide common functions that every derived service interface will need, such as the ability to read and write binary data to a particular device attribute using the device manager, and subscribing and unsubscribing from notifications of changes for a particular device attribute using the device manager. Derived service interfaces will maintain a mapping of all attributes relevant to that service to its underlying UUID, which will be used in conjunction with the provided read/write/subscribe/unsubscribe functions. All I/O operations to/from a VictoR device are performed in a non-blocking, asynchronous manner. In addition, the Service Interface provides end-users with the ability to set (and get) a Current Device, which is the device that will be used for communication if no device is specified in a read/write operation. This allows the end-user to just set the device once and perform any number of read/write operations on that device, without having to manually specify the same device for each call.

System Interaction

The sequence diagram below in figure 2 illustrates the typical sequence of events when an end-user’s application uses the SDK to retrieve data from a VictoR device. In this example, the end-user makes a call to the Device Information Service Interface to retrieve the Firmware Revision. This function has knowledge of which particular attribute ID this data corresponds to, and uses that information along with the provided device ID (if provided - otherwise it uses the Current Device ID) to call into the Service Interface. The Service Interface uses the Device Manager to retrieve the Device Interface that corresponds with the device ID, and then uses that Device Interface to request a read of the specified attribute from a VictoR Device over the underlying communications protocol (which is determined by the particular Device Interface that was constructed). This sequence of function calls is non-blocking, so that the end-user is not left blocked waiting for the device to respond with the data. Once the device has finished processing the request and the data has been successfully transmitted back to the Device Interface, it is propagated back down to the Device Information Service Interface in its serialized binary form. The original function used to retrieve the Firmware Revision contains logic to deserialize the the Firmware Revision from its binary form into an ordered Firmware Revision data structure that is then finally returned to the end-user.

Glossary

Term

Description

API

Application Programming Interface

ICD

Interface Control Document

I/O

Input/Output

OS

Operating System

  • No labels