I am looking forward to implement some file operations on a USB device which will be plugged into a microcontroller-based bench-top device. The device does not have any OS/RTOS and only runs on a firmware code that I plan to develop.
The firmware will have all the necessary functionalities (UART, timer, SPI, I2C, external memory controller etc) that an embedded device usually has.
My questions are:
Can the libusb library be incorporated into the firmware that I plan to develop?
Does the libusb work in non-operating system based environment? Or will I have to choose an OS that I can port onto the microcontroller and then use the libusb library in user space?
libusb is currently only supported on Linux, OS X, Windows, Windows CE, Android, and OpenBSD/NetBSD. So yes, it does require an underlying OS. Unless your microcontroller is an ARM that can run Linux, it would not be possible to run libusb without porting the low-level code to your microcontroller hardware and making it work without an OS which would be a huge amount of work.
If you have a microcontroller with USB capability, it is very likely the manufacturer already has a library to access the USB functionality, and/or there are third-party libraries available.
Related
I would like to use a windows machine as a USB488/USBTMC device. USB488/USBTMC is a reimplementation of the good old GPIB/IEEE-488 on USB rails. But most articles on the topic refer to a Windows machine as a host/controller. The Windows USB stack is not well suited for USB device/USB OTG modes. However, if you look at some of the high-end gear like oscilloscopes and spectrum/network analyzers, it is well known that they are often Windows machines inside with some additional hardware. So, how it is done?
To some background: it is a project to retrofit a very old SEM microscope with new hardware. The current one is a 68k custom system with a CRT that uses a GPIB interface for comm with a PC. Things like sample spectroscopy are done as a BASIC program running on a pc and communicating through that gpib port. The plan is to replace that 68k junk with a modern day windows pc with an FPGA on a PCIe bus. For compatibility reasons, it would be nice to have a usb488 port in the new PC. Though I have no idea of how to do it properly. The only solution I have so far is to have some cheap USB-capable micro hanging on the SPI bus on the FPGA facing side and a USBTDM class on the USB side. But maybe Im missing something and there is a specific thing or chip that exists that can do it that Im not aware of.
I can only speculate how high-end oscilloscopes achieve it. The most likely option is that they use a dedicated chip like a MAX3420E. It is connected via SPI. Part of the USB protocol is implemented by the chip, part of it will be implemented by the oscilloscope software.
Most USB controllers chips found in PCs can operate as the host only. And even if they could do a role swap, Windows (for Desktop) has not supported device/peripheral mode until recently. It now does. See USB Dual Role Driver Stack Architecture. But I don't fully understand it to tell you what hardware you would need to purchase where this feature is enabled.
Role swapping is very common on smartphones. It is also implemented in Linux (search for "Linux USB gadget"). Many Apple Macs can run in Target Disk Mode, which is a USB device/peripheral mode as well.
I am currently trying to use LibUSB to directly access the firmware controller on a USB device. How do I directly download firmware off a USB device so it can be modified later (using either the SCSI commands or the LibUSB library)?
The closest thing you'll find to a standard here is the USB Device Firmware Update (or "DFU") protocol. However, there are a number of major caveats:
Most USB devices do not have updatable firmware at all. The majority of devices have their functionality fully defined in hardware, or in mask ROM.
Of the devices that do have updatable firmware, most do not use USB DFU to do so.
Even of the few devices that do support USB DFU, most do not support the "UPLOAD" command to retrieve firmware from a device. (It serves very little purpose in most devices.)
If you run into one of the rare devices that does fully support DFU, you may be able to interact with it using dfu-util. However, this is very unlikely.
I am fairly new to linux world, I have to develop an application on embedded linux which sends data over internet. I have to choose a USB 3G modem with a SIM card holder. I would appreciate if anyone can help me choosing a USB 3G modem which works successfully or is supported on embedded linux.
Thanks
Emby
I use Pantech modems with Debian ARM linux for real-time vessel tracking.
Linux can use the cdc_acm and ppp kernel modules to drive many of the USB modems on the market. You may need to compile these modules depending on how stripped your embedded platform is. Alternatively, you can use a turnkey system like a Raven or MultiTech, but they draw much more power.
Avoid USB modems that have additional hardware such as SD cards. These modems require specialized drivers (many unavailable in open source) to peel away the non-modem hardware layers before exposing the actual modem.
Use a modem that is supported by ModemManager, an OpenSource project that is in many major Linux distro's, no need to reinvent the wheel!
Supported Modem:
https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/
Project Source:
https://www.freedesktop.org/wiki/Software/ModemManager/
I'm looking to control a bunch of LEDs from my computer, with a TI MSP430 or similar.
My computer is a Macbook Air, and so it looks like the only port I can communicate with is USB. The MSP430 has a USB port, but I can't find any information about using the USB port for anything besides programming the chip. Is there a way around this, to use USB to communicate with the board?
Thanks!
If you are using one of the processors with built in USB hardware then you should look at this Texas Instruments Page which describes the capabilities of the MSP USB. It includes links to the USB software stack that you will need to implement an HID class device.
I see two more options here. You can also use:
a) USB <-> LPT adapter to control the LEDs directly — in this case the schematics are extremely simple. See how it's done;
b) USB <-> COM or USB <-> RS232 adapter to communicate with the controller via RS232 — in this case you'll have to implement some simple protocol for communication with the controller, but the whole solution would still be much simpler than the one with USB.
The MSP430 Series 5 and Series 6 micro controllers (i.e. MSP430x6xx and MSP430x5xx) have built in USB modules that allow communication from PC and could be used to control the MSP430 via USB. Download the MSP430 USB Developers package here: http://www.ti.com/tool/msp430usbdevpack and use the USB CDC or HID API stacks to develop an application as per your requirements. In case you are using CDC(COM port) you may use a Terminal program to send the commands to control LEDs or if you use the HID stack, you may use the hidDemo PC software included in the Developers package to send/receive commands.
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.