Suppose I've a custom made hardware which is connected to the computer. I've my drivers installed to communicate with the hardware.Then how can I write an API through which i can access my hardware programmatically(As an example consider accessing oculus rift head mounted device using OculusSDK).Specifically how do i make my API communicate with device drivers to access the hardware using system call interface? If possible explain with an example.
Your hardware driver should implement a way of interracting with user.
E.g., it can be special file(s), which user can open (using standard open(2)) and then call read/write/mmap/ioctl for it. Each such operation actually triggers some driver code, which in case triggers some hardware request.
Related
I'm in the process of porting an application to ChromeOS with the requirement that it should look and feel as native as possible. This means in particular that it should allow things such as multi-monitor support and USB support.
One possibility would be to implement it as a web application (since we have already a web client), but in this case I would need to add support for native features (again, multi-monitor support and USB device access), so I wonder what needs to be done in this case. My wild guess as a ChromeOS developer newbie is that I would need to extend the code with ChromeOS JavaScript features, and I don't know if this is possible.
Another possible approach would be to write an Android application, since I see that ChromeOS added support for Android applications (in this case I would have to write the code from scratch).
Finally, another option would be to write native code, which could be possible for example relying on a Crouton development environment, and reuse the code of a native C application.
What approach would you recommend to build a ChromeOS application starting from a web application or from a native one?
What approach would guarantee access to native features (multi-monitor support and USB)?
I discovered two APIs which should help with multi-monitor support:
https://developer.chrome.com/extensions/windows
https://developer.chrome.com/apps/system_display
The system.display API allows one to discover and monitor the current monitor layout, while the windows API allows one to create several windows in the same application. By combining these ones I should be able to create a window for each monitor in case I go with the chrome implementation route.
Given that I already have a native implementation for Linux, Crostini (as opposed to Crouton) is also very appealing since it provides a deeper level of integration with virtually no changes to the code and no need to maintain two different versions of the web client, with the only downside that it requires the user to create a Linux environment and manually install the application, also it is not supported on all chromebook devices and on many it will be never supported.
I still need to check what is the performance overhead. Also the level of integration with USB I/O might be higher than the one achievable by using the chrome API.
I'm developing automated testing for software which needs to eject and reconnect USB devices automatically at the BUS level, not simply software.
This makes a virtual environment optimum because the virtual hardware can be controlled to emulate such behavior. However, I cannot find a way to do this programmatically through VMWare, VirtualBox, or Zen.
Is this kind of functionality implementable? Thank you!
using VSPhere API, it's soap based web service that can do the same thing as you using VSphere client.
there is a interface called: ReconfigVM_Task may be you can use, see ref at:
Vsphere API Reference
I've got a Windows 8 Professional device which has got a Mobile Broadband adapter embedded and I need to be able to send AT commands to the modem, usually I'd connect to the COM port and send the commands. However the device doesn't appear to have any COM ports, instead it presents its self as a network adapter.
I'm wanting to send AT commands to change the APN of the modem and to reset the device, I've looked into the 'netsh mbn add profile' but this command always returns an error advising that the XML profile is incorrect.
Also from looking at the functions of the netsh mbn it doesn't seem to provide as much control as sending AT commands.
The modem that I'm trying to interface to is the Ericsson C5621 GW on a Lenovo ThinkPad Tablet 2.
Is there another way to send AT commands?
Thanks
I do not know this product in particular, but since I worked in Ericsson, later in ST-Ericsson with mobile phone development for over a decade it is doomed to have some of my code in it so I'll answer on a general basis.
Short version is, no unless the device exposes a serial interface over one of the external interfaces (possible interface types are RS-232, IrDA, Bluetooth, USB or CAIF), there is no way of sending AT commands to it1.
Being an embedded device in a laptop and
your since you say it seems to be without serial interfaces I assume it uses CAIF (commonly used in embedded settings. It could also have be using USB with the serial interfaces disabled, but since this press release mentions that it will be available in a version with PCI interface, that is very unlikely). And thus unless the device is set up with any active VEI channels, there is no ways in for AT commands.
There might be other ways of changing the APN though.
1 We had a debug mechanism to inject AT commands onto arbitrary serial interfaces, but this itself was running on a serial interface, started by an AT command. And besides it will not be present in released products.
I have a local installation of Voxeo's Prophecy platform, and a voice xml application that runs on the voicexml browser of the platform. How can i call the application to listen to the message, without having a sip phone, and without using the voxeo's hosting capability? I just want to call the application at the local installation without using a phone. When i try this from the browser, i just get the xml file containing the dialog.
Why are you trying to start the application without a SIP phone? The developer version of Prophecy comes with a SIP phone that works great for testing and debugging. Are you trying to access the application from a regular telephone or POTS. If that is the case you will need additional hardware, such as a Cisco VoIP Gateway to translate the land-line signal to SIP. There are a number of VoIP Gateways available. Another option is to put Dialogic cards in your server and use a software that translates between SIP and the Dialogic API. If you purchase Prophecy from Voxeo as an appliance there are options they can sell you to achieve this. The advantage of getting this from Voxeo is that they will help configure it, which is not trivial depending upon the type type of telephone lines you are using and whether they are behind a PBX or not.
The telephony/communications interface to Prophecy is SIP so that is the only way to communicate with it. You could use any open source SIP stacks to develop something yourself, but the easiest thing to do is to use a software based SIP phone. It is not like you could just start talking and the VXML app would know what you intended, or if the if the voice input was really intended for the VXML app. You still need to maintain things like sessions and routing to the correct application which is easily handled by a SIP phone. Prophecy is designed for a telephony environment. If you are trying to use it for something like a home automation system, which some people have, I would think you would have to provide some type of SIP front end that is voice activated.
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.