This query is related to configuring the Occipital Structure Sensor with the OpenNI2 SDK. The SDK has already been in use with the MS Kinect family of depth-sensing devices originating from the XBox 360 technology. The Structure Sensor is basically an overwhelmingly reduced version of MS Kinect/Carmine which is specifically built with the iPad in mind. However, the manufacturers have made it configurable with the OpenNI2 SDK as well.
I am trying to configure this device with the NiViewer provided as part of the OpenNI2 interface. Based on the quick start guide at the following link, the "UsbInterface=2" must be changed to "UsbInterface=0" in the PS1080.ini file and this step should allow the depth and IR streams of this device to work properly.
http://com.occipital.openni.s3.amazonaws.com/Structure%20Sensor%20OpenNI2%20Quick%20Start%20Guide.pdf
However, when the NIViewer is run, despite showing the device as connected, it does not stream any of the streams of this device. After a bit of trying, I found that it was possible to right-click on the NIViewer and manually enable both the (the depth and IR) streams. However, when this is done, the following error appears (for the IR stream attempt):
Failed to create IR Stream: XnOniDevice: Can't initialize stream of type 1: Failed to set USB interface!
Stream: couldn't create using source 1
Context: Couldn't create stream from device: 0237c220, source 1
Based on my own search, similar "failed to set USB interface" problems are reported for Kinect with MACOSX but the solution is not really specific to the Structure Sensor with the Windows 7 64-bit.
If you directly look into the XnOniDevice.cpp, it does show unavailability of streams being caught:
https://github.com/OpenNI/OpenNI2/blob/master/Source/Drivers/PS1080/DriverImpl/XnOniDevice.cpp
I reckon, a recompilation of source should not be necessary as this was not required for Windows-based systems. Any help in this regard would be highly appreciated. I'll report back if I found a solution to this issue.
After looking further into the editing details of the "PS1080.ini" file, I noticed that the solution to this problem was a simple one. The semicolons ';' in the INI file are basically used in commenting and that's where the mistake was. If you forget to remove the ';' before the "UsbInterface=0" command, the comment is basically ignored. Once saved, the Sensor works perfectly and both the Depth and IR feeds can be seen in the NIViewer window.
Related
I am working with a Zynq board where a custom AXI 4 lite slave peripheral is created and then added from the IP Repository. Then these blocks have been successfully connected with Run Connection Automation. Then bit stream was generated successfully.
Further the SDK was launched. There was a blank C project with simple code for the ZYNQ PS working already. This code was altered by following the pdf "Designing a custom AXI4 lite Slave Peripheral" (the one shown in the following image).
Write and read functions for the custom AXI slave peripheral
Now the SDK executes without any error but when I observe the addresses on SDK monitor, there is no data written into it (as shown in the following image).
Where could I have gone wrong or what have I missed?
Working with vhdl on Vivado 16.2.
What I have already tried: -processing with XSDB console with command
mwr -force 0x43C00000 0x01234
no change there.
Checked the Vivado Address editor to contain the same base address
included xparamters.h
Thank you very much in advance..
update: the xparameters.h file did not have the same base and high address as the vivado address editor. So tried with changing the 'memory region' in linker script to RAM from DDR enter image description here ,
now when observed in the 'variables' window, when clicked on 'Step Into' button, i do get the expected change in valuesenter image description here ..
The XSDB console output and Memory monitor output remain unchanged though.
The hardware platform specification file does show the custom AXI lite with the right expected base and high address.enter image description here
Hardware_platform specified
One of the reasons that were causing this problem was a different hardware platform associated with the debug configurations wrt to the one you want to use.
As we make some changes in the IPs and update them, when the bitstream is exported to SDK, a new hardware platform gets created . Say if the older one is TOP_WRAPPER_hw_platform_0, now a new one is created TOP_WRAPPER_hw_platform_1.
This new platform should be updated in the debug configuration settings Hardware platform.
further in debug config settings the following needed to be ticked on
Under Target Setup
Reset entire system
Program FPGA
Under Application tab
Download Application
Stop at 'main'
I'm studying Microsoft Toaster sample code from WDK7, and I find a subtle problem.
Now trying the compiled drivers(WDM busenum and WDM featured1) on Windows 7.
As guided by README, enum -p 1 adds a toaster device, then, I open device manager(devmgmt), find the device, Uninstall it.
This will destroy the toaster devnode(I believe); we can see that ToasterDevice01 node now disappears from Device Manager. !devnode 0 1 shows that the toaster devnode still exists, with State=DeviceNodeUninitialized (0x301), Previous State=DeviceNodeRemoved (0x312).
Then, I execute enum -p 1 trying to add the device again. But I got error 0x57(ERROR_INVALID_PARAMETER).
I debug the source code and identify the reason: buspdo.c does not distinguish between devmgmt's Disable and Uninstall operation. His code logic is:
If toaster gets surprise-removed(enum -u 1), it calls Bus_DestroyPdo() which is correct behavior.
If toaster gets Disabled from devmgmt, it does not call Bus_DestroyPdo(), which is also correct.
The problem is, when an end-user executes Uninstall from devmgmt, it follows the Disable path. Something bad now happens: Windows removes the toaster devnode, but toaster bus driver does not destroy the corresponding PDO, so, when next time user execute enum -p 1, the toaster bus driver Bus_PlugInDevice() blames that the toaster device with SerialNo==1 already exists and hence fail the user request.
BTW: Toaster's KMDF version exhibits similar problem(only static-enumeration version tried today)
Now my question is clear: How can I distinguish from Disable and Uninstall, shall I do it in bus driver or child device driver? Answer for KMDF version is also welcome.
Now I can make a conclusion. Our client driver can NOT distinguish between Disable and Uninstall from Device Manager. This is Microsoft's design.
To make the distinguishment, we need the help from application layer. Provide a CoInstaller for the child device, and, when the CoInstaller gets DIF_REMOVE notification(this results from devmgmt doing Uninstall), send an custom IOCTL(e.g. IOCTL_UNPLUG_MY_CHILD) to the kernel driver so that kernel driver unplug corresponding child.
I am working on a project that uses the Spartan 6 FPGA eval kit.
The problem I am having is that when trying to change the directory on the CF card, the software can't build the working stack.
The directory is "a:\\setup" and that is being passed to the sysace_chdir(const char *path) function.
When I try to add some print code to debug the problem, none of the changes are registered.
In the SDK, I have the MicroblazeProc_hw_platform, then my project, then a standalone_bsp_0 project, which has the sysace_chdir() function in it.
When I build all the projects, the simple print statements (I use xil_printf() for output) do not display in the output.
Any help would be great.
PS - I am connected to the FPGA in the SDK using a COM port, and other print statements do get output during the initialization of the other things like the UARTs, so this is not a problem with output to the terminal or anything.
I think I figured out what the problem was.
I inserted my card into a USB card reader and formatted it using a FAT32 file system.
As for the cnages in the BSP, I was not able to figure that out, but the code is now able to change directory.
The wierd thing is that after the code is executed, if I pull out the CF card and insert it into my pc, I don't see the newly created directory. I don't know why.
I've been searching around and can't find a solution for this. The official NVIDIA Tegra 2 Linux SDK (L4T) doesn't include both XRandR or the VideoMode X11 extension for querying available video modes. My next thought was to parse the log file for video modes. Of course most of the time it's at /var/log/Xorg.0.log but I'd rather not always make that assumption. The XF86misc extension provides a way to get the log path but that extension is also not installed by default.
So I'm wondering if anyone knows of any other way to figure out what video modes are available and also what the current video mode of the display is.
The core X protocol does not mention modes. You have to use extensions. There's nothing wrong with that, that's what extensions are for.
Also, remember that there's no guarantee that the machine you're displaying on is the same machine as you're running on, so parsing the X log file is destined to fail if your app ever runs across the network.
I am currently trying to build an application, that will talk to the super IO chip using port IO. As part of that, I am trying to develop a kernel-mode windows driver that I can contact, and which will do the IO for me. I have therefore downloaded the Windows Driver Kit v7.1.0, build 7600.16385.1, and I am trying to compile and install the sample portio driver, which is provided by WDK, since it seems to be quite close to what I need.
I have compiled the driver in both free and checked x86 XP build environments. This works fine, but when I try to install the resulting driver, using the provided instructions - which basically just amount to using the Add Hardware Wizard, and then supplying the files manually - I get the following error:
-The following hardware was installed: Sample PortIO Driver (KMDF)
-The software for this device is now installed, but may not work correctly
-Windows cannot load the driver for this hardware. The driver may be corrupted or missing. (Code 39)
So, I see two explanations: corrupted or missing. Missing, as far as I can tell, given my environment variables and .inf file, would mean that the generated .sys file is not in c:\windows\system32\drivers, but when I look there, the file is there.
So that would mean that the file is corrupted. Given that I haven't touched the driver code, and that I have found others with the same problem, it doesn't seem to be a problem with my compilation, but rather with the code itself, or some common combination of machine type and code. But I may be wrong.
Does anybody have any suggestions on how to solve this?
I would recommend enabling SetupAPI logging as described in the following document from Microsoft:
http://www.microsoft.com/whdc/archive/setupapilog.mspx
For Windows 7, the log files are split up as described here:
http://support.microsoft.com/kb/927521
You may be able to isolate the problem with the additional information in the SetupAPI logs.