Related
Does anybody know any software (for win7 or winXP) that will allow me to capture or simply see data transferred between Firewire device and Application.
I wish to see data streams between my (ASIO) audio interface that works on firewire and my recording/mixing software.
Thank you
Yes-you need a firewire bus protocol analyzer. Look on ebay for CATC (Lecroy) FireInspector. There are a few listed recently, some reasonably priced, some not.
There is also Bushound (http://perisoft.net/bushound/) which allows for bus I/O analyzing on a pure software level.
I want to program a microcontroller (AVR) to control some leds through USB. It's just out of interest in how to build and program USB devices.
There are some AVR microcontrollers that support the USB protocol or I could implement the USB protocol in an another microcontroller myself, but I wonder what to use to write your own drivers on the computer.
My level in system programming: total noob (hence the question)
So what is the literature you people would advice to get good knowledge of the USB technology and how to write your own drivers and beyond?
P.S.: I know:
C (probably will need it here)
Java (probably won't need it here)
Python (hope can use it here)
assembler (hopefully won't need it here XD).
...
P.P.S: driver development differs for different OS's. I use Linux and Windows, so any material related to one or both of these systems is welcome.
Well, although you can develop and write your own USB driver, the beauty of USB is that you don't need to write your own driver. the USB Implementers Forum has defined class specifications for all the standard device classes. If you can make your device fit into a standard device class the driver has already been written for you!
If you truly want to become familiar with USB development, you should start by reviewing the USB approved class specification documents.
If you are into framework for AVR microcontrollers with hardware USB then take a look into LUFA, and if you are into AVRs with software USB then look into V-USB. They have both implemented many USB classes so you don't have to do it on your own - just use them.
That sounds like a great project! I'd suggest starting off with something a little simpler since you're - as you say - a "total n00b". I'm not sure what hardware you currently have (or have in mind) but what I would suggest for the total beginner is the STK500. It's a development board that's very well supported in both Linux and Windows and will give you the most flexibility. It comes with LEDs and switches built in for your projects, but you will need to get a microcontroller. And for that I recommend the ATMega32, a great multi-purpose IC that's also well supported and has lots of documentation on the web.
Once you get those I suggest you do your development on Linux using avr-gcc (make sure to also install avr-libc). If you're using Ubuntu it's easy to get all the packages you need:
% sudo apt-get install gcc-avr avr-libc avrdude
Those should get you up and running. I'd suggest Googling around for help writing your first programs but another good resource is the online materials for this class at Cornell.
That's enough to get your feet wet with AVR microcontrollers and the development tools. The sky is the limit at that point but since you said you want to get into USB I'd suggest using the excellent V-USB framework to have your ATMega32 act as a USB device. After that, as they say, the steps to flipping LEDs are a piece of cake :).
I wonder what to use to write your own
drivers on the computer
libusb (here, here and here)
wdk
WinDriver
For libusb variants info read this
You could us libusb. It's powerful and cross-platform.
But what you're trying to do is a rather simple control interface. You can sidestep most of the complexity by using HIDAPI, I think.
http://www.signal11.us/oss/hidapi/
HID devices often use generic drivers that come packaged into the OS. That way you don't actually have to write any drivers ever, you just make your device compliant with the generic driver and tailor the client software to it.
I think this is what's usually done in the hobbyist electronics field, which is what you're interested in here.
HIDAPI is even recommended for simple communications with HID devices in the libusb FAQ since its a bit more complicated to do it across platforms using libusb.
One good way to go is just to develop a HID device, since the driver is built in to most higher level OSes and pretty flexible for simple IO like you are talking about. Another good option is just using a USB RS232 device or software. I use PICs which have a number of nice devices with USB onboard.
I had built my own test bed based on the ARDUINO UNO and i was using the ionlabs programmer of type usbasp and it worked perfectly fine but it did not allow to convert the TTL back to Rs-232 and hence i couldn't use the features such as serial.print() and i had to install the ftdi cable which allowed me to do this.
The drivers were the libusb 1.xx working just fine.
If you want to program the AVR you can use the ARDUINO software bundle or the stino to upload the programs.
You need to know c(only basics).
I created a USB-keyboard adapter last year for my capstone. I did not do the host programming but used existing code that you can find on the web.But I did program the device side and for that I got a lot of help from this website Teensy Look into their "Code Library" which has code for Keyboard, Mouse and others. Also, the USB protocol handbook will always be useful and you should always consult it when you are doing stuff with USB.
I wonder whether your AVB acts as a host or device. I guess your board is a usb device and you need to light the leds on your board. So, it may be a good way to initialize your board as a HID device. To achieve this goal, you need a HID gadget software stack running on your board. References as follows:
gadget framework in uboot
HID specefication usb org
debug tools such as USB Protocol Analyzer
libusb running on Host PC to send packets
The Microsoft documentation area of the WDK (Windows Development Kit) is recently available on MSDN. There is a section on USB, though you would be best to read the earlier sections first, in particular the "Getting Started" areas. They assume you'll be using C as the programming language for driver development.
WDK Site
WDK - USB Section
For Linux, the Linux USB website should be able to point you in the right direction. In particular you'll want the Programming Guide for Linux USB Device Drivers.
I have been tasked to write a device driver for an embedded device which will communicate with the micro controller via the SPI interface. Eventually, the USB interface will be used to download updated code externally and used during the verification phase.
My question is, does anyone know of a good reference design or documentation or online tutorial which covers the implementation/design of the USB protocol stack/device driver within an embedded system? I am just starting out and reading through the 650 page USB v2.0 spec is a little daunting at the moment.
Just as a FYI, the micro controller that I am using is a Freescale 9S12.
Mark
Based upon goldenmean's (-AD) comments I wanted to add the following info:
1) The embedded device uses a custom executive and makes no use of a COTS or RTOS.
2) The device will use interrupts to indicate data is ready to be retrieved from the device.
3) I have read through some of the docs regarding Linux, but since I am not at all familiar with Linux it isn't very helpful at the moment (though I am hoping it will be very quickly).
4) The design approach, for now at least, it to write a device driver for the USB device then a USB protocol layer (I/O) would reside on top of the device driver to interpret the data. I would assume this would be the best approach, though I could be wrong.
Edit - A year later
I just wanted to share a few items before they vanish from my mind in case I never work on a USB device again. I ran into a few obstacles when developing code and getting it up and running for the first.
The first problem I ran into was that when the USB device was connected to the Host (Windows in my case) was the host issues a Reset request. The USB device would reset and clear the interrupt enable flags. I didn't read the literature enough to know this was happening, thus I was never receiving the Set-Up Request Interrupt. It took me quite a while to figure this out.
The second problem I ran into was not handling the Set-Up Request for Set_Configuration properly. I was handling it, but I was not processing the request correctly in that the USB device was not sending an ACK when this Set-Up Request came in. I eventually found this out by using a hardware USB protocol analyzer.
There were other issues that I ran into, but these were the two biggest ones that took me quite a while to figure out. The other issue I had to worry about is big-endian and little-endian, Freescale 9S12 vs USB data format (Intel), respectively.
I ended up building the USB device driver similar to UART device drivers I had done in the past. I have posted the code to this at the following URL.
http://lordhog.wordpress.com/2010/12/13/usb-drive
I tend to use structures a lot, so people may not like them since they are not as portal as using #defines (e.g., MAX3420_SETUP_DATA_AVAIL_INT_REQR 0x20), but I like them since it makes the code more readable for me. If anyone has questions regarding it please feel free to e-mail and I can try to give some insight to it. The book "USB Complete: The Developer's Guide" was helpful, so long as you knew what areas to concentrate on. This was a simple application and only used low-speed USB.
While writing a device driver for any interface (USB, Parallel port, etc...) the code needed to be developed would depend upon whether there is any Operating System(OS), RTOS running on that Processor/Micro controller.
e.g. if thats going to run say WinCE - It will have its own Driver development Kit , and steps to be followed in the device driver development. Same for any other OS like Linux, symbian.
If its going to be a plain firmware code(No OS) which is going to control the processor/microcontroller, then it's a different situation altogether.
So based on either of the above situation u are in, one needs to read & understand:-
1.) The Hardware Specification of the processor/micro controller development board - Register files, ports, memory layout, etc.
2.) USB spec
3.) Couple of pointers i found quickly. Google shud be ur friend!
http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/ - Linux USB device driver
http://www.microsoft.com/technet/archive/wce/support/usbce.mspx
-AD
I've used an earlier edition of USB Complete by Jan Axelson. Indeed very complete.
From the editorial review:
Now in its fourth edition, this developer's guide to the Universal Serial Bus (USB) interface covers all aspects of project development, such as hardware design, device firmware, and host application software.
I'm curious, why did you pick the 9S12? I used it at a previous job, and was not pleased.
It had lousy gcc support so we used Metrowerks
which may have been okay for C, but often generated buggy C++
had a lousy IDE with binary project files!
The 9s12 was also slow, a lot of instructions executed in 5 cycles.
Not very power efficient, either.
no barrel shifter, made operations that are common in embedded code slow
not that cheap.
About the only thing I dislike more is an 8051. I'm using an ARM CortexM3 at my current job, it's better than a 9S12 in every way (faster clock, more work done per clock, less power consumption, cheaper, good gcc support, 32-bit vs. 16-bit).
I don't know which hardware you're planning to use but assuming that's flexible, STMicro offers a line of microcontrollers with USB/SPI support and a library of C-code that can be used with their parts. -- I've used their ARM7 series micros for years with great success.
Here is an excellent site maintained by Jonathan Valvano, a professor at the University of Texas. He teaches four courses over there (three undergraduate, one graduate), all are about using a 9S12 microcontroller. His site contains all the lecture notes, lab manuals, and more importantly, starter files, that he uses for all his classes.
The website looks like it's from the 90's, but just dig around a bit and you should find everything you need.
users.ece.utexas.edu/~valvano/
Consider AVR for your next MCU project because of it's wonderful LUFA and V-USB libraries.
I'm working on a project using the Atmel V71. The processor is very powerful and among lot's of high end connectivity offered on chip is a USB engine that will do device or host modes for 480 Mhz or 48Mhz (not USB 3.0). The tools are free and come with a number of host and device USB example projects with all the USB stack code right there. It supports 10 end points and all the transfers are done via DMA so you have most of the processor horsepower available for other tasks. The Atmel USB stack works without needing an RTOS
I'd like to have an application monitor written in C# monitoring a set of Forex trading positions. It would be connected via USB to a real set of "traffic lights" sat on a desk which it would use to indicate system status. Can anybody suggest a good solution?
Normally I'd say parallel port or some other such thing, but if you've got your hopes up for USB, then definitely have a look at the Arduino. It's a very low cost microcontroller that can run standalone, or can talk to a PC through a number of flexible interfaces (including USB).
It is extremely popular with the hobbyist community, and as such, there are a number of entry-level projects to get one started with the device. Price on Sparkfun is $35 USD for a fully assembled USB-enabled version.
I have used the concepts in this CodeProject article to successfully light up LEDs.
It might meet your requirements if:
You can use parallel port instead of usb (or maybe usb to parallal cable/dongle)
You are ready to tackle some soldering and simple electronic tinkering
You can modify the vb code to monitor your status
As the author mentions in the article, you can destroy your computer's parallel port (and worse!) if you are not very careful.
In addition, a good engineer would insist that you isolate the lights from the port to further protect the computer. (relays, triacs, opto isolators, etc.)
That being said, it does work!
The easiest solution is to buy a USB traffic light, rather than building one yourself. E.g. USB Ampel. With a simple API included, it would probably be much easier.
Traditionally people have used the X10 automation framework for this kind of thing. People at my company use it to control lava lamps to indicate the status of our continuous integration build.
There's a pointer over at How does one get started writing applications that interact with x10 protocol?
One step further is to build something yourself using a microcontroller platform like the Arduino. Some examples of what is possible with the Arduino platform are available on the Arduino Playground page.
An article on how to make traffic lights using an Arduino is available at Instructables.
Channel9 has a video from the Microsoft PDC showing how some developers use a "Build Bunny" for something similar: PDC2008 ShowOff Entry: Brian the Build Bunny
There's also more information and source code here.
Try using simple usb experimentation interfaces such as Phidgets (Www.phidgets.com) or the Velleman k8055 USB experimentation board (http://www.velleman.be/ot/en/product/view/?id=351346).
We used this product at my last job to control a set of revolving traffic lights when a build would break on our CI server. The Ethernet is nice so that you are not limited to the 3M range of USB and it is as easy as opening a TCPClient to port 10000 and sending a "1R1\r".
http://www.6bit.com/products/smartrelayE.php?products_id=33
I'm just starting to design some embedded devices, and am looking for resources.
What I want to be able to do is to connect a GPS receiver to a lightweight SBC or mini-ITX, x86-based computer, and track a remote-controlled vehicle's location/progress.
Ideally, this could morph into building some hobby, semi-autonomous vehicles.
But what I need to start with is a development board for GPS programming.
What boards/packages have you used, and where can I find [preferably open source] development for them?
OpenEmbedded is a good place to go to get started. A lot of embedded products use ARM and other processors, so cross-compiling is a big deal. Buildroot is another resource for building custom linux kernels for small systems.
You can also find lots of manufacturers with Single Board Computers (SBCs) that have tools to do what you want - do a google search for "SBC Linux" and you should have a gold mine.
LinuxDevices keeps a pulse on the linux embedded community and you should find several good articles there that lead you to products or software to help you.
Debian has an embedded build, but I haven't explored that.
There are several books on embedded linux available if you want to go that route.
The GPS receiver simply connects to a serial or USB port, and present an NMEA stream of data, which you can parse with GPSD and several programs can access it through GPSD. It's a very simple text based format.
I've used regular PC motherboards, and Atmel AT91 processors for embedded systems (with GPS, cellular, etc). There's a lot of information out there right now, and it's not expensive to get into. If I were to start a new project, I'd look at the AVR32 processors from Atmel - they are very hobbyist friendly, and provide a lot of community support for linux on the AVR32 architecture. They provide free GCC compilers and significant framework and examples if you want to go the OS-less route and have a single program running on the processer as well.
Good luck!
-Adam
"NMEA" is the keyword to be searching for when looking for this stuff. While I haven't done anything with this in a long, long time, here is a good source for some boards and other hardware:
http://www.sparkfun.com/commerce/categories.php?c=4
We have had good luck with Holux GPS recievers (designed for samsung q1). A farily simple connect over serial port and you can read the NMEA string.
What OS are you targeting? If it's Linux there are a lot of GPS libraries available (here's a good list). GPSd and GpsDrive are two of the more popular ones I've seen.
I haven't see any GPS devices specifically for lightweight/embedded use, but many of the consumer GPS devices have USB hookups available that could probably work (watch out for low end ones, they usually don't have the computer interface).
I suggest starting with a plain old c project that reads and parses NMEA from a serial port. You can do this in Windows or Linux.
I usually break down any project like this into a set of smaller projects like:
read and parse NMEA from serial
port
establish a serial /
network link from the remote device
to the tracking system server
integrate the components
Wikipedia has a good article on the NMEA protocol. As Adam points out it's actually pretty simple.
Circuit Cellar magazine often has projects like this as well.
Depending on what you want to do, there are various sizes of target to consider. Use Atmel AVR for small low power (battery) stuff. Perhapse use Linux on an old laptop if I just wanted to rough out the concept and needed WiFi (or cellular) for internet.
The laptop Linux prototype then could be trimmed down and ported to an embedded Cinux system for even lower battery usage and portability later on. (not as low as Atmel though).
If you are comfortable with programming in Linux I would recommend the Gumstix range of small computers - http://www.gumstix.com/
You could pair the vedex motherboard with the GPSstix expansion board tp make a tiny GPS receiver with a well supported programming environment.
I suggest GPSBabel to communicate with your GPS receiver.
GPSBabel
Handles waypoints, tracks, and routes,
Knows lots of format (this explains the name Babel),
Runs on Windows, Linux, OSX,
Free.
Some people here have suggested devices like the gumstix - embedded devices which cost $149 without GPS. I don't understand that bit. A off-the-shelf TomTom comes with running Linux on ARM, built-in GPS, lots of flash, battery and screen. It's hard to beat the price advantage that comes with mass production. For your hobby project, the map included is not needed, but who cares?