I am trying to transfer the file via libusb to the USB device (pendrive). I have seen submit_bulk_transfer function in libusb-1.0.6 package. If there is a way to transfer the file then can you please suggest me. I want to transfer the file not as raw data.
It is possible, but you will need to implement Mass Storage, SCSI, and the file system that is used on the device in order to do so, which is a lot of work, and it is already done by the USB and FS drivers of all desktop (and many other) OSs.
See libusb FAQ.
BTW submit_bulk_transfer is a very low level functionality of USB, related to many device classes, not only Mass Storage.
Related
As far as I understand the USB devices introduce themselves by sending a device descriptor to the host which uses the information embedded in the descriptor to find and load the right driver/drivers. What I don't understand is why the drivers need the configuration, interface, endpoint and string descriptors from the device. I know the descriptors describe the device as a whole e.g. number of configurations, interfaces, endpoints, types, the size of the packets, the purpose of each byte in the packet etc. Why can't the drivers include this information from the start? Why does the USB device hold this information?
I guess the main reason is because it was designed that way. The designers could just as easily have gone the other way as you say.
Possibly more helpfully, I can think of a few reasons why they did decide on it this way:
Consider the context in which USB came about. PC peripheral connectivity was a mess. You had serial (UART) ports, PS/2 keyboard & mouse, parallel ports in various modes (e.g. ECP and EPP), game port & MIDI, the various SCSI variants, etc. Most of these did not allow for self-describing devices in a standardised way, demanding custom drivers for each type of device, and mostly manual driver loading. Device descriptors alone would mostly solve the problem of selecting the correct driver, but not necessarily the issue of needing a custom driver for each device.
Various standard device class specifications (e.g. HID, audio) define their own class-specific descriptors for communicating device variations to the standard driver. For this reason alone the generalised descriptor mechanism is useful.
Composite devices in their present form would effectively not be possible without standardised interface descriptors. You'd presumably have to make each composite device act as a hub with multiple devices attached.
Many (most?) standard device class specifications mandate a certain minimum number of endpoints where the standardised protocol is implemented, (e.g. bulk-only USB mass storage defines 1 bulk input and 1 bulk output endpoint) while devices are free to add more for vendor-specific extensions, or…
…future expansion of the standard device class or USB standard itself while maintaining backwards compatibility both ways (old driver/new device, new driver/old device). Think of UASP devices that fall back to regular bulk-only mass storage transport.
While not strictly necessary for making all those things happen, making devices self-describing in this way does seem to have been a success overall.
Many devices (cars, TVs, iPod Docks, AVR receivers etc) have the facility to access class compliant USB Mass Storage Devices and play wav files etc. stored upon them.
I understand I can use a small linux system with appropriate bi-mode USB host/ receiver ports (e.g. a Beagleboard black) to emulate a FAT32 mass storage device (a linux 'gadget') that can be plugged into a car and used as if it were a dumb memory stick - 'g_mass_storage'
http://www.linux-usb.org/gadget/file_storage.html
For static files this works fine. However, I would like to have the beagle board run a bluetooth receiver, decode the stream into PCM and then pipe this into a dummy.wav file that could be read (indefinitely) by the car (ipod Dock etc.)
E.g.
[Android or iPhone] --> [bluetooth a2dp] --> [beagleboard/ small linux system] --> [PCM audio]* --> [ g_mass_storage].'dummy.wav' --> [car's USB host]
The steps up to the * are trivial, but I can't work-out how to pipe data into a dummy.wav file as FAT32 doesn't support pipes and yet this is typically the only format supported by cars etc.
It seems something like this is at least conceptually possible:
http://www.dension.com/products/dbu
and 'cubund' on indigogo seems to be following the same principle (sorry can't paste second link as stackexchange won't let me)
I would have bought one if it had got-off the ground!
Any ideas?
Thanks,
Thomas
P.S. the first part of the chain (i.e. the phone via bluetooth) could be any mechanism and isn't particularly interesting. The challenge is to provide a virtual file that would enable 'streaming' of Google Music/ web radio etc. to devices only capable of reading files from a mass storage device.
It is already on the market for bluetooth. Check on ebay for bluetooth audio receiver. Is a little dongle that you can put in usb port and you may use it like regular usb drive.
Best regards,
Romeo
I'm looking for a way to exchange data between my own iOS app and my own OS X application through a cable.
I know there have to be frameworks to connect to the device from inside a Mac application, apps like iExplore can import and export files from the device.
It doesn't matter in which way the data is exchanged as long as it's through a cable. It may use the filesystem, or if I can get the device on the same network as the Mac through a connection or even use 3rd party hardware.
It doesn't matter if it uses private APIs or if the device needs a jailbreak, it is for internal use only.
Thanks in advance.
IMPORTANT: the solution can't feature anything wireless, no wifi, no bluetooth, no cellular tethering, the data exchange should work even with the device in airplane mode. This is the main requirement.
And it has to be relatively fast. I want to exchange small packages less than 1 kB once every few seconds. The delay between send and receive should be as little as possible, 1 second is the longest acceptable delay.
Take a look at https://bitbucket.org/tristero/ipodaccessframework which can get/put files into an applications private document directory, provided you know its application bundle id.
I have an external device that we manufacture that basically monitors 4 voltages, converts them to a 16 bit digital number then streams this info back to a PC every 100mS or so, using a serial over USB style chip. Basically a data logging system.
We would now like to collect this information on an iPhone and I am wondering what is the best way to get the data into the iPhone?
I am assuming there is no way we can physically connect directly to the iPhone dock connector as the protocol to do this is not available to iOS developers?
Obviously we could do it over a WiFi network but there will not always be one and we want to keep the external hardware fairly simple, i.e. no need for a computer or Wireless router etc.
If we add Bluetooth connectivity to our hardware would this work? I read that only 'Made for iPod' type Bluetooth devices will connect, in which case how can we achieve 'made for iPod' status? It would be relatively easy to add the necessary Bluetooth chips to get the system up and running.
In an ideal world we would like to do this without having to use a 3rd party interface.
I have been thinking about trying to digitise data as an audio signal – like a modem, and send it into the line input jack, but I don’t think it will be fast enough – this would be new territory for me.
Anyway all suggestions gratefully received!
Thanks!
ALSA or libusb api are two choices; both are new to me; its been years since I wrote a device driver and it was for Unix back in the 80's, but I do know I can figure out how, once I know what tools to use, which I'm guessing both use C still; I have looked at the libusb api; very nice; but I have no idea about ALSA project; seems they are geared into getting modules into the kernel to achieve this.
This is a generic question, but the Device I'm interested in is the Roland GR-55; it has MIDI and Audio from the same USB connection; it has Windows and MAC Drivers but no Linux.
Which libraries or tools do you prefer to use?
Do I write a Device Driver or Loadable Kernel Modules (LKM)?
libusb is useful and easy to get up and running. I would suggest that you start there, especially if you haven't written Linux drivers in a while. Use libusb to understand what the signalling protocol is for the Roland GR-55 and do some experiments.
USB supports several types of logical connections over the same physical wire. There will likely be DATA and CONTROL pipes available from the device and you will need to map that out before starting on a proper driver.
As I said, libusb is easy to get going and you could have something useful in a few days if you just want to write a control interface and store raw data from the device. However, ALSA is the way to go if you want to use the device with existing music software. Also, by updating ALSA you would be supporting the larger community because you could merge your work in to the ALSA project.
Writing a kernel module from scratch could be fun, but USB is a bit of a beast and would probably not be an ideal one to start with. With ALSA you will have a framework to guide you and won't need to worry so much about defining your own APIs.
As commented above, check out Linux Device Drivers http://lwn.net/Kernel/LDD3/ chapter 13 talks specifically about USB drivers. For development it's easier to write your driver as a kernel module because then you don't need to recompile the kernel when you make a change.
No need for writing a new driver - ALSA already has support for that since a while. See commit https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0ef283247a0cf0fd2e8370ee467030292eb3129e
Since you probably want to hear sound on your sound card, you should opt for ALSA. That way after you are done you are done. If you write libusb driver, then you would have to write your own user space tools for feeding that sound card sound for playing.