VxWorks Device Driver Port

Contents

  1. Project Overview
  2. Project Constraints
  3. Deliverables and Acceptance Testing
  4. Legal / Licensing
  5. Bid Process & Questions

Project Overview

This task is to port an existing C/C++ USB device driver to VxWorks (ideally version 6.9). The port would conceptually involve two main tasks:

1. Build Current Code Under VxWorks

First, the existing ANSI C++ code might require minor modifications to build under Wind River Workbench (ideally version 3.3). These modifications would be expected to include a few changes to #includes, possibly a few #define macros, and the like - preferably bracketed by consistent #ifdef VXWORKS / #endif symbols or similar.

Appropriate build files would also be required, whether as Makefiles, Ant build.xml, or whatever format is most commonly used by Wind River Workbench.

This portion of the port is not expected to be very difficult, as the existing code is fairly well-structured and already builds out-of-the box on several versions of Linux (GCC), MacOS (GCC), and Windows (Visual Studio 2005-2012).

For scale, the current codebase is 20 KSLOC (per sloccount) spread over 235 h/cpp classes. However, every .cpp #includes a common "globals.h" before anything else, allowing straightforward distribution-wide transformations.

2. Provide Native VxWorks USB Implementation

The second part of the port involves more meat. The device driver is architected to encapsulate all USB operations through calls to a single high-level interface, represented by the C header file NativeUSB.h. This file simplifies USB communication into 10 function calls (conceptually probe, open, close, read, write, and some trivial gettors).

The codebase already includes working implementations of this interface for Linux (using libusb-0.1), MacOS (also libusb), and Windows (using WinUSB.sys). The core of this project is to provide a VxWorks implementation for the NativeUSB.h interface.

The implementation should be written in C, compile in VxWorks Workbench (ideally version 3.3), and run under VxWorks (ideally version 6.9). The three existing implementations require an average 400-700 SLOC each (per sloccount), so this is a reasonable estimate of the amount of new code required to be written for this project.

We expect that this implementation will be created by calling into the existing VxWorks library calls such as these. However, we are happy to receive alternate proposals from experienced VxWorks USB developers.

Essentially:

-rw-rw-r-- 1 mzieg staff      7383 May 21 08:44 include/native/usb/NativeUSB.h            <--we have this
-rw-rw-r-- 1 mzieg staff     21645 May 21 08:44 src/native/usb/linux/NativeUSBLinux.c     <--we have this 
-rw-rw-r-- 1 mzieg staff     34551 May 21 08:44 src/native/usb/osx/NativeUSBMacOSX.c      <--we have this
-rw-rw-r-- 1 mzieg staff     27793 May 21 08:44 src/native/usb/winusb/NativeUSBWinUSB.c   <--we have this
-rw-rw-r-- 1 you   contract    ??? Summer 2013  src/native/usb/vxworks/NativeUSBVxWorks.c <--we need this

The delivered port will ultimately be built under different versions of VxWorks on different hardware platforms, and we do not expect that bidders should anticipate or test every possible deployment environment. As long as satisfactory performance is demonstrated on one current or near-current environment, we can provide maintenance and testing from there (or solicit follow-on contracts for desired updates).

Project Constraints
  1. Utilization of open-source libraries is allowed and encouraged. We would prefer not to encumber a per-seat license cost.
  2. No GPL or other "viral" licenses are acceptable (LGPL is fine).
  3. The resulting product will be used in a variety of commercial markets, so the solution may not utilize licenses which are restrictive of commercial deployment in any way.
  4. The code should not contain any memory leaks. The interface implementation should be performant and allow many thousands of repeated calls without showing growth in the stack or heap over time (confirmed with valgrind or similar).
  5. It is expected that the generated source code will follow reasonable readability and maintainability guidelines. No specific style-guide requirements are imposed, but consistent indentation, logical encapsulation, and block comments are expected.

Deliverables and Acceptance Testing

The contractor's deliverable to us will be a modified version of the original codebase which we initially provide to you. We will provision a secure DropBox for file exchange; due to the proprietary nature of some files, public repositories such as GitHub may not be used. Incremental "work-in-progress" snapshot deliveries would be appreciated on a weekly basis to provide demonstrated progress.

We will provide a sample USB device (a simple spectrometer, returnable to us at the end of the project) which you can use for final testing. Successful project completion will be indicated by the ability to successfully run api_test.c, a functional self-test included with the distribution.

Final acceptance testing will include a visual review of the source code for maintainability / completeness.

Legal / Licensing

Ocean Optics will retain all rights to use, sell, and distribute the modified code, either in compiled binary or source form.

Bid Process

If you would like to bid on this project, please provide a quote in USD and an estimated timeline for completion. Bid proposals can be emailed to Mark Zieg (mark.zieg@oceanoptics.com), and should include a summary of your experience with VxWorks and USB.

We will not be able to provide VxWorks licenses to outside developers, so can only be accept bids from developers with their own access to VxWorks development tools. Selected bidders will be required to sign a Non-Disclosure Agreement (NDA) before receiving a full copy of the existing driver source code and documentation.

If you require additional information about the project, please email us for details.