Category: programming

TL:DR

Live Debugging

Get a Full list of Supported Drivers

Testing a Specific Driver File

Testing Host and Sub Devices

Live Debugging

Due to the open nature of our driver system, it’s relatively straightforward to write a new driver file for almost any imaginable device in Nebula. However, driver development can be a pain, so I though I’d share some debugging tricks.

For all commands, we will navigate to the command line using windows Command prompt or powershell. Here I show command prompt syntax. Nebula is commonly installed under program files. So in the windows start bar type “cmd” and press enter. This should open the command prompt. The commands below navigate to the install location.

cd

c:>cd "Program Files"

c:Program Files>cd Nebula

c:Program FilesNebula>

First, is the use of logging to the command line. When Nebula is launched from the command line, a series of optional switches can be used to report logged output. By opening this alongside the app, it’s very fast to figure out what or where something is going wrong. To see log output, use –printlog.

c:Program FilesNebula>Nebula.exe --printlog

This launches the app, but shows a live log output on the console at the same time.

Get a full list of Supported Drivers

This command will return a complete list of drivers found in the Nebula supported list. To print this list, use:

c:Program FilesNebula>Nebula.exe --listdrivers

Here is live example of that command and the expected result. A list of drivers is shown, press enter to close the listing.

Testing a specific Driver File

Next, let’s load up one of these drivers in the test utility. Now, this is where things get cool! The test utility can load a host device driver, inspect it’s shown devices, attempt to connect them, and even test every sub-device!

So, let’s assume we have a new camera driver we want to work on. The camera should do things like snap an image, show various properties etc. In my example I use a real UVC (web) camera, and inspect the driver. The driver actually pulls the real camera info and even snaps a test image. The goal of this function is twofold, first to validate a given driver, and second to validate the device itself.

For this command we will use –testdriver *drivername* and optionally –port *portname*, for example, COM5

c:Program FilesNebula>Nebula.exe --testdriver --driver UVC_Camera

Here we can watch the expected output in real time. Note a new window is spawned to show us the results for these tests.

Testing Host and Sub Devices

Let’s say we have a controller, for example, an ASI or Marzhauser box, which has a Z motor attached. In Nebula, the controller can be thought of as the Host (the resident controlling brain), and the device can be considered an appendage attached to the host. So all drivers must have a Host, but a Host may only have one device. In this example, we use a demo Focus device. First the host is loaded and analyzed, and then, you ca select to test any device provided by that host. I choose option # 1 (focus) and the test runs, even showing my driver has a small error I missed!

Obviously, if you have a driver which isn’t behaving, please contact us – yet I hope these options provide a first-line of interface for power users, so simple things can be corrected and analyzed quickly!

-Austin

The post Starlyte Nebula Driver FAQ appeared first on AustinBlanco.com.