I am plannig to use usb connection to let PC communicate with my equipment based on STM32F373VC.
I tried the CDC class using the example in STM32CubeF3 V1.9.0 by removing the uart peripheral management.
PC detects a usb device with vid:pid 0483:5740. Linux automatically recognizes CDC class (STMicroelectronics STM32F407), loads the cdc_acm module, and the ttyACM0 VCP is created. I don't know about Windows, but reading the readme of the example it seems that a driver should be installed.
I have some questions:
Can I use VID:PID 0483:5740 for my product?
Does the various versions of Windows automatically recognize the device (and associate it with the CDC driver) or is it really necessary to install a driver?
If I can't use these VID:PID, can I ask ST for a PID assigned to me for small productions (as other silicon vendors do)?
Could ST assign me a PID that the various versions of Windows, Linux and Mac automatically recognize as CDCs without needing to install drivers or configure anything?
If not, do VID:PID pairs exist that are automatically recognized by the various versions of Windows, Linux and Mac as CDC class without needing to install drivers or configure and that I can legally use for my small production?
About drivers recognizing your device:
If your device is of class CDC, driver should be able to be loaded no matter what VID:PID is used (as long as selected VID:PID is not assigned to other device that has device specific driver). For Windows please refer to this document.
You should be able to test Linux CDC class driver by altering device descriptor in your device library code (which should be possible, if I correctly understand available ST documentation).
About having your own VID:PID:
There is some thread on github about this here. It should cover all possible options including the ones you asked about.
Related
I want to read the GPS data from my android phone inside the kernel space. I want to write a device driver for my GPS and request data through it. But unlike external devices I could not find the Vendor Id and device Id of the GPS hardware or the SOC on which it is installed. Can someone help me with how to collect the details required for writing the driver?
Thanks.
You already have found one of many problems with SOC and device drivers. Therefore another approach is used in the linux kernel: Platform driver and Platform devices. You wont need any Vendor IDs and such stuff.
I recommend you to read some tutorials and get started with it:
Readme: https://www.kernel.org/doc/Documentation/driver-model/platform.txt
Code example for CAN: https://github.com/torvalds/linux/tree/master/drivers/net/can/ifi_canfd
Disscussion about difference: What is the difference between a Linux platform driver and normal device driver?
Sadly I am not able to answer your questions on how to get those id's.
My goal is to create a virtual USB char device (not block device) for Linux 2.6.32 and above (I use debian squeeze) that would be recognize by the system.
I would like that this device be listed with lsusb as a normal USB device, and that every application could use libusb in order to open the device, and send control message, and make bulk write/read. But behind this virtual device, it's behavior would be set by my application. I want to set it's product ID, it's vendor ID, answer to USB status, and bulk read.
I've read some posts about how to use USB/IP in order to create a virtual USB device, and that's exactly what I want to do
Installation and emulation of virtual USB Device
http://breaking-the-system.blogspot.fr/2014/08/emulating-usb-devices-in-python-with-no.html
But unfortunately, when I tried with 2.6.32 kernel and above, I didn't succeed making it work. So I looked at how to create a kernel module that would create the virtual device :
http://pete.akeo.ie/2011/08/writing-linux-device-driver-for-kernels.html
This one looks great also, but the sample provided doest not indicate how to make it an USB device.
I've seen some post talking about it with windows but none that could help me with Linux.
I would like to avoid buying some USB programmable cards when it can be done with software.
Have anyone any leads on how to make the first methods works under newer kernel, or convert the sample code of the second method for making an USB device ?
I have fixed the code of http://breaking-the-system.blogspot.fr/2014/08/emulating-usb-devices-in-python-with-no.html (first method using USB/IP) to work with linux 4.3.
In the original code are missing USB requests like set configuration and get status. Without the implementation of all USB requests used for the OS driver the code will not work.
The fixed code can be downloaded in https://github.com/lcgamboa/USB-Emulation .
I guess raw-gadget kernel module is the thing that you want?
you can check the dummy_hcd and tests directory inside the repo, it will guide you how to create a virtual USB device
I'm trying to write a Linux character device driver for a device that just happens to communicate over I2C. The device is an Atmel microcontroller with code that provides an I2C address. It already works using the typical i2c-dev method on the Linux-side.
So now I want to replicate i2c-dev as a new driver that works specifically with this particular device, so that I can add some of my own device-specific abstraction code on top. But I'd like to trim out all the unnecessary code from i2c-dev that currently makes it generic. What can be removed in this situation?
What can be removed in this situation?
You're actually asking an XY question.
You would be better off looking at and adapting an existing I2C device driver that is already similar in required functionality, rather than hacking a special case driver for userspace access.
So now I want to replicate i2c-dev as a new driver that works specifically with this particular device, so that I can add some of my own device-specific abstraction code on top
So then you actually need to write a "Client driver" as described below (from Linux Documentation/i2c/summary):
When we talk about I2C, we use the following terms:
Bus -> Algorithm
Adapter
Device -> Driver
Client
An Algorithm driver contains general code that can be used for a whole class
of I2C adapters. Each specific adapter driver either depends on one algorithm
driver, or includes its own implementation.
A Driver driver (yes, this sounds ridiculous, sorry) contains the general
code to access some type of device. Each detected device gets its own
data in the Client structure. Usually, Driver and Client are more closely
integrated than Algorithm and Adapter.
Details are in Documentation/i2c/writing-clients.
To find a driver of similar functionality, scan the list of I2C client drivers. Note that these I2C drivers are located in the Linux source tree by their functionality (e.g. drivers/rtc/ or drivers/hwmon/) and not their interface (i.e. I2C).
I've been involved with a project where I have to install and use a USB GPRS modem on an ARM board (RSC-W910) with Windows CE 6.0 installed.
The modem is the Sierra Wireless product GL6110 (GL61x0) and I need to use it only for data, making HttpWebRequests (TCP) send/receive XML data. Prefered development tool is C# and .Net Framework 3.5.
When the modem is connected via USB to the board, the error message that appears is saying "Unidentified USB Device" which I believe its normal.
Siera Wireless(SW) provides a driver for ARM920, but it failed to install using 'wceload.exe'. The error was "Setup Failed" that I could see on the small LCD screen attached to the board. To install the driver I connect to the board via Telenet and CAB file is stored on SD card.
Am I right to think that the failure to install the driver could be related to the fact that the Win CE image has RAM-based Registry?
If SW does not provide a driver for the modem, could this mean that I have to develop my own driver? or is there a generic driver that I can use instead?
Will I have to create a new Win CE image for the board to support the modem, or is it possible to use code within the C# application to access it?
Any help will be very much appreciated!
Thanks,
Nick
There's no generic driver, no. Sierra modems generally have CE support (I'm not checked this model, but it's likely to work). What you need is:
A Driver DLL, build for ARM and for CE 6.0 or 7.0 (the CE 5.0 driver model differs, so a CE 5.0 driver probably won't work)
The registry entries the device.exe looks for when the device is enumerated
These sometime come in a CAB, sometimes not. Generally I prefer it when they don't but either will work.
If the CAB file fails to install, it's probably because it's marked for some other platform. I'd use something like WinZip or WinRAR to pull it apart, rename the DLL and extract the necessary reg entries (depends on the CAB format how easy/hard this will be).
Generally, though, you need to copy the driver DLL to the \Windows Folder, then apply the registry entries. Then when the device is plugged in, it will read the registry, which will point it to the DLL, which is then loaded. "Unidentified USB device" typically means the registry entries were not found.
This can all be done without rolling a new OS image, though sometimes a new image is simpler than doing the necessary copying at startup, especially if the device is plugged in at boot.
The Silicon Labs CP210x chip allows the PID to be customized which in turn means a customized driver is needed to have a matching PID. On x64 systems that require driver signing using a customized driver would also require signing that driver. Fortunately it is possible to use the original signed CP210x driver by manually select it for the device as explained here.
What I would like to know is if it is possible to use DPinst or some other method to automatically have the original signed CP210x driver selected for the device during install or when the CP210x device is plugged in?
As an option you can write a service that will be monitoring for device changes and install a driver for CP210x.