It is possible to use a tty device like a chardev device in kernel module?
I would like to write a kernel module to control some electronics connected by USB port and registered as /dev/ACM0 in Linux. I like to do it the easiest way. So, I would like to treat a tty device like a chardev device and send something like a letter for example to light a diod. It is possible and how can I do it?
A tty is character device, and in order to implement char device you need write a kernel module, its a bit tricky for linux beginners.
As you stated
I like to do it the easiest way
and
control some electronics connected by USB port
I recommend you to use libusb, its more easier to implement USB drivers with libusb, its cross platform and have lots of documentations.
Related
When I do lsusb, I get:
Bus 020 Device 013: ID 03f0:7d04 Hewlett Packard Deskjet F2100 series Serial: CN76R3R53Q04TK
How can I associate it to a file in /dev?
Adding a file-like handler to a USB device is job of a kernel driver.
In general, however, printers don't need a kernel driver. They usually just do bulk USB transfers, which you handle with libusb, and that works without an explicit /dev/ entry describing exactly your printer.
Depending on your OS, libusb's communication with the USB stack of your kernel will look different (and I'm not overly versed with OS X), but there's probably something like a /dev/bus/usb/20/0/13 or so; really depends.
Anyway, unless you want to write a CUPS printer filter, you probably don't want to interfere directly with the USB device, but let your printing system do that.
So, TL;DR: That's a printer. It usually does not have a /dev/ entry on its own. Use libusb to communicate with USB devices on a USB packet level.
I have developed a USB device that communicates with linux over a simple but proprietary interface and some custom Linux drivers. My goal is to port this to Windows without writing windows drivers. What I would like to do is find an open source or inbuilt class driver for windows that would look like a COM port in Windows. Then I would tailor the embedded software to match what ever protocol and descriptors the virtual COM port expects to see.
The idea would be that I could plug my device in to a Windows machine and a relatively high speed COM port would appear with out me having to develop Windows drivers for it.
I have been looking at the USB CDC (Communications Device Class) documentation and it looks promising, but I don't know which sub interface would be best to use so that it would show up as a COM port.
Has anyone here done any work like this before or could provide some insight?
Specifically:
Are there virtual COM drivers "built in" to windows or would I need a 3rd party driver.
Which CDC sub class should I use for simple RS232 emulation (No need for modem AT commands, etc)
Is there a better option to do what I am trying to do.
Thanks
There is a USB-to-serial driver built in to Windows that will do what you want. It is called usbser.sys:
http://support.microsoft.com/kb/837637
You will have to write an INF file and distribute that to your users, but that will not be too hard because it is only a few kilobytes of text and you can find examples online.
I'm not aware of any great documentation for this driver by Microsoft, so my advice would be to find some other device that uses it, such as Pololu Wixel, and copy what they did.
Here are the device descriptors we used and the special control tranfers we had to implement:
https://github.com/pololu/wixel-sdk/blob/master/libraries/src/usb_cdc_acm/usb_cdc_acm.c
You can see our INF file, wixel_serial.inf, by downloading the software and looking in the drivers folder:
http://www.pololu.com/docs/0J46/3.a
(There are other files in there that are not necessary for you.)
You can also look at the Arduino Uno because they use the same driver.
Whatever you do, please don't use our USB Vendor ID in your product! You need to get your own.
Update: In Windows 10, you don't need an INF file anymore because of the new usbser.inf driver that comes with Windows.
If you are using a UART you can easily interface it to a FTDI USB chip like http://www.ftdichip.com/Products/ICs/FT232R.htm or a Prolific like http://www.prolific.com.tw/eng/products.asp?id=59
For development, prototype and testing I have half dozen of these laying around http://www.pololu.com/catalog/product/391
I connect it directly to the UART pins on AVR and 8051 micros.
I have a USB web camera from ViMicro that contains a GPIO chip. We have a microswitch wired to one of the IO pins and can read the status of the switch on Windows using an ActiveX control that was provided by ViMicro, named exvmuvc.ax. I need to duplicate this functionality using IOKit on OS X.
USBTrace from SysNucleus displays the conversation happening between the Windows system and the USB device, but I cannot duplicate this on the Mac.
Does anyone know of a software USB sniffer, like USBTrace, that works on OS X so that I can compare the packets? Also, is anyone familiar with this particular camera chip and its GPIO subsystem, even on Linux?
You could use usbtracer from Xcode, or you can try using using USB Prober with a debug release of IOUSBFamily, this will most likely output more information than you actually want. You may want to look at qa1370 for more information.
In general though, I'd recommend you get a hardware USB analyzer, they make this sort of thing much easier.
We are creating small system which has GPS receiver and PC. We want to test my GPS receiver, We do not want to go for a driver on the first go. First I would like to test my circuit works or nor. GPS IC has been set to output NMEA sentence. We want a program which just reads data from USB port and print it on the screen.
Can we write something like this easily ? Do we have any open source tool which will achieve this purpose ?
Platform : Windows 7
All devices need a driver, so I'm going to interpret your question as "how can I read NMEA data from my GPS using only drivers provided by the OS, so I don't have to write my own?"
If the GPS chip has a USB interface, then you should have gotten a driver with it. But most GPS chips have a UART interface which in your case sounds like it is connected to a separate USB-UART conversion chip. That conversion chip most likely came with a driver as well, but if not, you could jumper the reset pin of the converter chip, disabling it, and then attach a TTL/RS-232 level converter (available off-the-shelf) to the UART traces and then to your computer's serial port.
Unless you suspect that the driver for the USB-UART converter is causing problems, I wouldn't bother.
Anything connected via USB is a device. Devices require a device driver, period.
You might be able to get away with an existing driver built into Windows. This is how USB memory keys work for example - they present a generic device that looks like a removable disk, and Windows already includes the drivers for generic removable disks.
You would need to check the documentation for your device to see if it can emulate a device which already has drivers. Otherwise you must install the company's drivers, or you're out of luck.
Have a look at libusb. You should be able to read the data with that and a little code. (Yes, it's a driver. I take the question to mean "without writing a driver".)
You need a device driver for your device. Unless Windows already have a class driver for the device.
For USB devices on Windows 7 you can write a user-mode driver, see UMDF.
How can I create a virtual HID device in code? I'm trying to avoid writing a kernel extension to accomplish this, but it seems to be the only way. I need to be able to create virtual HID devices of all types, and have an app running in the background feed them events. Is there a way to do this in user-space, or must I venture into kernel land?
The typical way of creating HID devices is to use the IOHID* classes in IOKit. You can write a userclient that passes events in and out.
I'm not sure what a "virtual" HID device is, however, I guess. If you want to create a keyboard on the screen, that sort of thing can probably be done in userspace.